FortiGate certificate renewal: check the listener, not just the certificate list

FortiGate certificate renewal has two success conditions: a valid replacement exists, and the intended service presents it. A certificate in the appliance's certificate list does not establish that the administrative interface or another TLS listener is using it.

Start by identifying the FortiOS version, the service being changed, and the hostname clients use. Native ACME support and certificate handling vary by release. This guide is a planning and verification checklist, not a set of commands to apply across every FortiGate model or software version.

Identify what the certificate actually protects

Write down the exact listener and the certificate reference in its configuration. The administrative interface and a user-facing service can use different objects. Where your deployed release supports an SSL VPN service, treat its configuration separately from management access.

Record the configured port as well as the hostname. A successful check on port 443 tells you little about a management service on a different port. If the connection passes through another proxy or a virtual IP, determine which device terminates TLS first.

Before making changes, record the old certificate's fingerprint, expiry, and configuration reference. Arrange a recovery path that does not depend on the service you are modifying. Losing access to the only management route makes even a small configuration error expensive.

Check whether native ACME fits the service

FortiGate already has native ACME support. Fortinet's FortiOS 7.6.6 certificate provisioning documentation describes automated issuance, public reachability requirements, and port interactions. For that documented workflow, the hostname must resolve to the public IP, and services or VIPs using challenge ports can interfere with validation. It also documents restrictions on wildcard and multiple SAN names.

Use the documentation for your installed release before choosing a renewal method. A workflow that works on an internet-facing appliance may not fit a private management endpoint, a wildcard requirement, or a site where the challenge cannot reach the appliance.

Native automation can be the right answer when it meets your requirements. A separate orchestration tool becomes useful when you need consistent inventory, alerting, or deployment across a mixed fleet. Evaluate the missing operational work rather than assuming every firewall needs another ACME client.

Separate domain validation from appliance installation

With an external issuance workflow, decide how domain control is demonstrated and where the private key is created. The issued certificate must match the key used for that request, and the appliance must receive the appropriate chain and supported format.

DNS validation can avoid making the protected service publicly reachable for an HTTP challenge. It still requires functioning public DNS validation and an installer for the appliance. The DNS-01 guide explains the difference between challenge delegation and permanent validation.

Document the automation identity and its scope. Keep passwords and private keys out of runbook examples and ticket attachments. A technician should be able to follow the certificate reference without needing a copy of the key.

Use a renewal change checklist

For a first deployment or a change in renewal method:

1. Confirm the replacement covers the client-facing hostname and is currently valid.
2. Confirm the key and chain are appropriate for the appliance and release.
3. Record the existing listener's certificate reference and recovery steps.
4. Install through the supported process for that FortiOS release.
5. Update the intended service reference if the process creates a new certificate object.
6. Test a fresh connection from the client path and compare the live certificate with the replacement.
7. Check the actual management or application function, then record the result.

For an HA deployment, include the cluster's documented synchronization behavior and a check of the paths that can become active after failover. A successful observation of one node does not prove the other node is ready.

Diagnose a renewed certificate that is not live

If the old certificate is still visible, compare the listener reference with the object you imported. Then check whether your test reached the right device, port, and hostname. A default virtual host or upstream TLS terminator can make a correct appliance update look unsuccessful.

If clients reject the replacement, inspect hostname coverage, validity dates, trust chain, and clock accuracy. If domain validation failed before issuance, troubleshoot DNS or challenge reachability instead of repeating the import.

Use the general renewal troubleshooting workflow to isolate the failing stage. When rollback is appropriate, restore the recorded configuration and a known valid certificate. Keep the failed replacement available for investigation without leaving it bound to a broken service.

Move from a one-time fix to an observed renewal

The first successful import proves only that an install can work. Before calling the process unattended, observe a scheduled renewal, confirm its live certificate, and test the failure alert route. Keep endpoint monitoring separate from the job's success message.

FortiGate is in Certonomy's published launch scope. If your team needs renewal and deployment across several customer platforms, review the on-site agent workflow and join the founding waitlist with the FortiOS versions and services you manage.