When a WordPress SSL certificate does not renew, determine whether issuance failed or a renewed certificate was never deployed to the server visitors reach. WordPress content settings do not renew a hosting or CDN certificate. The responsible host, certificate manager, or proxy must complete that process.
Do not ask customers to bypass a browser warning. Preserve the error and certificate details, then contact the service that owns HTTPS for the affected hostname. A certificate for the apex domain does not automatically cover every subdomain.
Record what the visitor receives
Capture the exact hostname, certificate expiry, issuer, and browser error. Test the business's real public names, including www if it is in use. Compare an affected visitor route with the hosting dashboard's certificate record.
A command-line check can confirm whether a normal client trusts the endpoint:
curl -sS -I --max-time 15 https://example.com/
Replace the domain. Leave certificate verification enabled. This check is not a renewal command and does not establish which automation step failed.
If a CDN terminates visitor HTTPS, its certificate and the origin certificate are separate objects. A valid origin certificate will not repair an expired edge certificate, and a valid edge certificate does not prove the CDN can connect securely to the origin.
Read the failed renewal attempt
Ask the host for the last attempt time, certificate names, challenge type, and exact error. Let’s Encrypt's challenge documentation distinguishes HTTP-based validation from DNS-based validation. Other providers may have different workflows.
For HTTP-01, investigate whether the expected challenge path reaches the correct server on port 80. Authentication walls, incorrect routing, or multiple backends with inconsistent challenge files can interfere. Have the host make a narrowly scoped supported correction, not disable the site's firewall broadly.
For DNS-01, verify the expected TXT record with the authoritative DNS provider. Check whether automation still has access to the correct zone after a DNS move. Do not copy a DNS API credential into a public ticket or permanently grant broad zone access as a quick fix.
Evidence guide for this investigation. Record your own observations; the fields are not test results.
Check the last infrastructure change
Compare the failure with nameserver changes, a new CDN, host migration, altered A or AAAA records, or a removed validation integration. A working IPv4 route and an old IPv6 destination can send different clients to different servers.
Do not repeatedly request certificates without reading the error. Certificate authorities apply limits, and repeated failed attempts can add delay. Use the provider's recommended diagnostics and staging facilities where available.
If renewal succeeded, ask where the new certificate was installed and whether the serving process or edge distribution completed its update. The dashboard's success label is not proof of the certificate delivered on the public route.
Close the incident with a monitored expiry
Confirm trusted HTTPS on each intended hostname and a representative login, form, or checkout route. Then examine canonical redirect behavior; a certificate repair should not introduce a redirect loop.
Assign renewal ownership and an expiry alert that reaches an active business contact. Record the provider and validation method without recording private keys. HandL WP can coordinate certificate troubleshooting when DNS, hosting, and CDN ownership are split across teams.
Sources checked September 30, 2026. Examples and visuals are explanatory, not customer measurements.