How do I read a TLS certificate?
What each field in a certificate means, which ones actually matter, and how to inspect any site's certificate in one command.
A certificate asserts that a particular public key belongs to particular hostnames, vouched for by an issuer, within a validity window. Four fields carry almost all the practical meaning: the subject alternative names, the validity dates, the issuer, and whether the served chain is complete.
Reading one
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltNameThe -servername flag is not optional in practice. Without it no SNI is sent, and a shared host will hand you the default certificate for that IP rather than yours — which looks exactly like a misconfiguration and is not one.
The fields worth understanding
Subject Alternative Name — the one that matters
The SAN list is what browsers check. The Common Name in the subject is legacy and ignored by every modern client, so a certificate can have a perfect-looking CN and still fail if the hostname is absent from the SAN list.
A wildcard such as *.example.com covers exactly one label: www.example.com yes, a.b.example.com no, and the bare apex example.com no — which is why the apex is so often the one that breaks. It needs its own entry.
Validity dates
Not-before and not-after. A certificate is untrusted outside that window, with no grace period. The failure at expiry is total: every visitor gets a full-page interstitial, not a subtle warning.
Public certificate lifetimes have been shortening steadily, and automated renewal is now the only sustainable approach. If renewal is a calendar reminder rather than a cron job, it will eventually be missed.
Issuer
Which CA signed it. Worth checking mainly as a change-detection signal: an issuer you did not expect means either a migration you forgot about or something that warrants immediate attention.
The chain
Servers must send the leaf certificate and any intermediates. Browsers often paper over a missing intermediate by fetching it themselves; many other clients do not. The classic symptom is a site that works perfectly in Chrome and fails from curl, a mobile app or a server-side integration.
openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
| grep -c 'BEGIN CERTIFICATE'One result usually means the intermediate is missing. Two or three is normal.
What else the handshake reveals
The certificate is only part of it. The negotiated connection matters as much:
- Protocol version. TLS 1.2 is acceptable, 1.3 is better. Anything offering TLS 1.0 or 1.1 is running configuration nobody has revisited in years.
- Cipher suite. Modern suites provide forward secrecy, so a future key compromise cannot decrypt traffic captured today.
- HSTS. A response header rather than a certificate property, and the thing that stops a first request being downgraded to plain HTTP.
The failures you will actually meet
| Symptom | Cause |
|---|---|
| Works on www, fails on the apex | Wildcard SAN does not cover the bare domain |
| Works in Chrome, fails from curl | Missing intermediate; the browser fetched it, curl did not |
| Expired despite auto-renewal | Renewal succeeded but the service was never reloaded |
| Wrong certificate entirely | Testing without SNI, or a shared IP serving its default |
| Valid certificate, still insecure warnings | Mixed content — the page loads http:// subresources |
The third row is the most common real-world outage of the set. Renewal writing a new file is not the same as the running process using it.
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.
- Certificate issuer, validity window and days remaining, read from the handshake rather than inferred.
- Whether the hostname is genuinely covered by the subject alternative names, including the apex-versus-wildcard case.
- Chain completeness, so a missing intermediate is caught even when a browser would silently paper over it.
- Negotiated protocol version and cipher, plus whether HSTS is present and what its max-age is.
For agents and scripts, the same measurement is at
/api/v1/tls?url=yoursite.com —
see the API documentation.
Related questions
How long before expiry should I worry?
Renewal should be automated and should run with at least a third of the lifetime remaining. For alerting, 21 days is a sensible threshold — enough time to notice, investigate and fix a broken renewal without urgency.
Does a wildcard cover my apex domain?
No. *.example.com covers one label of subdomain and not the bare apex. The apex needs its own SAN entry, and forgetting it is one of the most common certificate faults.
Why does my site work in a browser but not from a script?
Usually a missing intermediate certificate. Browsers can fetch a missing intermediate themselves; curl, mobile apps and server-side HTTP clients generally will not. Serving the full chain fixes it everywhere at once.
Is a free certificate less secure?
No. The cryptography is identical and free automated issuance produces better outcomes in practice, because certificates that renew automatically do not expire. Paid certificates differ in warranty and organisational validation, not in protection.
Read next
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.
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.
ReadWhy 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 do my DNS records actually say?
Reading your own DNS from first principles — which records exist, what each one decides, and the four commands that show you all of them.
Read