How to Install an SSL Certificate on a FortiGate Firewall

Which FortiGate certificate are you replacing?

Four services on a FortiGate present a certificate, and they are configured in four different places. The administrative web interface, the remote access portal, and any virtual server that terminates TLS for a published application all take an ordinary publicly trusted server certificate. SSL deep inspection does not. It needs a signing CA, which is a different kind of certificate entirely.

Work out which of those you are being asked to fix before you order anything. “The firewall shows a certificate warning” is ambiguous: it might be an administrator seeing the self-signed certificate on the login page, a remote worker seeing it on the VPN portal, or every internal user seeing it on every site they visit, which means inspection is enabled and its CA is not trusted on the endpoints. The first two are a purchase. The third is not.

For the three that are a purchase, the deciding factor is names rather than services. A firewall that answers to fw.example.com for management and vpn.example.com for remote access needs both names on one certificate, which is a multi-domain certificate or a wildcard, or two certificates, if you prefer to keep the management name off any public list. The certificate types that cover appliance hostnames sets out what each one includes and what validation involves.

How do you generate a CSR on a FortiGate?

Go to System > Certificates, choose Create/Import > Certificate, and pick Generate. Give it a certificate name, put the fully qualified hostname in the subject, fill in the organisation fields, add every other name the firewall answers to as a subject alternative name, and save. The FortiGate creates the key pair locally and the entry appears in the list marked pending, with the request available to download.

If System > Certificates is not in the menu at all, it is hidden rather than missing: turn on Certificates under System > Feature Visibility and it comes back. This catches people on a fresh unit often enough to be worth checking before assuming a licensing problem.

Two fields decide whether the certificate works everywhere or only in one browser. The subject alternative names are what clients actually match against, the common name has been ignored by browsers for years, so list every hostname the appliance answers to, including the one you use for management even if you think of it as internal. And the key size is a choice you live with for the life of the certificate: 2048-bit RSA is the safe default for an appliance that has to work with old VPN clients, 3072 or 4096 if your estate is modern and you want the margin. What actually goes into a CSR explains each field and why the CA re-derives most of them anyway.

# argument order varies slightly between FortiOS versions, 
# ask the box for its own syntax before typing the whole line
execute vpn certificate local generate rsa ?

# then, on most builds:
execute vpn certificate local generate rsa fw-cert 2048 \
  fw.example.com GB London London "Example Ltd" IT \
  it@example.com DNS:fw.example.com,DNS:vpn.example.com

Multiple SANs go in one comma-separated list with no spaces. The GUI is the more reliable route here precisely because the CLI argument order has shifted between releases, and a CSR with the city in the organisation field is a CSR you find out about after validation has already started.

Download the request, submit it to your certificate authority, and leave the pending entry alone while validation runs. Deleting it deletes the private key with it, and a signed certificate whose key no longer exists is worth exactly nothing, reissue is the only way back, which costs you the validation wait a second time.

How do you import the certificate and its chain?

It is two imports, not one. Go to System > Certificates > Create/Import > Certificate, select the signed certificate file, and it completes the pending entry that holds the matching key. Then repeat with Create/Import > CA Certificate for every intermediate your CA supplied. Those land in the external CA list as CA_Cert_1, CA_Cert_2 and so on.

Skipping the second import is the single most common way a FortiGate certificate install goes wrong, and it is designed to fool you. Your desktop browser has probably already cached that intermediate from another site, so the admin page turns green, the ticket gets closed, and the failures surface somewhere you are not looking: a VPN client that will not connect, a mobile device that reports the issuer as unknown, a monitoring check that starts alerting at 3 a.m., an API integration that fails certificate verification.

# the signed certificate, into the pending local entry
execute vpn certificate local import tftp fw-cert.crt 10.0.0.20

# each intermediate, as an external CA certificate
execute vpn certificate ca import tftp intermediate.crt 10.0.0.20

Verify from outside the appliance rather than trusting the absence of an error. The check below asks the firewall what it is actually presenting and prints the whole chain; a verify error: unable to get local issuer certificate in the output means an intermediate is still missing however green the admin page looks. If you would rather see it rendered, the SSL checker reads the chain from outside your network for any host that is publicly reachable.

openssl s_client -connect fw.example.com:443 \
  -servername fw.example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Point that at whichever port the service in question listens on : the management interface may be on 443, on a custom port, or on a dedicated management interface that is not the one your users reach. How certificate chains break and how to repair them works through reading that output properly.

Putting the certificate on the admin login page

Go to System > Settings, find the administration settings, set the HTTPS server certificate to the certificate you imported, and apply. The web server restarts, your session ends, and you sign back in on a page with no warning. No reboot, no interruption to traffic passing through the firewall, the management daemon and the data path are separate.

config system global
    set admin-server-cert "fw-cert"
end

Use the certificate name exactly as it appears in the list, not the filename you uploaded. If the command is rejected, the certificate is either in a different virtual domain or still pending because the signed file was never imported back into it.

One thing worth doing in the same window: browse to the management interface by hostname, not by IP. A certificate is bound to names, so https://fw.example.com is clean and https://192.168.1.99 still warns, correctly and forever. Administrators who keep the IP in a bookmark conclude the install failed, and it is the bookmark.

Where the certificate goes after the 7.6 VPN changes

Remote access on a FortiGate still needs a publicly trusted certificate, but where you select it depends on your FortiOS version and your model. From FortiOS 7.6.3, SSL VPN tunnel mode is replaced by IPsec VPN, which can be configured to listen on TCP port 443, and SSL VPN web mode is renamed Agentless VPN. Settings are not carried over by the upgrade.

There is a second change that lands earlier and harder. FortiOS 7.6.0 removed SSL VPN, both web and tunnel mode, from FortiGate models with 2 GB of RAM or less, which covers a lot of the installed base, including the 40F, 60F and 61F series. On those units the menu you were told to use does not exist after the upgrade, and no certificate purchase changes that. Fortinet later extended the list of models where Agentless VPN is unavailable, so read the release notes for your exact target build rather than for 7.6 in general.

None of this makes the certificate redundant. Agentless VPN presents a server certificate to the browser exactly as the old web portal did. An IPsec gateway configured for certificate authentication presents one to the client. The certificate you bought for vpn.example.com keeps working across all of it: what moves is the menu, and on the smaller boxes, whether the feature is there to configure.

On a build that still has SSL-VPN, the selection is under VPN > SSL-VPN Settings, in the connection settings pane, in the server certificate drop-down. If that menu is missing on 7.4 or later it is usually hidden rather than absent, SSL-VPN is off by default under System > Feature Visibility. On the CLI the same setting is:

config vpn ssl settings
    set servercert "fw-cert"
end

Existing sessions keep whatever certificate they negotiated until they reconnect, so the change is not disruptive, but it is also not immediately visible, which is worth knowing before you conclude it did not take.

Can you buy a certificate for deep inspection?

No. Deep inspection means the FortiGate terminates each outbound TLS session and mints a fresh certificate for whatever site the user asked for, so it needs a certificate that can sign other certificates, a CA, not a server certificate. Mozilla’s root store policy calls issuing a subordinate CA for the purpose of TLS interception unacceptable even on a closed network, and the other root programs agree.

This is not a Fortinet limitation, and no reseller can route around it. The rule dates to 2012, when a publicly trusted CA admitted having issued a subordinate CA to a company for inspecting traffic on its own network; the root programs responded by demanding those certificates be revoked and writing the prohibition into policy. The reasoning has not aged: a certificate that can mint a valid identity for any website on the internet is a certificate nobody wants sitting in a 1U appliance in a comms room.

The supported design is a private CA that you run and whose root you install on your own managed endpoints. Fortinet’s own guidance is to use a subordinate CA signed by the organisation’s private CA, a FortiAuthenticator, Active Directory Certificate Services, step-ca, Vault, or a managed private CA service, and to push that root to every device through whatever configuration management you already run. That last clause is the real project. Domain-joined Windows machines take the root through group policy in an afternoon; unmanaged phones, contractor laptops, Java keystores, container images and anything with its own bundled CA list each need their own answer.

Two consequences follow that are easy to miss at design time. Endpoints you cannot manage cannot be inspected without teaching their users to click through warnings, which costs more security than the inspection buys. And certificate pinning defeats inspection by design, banking apps, several updaters and a long tail of mobile software will simply fail rather than warn, which is why every real deployment carries an exemption list. How pinning works explains why those failures are the software behaving correctly.

Renewal on a 200-day clock

Since 15 March 2026, publicly trusted TLS certificates max out at 200 days under CA/Browser Forum ballot SC-081v3, and the ceiling drops to 100 days in March 2027 and 47 days in March 2029. A firewall you used to touch once a year now needs two rounds a year, then four, then eight. The install did not get harder. It got frequent.

That arithmetic lands badly on appliances specifically, because the work is manual by default and it happens inside a change window. Four renewals a year across a handful of firewalls, each needing a CSR, a validation wait, two imports and a service binding, is the kind of task that gets deferred until the Monday morning it expires. The realistic mitigations are unglamorous and they work:

• Reuse one certificate across the estate. A wildcard covering *.example.com can serve the admin interface, the VPN gateway and the published applications, which turns several renewals into one purchase and several imports. What a wildcard covers, and what it does not is worth reading before assuming it fits.
• Diarise the CSR, not the expiry. Validation for organisation-validated products takes days, not minutes. Working backwards from expiry rather than forwards from the reminder is what keeps the change window calm.
• Monitor from outside. An expiry check against the public name catches the firewall you forgot as well as the one you renewed but never rebound, the second failure mode is invisible to any inventory that reads your CA account.
• Keep the certificate name stable. Import each renewal into a consistently named entry and the CLI binding commands stay identical year after year, which is what makes the job scriptable.

The direction of travel is fixed, and appliance vendors are catching up at different speeds. The full SC-081v3 timeline and why automation stops being optional in 2027 both set out what the calendar looks like from here, which is the argument to make when someone asks why the firewall needs a change window four times a year.

When it goes wrong

Almost every failure here is one of six things, and none of them locks you out permanently. SSH and the console port never depend on the HTTPS server certificate, so however badly the binding goes you always have a way back in. Worth knowing before the first attempt rather than during it.

The last row is the one that arrives as an angry ticket and gets misdiagnosed as a certificate problem. It is a distribution problem. Nothing you can buy will make an endpoint trust a CA it has never been given, and the fix is on the endpoint management side of the house, not the procurement side.

FAQ