Skip to content

Guides · Certificates

Certificate renewed but not installed: why it still expires and how to fix it

The CA issued a new certificate, but your server still serves the old one, so it expires on schedule. How to spot the gap and close it for good.

Updated 29 October 2026 · 4 min read

You renewed the certificate. The CA issued it, the invoice is paid, maybe an ACME client even logged "success". And on the expiry date the VPN portal or the website still breaks, because the server never started using the new certificate. Renewing and installing are two different steps, and only the second one keeps users connected.

This gets more common every year. Public TLS certificates are limited to 200 days from 15 March 2026, 100 days from March 2027 and 47 days from March 2029 (CA/Browser Forum ballot SC-081). Every renewal is another chance for the install step to be missed.

How it happens

  • Appliances that need a manual import. Firewalls, VPN gateways, load balancers and Windows servers often need the new file uploaded and selected per service. The renewal lands in someone's inbox and stops there.
  • More than one place serves the name. You updated one web server, but a second node, a load balancer or a CDN still holds its own copy.
  • The service was never reloaded. The file on disk is new, but the running process loaded the old one at start-up. nginx, HAProxy, Postfix and many others need a reload.
  • The ACME client renews, but nothing deploys. The client saves the new certificate where nothing reads it, or the deploy hook failed silently.
  • A wildcard was renewed, but each host has its own copy. Every server, appliance and mail gateway that uses it needs the new file.

How to spot it

Every publicly trusted certificate is published in Certificate Transparency (CT) logs. If the logs show a newer certificate for a name than the one your server presents, the renewal was not installed.

  1. Check what the server actually serves:

    openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -serial -enddate

  2. Search the CT logs for the same name, for example on crt.sh, and compare serial numbers and expiry dates. A newer certificate covering the same names means it is waiting to be installed.

For mail servers, add -starttls smtp and use port 25.

How to fix it

  1. Install the new certificate everywhere the name is served: every node, the load balancer, the CDN and any appliance. Include the intermediate certificate; a missing chain causes errors on phones and older clients.
  2. Assign it to every service. Appliances often bind certificates per service: admin console, VPN portal, reverse proxy and so on.
  3. Reload or restart the service so it picks up the file.
  4. Check from outside with the command above, and confirm the new serial and expiry date are served on every address the name resolves to.
  5. Remove the old certificate once nothing uses it, so it can't be selected by mistake next time.

Make it stop happening

  • Automate the install, not just the renewal. With certbot, a --deploy-hook runs only after a successful renewal, which is the place to reload services or push the file to other hosts.
  • Use the appliance's built-in ACME support where it exists. FortiGate, Sophos Firewall and recent SonicOS releases can request and renew certificates themselves. See the vendor runbooks below.
  • Keep a list of where each certificate lives. The CT logs tell you every name you have certificates for; the list tells you where to install them.

Step-by-step runbooks: FortiGate, SonicWall, Sophos Firewall, IIS and Remote Desktop and Exchange hybrid.

Check your domain

The free scan lists every unexpired certificate for your domain from the CT logs, connects to each host, and flags any host still serving an older certificate when a renewal already exists.

Sources

Free scan

No signup. Only scan domains you own or manage.

More in Certificates