How do I check if my SSL certificate is valid?
Five things to verify, how to check each from the command line, and the failure that only shows up on mobile.
Verify five things: it has not expired, it covers the exact hostname you serve, the intermediate chain is complete, it was issued by a trusted authority, and the protocol and cipher negotiated are modern. A browser padlock confirms the first four for your browser only — the chain problem is the one it can hide.
Check it from the command line
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltNameThat returns the subject, issuer, validity window and every hostname the certificate covers — which is everything you need for four of the five checks.
The five things
1. Expiry
Certificates last 90 days from Let's Encrypt, up to about a year elsewhere, and the industry is moving shorter. The real question is not the date but whether renewal is automated and whether you would find out if it stopped. Expired certificates are almost always automation failures rather than forgetfulness.
2. Hostname coverage
The certificate must list every hostname you serve. example.com and www.example.com are different names and both must appear. Wildcards such as *.example.com cover one level only — they do not cover a.b.example.com, and they do not cover the bare apex.
3. Chain completeness
Your server must send the intermediate certificate alongside your own. This is the failure that produces "it works on my computer": desktop browsers often fetch the missing intermediate themselves, while mobile browsers and command-line clients do not.
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep -A2 "Certificate chain"A chain of one certificate where there should be two is the tell. Fix it by configuring the full-chain file rather than the certificate alone — with Certbot, use fullchain.pem, not cert.pem.
4. Trusted issuer
The issuing authority must be in the browser trust stores. Any mainstream CA is. Self-signed certificates are fine on internal systems and never acceptable publicly.
5. Protocol and cipher
TLS 1.2 as a minimum, 1.3 preferred. TLS 1.0 and 1.1 are deprecated and rejected by current browsers. If you are still serving them, that is a configuration left over from years ago.
-servername in the commands above sets SNI. Without it you may be handed a default certificate belonging to a different site on the same server, and conclude your certificate is wrong when it is fine. Always pass it.Monitoring instead of remembering
- Automate renewal — Certbot, ACME, or your host's built-in mechanism.
- Add expiry monitoring that alerts you at 21 days, independently of the renewal system. If they share a failure mode, you have no monitoring.
- Verify from an external network after any certificate change, not just from your own machine.
- Test on a real mobile device, which is where chain problems surface first.
- Publish a CAA record naming your CA, so no other authority can issue for your domain.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- Subject, issuer, serial, validity window and days remaining, read from a real TLS handshake.
- Every hostname in the certificate, and whether the audited host matches, wildcards included.
- Chain length and whether verification succeeds without help.
- Negotiated protocol version and cipher suite.
For agents and scripts, the same measurement is at
/api/v1/tls?url=yoursite.com —
see the API documentation.
Related questions
How often do certificates need renewing?
Let's Encrypt issues for 90 days and recommends renewing at 60. Commercial certificates have historically run up to a year, and maximum lifetimes are shortening across the industry. Either way, automate it.
Does a wildcard certificate cover subdomains of subdomains?
No. *.example.com covers www.example.com but not api.v2.example.com. It also does not cover the bare example.com unless that is listed separately.
What is a CAA record?
A DNS record naming which certificate authorities may issue for your domain. Without one, any public CA may issue a certificate for you. It is one DNS record and it closes a real gap.
Read next
Why does my site say "Not Secure"?
Either you are not on HTTPS at all, or you are and something on the page is not. The second is harder to spot.
ReadWhat is a CAA record and do I need one?
A DNS record naming which certificate authorities may issue certificates for your domain. One line, and it closes a real gap.
ReadWhat is HSTS and should I enable it?
It forces browsers to use HTTPS for your domain. Almost always worth it — with two decisions that are genuinely hard to reverse.
ReadIs my website secure? How do I check?
What you can verify yourself in twenty minutes, what needs tooling, and what "secure" does and does not mean.
Read