Expired HTTPS certificates are common public failures. Teams often assume automatic renewal solves the issue, but risk returns when domain accounts move, DNS validation breaks, server access changes, reverse proxy rules shift, or multiple nodes are not updated consistently.
Confirm who controls the domain
Renewal depends on domain validation. If DNS access belongs to a former employee, a supplier's personal account, or a temporary registrar, automation is not reliable. Domain ownership, DNS permission, alternate contacts, and change records belong in the asset inventory.
HTTP and DNS validation serve different conditions
HTTP validation is simple for one site but can be affected by CDN, proxy, multi-origin, and static hosting rules. DNS validation supports wildcard and multi-node use but requires reliable DNS control. The decision should consider migration and recovery, not just initial speed.
Issued does not mean deployed
A certificate may renew on one server without reaching the proxy. It may cover the primary domain but miss a subdomain. It may also ship with an incomplete chain. Acceptance should verify certificate, domain, expiry, chain, and redirect externally.
| Risk | Check | Record |
|---|---|---|
| Domain account | Registrar and permission | Owner, contact, fallback |
| Validation | HTTP or DNS test | Path and records |
| Deployment | External TLS inspection | Nodes, proxies, chain |
| Alerting | Expiry monitoring | Threshold, recipient, action |
Renewal belongs in the operating rhythm
Create reminders at least 30 days before expiry, confirm renewal 14 days before, and escalate within 7 days. Certificate incidents are immediately visible to users and should be checked like backups and monitoring.