An expired certificate and an incomplete certificate chain can look similar in the browser but require different repairs. First identify which TLS endpoint the visitor actually reaches—CDN/edge, load balancer or origin—and inspect the chain presented there before changing WordPress URLs or redirect rules.
Identify the certificate endpoint
Resolve the hostname and inspect issuer, subject/SAN, expiry and full chain on the public endpoint. Do not assume the origin certificate is what browsers see.
Distinguish expiry from chain failure
An expired leaf certificate needs renewal; a missing intermediate needs the correct bundle/order. Reissuing repeatedly does not fix a server that serves the wrong chain file.
Check CDN origin mode separately
With a reverse proxy, edge TLS and origin TLS are two contracts. Confirm the selected mode and whether the origin certificate is valid for that mode.
Renew without changing application URLs
Certificate renewal normally does not require changing WordPress home/site URLs. Mixing certificate work with URL changes is a common route to redirect loops.
Audit redirects after TLS works
Once HTTPS terminates cleanly, check HTTP→HTTPS rules at one authoritative layer. Proxy, server and WordPress redirects stacked together can loop.
Verify the complete path
Test apex/www variants, representative pages, admin and API. Confirm no hostname serves an old certificate and monitor the next expiry with enough renewal margin.
Before changing DNS during a certificate incident, use the migration DNS checklist; if HTTPS reaches a broken upstream, continue with the 502 proxy/PHP diagnosis.