How TLS/SSL Certificates Work

Why TLS Exists

Every time you visit a site over HTTPS, your browser and the server perform a TLS handshake. The goal is simple: establish an encrypted channel so that nobody between you and the server can read or tamper with the data.

TLS (Transport Layer Security) replaced SSL years ago, but the industry still uses both terms interchangeably. If someone says "SSL certificate," they mean a TLS certificate. The last SSL version (3.0) was deprecated in 2015.

The TLS Handshake in 30 Seconds

Here's what happens when your browser connects to https://example.com:

1. Client Hello -- Your browser sends the TLS versions and cipher suites it supports.
2. Server Hello -- The server picks a cipher suite and sends back its certificate.
3. Certificate Verification -- Your browser checks the certificate against its trusted root CAs. Is it expired? Is the domain correct? Is the chain valid?
4. Key Exchange -- Both sides agree on a shared secret using asymmetric cryptography (more on this below).
5. Encrypted Session -- Everything from here on is encrypted with symmetric keys derived from that shared secret.

The whole thing takes one round trip in TLS 1.3 (two in TLS 1.2). Your browser does this thousands of times a day without you noticing.

TLS 1.2 vs TLS 1.3

TLS 1.3 removed legacy cipher suites, reduced the handshake to a single round trip, and made forward secrecy mandatory. If you're deploying anything new, there's no reason to support anything older than TLS 1.2, and you should prefer 1.3.

How Certificates Prove Identity

A certificate is a signed document that says: "This public key belongs to this domain." The signature comes from a Certificate Authority (CA) that your browser already trusts.

The logic is straightforward:

• Your browser ships with a set of trusted root CA certificates (about 150 of them).
• When a server presents a certificate signed by one of those CAs (or by an intermediate CA that chains up to a root), the browser trusts it.
• If the certificate is self-signed or signed by an unknown CA, the browser shows a warning.

This is a chain of trust, not a chain of encryption. The certificate doesn't encrypt anything by itself -- it proves that the server's public key is legitimate, so the key exchange can proceed safely.

Certificate Chains

Certificates rarely come directly from a root CA. Instead, the chain typically looks like this:

Root CA (trusted, in your browser/OS)
  └── Intermediate CA (signed by root)
        └── Leaf certificate (your server's cert, signed by intermediate)

Why intermediates? Root CA private keys are kept offline in hardware security modules. Intermediates handle day-to-day signing. If an intermediate is compromised, the root can revoke it without replacing every certificate ever issued.

When you configure a web server, you need to serve the full chain: your leaf certificate plus any intermediates. The root is already in the client's trust store, so you don't include it. A common misconfiguration is serving only the leaf, which causes trust errors in some clients.

Public and Private Keys

TLS certificates use asymmetric cryptography. You generate a key pair:

• Private key -- Stays on your server. Never shared. Used to prove you own the certificate.
• Public key -- Embedded in the certificate. Sent to every client that connects.

During the handshake, the server uses its private key to sign a piece of data. The client uses the public key from the certificate to verify that signature. If it checks out, the client knows it's talking to the real server.

# Generate a private key and CSR with OpenSSL
openssl req -newkey rsa:2048 -keyout server.key -out server.csr -nodes

The private key file is the most sensitive piece. If it leaks, anyone can impersonate your server. Protect it with filesystem permissions and never commit it to version control.

What's Inside a Certificate

A TLS certificate is an X.509 document. When you decode one, you'll see fields like:

Subject and Issuer

Subject: CN=example.com, O=Example Inc, C=US
Issuer:  CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US

The Subject identifies the certificate owner. The Issuer identifies who signed it. For self-signed certificates, these are identical.

Common Name (CN) and Subject Alternative Names (SAN)

The CN field historically held the domain name, but modern browsers ignore it entirely. They check the SAN extension instead:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com, DNS:api.example.com

Always set SANs. A certificate without SANs will fail validation in every modern browser.

Validity Period

Not Before: Mar 14 00:00:00 2026 GMT
Not After:  Jun 12 00:00:00 2026 GMT

Let's Encrypt issues 90-day certificates. Commercial CAs issue up to 398 days (down from the old 3-year maximum). Shorter lifetimes limit the damage from key compromise.

Key Information

Public Key Algorithm: id-ecPublicKey
    Public-Key: (256 bit)
    ASN1 OID: prime256v1

This tells you the key type and size. In this case, it's an ECDSA P-256 key.

Signature

Signature Algorithm: ecdsa-with-SHA256

The CA signs a hash of the certificate contents. Clients verify this signature to confirm the certificate hasn't been tampered with and was issued by a trusted authority.

Extensions

X.509v3 extensions carry additional information:

• Key Usage -- What the key can do (digital signature, key encipherment).
• Extended Key Usage -- More specific: TLS server auth, TLS client auth, code signing.
• Basic Constraints -- Whether this is a CA certificate or an end-entity cert.
• CRL Distribution Points / Authority Information Access -- Where to check for revocation.

See It for Yourself

The best way to understand certificates is to look at one. Try it: generate a self-signed cert and then decode it to see these fields.

You can also inspect any live certificate with OpenSSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -text -noout

This dumps the full certificate with every field and extension. Once you've read a few, the structure becomes second nature.

Key Takeaways

• TLS encrypts the connection; the certificate proves identity.
• Certificate chains build trust from your leaf cert up to a root CA in the client's trust store.
• Always include SANs -- CN alone is not enough.
• Serve the full chain (leaf + intermediates) from your server.
• Keep your private key private. Rotate it if there's any chance of compromise.