SSL certificate
A digital file that binds a public key to a domain and is signed by a trusted Certificate Authority. The proof browsers use to trust HTTPS connections.
An SSL certificate (more accurately a TLS certificate; see TLS certificate) is a file with three things in it: a public key, a list of domain names this key is valid for, and a signature from a Certificate Authority that browsers trust.
When a browser connects to https://example.com, the server presents this certificate. The browser checks:
- Is the domain in the cert? (Common Name or Subject Alternative Name.)
- Is it signed by a CA my system trusts?
- Is it within its valid date range?
- Has it been revoked?
All four pass: green lock, encrypted connection. Any fail: scary browser warning.
What's actually inside
A simplified view of a cert's fields:
Subject: CN=example.com
SAN: example.com, www.example.com
Issuer: Let's Encrypt R3
Valid from: 2026-04-01
Valid until: 2026-06-30
Public key: RSA 2048 / ECDSA P-256
Signature: <CA's signature>
The public key is what the server uses to prove it owns the corresponding private key. The CA's signature is what browsers verify against their built-in trust store.
Cert types
- Domain Validation (DV). CA only verifies you control the domain. Issued in seconds. Free from Let's Encrypt. Used by almost every SaaS.
- Organization Validation (OV). CA also verifies the legal entity. Takes 1–3 days, costs ~$50/yr.
- Extended Validation (EV). Most thorough check. Browsers used to show the company name in the URL bar (removed in 2019). Now mostly legacy.
For SaaS custom domains, DV is almost always the right choice. It's free and automatable.
SAN cert vs single-name cert
A SAN cert covers multiple hostnames in one file (typically up to ~100). A wildcard cert covers *.example.com for one level of subdomain. For multi-tenant SaaS serving many customer hostnames, you either issue many single-name certs (one per customer) or bundle them into SAN certs of moderate size.