aethercert
Documentation

FortiGate: Replace or Rename an SSL Certificate

Import a new SSL certificate on FortiGate, assign it to the admin GUI and SSL VPN via GUI or CLI, update it in place, rename it safely and verify each service.

FortiGate stores a certificate as a named local certificate object, and each TLS feature references that object by name: HTTPS administration, SSL VPN, virtual servers, explicit proxy and SSL inspection are all separate references. Importing a new certificate changes nothing until each feature points at it.

Before you begin

  • Record the current certificate object name, its scope and every feature that uses it. The CLI lists the references:

    diagnose vpn certificate list-usage <certificate-name>
  • Back up the configuration (admin menu in the top right > Configuration > Backup). For an in-place update or a rename, also download the current certificate from System > Certificates - both overwrite what is there, and the backup is your way back.

  • Prepare one of:

    • a PFX/PKCS#12 file with certificate, private key and its password, or
    • PEM certificate and private-key files, or
    • the signed certificate for a CSR generated on the FortiGate, whose private key is already on the device.
  • Make sure the SAN contains every name clients use: the admin GUI FQDN or IP, the SSL VPN name and each virtual-server hostname.

  • Plan a maintenance window if SSL VPN is affected: changing the SSL VPN server certificate disconnects all connected SSL VPN users. They can reconnect right away.

VDOMs and the global context

On a FortiGate with multiple VDOMs, a certificate imported into a VDOM is available only to that VDOM; a certificate imported in the Global context is available to all. In the GUI, switch to the right VDOM or to Global before importing. In the CLI, the certificate tables are config vpn certificate ... inside a VDOM and config certificate ... after config global. The examples below use the VDOM form; on a multi-VDOM FortiGate, prefix them with config global and drop vpn.

Choose a method

SituationMethod
New certificate with a new key (the usual case)Import it and switch each feature to it
The CA renewed the certificate for the same key pairUpdate the existing object in place
Only the object name should changeRename it in the CLI

Import a new certificate and switch to it

  1. In the correct VDOM (or Global), go to System > Certificates > Create/Import > Certificate > Import Certificate.

  2. Choose the type and enter a Certificate Name that shows purpose and year, for example sslvpn-2026 or admin-2026:

    • PKCS #12 Certificate for a PFX: upload the file and enter its password.
    • Certificate for PEM files: upload the certificate and the private key, and set a password that FortiOS uses to protect the key.
    • For a CSR generated on the FortiGate, upload the signed certificate as a Local Certificate; it pairs with the key already on the device.

    PEM files must be PEM, not DER. Convert a DER file first:

    openssl x509 -inform DER -in certificate.der -outform PEM -out certificate.pem
  3. Import any missing intermediate and root CA certificates as CA certificates, so the full chain is available to the features that serve it.

  4. Point every feature at the new object. Test with the admin GUI first - it does not disconnect VPN users - then change SSL VPN in the maintenance window.

    Admin GUI (HTTPS administration): System > Settings > HTTPS server certificate, or:

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

    Your browser session may need to reconnect.

    SSL VPN: VPN > SSL-VPN Settings > Server certificate, or:

    config vpn ssl settings
        set servercert "sslvpn-2026"
    end

    This disconnects every connected SSL VPN user.

    Everything else that list-usage showed - virtual servers, explicit proxy, SSL inspection profiles - has its own certificate field in that feature's settings.

  5. Save. In the GUI the change takes effect when you click Apply or OK; in the CLI when you leave the block with end. No reboot is needed.

  6. Run diagnose vpn certificate list-usage <old-name> again. When it shows no references, delete the old object under System > Certificates.

Update an existing certificate in place

When the CA renews a certificate for the same key pair, you can replace the certificate inside the existing object instead of importing a new one. The object keeps its name, so no feature setting has to be edited.

  1. Download the current certificate as a backup (see Before you begin).

  2. Paste the renewed PEM certificate into the object:

    config vpn certificate local
        edit "sslvpn-2025"
            set certificate "<paste the PEM certificate>"
        next
    end

    Press Enter before pasting the PEM block, and paste from an editor that does not add carriage returns - both are common causes of syntax errors.

  3. Check each feature over the network (see Verify). Fortinet notes that a feature may keep serving the previous certificate until the certificate is unset and set again in that feature. If a service still presents the old certificate, set it again there - for SSL VPN this disconnects the connected users.

This does not work for a certificate with a new key; use the import method for that.

Rename a certificate

Fortinet documents renaming in the CLI. Run it in the table the certificate lives in:

config vpn certificate local
    rename "sslvpn-2025" to "sslvpn-2026"
end

The same rename works under ca, remote, ocsp-server and crl. CA certificates get automatic names on import, and this is the only way to change them.

Fortinet warns that renaming can disrupt services that rely on the old name, and does not document that feature references follow the rename. Treat it as a change to every feature that uses the certificate:

  1. Run diagnose vpn certificate list-usage "sslvpn-2025" and note the features.
  2. Rename.
  3. Check that each of those features still shows the certificate in its settings, and verify it over the network.
  4. If a feature lost the reference, select the renamed certificate there again - or rename it back with rename "sslvpn-2026" to "sslvpn-2025".

If you are replacing the certificate anyway, importing it under the new name is the safer way to a new name: the object in use is never touched.

Product-specific considerations

Replacing the admin certificate does not change SSL VPN or any virtual server - each is its own reference. In an HA cluster, confirm that certificate and configuration have synchronized to the secondary before a failover, and test each member.

Verify the new certificate

Connect to every service by the name clients use, including a non-standard SSL VPN or admin port:

openssl s_client -connect fw.example.com:443 -servername fw.example.com -showcerts </dev/null
openssl s_client -connect vpn.example.com:10443 -servername vpn.example.com -showcerts </dev/null

In the output, check the subject and SAN, the issuer, the expiry date (NotAfter) and that the intermediate certificate is sent. Test through the HA virtual IP and, where the runbook permits it, directly against each member.

Rollback

  • After an import: set the old object again in each feature (admin-server-cert, servercert, virtual servers, profiles). Changing servercert back disconnects SSL VPN users once more.
  • After an in-place update: paste the backed-up certificate into the object the same way.
  • After a rename: rename it back.
  • If in doubt: restore the configuration backup (admin menu > Configuration > Restore); the FortiGate reboots to apply it.

Keep the old certificate object and CA chain until every client path validates.

Common problems

  • The leaf was imported without its intermediate chain.
  • The certificate was imported into the wrong VDOM.
  • The new object exists but a feature still references the old one - list-usage shows which.
  • The SAN does not cover the admin, VPN or virtual-server hostname.
  • An in-place update was attempted with a certificate for a different key.
  • SSL VPN users were disconnected because the server certificate was changed outside a maintenance window.

Automating certificate replacement with aethercert

The aethercert FortiGate target imports the leaf certificate and private key as a named FortiOS local certificate. It does not import the chain as FortiOS CA objects or assign the certificate to a particular FortiGate feature; configure those product-specific references separately.

See Deploy targets for the fields this preset takes, what it needs on the host, and how far it has been verified.

Sources

On this page