Your certificate loads fine on your laptop, so you assume it's healthy — then a customer on their phone sees a full-page security warning, or a webhook silently stops firing. Nearly every one of these outages traces back to a handful of certificate problems that are invisible unless you look. This guide explains what to check, why the chain matters more than the certificate itself, and how to stay ahead of expiry.
What an SSL/TLS certificate proves
“SSL certificate” is the everyday name for what is technically a TLS certificate — SSL is the deprecated predecessor of TLS, but the name stuck. Whatever you call it, the certificate is a small signed file your server presents at the start of an HTTPS connection, and it does two distinct jobs.
First, it enables encryption: the certificate contains the server's public key, which the client uses to negotiate a secret session key so traffic can't be read in transit. Second, and more subtly, it provides identity: the certificate is signed by a Certificate Authority (CA) that has verified you control the domain. That signature is what lets a browser display example.com in the address bar and trust that it is really talking to example.com and not an impostor on the same network.
A certificate binds three things together: a domain name (or several, listed in the Subject Alternative Name field), a public key, and a validity window (notBefore and notAfter dates). If any of those don't line up with reality — wrong name, expired window, untrusted signer — the client rejects the connection. Encryption without verified identity is nearly worthless, which is why every failure below is really a failure of trust, not of math.
The certificate chain — and the #1 silent failure
No public CA signs your certificate with its precious root key directly. Instead, trust flows through a chain of certificates:
- Root CA certificate — a self-signed certificate baked into every operating system and browser trust store. Roots are kept offline and rarely used to sign anything but intermediates.
- Intermediate certificate — signed by the root, this is the certificate that actually signs your certificate. There may be more than one intermediate in the chain.
- Leaf (end-entity) certificate — your domain's certificate, signed by the intermediate.
To trust your site, a client walks this chain upward: leaf → intermediate → root, verifying each signature until it reaches a root it already trusts. If any link is missing, the walk fails and the connection is rejected.
The most common SSL errors and their causes
Most certificate warnings map to a short list of root causes. Knowing which one you're looking at tells you exactly what to fix:
| Error | What the client sees | Concrete cause |
|---|---|---|
| Expired certificate | NET::ERR_CERT_DATE_INVALID | Current date is past notAfter; auto-renewal failed or was never set up |
| Name mismatch | ERR_CERT_COMMON_NAME_INVALID | The domain isn't listed in the certificate's SAN field (e.g. cert for www but visitor used the bare domain) |
| Self-signed | “Not trusted” / ERR_CERT_AUTHORITY_INVALID | Certificate signed by itself, not a public CA — common on staging/dev servers left exposed |
| Unknown issuer | “Issued by an unknown authority” | Signed by an internal or private CA the client's trust store doesn't contain |
| Incomplete chain | Works in some clients, fails in others | Server sends the leaf but not the intermediate(s) |
| Revoked | ERR_CERT_REVOKED | CA revoked the certificate (key compromise, mis-issuance) — flagged via OCSP/CRL |
| Weak signature | “Obsolete/weak security” | Old algorithm like SHA-1, or an undersized RSA-1024 key no longer accepted |
| Mixed content | Padlock with warning; blocked resources | HTTPS page loads scripts/images over plain http:// after the cert is installed |
Two of these routinely get misdiagnosed. A name mismatch is a certificate problem, not a DNS problem — the fix is to reissue the certificate with the correct name in the SAN list, or add a redirect so users land on a covered hostname. Mixed content isn't a certificate flaw at all: the certificate is valid, but the page undermines it by pulling in insecure sub-resources, so update those URLs to https:// (or protocol-relative) references.
How to check a certificate
A quick manual inspection — clicking the padlock in a browser — only tells you what your browser thinks, and your browser may be papering over an incomplete chain. A proper certificate check looks at the connection the way a strict client would, and reports on five things:
- Expiry date. Read
notAfterand confirm you have comfortable runway — ideally more than 30 days. - Subject Alternative Names (SANs). Confirm every hostname you actually serve — bare domain,
www, and any subdomains — appears in the SAN list. The old Common Name field is ignored by modern browsers. - Issuer. Verify it's a publicly trusted CA and not a stray self-signed or internal certificate.
- Chain order and completeness. Confirm the server sends the leaf followed by the correct intermediate(s), in order, with no missing links and no root.
- Protocol and cipher. Confirm the server negotiates a modern protocol (TLS 1.2 or 1.3) and a strong cipher, and isn't still offering deprecated SSLv3/TLS 1.0.
Check your SSL certificate now
Inspect the full chain, SANs, issuer, protocol, and exact expiry date for any domain — free, no signup.
Open the SSL Checker →Expiry monitoring & auto-renewal
Certificate lifetimes keep shrinking. Public TLS certificates are capped at 398 days, and free CAs like Let's Encrypt issue 90-day certificates on purpose — the short window is meant to force automation. That's healthy in principle, but it means expiry is now a recurring event, not a once-a-year chore, and the failure mode has shifted from “we forgot to renew” to “automation broke and nobody noticed.”
Auto-renewal tools such as certbot handle the happy path, but they fail quietly in ways worth planning for:
- A firewall change blocks the ACME HTTP-01 or DNS-01 challenge, so renewal can't validate.
- The renewed certificate is issued but the web server is never reloaded, so it keeps serving the old file.
- A host migration leaves the renewal cron job or credentials behind on the old server.
Because renewal can fail silently, independent expiry monitoring is not optional. Set an alert at 30 days before expiry — that's enough runway to debug a stuck ACME challenge, reissue manually if needed, and redeploy without an outage. Monitor from outside your own infrastructure so you're testing the certificate visitors actually receive, not the file sitting on disk.
Troubleshooting
“It works for me but a customer sees a warning”
Almost always an incomplete chain. Test with a strict client (Firefox, or curl -v / openssl s_client -connect host:443) rather than desktop Chrome, then reinstall the certificate with the full intermediate chain and reload the server.
Padlock is missing even though the certificate is valid
Suspect mixed content. Open the browser console and look for blocked http:// resources on the page, then switch those URLs to https://.
Certificate is valid but the name is wrong
The hostname isn't in the SAN list. Reissue the certificate covering every name you serve, or add a redirect so visitors reach a hostname the certificate actually covers.
Renewed the certificate but the old one is still served
The new certificate was issued but the service wasn't reloaded. Restart or reload the web server (or load balancer) so it picks up the new file, then re-check the served expiry date.