Open a certificate in your browser and you get a wall of fields, most of which you'll never need. A handful of them answer nearly every real question: which names does it cover, who issued it, when does it expire, and will every client be able to verify it. Here's how to find those fields and what they're telling you.
There are three easy ways to look.
In a browser, click the icon to the left of the address (it's no longer always a padlock), choose the connection or security details, and open the certificate viewer. Fine for a quick look, but browsers show you the chain they built, which may not be the chain the server actually sent.
Our SSL certificate checker fetches the certificate the way a client would and lays out the subject, issuer, alternative names, validity dates, serial number and SHA-256 fingerprint, plus whether it's trusted.
For everything, use openssl:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -textThat prints the full decoded certificate. To pull out just the fields that matter, swap -text for -subject -issuer -dates -ext subjectAltName.
The Subject is usually just CN=example.com. It looks like the important bit, but it isn't. Browsers match the hostname against the Subject Alternative Name (SAN) extension and ignore the common name. Chrome stopped relying on the CN back in 2017.
X509v3 Subject Alternative Name:
DNS:example.com, DNS:*.example.comA few rules catch people out:
*.example.com matches www.example.com and shop.example.com, but not a.b.example.com, and not the bare example.com. That's why certificates usually list the apex and the wildcard side by side, as above.www isn't in the SAN, visitors to www.example.com get a name mismatch: NET::ERR_CERT_COMMON_NAME_INVALID in Chrome, SSL_ERROR_BAD_CERT_DOMAIN in Firefox. The certificate is valid, just not for that name.The Issuer field names the certificate authority that signed this certificate. In practice that's an intermediate CA, not the root. You'll see something like O=Let's Encrypt, CN=R12 or a commercial CA's issuing name. Let's Encrypt rotates between several short-named intermediates, so the exact name changes over time and isn't worth hard-coding anywhere.
The validation level lives in the Certificate Policies extension as an object identifier:
2.23.140.1.2.1: domain validated (DV). The CA checked you control the domain, nothing more.2.23.140.1.2.2: organisation validated (OV). The CA also checked the organisation exists, and its name appears in the Subject as O=.2.23.140.1.1: extended validation (EV).Encryption strength is identical across all three. Chrome and Firefox stopped showing the company name for EV in the address bar in 2019, so to a normal visitor the three look the same. The difference is only visible to someone who opens the certificate.
notBefore=Jul 29 22:10:08 2026 GMT
notAfter=Oct 27 22:17:21 2026 GMTBoth times are in UTC. notAfter is the expiry, and the moment it passes, clients reject the certificate (see what an expired certificate looks like and how to fix it). A notBefore in the future also fails, which happens when a client's clock is wrong or a certificate was installed moments after issue on a server with clock drift.
The gap between the two dates tells you something too. A 90-day or shorter span points to automated issuance, usually ACME. Under the CA/Browser Forum's current rules, publicly trusted certificates issued from 15 March 2026 can last at most 200 days, falling to 100 days in March 2027 and 47 days in March 2029. So if you find a public certificate valid for over a year, it was issued before that change, and its replacement will have a much shorter life.
Clients don't trust your certificate directly. They trust a small set of root certificates built into the operating system or browser, and your certificate has to link back to one of them through one or more intermediates. See what the server actually sends with -showcerts:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/nullEach certificate prints an s: (subject) and i: (issuer) line:
0 s:CN=example.com
i:C=US, O=Example CA, CN=Example Issuing CA 1
1 s:C=US, O=Example CA, CN=Example Issuing CA 1
i:C=US, O=Example CA, CN=Example Root CARead it as a chain: each certificate's issuer should be the next one's subject. Certificate 0 is your leaf. The server should send the leaf and every intermediate. It doesn't need to send the root, since clients already have it. Near the bottom, Verify return code: 0 (ok) means openssl could build a trusted path.
The most common chain bug is a missing intermediate, and it's sneaky because desktop browsers often paper over it. Firefox preloads known intermediates and some browsers fetch missing ones, so the site looks fine to you. curl, many Android apps, API clients and payment gateways don't do that, so they fail with "unable to get local issuer certificate". If the checker says untrusted but your browser shows a padlock, suspect the chain first. The fix is to install the full chain file your CA provides (certbot calls it fullchain.pem) rather than the leaf alone.
No. It means the connection is encrypted and the certificate matches the domain name. A phishing site on a lookalike domain can get a DV certificate as easily as anyone else. The certificate proves which domain you're talking to, not whether that domain is honest.
Certificate Transparency logs are public, and search tools such as crt.sh let you query them by domain. It's a good way to spot certificates you didn't know about, including ones issued by a forgotten service or a CA you never used.
Either the browser built a different chain from the same leaf, or you're reaching a different server. Compare the SHA-256 fingerprints. If the leaf fingerprints match, it's a chain difference. If they don't, you have more than one server or IP answering for that name.
No. Clients only trust roots they already hold, so sending one adds bytes and nothing else. Send the leaf followed by the intermediates, in order.
0 comments
No comments yet. Be the first.