A TLS certificate is a small signed file that ties one or more hostnames to a public key. A certificate authority (CA) checks that whoever asked for it controls those names, then signs it. When your browser or API client connects, the server hands over the certificate, proves it holds the matching private key, and the client checks the CA's signature against a list of roots it already trusts. If any of that fails, the connection stops. "SSL certificate" means the same thing: SSL is the protocol TLS replaced years ago, and the name stuck.
That's the definition. The useful part is reading one, so here's a real certificate pulled off a live server.
Pull One Off a Live Server
openssl s_client connects the way any client would and prints what it negotiated. The -brief flag keeps it to the summary:
$ openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org -brief </dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_128_GCM_SHA256
Peer certificate: CN=letsencrypt.org
Hash used: SHA256
Signature type: ecdsa_secp256r1_sha256
Verification: OK
Peer Temp Key: X25519, 253 bits
Verification: OK means the chain reached a trusted root and the name matched. Keep -servername in every command like this: it sends SNI, and without it a shared IP may hand you some other site's certificate.
To see the certificate itself, pipe the connection into openssl x509:
$ openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org </dev/null 2>/dev/null \
| openssl x509 -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
05:43:93:3b:e3:86:b3:a2:b3:ad:d5:34:f2:10:3b:c8:b6:5f
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=US, O=Let's Encrypt, CN=YE2
Validity
Not Before: Sep 4 14:34:32 2026 GMT
Not After : Dec 3 14:34:31 2026 GMT
Subject: CN=letsencrypt.org
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
16:68:8D:1E:2A:32:48:8C:B5:F1:10:0A:16:08:37:08:3B:9D:30:23
X509v3 Authority Key Identifier:
B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
Authority Information Access:
CA Issuers - URI:http://ye2.i.lencr.org/
X509v3 Subject Alternative Name:
DNS:cp.letsencrypt.org, DNS:cp.root-x1.letsencrypt.org, DNS:cps.letsencrypt.org,
DNS:cps.root-x1.letsencrypt.org, DNS:lencr.org, DNS:letsencrypt.com,
DNS:letsencrypt.org, DNS:www.lencr.org, DNS:www.letsencrypt.com,
DNS:www.letsencrypt.org
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://ye2.c.lencr.org/96.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : D8:09:55:3B:94:4F:7A:FF:C8:16:19:6F:94:4F:85:AB:
B0:F8:FC:5E:87:55:26:0F:15:D1:2E:72:BB:45:4B:14
Timestamp : Sep 4 15:33:02.377 2026 GMT
...
The public key bytes, the remaining timestamps, and the CA's signature are trimmed, and the SAN line is wrapped to fit. Run it yourself and the serial, dates, and issuer will differ: this certificate gets replaced every few weeks.
Reading the Fields
Most of that output is boilerplate you'll never touch. These are the lines that decide whether a client connects:
| Field | What it says | What breaks when it's wrong |
|---|---|---|
| Subject Alternative Name | Every hostname the certificate covers | A name missing here fails the hostname check, whatever the CN says |
| Subject (CN) | A legacy name field | Nothing in browsers, which ignore it. SAN is what counts |
| Issuer | The CA certificate that signed this one | The client can't build a chain if it can't find this issuer |
| Validity | Not Before and Not After, in GMT | Outside the window, every client refuses it |
| Public Key | The key the server must prove it holds | A key the server doesn't have means it can't finish the handshake |
| Key Usage / Extended Key Usage | What the key may be used for | An EKU list that leaves out TLS Web Server Authentication gets rejected for HTTPS |
| Basic Constraints | CA:FALSE marks it as a leaf |
A leaf marked CA:TRUE trips errors like Firefox's MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY |
| CRL Distribution Points | Where to check if it's been revoked | Revocation checkers have nowhere to look |
| Authority Information Access | Where to fetch the issuer's certificate | Clients that repair broken chains can't |
| Certificate Policies | 2.23.140.1.2.1 means domain validated |
Informational |
| CT Precertificate SCTs | Proof it was logged publicly | Chrome and Safari reject public certificates without them |
A few of these are worth a second look on this particular certificate. It covers ten names, from letsencrypt.org to www.lencr.org, and the CN only mentions one. The validity window runs from September 4 to December 3: 90 days. There's no OCSP URL in the Authority Information Access block, only the CA Issuers link, because Let's Encrypt shut its OCSP service down and moved revocation to CRLs, which is why the CRL Distribution Points line matters more than it used to. Our post on how certificate revocation is changing covers what that shift means for clients.
The Chain Behind It
A leaf certificate is only trusted because something trusted signed it. Add -showcerts and the server prints everything it sends:
$ openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org -showcerts </dev/null
Certificate chain
0 s:CN=letsencrypt.org
i:C=US, O=Let's Encrypt, CN=YE2
a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
v:NotBefore: Sep 4 14:34:32 2026 GMT; NotAfter: Dec 3 14:34:31 2026 GMT
1 s:C=US, O=Let's Encrypt, CN=YE2
i:C=US, O=ISRG, CN=Root YE
a:PKEY: EC, (secp384r1); sigalg: ecdsa-with-SHA384
v:NotBefore: Sep 3 00:00:00 2025 GMT; NotAfter: Sep 2 23:59:59 2028 GMT
2 s:C=US, O=ISRG, CN=Root YE
i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
Each certificate's issuer (i:) is the subject (s:) of the next one down. Certificate 0 is the leaf, 1 is the intermediate that signs leaves every day, and 2 and 3 are cross-signs that let older clients reach a root they already have. The client walks that ladder until it hits something in its own trust store. When a server leaves out the intermediate, browsers often paper over it and other clients fail; why certificate chains break walks through exactly that.
What the Certificate Does in the Handshake
People often assume the certificate's key encrypts the traffic. In TLS 1.3 it doesn't. The two sides agree on session keys with an ephemeral key exchange, the Peer Temp Key: X25519 line above, and those keys are thrown away when the connection closes. The certificate's job is authentication. The server signs the handshake with its private key, and the client checks four things before it sends a byte of data:
- The signature on the handshake matches the certificate's public key.
- The hostname it dialed appears in the Subject Alternative Name.
- Today falls between Not Before and Not After.
- The chain leads to a root in its trust store and, if the client checks, the certificate isn't revoked.
Fail any one and you get a handshake error. The private key never leaves the server, which is why a leaked key is a reissue-everything event: anyone holding it can impersonate every name in the SAN.
DV, OV, and EV
The Certificate Policies line tells you how much the CA checked. 2.23.140.1.2.1 is domain validated (DV): the CA confirmed control of the names and nothing else. Organization validated (OV) is 2.23.140.1.2.2, and extended validation (EV) is 2.23.140.1.1; both add checks on the company behind the request. The encryption is identical across all three. Chrome and Firefox stopped showing the organization name in the address bar in 2019, so for most sites the extra validation buys nothing a visitor can see. Every certificate in this post's chain is DV, and so are most of the certificates on the web.
Checking Your Own Certificates
You don't need the full dump to check a certificate. These are the one-liners worth keeping:
# who it's for, who signed it, and when it expires
$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
# exit code 0 if it's still valid in 30 days (2592000 seconds), 1 if not
$ openssl x509 -in cert.pem -noout -checkend 2592000
Certificate will not expire
# fingerprint, to tell two certificates apart
$ openssl x509 -in cert.pem -noout -fingerprint -sha256
For a quick look without a terminal, our free SSL checker shows a site's expiry date, days left, hostname coverage, and chain from a single hostname.
Why Certificates Need Watching
Every field in that table is a way for a certificate to fail, and the validity window is the one that fails on a schedule. Public certificates are capped at 200 days today and that cap keeps dropping, down to 47 days by 2029, as covered in why certificate lifetimes are getting shorter. More renewals mean more chances for one to land on a single load balancer node and miss the others, or to ship without its intermediate.
Generator Labs Certificate Monitoring connects to every IP behind a hostname the way a real client does and checks what comes back: expiry against your alert thresholds, the full chain to a trusted root, SAN coverage, CRL revocation status, weak signing algorithms and keys, and CAA records. When a certificate changes unexpectedly, you hear about that too.
