Certificate errors are easier to diagnose when the problem is split into four questions: which hostname is being requested, which system presents the certificate, whether the certificate covers that hostname, and whether the client can build a trusted chain. Expiry is only one failure mode.
The word SSL is still common in error messages and searches, while most modern systems negotiate TLS. This article uses both terms naturally, but the troubleshooting work is about the certificate, hostname, trust chain and endpoint actually reached by the client.
1. Identify where TLS terminates
Start by confirming which system terminates TLS. The certificate visible to the browser may come from CloudFront or another CDN, an application load balancer, NGINX or Apache, a managed hosting platform, or the origin server. Renewing a certificate on the origin does nothing for browsers when the CDN is the public TLS endpoint.
Browser
→ CDN / reverse proxy
→ load balancer
→ NGINX
→ applicationThe first public layer that accepts the HTTPS connection determines the certificate the browser sees. The origin may have a perfect certificate and still be irrelevant for the user-facing error if the CDN or load balancer presents a different one.
2. Confirm the exact hostname being requested
Apex, www and application subdomains are separate names. Check the hostname in the address bar, the hostname after DNS resolution, and every alternate name that users or redirects may touch. Include IPv4 and IPv6 when both records exist because they can reach different endpoints.
example.com
www.example.com
app.example.comThese names require explicit certificate coverage. A valid redirect from an uncovered hostname does not solve the warning because redirects happen after the initial TLS connection. The browser must trust the certificate before it can receive the HTTP response containing the Location header.
3. Inspect SAN coverage, not only the common name
Modern clients use the Subject Alternative Name list as the authoritative hostname list. A certificate subject can look familiar while the SAN extension omits the requested name. Inspect the exact names covered by the certificate that the production endpoint presents.
Hostname matching is exact except for supported wildcard behavior. A wildcard such as the following normally covers one label below the domain:
*.example.comThat can cover names such as www.example.com and api.example.com, but it normally does not cover example.com or deep.api.example.com. If the apex and www names must both work, confirm both appear directly or through appropriate separate certificates.
4. Understand certificate-chain failures
A trusted HTTPS connection depends on more than the leaf certificate. The client must build a path from the server certificate through one or more intermediate certificate authorities to a trusted root already present in the client trust store.
Leaf certificate
→ Intermediate CA
→ Trusted root CACommon certificate-chain errors include a server that sends only the leaf certificate, an incorrect intermediate certificate, an outdated imported bundle, a client that lacks the required trust anchor, or a CDN/proxy certificate import that omitted the intermediate chain. Servers generally send the leaf and required intermediates; clients usually maintain the trusted root store themselves.
5. Distinguish expiry, trust and hostname errors
| Error type | What it means | Where to inspect |
|---|---|---|
| Expired certificate | The certificate validity window has ended. | Certificate dates on the public TLS endpoint and any CDN or load-balancer binding. |
| Not yet valid | The certificate starts in the future or client time is wrong. | Certificate notBefore date and client/server clock accuracy. |
| Hostname mismatch | The requested hostname is not listed in SAN coverage. | SAN names on the certificate actually presented for apex, www and subdomains. |
| Incomplete chain | The client cannot build a path to a trusted root. | Server bundle, imported CDN certificate chain and intermediate certificates. |
| Self-signed or untrusted issuer | The issuer is not trusted by the client. | Issuer, private CA use, client trust store and whether a public certificate was intended. |
| Wrong certificate presented | A different certificate is bound to the endpoint reached by traffic. | CDN distribution, listener, SNI configuration, IPv4/IPv6 endpoints and old load balancers. |
Do not treat “certificate valid” as a complete result. A certificate can be within its dates but fail hostname coverage, chain validation or endpoint binding.
6. Use command-line evidence
Use command-line checks to see what the endpoint presents. Include SNI with openssl because many public endpoints serve different certificates for different hostnames on the same IP address.
openssl s_client -connect example.com:443 -servername example.com -showcertscurl -Iv https://example.com/In the output, inspect the subject, SAN list, issuer, validity dates, verification result and the number of certificates sent. Avoid drawing conclusions from one line alone. For example, a successful TCP connection does not prove hostname coverage, and an issuer name alone does not prove the chain is complete.
7. Check CDN, load balancer and origin separately
A practical isolation process starts with the public hostname. Identify its DNS target, then inspect the CDN or load-balancer certificate binding before inspecting the origin. Check the origin only through a safe approved hostname; do not expose a private origin just to test a certificate.
- Inspect the public hostname first.
- Identify whether DNS points at a CDN, load balancer, reverse proxy or origin.
- Check the certificate attached to the matching distribution, listener or virtual host.
- Inspect the origin separately only through an approved hostname and access path.
- Retest the public hostname after deployment or propagation completes.
Common causes include a certificate uploaded but not attached, a certificate attached to the wrong listener, pending DNS validation, a CDN deployment still in progress, an old distribution still receiving traffic, IPv6 pointing to another endpoint, or multiple origins with inconsistent configuration.
8. Explain why different clients may disagree
One browser succeeding does not prove the configuration is correct for every client. Different clients can see different DNS answers, prefer IPv6 over IPv4, use different trust stores, cache TLS sessions, or reach different CDN edges. Some clients repair incomplete chains by fetching intermediates while others fail immediately.
Corporate proxies and TLS interception can also replace the certificate. Older operating systems may lack newer roots, and CDN edge propagation can leave one region serving old bindings briefly after a change. Treat disagreement as evidence that the request path varies, not as proof that one client is “wrong.”
9. Practical troubleshooting sequence
- Confirm the exact failing hostname.
- Check DNS resolution for A and AAAA records.
- Identify the public TLS termination layer.
- Inspect the certificate actually presented.
- Confirm SAN hostname coverage.
- Confirm validity dates.
- Validate the certificate chain.
- Compare apex, www and other expected hostnames.
- Check IPv4 and IPv6 endpoints.
- Verify CDN or load-balancer bindings.
- Retest after deployment or cache propagation.
- Document the final working request path.
The order matters. If the wrong endpoint is serving traffic, renewing a certificate elsewhere will not help. If the hostname is not covered, a redirect fix will not help. If the chain is incomplete, the leaf certificate can look correct and still fail for many clients.
10. Common mistakes
- Renewing the origin certificate when TLS terminates at the CDN.
- Assuming a wildcard certificate covers the apex domain.
- Checking the certificate without SNI.
- Fixing redirects before fixing hostname coverage.
- Validating only one hostname.
- Ignoring IPv6 records.
- Omitting intermediate certificates when importing a bundle.
- Attaching the new certificate to the wrong listener.
- Assuming a valid certificate means the whole site is secure.
11. Use the LaunchWithDilip tools
The public SSL Certificate Checker is useful when you want a browser-based point-in-time view instead of raw openssl output. It focuses on certificate trust, hostname coverage, issuer, validity, expiry and negotiated TLS evidence where available.
Domain Health Studio is better when the certificate may be only one symptom. Use it when DNS, redirects, security headers or email authentication may be part of the same production issue. Both tools are point-in-time diagnostics, not continuous monitoring.
12. When to investigate beyond the certificate
Investigate beyond the certificate when DNS points to inconsistent endpoints, apex and www redirect differently, CDN and origin configuration disagree, only some regions or networks fail, security headers or caching are involved, or a recent deployment changed routing. Certificate warnings often expose a broader ownership problem in the request path.
Conclusion
A reliable diagnosis starts by identifying the exact hostname and the exact system presenting the certificate. Expiry is only one possible failure mode; hostname coverage, chain completeness and endpoint binding are just as important.
References and further reading
- Mozilla TLS certificate guidance
- OpenSSL s_client documentation
- CloudFront alternate domain names and HTTPS