Certificate incidents are usually caused by expiry, hostname mismatch, incomplete chains, failed validation, incorrect proxy configuration or mixed content. Diagnose the exact browser or monitoring error before replacing certificates repeatedly.
Identify the failure
| Symptom | Likely area |
|---|---|
| Certificate expired | Automation, renewal scheduling or deployment |
| Name mismatch | Wrong hostname or incomplete certificate coverage |
| Works on some devices only | Certificate chain or legacy client compatibility |
| Too many redirects | Conflicting proxy, CDN or application HTTPS rules |
| Padlock warning on one page | Mixed HTTP resource or insecure form action |
| Renewal validation fails | DNS/HTTP challenge cannot reach the expected location |
Check the request path
- Confirm the exact public hostname and time of failure.
- Inspect the certificate presented by the public endpoint.
- Identify whether a CDN, load balancer or host terminates TLS.
- Compare certificate names and validity with the requested hostname.
- Check the chain and intermediate certificates.
- Review renewal logs and validation records.
- Test redirects and application base URLs separately.
Common hidden causes
- The certificate was renewed on the origin but the CDN still serves the old one.
- A www or non-www variant was omitted.
- An obsolete AAAA record sends some visitors to another server.
- CAA records block the selected certificate authority.
- A staging certificate or self-signed certificate was deployed publicly.
- Server time is incorrect.
Recovery approach
Restore a previously working configuration if available, issue a correct replacement and verify it externally. If a private key may be compromised, revoke the affected certificate and rotate the key.
Prevent recurrence
Use automated renewal, external expiry monitoring, named ownership and a certificate inventory for every public hostname. Renewal success in a control panel is not enough if the renewed certificate was never deployed to the public endpoint.
Business continuity during an incident
Do not advise customers to bypass a browser warning on a public business site. If the fault cannot be fixed immediately, pause sensitive transactions and publish a verified status update through another trusted channel. Protect payment and login data rather than pressuring visitors to continue.
After service returns, inspect monitoring gaps and renewal ownership. A certificate outage often reveals that alerts went to an abandoned inbox or that responsibility was assumed rather than assigned.
Final publication check
- The exact public certificate and endpoint have been inspected.
- Origin, CDN and IPv6 paths have been checked where relevant.
- Visitors are not told to bypass warnings.
- Renewal ownership and monitoring gaps are corrected after recovery.
Sources and date checked
Technical and policy information was checked on 21 July 2026. Recheck provider-specific procedures before making a live change.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.