Automatic certificate deployment across firewalls and web servers

Automatic certificate deployment is the half of renewal that operators feel. The certificate authority can hand you a new certificate at 2 a.m. The firewall, the Windows server, and the reverse proxy are still serving yesterday's certificate until something installs the new one and reloads the right listener.

A file in an inbox, a ZIP on a jump host, or a "renewed" row in a portal is not deployment. Deployment is the live service presenting the new certificate.

Other CLM products and ACME clients deploy certificates too. What matters on a mixed fleet is whether the install target is a web server you already automated, or a firewall and a Windows role you still touch by hand.

A renewed certificate that is not installed is still the old one

Clients do not read your inventory. They complete a handshake with whatever the device presents. After a renewal, check the thing in the path:

• The firewall VIP, SSL VPN, or management interface.
• The IIS site binding, or the RDS gateway, not a different certificate sitting in the Windows store.
• The NGINX, Apache, or HAProxy listener that actually terminates the name. A certificate updated on the origin does nothing for a name that terminates on the proxy.

If two of those share a name and only one was updated, you will debug the wrong box.

What the deployment step has to do

For each name, the install needs a key that matches the certificate, the chain the clients will build, and a reload of the correct service. Then someone, or something, has to confirm the handshake.

Doing that by hand is a reasonable change window when you renew a handful of public sites once a year. It stops being reasonable when the same person also owns the firewalls, and the renewal cadence shortens. The lifetime schedule is covered in TLS certificate lifetime changes.

Automatic deployment is not "upload a PFX and hope." The safe version has three properties.

• The private key is created where it will be used. It does not get exported to a spreadsheet, a ticket, or a vendor that does not need it.
• The change can be previewed. A dry run shows what will be installed before the commit.
• If the service check fails, the previous certificate comes back. A failed push should not be the moment you discover you have no rollback.

Firewalls and VPN portals

FortiGate, Palo Alto PAN-OS and GlobalProtect, and SonicWall all terminate TLS on the appliance. The certificate is a configuration object, bound to a VPN portal, a virtual IP, or an administrative interface. Replacing it is a commit, not a web-server reload.

Sophos and WatchGuard sit in the same bucket at launch: edge devices operators still update by hand. The pattern is the same even when the API is not. Identify the object, install the new certificate and chain, commit, then connect to the name clients use and read the certificate they received.

If the check fails, roll back the object. Leaving a firewall half-committed because the portal "should come back" is how a renewal becomes an outage.

The device-by-device list, including what is not at launch, is in the device certificate auto-renew checklist.

Windows Server, IIS, and RDS

Windows is where certificates go to sit in a store unused. Importing a certificate is not binding it. IIS can have a new certificate in the machine store while the site still binds the old one. Remote Desktop Services can be serving a different certificate than the website on the same host.

A deployment that stops at "imported into Windows" will look healthy in a certificate MMC snap-in and expired, or unchanged, in a browser. The check has to be the listener: the site binding, or the RDS gateway name, from the network path users take.

The web tier

NGINX, Apache, and HAProxy are the cases ACME clients already handle well, when the client runs on that host and the reload command is correct. They still belong in the same inventory as the firewalls. A name that moves from NGINX to a firewall VIP during a cutover disappears from the web-server job and becomes a manual firewall job, which is how it gets lost.

Keep one inventory. Let the install method change with the platform. Do not keep a separate renewal culture for "the Linux boxes" and "the appliances."

Verify, then roll back

Certonomy's published workflow starts with a CNAME setup that enables fresh domain validation when required. The on-site agent creates the key and keeps it on site. The workflow covers the ACME order, delivery to the agent, installation, a live check, and rollback if verification fails. The DNS validation guide explains why the setup can persist while validation remains part of issuance.

That is certificate renewal automation ending at the device, which is the only place a user would notice.

See how it works for the four steps: validation, the on-site agent, ACME, then push, verify, and rollback.