Device certificate auto-renew checklist

Firewall certificate renewal fails in a specific way. The certificate is renewed somewhere else, then someone still has to upload it, bind it to the VPN or the virtual IP, commit, and prove the portal presents it. Device certificate management is that upload, done on a clock, with a rollback.

This checklist is only for platforms Certonomy installs on at launch, plus an explicit list of platforms that are not at launch. Do not treat a logo on a slide as support.

Launch installs cover:

• Fortinet FortiGate
• Microsoft IIS, Windows Server, and RDS
• Palo Alto PAN-OS and GlobalProtect
• SonicWall
• Sophos and WatchGuard
• NGINX, Apache, and HAProxy

F5 BIG-IP, Citrix NetScaler, Microsoft Exchange, Cisco Secure Firewall and ISE, and VMware vCenter and ESXi are later. Tomcat and Kubernetes are later still. If your outage is on one of those, this checklist does not claim an installer for it today.

The shared renewal path is the same before the platform steps. Certificate renewal automation describes it: inventory, a visible failure, ACME, an on-site key, an install, a live check, a rollback.

Before the first auto-renew

Do these once per name, on any platform.

• Write the hostname clients use, not only the device hostname. vpn.example.com and the firewall's management name are often different certificates.
• Note which service presents it: SSL VPN, GlobalProtect portal, IIS binding, RDS gateway, or a proxy listener.
• Confirm you can reach that name from the path users take. A check from the agent's host to localhost can pass while the VIP is still on the old certificate.
• Know the previous certificate is still on the device so a failed install can return to it.
• Set up the CNAME delegation once. Fresh domain validation still takes place when issuance requires it. The agent in the customer network creates the key and keeps it. The key is not copied back.

Then run a dry-run before the first unattended renewal. The product is built to preview the change, install, confirm the live service, and roll back if that confirmation fails.

FortiGate

FortiGate has native ACME support in supported releases. Compare that option with your validation and deployment needs using the FortiGate renewal guide.

• Identify the certificate object and every policy, VIP, or SSL VPN portal that references it. Replacing the object without the references leaves the portal on the old certificate.
• Install the new certificate and chain, commit, and open the VPN or VIP name from outside.
• Read the certificate on that connection. Match the name and the dates. "Commit succeeded" is not the check.
• If the portal does not come back with the new certificate, roll back to the previous object. Do not debug a remote site by leaving the VPN down.

Windows Server, IIS, and RDS

The IIS certificate renewal guide covers HTTPS bindings, SNI, and verification across multiple nodes.

• Importing into the certificate store is not the install. Bind the certificate to the IIS site, or to the Remote Desktop service that users actually open.
• A host can present one certificate for a website and another for RDS. Check both names if both exist.
• After the bind, connect to the public name. Confirm the store and the listener agree.
• If the site fails its check, restore the previous binding. A new certificate in the store with a broken binding is a silent miss. It looks renewed and serves the old file.

Palo Alto PAN-OS and GlobalProtect

• Decide whether you are renewing the portal, the gateway, or both. They can be different certificates. Renewing one and testing the other wastes the window.
• Commit, then connect to the GlobalProtect name users type. Check the certificate on that session.
• Roll back the commit if the gateway presents the old certificate or the client will not connect. A pushed config that does not survive a handshake is not a renewal.

SonicWall

• Bind the new certificate to the SSL VPN or the management interface you intended. SonicWall appliances collect unused certificates. Presence in the list is not deployment.
• Connect to the name in the certificate. If the handshake fails or the dates are unchanged, restore the previous certificate on that interface.

Sophos, WatchGuard, and the web tier

For NGINX paths, chain delivery, and graceful reloads, use the NGINX renewal checklist.

Sophos and WatchGuard are the same edge pattern: install on the appliance, commit, check the name clients use, roll back if the live certificate is wrong.

NGINX, Apache, and HAProxy are the web tier at launch. The reload has to hit the process that owns the listener, and the file path in the config has to be the file the agent wrote. A reload of the wrong service, or a second host in a pair that did not receive the file, leaves half the fleet on the old certificate. Check each name from the outside, not only the local config test.

More on why deployment is its own step: automatic certificate deployment.

After the install

• Record the expiry you just created. Under the current public cap that is about 200 days for a certificate issued now, not 47. The later dates are in TLS certificate lifetime changes.
• Confirm a failed renewal would alert someone. A green dashboard that hides errors recreates the silent-failure outage.
• Add the next device only after the first name has renewed once without a ticket.

See how it works for the agent, the ACME handoff, and the verify-and-rollback step on the launch platforms above.