SSL certificate expiration can make a healthy website appear broken, while DNS changes, incomplete renewals, and mixed content can create similar HTTPS warnings. This checklist explains what to monitor, how to verify a certificate from a browser or command line, and how to troubleshoot renewal failures before they affect visitors.
Overview
An SSL certificate enables a browser to establish an encrypted HTTPS connection with a website. In current technical usage, the encryption is provided by TLS, but hosting dashboards and everyday discussions still commonly use the term SSL certificate. A certificate is issued for specific hostnames, has a validity period, and is presented by the web server during the TLS handshake.
A certificate warning does not always mean the certificate has expired. The browser may be reporting that the certificate is issued for a different hostname, cannot be linked to a trusted issuer, is not yet valid, or is being served by the wrong server. A page can also load over HTTPS while still requesting images, scripts, fonts, or stylesheets over HTTP, producing a mixed-content warning.
The most reliable approach is to treat HTTPS as a lifecycle rather than a one-time setup task. Record which domains and subdomains need certificates, identify how each certificate is renewed, monitor the expiry date, and test the live endpoint after every renewal or infrastructure change. For broader server protection, use this website hosting security checklist alongside the certificate checks below.
What to track
Certificate identity and coverage
For every public hostname, record the certificate's subject names or SANs, issuer, expiration date, and the server or hosting account that presents it. Confirm that the certificate covers the exact hostname visitors use, such as www.example.com and example.com. A certificate for one hostname does not automatically cover every subdomain.
Include less visible endpoints in the inventory: staging sites that are publicly reachable, API subdomains, customer portals, mail-related hostnames when applicable, and alternate domains that redirect to the main site. Remove retired hostnames from monitoring only after confirming that they are no longer used.
Renewal method and ownership
Record whether renewal is handled by a hosting panel, a managed WordPress platform, a reverse proxy, a CDN, or an ACME client running on a VPS. Also record where DNS validation is performed and which account controls the DNS zone. Renewal automation can fail when credentials expire, a DNS provider changes, a web server stops serving the validation file, or port 80 and port 443 traffic reaches the wrong system.
Keep an operational contact and a documented recovery path. The person investigating an alert should know how to access the hosting panel, DNS provider, server, certificate logs, and deployment configuration without searching through old messages.
Chain, protocol, and application behavior
Monitor more than the date. A server can have a current certificate but send an incomplete certificate chain, serve an old certificate from one IP address, or use a configuration that behaves differently over IPv4 and IPv6. Check the live certificate from outside the hosting environment and test the main redirect path from HTTP to HTTPS.
After a certificate change, inspect the page for mixed content and verify that application URLs, canonical links, redirects, cookies, webhooks, and API calls use the intended scheme. DNS records determine where traffic goes, so review the relevant A, AAAA, and CNAME records when the result does not match the expected server. The DNS records guide provides a useful reference for that review.
Cadence and checkpoints
Use a monthly review for ordinary websites and a shorter interval for business-critical services or frequently changing infrastructure. A practical review should include the following checkpoints:
- Review expiry alerts: Confirm that every production hostname has an alert with enough lead time for investigation and manual renewal if automation fails.
- Check the inventory: Compare monitored hostnames with the current domain, DNS, hosting, and deployment records. Add new subdomains and remove obsolete entries deliberately.
- Inspect renewal logs: Look for successful issuance, validation errors, permission failures, rate-limit messages, or jobs that stopped running.
- Test the public endpoint: Open the site in a clean browser session and use an external TLS checker or command-line test. Do not rely only on the local browser cache.
- Verify redirects and content: Test both the apex domain and the www hostname, along with important landing pages, login forms, APIs, and assets.
Repeat the full checklist after changing nameservers, A or AAAA records, CDN settings, load balancers, web servers, control panels, or hosting providers. It is also part of a sensible website migration to cloud hosting plan because the new server may not inherit the previous certificate or renewal configuration.
How to interpret changes
Start with the exact browser message and the hostname in the address bar. Then compare DNS resolution with the server you expect. A warning that appears only on one hostname often points to incomplete certificate coverage or a separate virtual-host configuration. A warning that appears after a DNS change may indicate that traffic has reached an old server, a default server, or a platform that has not yet issued a certificate.
| Symptom | Likely area to check | First action |
|---|---|---|
| Certificate expired | Renewal job, hosting panel, or ACME client | Renew through the documented method, then verify the live endpoint and chain. |
| Hostname mismatch | Certificate names, virtual host, or DNS target | Confirm the requested hostname and identify which server answers it. |
| Certificate not trusted | Certificate chain or unusual local trust store | Check that the server sends the required intermediate certificates and test from another network. |
| Mixed-content warning | Application URLs, templates, plugins, or cached assets | Locate HTTP requests in browser developer tools and update them to HTTPS. |
| Renewal validation failed | DNS records, port access, redirects, or validation permissions | Check the validation method and confirm that the challenge reaches the correct host. |
| Works on one network only | DNS propagation, split DNS, IPv6, proxy, or caching | Compare DNS answers and certificate details over multiple networks and address families. |
Browser and command-line verification
In a browser, open the connection or security details for the page and inspect the certificate names, issuer, validity dates, and chain. Use a private window or a separate device when checking a recent fix. Developer tools can identify mixed-content requests and reveal whether a redirect ends at the intended HTTPS URL.
From a trusted administration system, OpenSSL can display the certificate presented by a host:
openssl s_client -connect example.com:443 -servername example.com -showcertsThe -servername option matters on servers hosting multiple sites because it sends the requested hostname during the handshake. Review the returned subject names, dates, and chain. A simple HTTP header check can also show redirect behavior:
curl -I http://example.com
curl -I https://example.comThese commands do not replace application testing. They help separate a TLS problem from a redirect, DNS, or page-content problem.
When to revisit
Revisit this checklist monthly or quarterly, depending on the importance and rate of change of the site. Always run it before a known certificate expiration window, after a hosting or DNS migration, and after changing a CDN, reverse proxy, load balancer, web server, or WordPress security plugin. Include it in deployment and disaster-recovery runbooks rather than leaving it as an individual administrator's memory.
When a certificate expires unexpectedly, first preserve evidence: note the time, affected hostname, browser error, DNS answers, server identity, and renewal log output. Restore service using the approved hosting or ACME process, then investigate why monitoring or automation did not prevent the incident. Avoid installing a certificate for the wrong hostname merely to remove the warning; that can conceal the routing problem.
For the next review, update the inventory with any new domains and subdomains, confirm alert recipients, test one renewal or recovery path in a controlled environment where practical, and link the result to your uptime records. The website uptime and performance monitoring guide can help connect certificate failures with availability monitoring, while the domain-to-hosting checklist is useful when DNS is part of the incident.
Action checklist: inventory every HTTPS hostname, record its renewal owner and method, alert before expiration, test the public certificate, inspect redirects and mixed content, and repeat the checks after every DNS or hosting change.
