A renewal job can succeed while visitors still see an expired certificate. That usually means the new certificate was issued but never installed, bound, or reloaded on one of the systems serving the site.
The fix is to identify the certificate presented for each public hostname, deploy the renewed full chain everywhere it is needed, and then prove that automatic renewal will complete the entire path next time.
What it means
The browser checks the validity period of the certificate it actually receives. Files on disk do not matter until the web server, load balancer, or CDN presents them for the requested hostname.
- Serial number:distinguishes the old certificate from the renewed one.
- Not After:shows when the presented certificate expires.
- SNI and hostname:determine which certificate a shared listener returns.
- Full chain:includes the required intermediate certificates as well as the site certificate.
A realistic WordPress example
A site renews through ACME and the renewal log reports success. The origin has a fresh certificate file, but the load balancer still serves the expired serial because its listener was not updated or reloaded.
Checking only the origin would miss the fault. Querying the public hostname, each active IP address, and both IPv4 and IPv6 reveals which endpoint still has the old binding.
Why it matters and when to use it
An expired certificate can block every HTTPS request before WordPress runs. It affects the storefront, login, REST API, webhooks, and monitoring at once.
Use this diagnosis when a browser or external TLS check reports expiry. If only one hostname or network path fails, compare the certificates served on those paths before requesting another renewal.
A straightforward route for beginners
- Check the certificate dates and serial number for the exact public hostname.
- Test the apex and
wwwnames separately, including any hostname visitors use directly. - Find where TLS terminates: the web server, reverse proxy, load balancer, CDN, or hosting control panel.
- Renew through the supported method, then install the full chain on the component that serves traffic.
- Reload or deploy the relevant service and confirm that the new serial appears externally.
- Test redirects, login, forms, and a normal public page after the certificate is replaced.
The advanced route
Treat issuance and deployment as separate stages. Record the old and new serials, certificate path, full-chain hash, listener binding, deployment time, and reload result. Query every public address with the intended SNI value so round-robin DNS or a stale IPv6 endpoint cannot hide.
Review automation in order: domain challenge, issuance, installation, service reload, CDN deployment, and expiry monitoring. A successful challenge proves control of the name; it does not prove that visitors receive the new certificate. Run the provider-supported renewal dry run and set an alert window that leaves time for manual recovery.
Risks, common mistakes, backup, and rollback
Do not delete the old certificate until a valid replacement is installed and bound. Copying only the leaf certificate, restarting the wrong service, or repeatedly reissuing can prolong the outage and may trigger certificate-authority rate limits.
Keep a recovery path to the server or hosting panel. If the replacement causes a hostname mismatch, serves an incomplete chain, or leaves the listener with an invalid certificate binding, restore the previous binding while you correct the deployment. The expired certificate is not a useful long-term fallback, but a known configuration can help isolate the new fault.
How AIOWS helps:
AIOWS SSL Manager
AIOWS SSL Manager can help review and manage supported WordPress-side HTTPS settings after the public certificate is valid. It is useful for checking the site URLs and WordPress behavior that depend on HTTPS.
The certificate itself may be owned by the hosting platform, web server, CDN, or certificate authority. AIOWS does not replace that renewal and deployment process, nor can it repair a stale load-balancer binding or DNS route.
Once the renewed certificate is serving everywhere, use SSL Manager as part of the application check: confirm the WordPress URLs, redirects, administration area, assets, and forms behave correctly over HTTPS. Keep certificate-expiry monitoring outside WordPress so an edge failure is detected even when the application is unreachable.
Related AIOWS articles
- How to Install SSL on a WordPress Site
- SSL Handshake Failed on WordPress: Causes and Fixes
- How to Check WordPress SSL Certificate and HTTPS Health
Conclusion and recommended route
Replace the certificate that visitors actually receive, not merely the file you expected the server to use. Confirm the fresh serial on every active hostname and endpoint, then leave renewal, deployment, reload, and expiry alerting working as one tested process.
