How Websites Get SSL Certificates

The certificate trust system is hierarchical. Root CAs are self-signed and embedded in operating systems and browsers. Intermediate CAs are signed by root CAs and do the actual certificate issuance.

This two-tier structure keeps root CA private keys offline and air-gapped. If an intermediate CA is compromised, its certificates can be revoked without requiring changes to root CA trust anchors.

To obtain a DV certificate, the applicant must prove control of the domain. There are three standard ACME challenges: DNS challenge (add a TXT record to the domain's DNS), HTTP challenge (place a specific file at a specific URL), and TLS-ALPN challenge (serve a specific certificate during TLS negotiation).

All three methods confirm that the applicant controls either the domain's DNS or the web server at that domain. This prevents someone from obtaining a certificate for a domain they do not control.

ACME (Automatic Certificate Management Environment, RFC 8555) is the protocol used by Let's Encrypt and supported by most modern CAs. It automates the entire certificate lifecycle: challenge, validation, issuance, and renewal.

ACME allows web servers to automatically obtain and renew certificates without human intervention. Certbot, acme.sh, and most web servers have ACME clients built in, making certificate management nearly maintenance-free.

A Certificate Signing Request (CSR) is a block of data containing the applicant's public key and information about the entity (domain name, organization, country). The CSR is signed with the corresponding private key to prove possession.

The CA validates the CSR, verifies the domain control proof, and issues a certificate binding the public key in the CSR to the validated domain name. The private key never leaves the server.

An X.509 certificate contains: Subject (the identity being certified), Subject Alternative Names (SANs, additional domain names), Issuer (the CA that signed it), Validity period (Not Before and Not After), Public Key and algorithm, and the CA's digital signature.

Modern certificates use SANs rather than the older Common Name field for domain names. A certificate can list multiple domains in its SAN field, allowing one certificate to cover several related domains.

Let's Encrypt, launched in 2016 by the Internet Security Research Group, issues free DV certificates using fully automated ACME challenges. It has issued over three billion certificates, dramatically accelerating HTTPS adoption.

Let's Encrypt certificates are valid for 90 days (shorter than commercial CA certificates) and must be renewed regularly. The short validity period is intentional: it limits exposure if a certificate is compromised and encourages automation.

Commercial CAs like DigiCert, Sectigo, and GlobalSign charge for certificates but offer additional services: OV and EV validation (with organizational identity verification), multi-year certificates, warranty coverage for misissuance, and customer support.

For organizations that need OV or EV certificates, require longer validity periods, or need commercial warranties and SLAs, commercial CAs provide value that free DV certificate providers do not.

A wildcard certificate covers a domain and all its direct subdomains. A certificate for *.example.com covers mail.example.com, www.example.com, and api.example.com, but not sub.mail.example.com.

Wildcard certificates are convenient for organizations with many subdomains. However, the same private key protects all subdomains, so compromising one server compromises the certificate for all covered subdomains.

A Subject Alternative Names (SAN) certificate, also called a multi-domain or UCC certificate, explicitly lists multiple domain names. Unlike wildcards, it covers specific named domains rather than a pattern.

SAN certificates are commonly used for related properties: a certificate might cover example.com, www.example.com, app.example.com, and example.io. Each domain requires separate validation but one certificate covers all of them.

Certificate pinning instructs a client to accept only specific certificates or public keys for a given domain, ignoring CA-signed certificates it does not recognize. This prevents attacks using rogue CA-issued certificates.

HTTP Public Key Pinning (HPKP) was a browser mechanism for certificate pinning. It was deprecated and removed from browsers by 2019 because misconfiguration could permanently lock users out of a site. Certificate Transparency is now the preferred mechanism for detecting certificate abuse.

When a certificate is compromised, the CA can revoke it before expiry. The Certificate Revocation List (CRL) is a list of revoked certificate serial numbers that clients can download and check.

OCSP (Online Certificate Status Protocol) allows real-time per-certificate revocation checks. OCSP stapling improves privacy and performance: the server pre-fetches a signed OCSP response and includes it in the TLS handshake so the browser does not need to contact the CA.

Test your knowledge of certificate validation types.

Certificates are issued through a CA hierarchy where root CAs sign intermediate CAs that issue end-entity certificates. DV certificates verify domain control only; OV and EV verify organizational identity.

ACME automates certificate issuance and renewal. Let's Encrypt issues free DV certificates valid for 90 days. Wildcard certificates cover all direct subdomains. Certificate Transparency logs provide auditable records of all issued certificates.