How SSL Certificates Work

Every HTTPS connection begins with a question: How do I know I'm actually talking to the real example.com and not an impostor?

The answer is a certificate—a signed statement that says: I, the Certificate Authority, vouch that this public key belongs to example.com.

That's it. Everything else about certificates—the formats, the chains, the validation levels—is just machinery around that core concept.

The Signed Statement

A certificate contains a few essential pieces:

• Who it's for: The domain name (and optionally, organization details)
• The public key: The cryptographic key that belongs to that domain
• Who vouches for it: The Certificate Authority that issued it
• The signature: The CA's cryptographic signature over all the above

The signature is what makes it work. Anyone can claim "this public key belongs to example.com." But only a Certificate Authority can produce a signature that your browser will recognize and trust.

The Missing Half

The certificate contains a public key, but that's only half of a key pair. The website operator holds the corresponding private key, which never appears in the certificate and must be fiercely protected.

These two keys have a mathematical relationship: data encrypted with the public key can only be decrypted with the private key. Signatures made with the private key can only be verified with the public key.

During the TLS handshake, the server proves it holds the private key that corresponds to the public key in the certificate. This is the authentication moment—the server proves it's the legitimate owner, not just someone who copied the certificate.

If an attacker steals the private key, they can impersonate the website. This is why private key compromise is catastrophic.

Why Your Browser Trusts It

Your browser comes preloaded with a list of trusted Certificate Authorities—organizations like DigiCert, Let's Encrypt, and GlobalSign. When a website presents a certificate, your browser checks: Was this signed by a CA I trust?

The browser verifies the signature using the CA's public key. If valid, the browser trusts that the CA properly verified the website's identity before signing.

This is trust by delegation. You don't personally verify that example.com is legitimate. You trust that the CA did the verification. And you trust the CA because... your browser shipped with it on the list.

It's trust all the way down. What makes it work isn't cryptographic certainty—it's economics. CAs have enormous incentive to verify carefully because a single high-profile mistake could get them removed from browsers' trust lists, destroying their business.

The Chain

Most certificates aren't signed directly by a root CA. They're signed by an intermediate CA, which was signed by another intermediate, which was signed by the root.

The server sends this entire chain. Your browser walks it link by link: website cert signed by Intermediate A, Intermediate A signed by Intermediate B, Intermediate B signed by Root CA. The root is in the browser's trust store. Chain verified.

Why the complexity? Root CA private keys are extraordinarily valuable. They're kept offline in hardened facilities, used only to sign intermediate certificates. If an intermediate is compromised, you revoke it. The root stays safe.

Getting a Certificate

To get a certificate, you prove to a CA that you control the domain. The simplest method (Domain Validation) might ask you to:

• Add a specific DNS record
• Host a specific file on your web server
• Respond to an email sent to admin@yourdomain.com

Pass the check, get the certificate. With Let's Encrypt, this takes seconds and costs nothing.

Organization Validation and Extended Validation certificates verify more—business registration, legal existence, authorization. They take longer and cost more. The encryption is identical; only the identity verification differs.

For most websites, DV is sufficient. The padlock means the same thing regardless of validation level: your connection is encrypted to whoever controls that domain.

Multiple Domains, One Certificate

Modern certificates list all the domains they cover in the Subject Alternative Names (SAN) extension. One certificate might cover:

• example.com
• www.example.com
• api.example.com
• staging.example.com

Wildcard certificates cover all subdomains with a pattern like *.example.com. Convenient, but if compromised, the blast radius includes every subdomain.

Certificate Transparency

Here's a problem: what if a CA issues a fraudulent certificate for your domain? Maybe an attacker social-engineers their way through validation. Maybe a CA makes a mistake.

Certificate Transparency fixes this. Every certificate must be submitted to public, append-only logs before browsers will trust it. Domain owners can monitor these logs. If someone gets a certificate for your domain, you'll see it.

This turned certificates from secrets into public records. Fraud becomes detectable.

The Files

Certificates come in confusing file formats:

PEM: Base64 text with -----BEGIN CERTIFICATE----- headers. Most common for web servers. Files end in .pem, .crt, or .cer.

DER: Binary version of the same data. Files end in .der or .cer.

PKCS#12: Certificate and private key bundled together, encrypted. Files end in .pfx or .p12. Convenient for moving everything at once.

They're all the same certificate—just different encodings.

Protecting the Private Key

The certificate is public. The private key is everything.

At minimum, private keys live in files readable only by the web server process. In high-security environments, they live in Hardware Security Modules (HSMs)—tamper-resistant devices that perform cryptographic operations without ever exposing the key. The private key never leaves the hardware.

Cloud providers offer managed key storage with similar properties. The key exists, operations happen, but the key material itself stays locked away.

The Actual Security

Certificates don't make connections secure by themselves. They solve the authentication problem: Am I talking to the real example.com?

Once that's established, the TLS handshake uses the authenticated public key to set up encryption. The certificate enabled that handshake to happen with the right party.

Without certificates, you could have a perfectly encrypted connection... to an attacker. Encryption without authentication is security theater.