How SSL/TLS Certificates Work
What is TLS?
Transport Layer Security (TLS) is the cryptographic protocol that secures connections over the internet — for HTTPS, SMTP, IMAP, and many other protocols. SSL (Secure Sockets Layer) was its predecessor; despite being deprecated since 2015, the term "SSL certificate" persists colloquially.
TLS provides three guarantees:
- Confidentiality — data is encrypted in transit.
- Integrity — tampering is detectable.
- Authentication — you're talking to who you think you are.
Certificate Anatomy
An X.509 certificate is a structured document containing:
- Subject — who the certificate belongs to (CN, O, C, ST, L)
- Issuer — the Certificate Authority that signed it
- Serial number — unique identifier within the CA
- Validity period —
Not BeforeandNot Afterdates - Public key — RSA or ECDSA key and its parameters
- Subject Alternative Names (SANs) — list of hostnames the cert covers
- Signature — the CA's digital signature over all of the above
# Inspect a certificate with openssl
openssl s_client -connect example.com:443 -servername example.com < /dev/null \
| openssl x509 -noout -text
# Key fields in output:
Issuer: C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1
Subject: CN=example.com
Not Before: Jan 1 00:00:00 2026 GMT
Not After : Jan 1 23:59:59 2027 GMT
Subject Alternative Name:
DNS:example.com, DNS:www.example.comCertificate Chains
Certificates are organized in a hierarchy. Browser trust stores ship with a set of root CA certificates — typically 100–200 trusted authorities. Root CAs don't sign website certificates directly; instead, they sign intermediate CA certificates, which in turn sign the end-entity (leaf) certificates for individual domains.
Root CA (in browser trust store)
└── Intermediate CA (signed by Root CA)
└── Your domain certificate (signed by Intermediate CA)Your web server must send the complete chain — your certificate plus all intermediate certificates — so the browser can verify the chain back to a trusted root. Missing intermediates cause "incomplete chain" errors.
The TLS Handshake
When a browser connects to an HTTPS site, a TLS handshake occurs before any HTTP data is exchanged. TLS 1.3 simplified this to:
- ClientHello — browser sends supported cipher suites, TLS version, and a random value.
- ServerHello — server selects cipher suite, sends its certificate chain and key exchange data.
- Certificate verification — browser verifies the certificate chain, hostname, and expiry.
- Key derivation — both sides derive the same symmetric session key from the exchanged data (using ECDHE for forward secrecy).
- Finished — both sides confirm with a MAC. Encrypted data transfer begins.
TLS 1.3 completes the handshake in one round-trip (1-RTT), versus two for TLS 1.2. For resumed sessions, it supports 0-RTT resumption.
Certificate Types
| Type | Validates | Browser indicator |
|---|---|---|
| DV (Domain Validated) | Domain ownership only | Padlock |
| OV (Organization Validated) | Domain + organization identity | Padlock |
| EV (Extended Validation) | Rigorous legal entity verification | Padlock (company name in older browsers) |
| Wildcard | One domain + all subdomains (*.example.com) | Padlock |
| Multi-domain (SAN) | Multiple distinct domains in one cert | Padlock |
Let's Encrypt issues DV certificates automatically and for free, making DV the practical choice for most web properties.
Expiry and Renewal
As of 2020, publicly trusted certificates have a maximum validity of 398 days. Let's Encrypt issues 90-day certificates to encourage automation. The recommended practice is to automate renewal at 60 days remaining — this gives a 30-day buffer before any service disruption.
# Check certificate expiry with openssl
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates
# Output:
notBefore=Jan 1 00:00:00 2026 GMT
notAfter=Jan 1 23:59:59 2027 GMTUse the SSL Certificate Checker to inspect any domain's certificate status, expiry date, and issuer details without installing any tools.
Frequently Asked Questions
What's the difference between a certificate and a private key?
The certificate is public — it contains your public key and is sent to every connecting client. The private key is secret and must never leave your server. The private key is used to prove you are the rightful holder of the certificate during the TLS handshake.
Why does certificate transparency matter?
Certificate Transparency (CT) requires CAs to log every issued certificate to public, append-only logs. Browsers check that certificates appear in CT logs. This makes it possible to detect rogue certificates (mis-issuance by a CA) within hours rather than months.
What is a CSR?
A Certificate Signing Request (CSR) is a PKCS#10 encoded block you send to a CA when requesting a certificate. It contains your public key and subject information. The CA verifies your domain ownership, signs the CSR, and returns your certificate. Use the CSR Generator to create a CSR entirely in your browser.
Why is my certificate showing as untrusted on some devices?
Older devices have outdated trust stores and may not include newer root CAs. Let's Encrypt's ISRG Root X1 was cross-signed by IdenTrust DST Root CA X3 (which expired September 2021). Devices running Android 7.1 or earlier that haven't been updated may fail to validate Let's Encrypt certificates issued after that expiry.