How HTTPS certificates actually work

You've seen the lock icon next to a URL. You've clicked it and seen a "certificate" dialog. Maybe you've seen the bright red "Not Secure" or "Connection Not Private" warnings that browsers throw when something's wrong. Underneath all of it is a system of cryptographic certificates that's been quietly running for thirty years and is still the foundation of trust on the open web.

If you've read our HTTPS post, this is the deep dive on the certificate part — what they are, who issues them, and why "Let's Encrypt" changed the web in 2015.

The two-line summary

A TLS certificate is a small public document that says "this public key belongs to this domain," signed by a Certificate Authority your browser trusts. Browsers ship with a list of trusted CAs; servers present certificates; browsers verify the signature chain.

That's the whole trust model.

What's in a certificate

A typical TLS certificate contains:

Subject — the domain (or domains) the certificate is for. E.g., cloudflare.com, *.cloudflare.com.
Public key — the server's public key. (The matching private key stays on the server.)
Issuer — the Certificate Authority that signed it. E.g., "Let's Encrypt R3" or "DigiCert TLS RSA SHA256 2020 CA1".
Validity period — Not Before and Not After dates.
Serial number — unique per CA.
Signature — a cryptographic signature over the rest of the certificate, made with the CA's private key.
Subject Alternative Names (SANs) — additional domains the cert is valid for. The Subject field is largely vestigial; modern browsers check SANs.
Extensions — purpose constraints, OCSP endpoints, CT logs, etc.

When your browser receives a certificate, it can:

Verify the signature using the CA's public key (which it has bundled).
Check the date is in the validity period.
Confirm the domain you're visiting is in the SAN list.
Check for revocation (more on this below).
Confirm the certificate is logged in Certificate Transparency logs.

If everything passes, the lock icon appears.

The chain of trust

Browsers don't actually trust each individual certificate. They trust root CAs — about 150 of them ship in major browsers and operating systems.

But CAs don't issue end-entity certificates directly with their root keys. The roots are kept offline and used rarely. Instead:

A root CA signs an intermediate CA.
The intermediate CA signs the end-entity certificate for your site.

Your browser verifies the chain: end cert → intermediate cert → root cert (which it trusts). All three signatures must be valid.

This is why a server presents not just its own certificate but also any intermediate certs needed to chain back to a root. Misconfiguring this — leaving out the intermediate — produces "incomplete chain" errors that some clients accept and some reject.

Domain validation: who can get a certificate?

Three levels of certificate, distinguished by how thoroughly the CA verified the requester:

DV (Domain Validation)

CA verifies you control the domain — typically by asking you to put a specific value at a specific URL or DNS record on the domain. Automated, fast (seconds to minutes), free.

This is what Let's Encrypt issues. Most of the modern web runs on DV certificates. They prove "whoever is requesting this controls the DNS for the domain" — which is the right level of assurance for "show me this site is what it claims."

OV (Organization Validation)

CA also verifies the requesting organization is real — by checking corporate registration documents, calling listed phone numbers, etc. Takes days, costs $50–500/year. Marginal benefit over DV in 2026; browsers don't visually distinguish.

EV (Extended Validation)

The strictest. CA verifies the organization, the requestor's authority to obtain the cert, the physical address, and more. Used to display a green company name in the browser bar. Browsers stopped showing the visual indicator around 2019 because users didn't notice or use it. Now mostly historical.

For 99% of public-web cases in 2026, DV is the right choice and Let's Encrypt is the right CA.

Let's Encrypt: the most important free service

Until 2015, getting an HTTPS certificate cost money — typically $50–500/year. This kept HTTPS off most small sites. Let's Encrypt, founded by Mozilla, EFF, and others, changed that completely:

Free. No payment, no subscription.
Automated. The ACME protocol issues certificates programmatically.
Short-lived. 90-day certs encourage automation; renewal is a cron job.
High-volume. They've issued billions of certificates.

Within a few years of launch, the percentage of web traffic over HTTPS jumped from ~30% to over 90%. Browsers started warning aggressively about HTTP. The cost barrier evaporated.

In 2026, you have no good reason to run HTTPS without using Let's Encrypt or a similar free CA. Cloudflare, AWS, Google all also offer free certificates as part of their infrastructure.

How automated issuance works (ACME)

The protocol behind Let's Encrypt is ACME (Automatic Certificate Management Environment), now an IETF standard.

To get a cert for example.com:

Your client generates a key pair and creates a Certificate Signing Request (CSR).
The client tells the ACME server: "I'm requesting a cert for example.com."
The ACME server responds with a challenge: prove control of the domain.
The client fulfills the challenge (places a token at a specific URL or DNS record).
The ACME server verifies, then signs the certificate.
The client receives the cert and installs it on the server.

Tools like Certbot, acme.sh, and Caddy automate this entire flow. Once configured, certificates renew automatically every ~60 days for the 90-day validity window. Zero human intervention after setup.

How browsers know about revocation

Sometimes a certificate needs to be invalidated before its expiry — the private key was compromised, the domain changed hands, the issuance was mistaken. The system has two mechanisms:

CRL (Certificate Revocation List)

CAs publish lists of revoked certificate serial numbers. Browsers fetch and check. Slow, big files, mostly deprecated for browser use.

OCSP (Online Certificate Status Protocol)

Browser asks the CA "is cert X still valid?" in real time. Faster but creates privacy issues (the CA learns which sites users visit) and reliability issues (if OCSP fails, browsers historically just accepted the cert).

CRLite, OCSP stapling, short-lived certs

Modern fixes: browsers download compressed revocation data ahead of time (CRLite, used by Firefox), or servers staple OCSP responses themselves so browsers don't query, or issuers move toward shorter-lived certs (Let's Encrypt is exploring 7-day certs) where the validity period is short enough that revocation matters less.

Certificate Transparency

A 2013 innovation: every CA must publicly log every certificate they issue, in CT logs that anyone can read. Browsers check that certificates appear in CT logs before accepting them.

Why? To prevent CAs from secretly issuing fraudulent certificates. If a rogue CA issues a cert for google.com, Google can see the cert in CT logs and respond. CT has caught real misissuances and forced CAs out of trust programs.

Today, every public certificate appears in multiple CT logs. Tools like crt.sh and merklemap.com let anyone search the global CT corpus.

Common error states and what they mean

"Certificate has expired" — the cert's Not After date has passed. The site needs to renew.
"Self-signed certificate" — the cert wasn't signed by a CA in the trust store. Either an internal/dev cert, or someone is mis-claiming the domain.
"Subject name does not match" — the domain you're visiting isn't in the SANs. Misconfigured cert.
"Untrusted issuer" — the chain doesn't reach a root in your browser's trust store. Often caused by missing intermediate cert in the server config.
"Revoked" — the cert was explicitly revoked by the CA. Shouldn't be trusted.
"Weak signature algorithm" — older cert using SHA-1 or weak RSA. Trust stores have largely removed these.

In all cases, the browser is doing its job. Don't override certificate warnings on the public internet. They mean either the site is misconfigured or someone's actively trying to intercept your traffic.

Quick FAQ

Why do certs expire? To force re-verification of domain control and key freshness. A cert valid for ten years becomes a ticking timebomb if the key leaks. Short validity means short blast radius.

Can I issue my own certificates? You can run your own CA for internal use (corporate networks, dev environments). Browsers won't trust it unless you install your CA's root cert into their trust store. For the public web, you can't.

What about Cloudflare's "free SSL"? Cloudflare issues TLS certificates for sites behind their CDN. They're standard public CA certs. The "free" part is paying nothing, not running a different system.

Are wildcards (*.example.com) different? Same system, different scope. A wildcard cert covers any single-level subdomain. Often issued via DNS challenge (you put a TXT record on the parent domain).

What's the difference between RSA and ECDSA certs? The asymmetric crypto algorithm. RSA is older and slower; ECDSA is newer and faster. Most CAs offer both; modern best practice is to issue both and let the browser pick.

TL;DR

A TLS certificate is a small signed document binding a public key to a domain.
CAs sign certs; browsers trust ~150 root CAs; chains link end-entity certs back to roots.
Let's Encrypt changed the web by making automated, free DV certs the default.
Modern protections: CT logs (catch misissuance), CRLite/OCSP (catch revocation), short validity (limit damage).
"Invalid certificate" warnings are real; don't dismiss them.

The lock icon you see in the browser? It's the visible end of all of this.