SSL Automation
FortiGate
The certificate on a FortiGate usually sits on the SSL VPN and on the admin interface. Those are the two places where an expired file is found by a user who cannot get in.
Replacing it by hand touches the access you use yourself
A new certificate has to be uploaded, bound to the SSL VPN and possibly to the admin interface. The SSL VPN holds the certificate in memory, so the binding has to be moved away and back before the new file is used. It is a few minutes of work, and it sits on the device where you least want to make a mistake.
What the generated setup does
From FortiOS 7.6.3 the FortiGate speaks ACME itself, with External Account Binding. The wizard writes the configuration block with FairSSL as the ACME server, your EAB key pair and the domain name the certificate should cover. The device stores the ACME account internally and renews on its own.
- Creates a local certificate object with enrollment set to ACME.
- Points at the FairSSL ACME server and uses your EAB keys.
- Sets how many days before expiry the device should renew.
- The object is bound to the SSL VPN and optionally to the admin interface.
Where the certificate ends up
As a local certificate object on the device. You bind the object to the SSL VPN, and the same object can be bound to several services. Every binding on the object picks up the renewed certificate without the binding being touched again.
What to know in advance
ACME with EAB needs FortiOS 7.6.3 or newer. Earlier 7.6 releases have ACME without EAB, which cannot be used against a commercial CA. The built-in client is meant for a single FQDN, so wildcards and multiple SAN names go through a host running Lego or simple-ACME that pushes the certificate over the device API. FortiMail has no built-in ACME client. FortiWeb has one from 8.0.3.
Guides for this platform
Supported versions
The wizard in the control panel is written for these versions. If you run an older version than the one listed, ask us before you order.
| Platform | Versions | Runs on | ACME client |
|---|---|---|---|
| FortiGate | VersionsFortiOS 7.6.3 and newer | Runs onThe device itself | ACME clientThe device’s built-in ACME client with EAB |
| FortiGate | VersionsFortiOS before 7.6.3 | Runs onWindows Server 2016 or newer, or 2012/2012 R2 with WMF 5.1 (PowerShell 5.1) | ACME clientsimple-acme 2.4.0+ (FairSSL edition, .NET 10 included) + Posh-SSH, CredentialManager |
| FortiGate | VersionsFortiOS before 7.6.3 | Runs onA Linux server that pushes the certificate to the device | ACME clientlego 5.0.4+ |
| FortiMail | VersionsThe guide sets no version limit | Runs onWindows Server 2016 or newer, or 2012/2012 R2 with WMF 5.1 (PowerShell 5.1) | ACME clientsimple-acme 2.4.0+ (FairSSL edition, .NET 10 included) + Posh-SSH, CredentialManager |
| FortiMail | VersionsThe guide sets no version limit | Runs onA Linux server that pushes the certificate to the device | ACME clientlego 5.0.4+ |
| FortiWeb | VersionsThe guide sets no version limit | Runs onWindows Server 2016 or newer, or 2012/2012 R2 with WMF 5.1 (PowerShell 5.1) | ACME clientsimple-acme 2.4.0+ (FairSSL edition, .NET 10 included) + FortiWeb REST API, CredentialManager |
Validation without opening anything inbound to the server
An ACME client that validates over HTTP needs port 80 open inbound to the server. A client that validates over DNS needs an API key for your DNS provider, and that key then sits on the server with write access to your zone. Internal servers and appliances rarely allow either.
The one CNAME you create per domain
_dnsauth.<domain> CNAME <hash>.autodns.fairssl.dk
You create it once per registered domain. FairSSL writes the CA validation record in our own zone, and you do not touch your DNS again at renewal.
One record per domain
Wildcards, SAN names and new subdomains on the same registered domain all use the same CNAME delegation.
No DNS keys on the server
The client never gets access to your DNS zone, so a compromised server cannot change your DNS records.
Outbound HTTPS, no inbound rule
The server has to reach fairssl.dk over HTTPS. No inbound firewall rule is needed, and the server needs no public address.
What is monitored once the client is running
An automation that stops without saying so is worse than a renewal in the calendar. We measure both the certificate and the client that is supposed to renew it.
Renewal window checked hourly
We ask the CA over ARI when the certificate should be renewed and check every hour. If the CA does not answer, we fall back to 21 and 7 days before expiry.
The client stops reporting in
If a client halves its check-in rate we raise a warning. A certificate can stay valid long after the client that was going to renew it stopped running.
Whether the install succeeded
The Windows client reports the result of the install back. A certificate that issued but was never bound to the site counts as a failure.
Email alerts per profile
Alerts are configured per profile, so operations and development can be notified at different addresses.
Monitoring API
Status is available as JSON, or read directly by PRTG and Prometheus, so the certificates appear in the monitoring system you already watch.
Certificates without automation
Certificates that do not run automatically get expiry mail 28 days and 7 days before expiry.
What the automation costs
The fee is charged per main certificate, per year, on top of the price of the certificate itself.
A shorter lifetime means more issuances per year. The number of issuances does not change the price: you pay for the certificate under management, not per renewal.
- Up to 25 servers using that certificate are included in the fee. Each of them gets its own reissued certificate.
- Reissues cost nothing extra.
- Changing the SAN names on the certificate costs nothing extra.
- Additional ACME clients using the same certificate cost nothing extra.
A second certificate is priced on its own: its own certificate price plus the fee for a year.
Worked example and price details →From order to a certificate that renews itself
Step three is the one a generic ACME guide does not have: the setup is written for your platform.
- 1
Order the certificate in the control panel and turn automation on for it.
- 2
Create the CNAME delegation for the domain. Once per registered domain.
- 3
Pick your platform in the wizard. The portal writes the setup command with the account key and the domains filled in, and you copy it with one button.
- 4
Run the command on the server. The client fetches the certificate, installs it and renews it on its own from then on.
We package the Windows client ourselves and rebuild it daily. Linux and macOS use stock lego, which the generated command calls. Download the Windows client
Get started in the control panel →Support by email and phone is free before, during and after the installation. Remote installation is a paid add-on at a fixed price.
Find your platform
The wizard in the control panel writes the setup for the platform you pick, with the account key and the domains already filled in. You copy it with one button and run it on the server.
Windows
Simple-ACME in the FairSSL edition fetches the certificate, installs it in the certificate store and binds it to the site or service.
IIS 8+, IIS 6-7.5, Exchange, RDS, ADFS, WAP, SQL Server, PRTG, Dynamics NAV/BC, Tomcat
See the setup →Linux
Stock lego with FairSSL as the ACME server. The generated command writes the certificate and reloads the service afterwards.
nginx, Apache, HAProxy, Traefik, Caddy, Postfix, lego
See the setup →macOS
Lego, with the same setup as on Linux.
lego
Appliances
FortiGate 7.6.3 and F5 BIG-IP 21.1.0 and newer speak ACME themselves. Older versions and the other boxes fetch the certificate through an agent or an enrollment URL.
FortiGate, FortiMail, FortiWeb, NetScaler ADC, F5 BIG-IP, Kemp LoadMaster, Cisco ASA, Cisco FDM, Kubernetes cert-manager
What is not covered
The wizard does not write a setup for pfSense, Synology, Palo Alto or Sophos. If you run one of them, ask us before you buy and we will look at what can be done.
Certificates on many servers and appliances
A publicly trusted SSL certificate can be valid for at most 199 days now, 99 days by 15 March 2027 and 46 days by 15 March 2029. Each certificate then has to be replaced at least twice a year now and at least eight times a year from 2029, on every server, firewall and load balancer that uses it. sslbrain from FairSSL runs as an appliance in your own network and renews and installs the certificates from one place, including on devices without an agent.
How sslbrain renews and installs certificates on FortiGate(opens sslbrain.com in a new tab)