Certificate renewed but the site still shows expired? Follow the TLS path

If a certificate renewed successfully but the site still shows an expired certificate, the replacement may not be installed on the endpoint your client reaches. Start by comparing the live certificate with the issued replacement. Then trace the path through the CDN, load balancer, firewall, or web server that terminates TLS.

Do not begin by repeatedly ordering new certificates. If issuance already succeeded, another order will not correct the wrong HTTPS binding or reload the right proxy process. Diagnose the stage that failed.

First confirm the error and the endpoint

Record the failing hostname, port, time, client, and error message. A warning about an expired certificate is different from a hostname mismatch, an untrusted chain, or a connection failure. Check that the client clock is reasonable before assuming the certificate's dates are wrong.

Inspect the certificate on a fresh connection using the expected SNI hostname. The monitoring guide provides read-only OpenSSL examples. Compare the observed serial number or fingerprint, validity dates, and names with the replacement from the renewal job.

If the observed identity is different, map the TLS termination path. The public certificate might belong to an upstream CDN while the renewed file sits on the origin. If different requests show different certificates, investigate multiple addresses, nodes, or split DNS routes.

Stage one: domain validation did not complete

Check the ACME or CA error before touching the service configuration. With an HTTP challenge, confirm the authority can reach the required challenge path through your routing and firewall. With DNS-01, check the exact challenge name and authoritative TXT answer.

A DNS editing screen showing the expected value does not prove every relevant nameserver answers correctly. A delegated challenge can also fail when the client lacks access to the destination zone. Follow the DNS validation checklist to separate delegation, credentials, and propagation.

Keep the original failure visible. Repeated blind attempts can create extra errors and make it harder to identify the first cause. Use a CA's test environment when available to validate a changed workflow before trying production issuance again.

Stage two: issuance succeeded, installation did not

Find the deployment job's output. A certificate authority can issue a certificate without knowing whether your firewall or Windows server received it.

Check that the installer reached the intended device, had the required access, used the expected format, and delivered the required chain. Confirm that the certificate matches the private key available at the deployment target. Avoid moving private keys into a ticket or an online diagnostic tool while investigating.

If deployment created a new object, note its identifier. The next stage may still reference the old object. Treat “import successful” as evidence of import, not evidence of a working listener.

Stage three: the service still selects the old certificate

This is often a binding or configuration reference problem. Inspect the actual service configuration rather than only the certificate store or file directory.

• IIS: check the HTTPS binding, hostname, port, selected certificate, and SNI settings. Use the IIS renewal checklist.
• NGINX: check the active server block, mounted certificate paths, configuration test, and reload target. Use the NGINX renewal checklist.
• FortiGate: check the intended service's certificate reference and the appliance and port reached by the probe. Use the FortiGate renewal checklist.

In a cluster or farm, confirm every relevant target. One updated node can make spot checks pass while another continues serving the expired certificate.

Stage four: the replacement is live but clients reject it

If the live identity matches the replacement, inspect the actual rejection. Check hostname coverage, validity dates, chain delivery, client trust, and the service's TLS configuration.

A server that omits an intermediate certificate can behave differently across clients. Some clients may already have an intermediate cached. NGINX's HTTPS documentation explains this chain-delivery problem. Test with an appropriate clean trust context and inspect what the server sends.

Do not ask users to disable certificate validation to resolve the incident. Restore a trusted connection or use your documented recovery path. If the service is business-critical, keep the incident owner and affected users informed through your normal operational process.

Recover with evidence, then fix the workflow

When a known valid prior certificate and configuration are available, a controlled rollback may restore service while you investigate. An expired prior certificate will not restore trust. Verify the recovered endpoint and application before marking the incident resolved.

Record which stage failed, when it first failed, and why the alert or retry path did not resolve it in time. Then change the workflow so that completion requires live verification. Add an alert for the failed stage instead of relying only on the next expiry warning.

Prevent the same incident at the next renewal

Keep separate evidence for issuance, installation, configuration selection, and endpoint verification. Give every service an owner in the certificate inventory, and test the alert route before leaving a renewal unattended.

Certonomy's published workflow is built around that full path: issuance, an on-site agent, deployment, live verification, and rollback. If the manual handoff is where your team gets stuck, review how it works and the founding waitlist for the platforms you manage.