SSL problems often look like hosting failures, but the cause may be an expired certificate, incorrect domain coverage, incomplete DNS or CDN configuration, or insecure content loaded by the page. This guide provides a practical SSL certificate troubleshooting process, including what to monitor, how often to check it, and how to distinguish certificate errors from related domain and hosting problems.
Overview
HTTPS depends on several connected systems: your domain registration, DNS records, web server, SSL/TLS certificate, redirects, and sometimes a CDN or reverse proxy. A certificate can be correctly installed on the origin server while visitors still see an error because the CDN presents a different certificate, DNS points to an old host, or the requested hostname is not included in the certificate.
The first step in SSL certificate troubleshooting is to identify what the browser is actually reporting. Messages such as ERR_CERT_DATE_INVALID, “connection is not private,” “certificate name mismatch,” and “NET::ERR_CERT_COMMON_NAME_INVALID” point to different categories of problems. A mixed content warning is different again: the main page may have a valid certificate, but it is loading images, scripts, stylesheets, fonts, or other resources over plain HTTP.
Because certificates expire and domain infrastructure changes, HTTPS should be treated as an ongoing domain-management responsibility rather than a one-time launch task. Keep a record of certificate coverage, renewal ownership, DNS changes, hosting endpoints, and CDN settings. For related record configuration, see DNS Records Explained: How to Configure A, CNAME, MX, TXT, and AAAA Records.
What to track
A small monitoring checklist can reveal whether an HTTPS error is isolated or part of a wider domain configuration problem. Track the following for every production domain and important subdomain.
| Symptom | Likely cause | First check |
|---|---|---|
| Certificate expired or not yet valid | Renewal failed, the wrong certificate was installed, or the server clock is inaccurate | Inspect the certificate validity dates and confirm the server time |
| Hostname or common-name mismatch | The certificate does not cover the exact hostname being visited | Compare the URL with the certificate’s subject alternative names |
| Certificate chain error | One or more intermediate certificates are missing or served incorrectly | Check the complete chain delivered by the server or CDN |
| Mixed content warning | HTTPS page resources still use http:// URLs | Review browser developer tools and page source for insecure requests |
| HTTPS redirects to HTTP | Redirect rules, application settings, or proxy headers are incorrect | Follow the redirect sequence and inspect origin and proxy configuration |
| Works on the origin but fails through a CDN | CDN certificate mode, hostname, or origin TLS setting is inconsistent | Test the public hostname separately from the origin hostname |
| Only one subdomain fails | That subdomain has separate DNS, hosting, or certificate settings | Check its DNS record and certificate coverage independently |
Record the certificate issuer, expiration date, covered hostnames, renewal method, and installation location. The installation location matters when a site uses a load balancer, container platform, hosting panel, or CDN. Renewing a certificate at one layer does not necessarily replace the certificate being shown to visitors at another.
Also track DNS changes. An A or AAAA record may send visitors to a different server than the one you tested, while a CNAME may send a subdomain through a managed service. If a domain recently moved, allow for DNS caching and verify the authoritative records before changing certificates repeatedly. For ownership and account protections, use the recommendations in the Domain and DNS Security Checklist.
Cadence and checkpoints
Use a layered schedule rather than waiting for a browser warning.
At least monthly
- Open the primary domain and key subdomains over HTTPS.
- Confirm that HTTP requests redirect to the intended HTTPS URL.
- Review certificate expiration and renewal status in the hosting panel, certificate manager, or ACME client.
- Check basic uptime monitoring for TLS handshake, redirect, and hostname errors.
Quarterly
- Test every important hostname, including
www, the root domain, application subdomains, and customer-facing endpoints. - Review DNS records against the current hosting and CDN architecture.
- Inspect certificate chains and confirm that renewal alerts reach someone responsible for the domain.
- Scan representative pages for mixed content after major theme, plugin, application, or asset changes.
After infrastructure changes
Run a full HTTPS check after domain registration changes, a domain transfer, website migration, hosting changes, DNS edits, CDN activation, server replacement, or a change to automatic certificate renewal. Test from outside the administrative network when possible; internal DNS overrides can hide a public configuration problem.
For a broader maintenance routine, combine these checks with the steps in How to Check Website Uptime and Performance. Certificate monitoring should be connected to uptime monitoring, but it should not replace it: a valid certificate does not prove that the application is available or functioning.
How to interpret changes
When an SSL certificate is not working, change one layer at a time and retest. Start with the public hostname and capture the exact certificate and redirect behavior presented to a visitor. Then compare it with the intended DNS target, CDN configuration, and origin server.
- Confirm the exact URL. Check whether the failure affects the root domain,
www, a subdomain, or an alternate port. A certificate for one hostname may not cover another. - Inspect validity and coverage. Verify the start and expiration dates and review all subject alternative names. A wildcard certificate has defined coverage; do not assume it covers every possible hostname.
- Check DNS resolution. Compare A, AAAA, and CNAME responses with the server or service that should answer for the hostname. An unexpected IPv6 record can send some visitors to a misconfigured server even when IPv4 works.
- Check the chain. The server generally needs to present the leaf certificate together with the required intermediate certificates. Installing only the site certificate can cause trust errors in some clients.
- Trace redirects. Follow the request from HTTP to HTTPS and through any canonical-domain redirect. Look for loops, an HTTPS-to-HTTP step, or an application that believes the original request was not secure because proxy headers are missing.
- Find mixed content. Replace hard-coded HTTP asset URLs with HTTPS or protocol-independent application settings where appropriate. Update database values, templates, scripts, CSS, and third-party integrations rather than relying only on a browser-side workaround.
- Compare CDN and origin behavior. If a CDN is enabled, verify the certificate for the public hostname, the connection mode to the origin, and whether the origin certificate covers the hostname the CDN uses. Avoid making repeated changes until you know which layer is serving the failing certificate.
Automatic renewal failures deserve special attention. Check whether the renewal client can complete its validation challenge, whether port 80 or required DNS records are available for that validation method, and whether permissions allow the renewed certificate to be installed and reloaded. If renewal succeeds but visitors still see the old expiration date, the certificate may not have been deployed to every server, load balancer, or CDN edge.
When to revisit
Revisit this guide monthly for high-value websites and at least quarterly for lower-change projects. Schedule an extra review before a certificate’s renewal window, although the exact timing depends on the certificate provider and automation used. Do not wait for the browser to report an outage.
Update your checklist whenever the domain’s ownership, DNS provider, hosting platform, CDN, certificate authority, renewal method, or application architecture changes. A domain transfer is also a useful trigger: confirm that DNS remains correct, certificate automation still has access, and the new registrar or hosting account contains current renewal and security contacts. The Domain Renewal and Expiration Guide can help prevent registration and renewal issues that are separate from certificate expiry.
For a practical next step, create a simple inventory with these columns: hostname, DNS target, certificate source, expiration date, renewal method, CDN or proxy, last test date, and owner. Test each row over HTTPS, save the observed result, and investigate only the rows that differ from the expected configuration. If a change causes a wider outage, use a tested backup and restore process as part of recovery; see the Website Backup and Restore Testing Guide.
Finally, record the fix and its cause. “Renewed certificate” is less useful than “renewal completed, but deployment to the load balancer was missed.” Clear notes turn the next SSL certificate troubleshooting session into a short verification task instead of a rushed investigation.
