Cryptography
PKI and Certificates
In 2016, HTTPS adoption was 52%. By 2024 it exceeded 95% across browsers. Let's Encrypt accounts for the majority of this growth by making TLS certificates free and automated. Before 2015, a small organization hosting a website over HTTPS needed to pay $100-300/year and manually configure certificate renewal. The automation of PKI infrastructure changed the economics of web security.
- **Let's Encrypt**: 4+ billion certificates issued since 2015. 300+ million websites secured. ACME protocol automated what was previously a manual, paid process.
- **DigiNotar collapse (2011)**: compromised CA issued *.google.com. Used to intercept 300,000 Iranian Gmail sessions. CA removed from all trust stores; company bankrupt within weeks.
- **Certificate Transparency (RFC 6962)**: every certificate must be logged. Google Chrome requires CT for all new certificates. Enables detection of unauthorized issuance.
- **Apple App Transport Security**: iOS requires TLS for all app connections. Apps must use CAs in Apple's trust store. Short-circuits on invalid chains.
X.509: Digital Certificate Format
An X.509 certificate binds a public key to an identity. It contains: subject name, public key, issuer name, validity period, extensions (SANs, key usage), and the CA's signature over all fields. The structure is ASN.1 DER-encoded.
openssl x509 -in cert.pem -text -noout displays all certificate fields. Certificate transparency logs (RFC 6962) record every certificate issued, enabling detection of unauthorized CA-issued certificates.
What does a CA signature on an X.509 certificate guarantee?
Certificate Authority: The Trust Hierarchy
Web PKI is a hierarchy: browser/OS vendors include ~150 Root CAs in their trust store. Root CAs issue Intermediate CA certificates. Intermediates sign end-entity certificates. Root CA private keys are kept offline in HSMs; intermediates are online for daily operations.
In 2011, DigiNotar (Dutch CA) was compromised. Attackers issued 500+ fraudulent certificates including *.google.com, used to MITM 300,000 Iranian Gmail users. DigiNotar went bankrupt within weeks. This incident led to Certificate Transparency (CT) requirements.
Why do Web PKI Root CAs keep their private keys offline in HSMs?
Chain of Trust and Certificate Revocation
TLS handshake certificate validation: verify each certificate in the chain is signed by the next, up to a trusted root. Check each certificate is not expired. Check each certificate is not revoked. Check the leaf certificate Subject Alternative Names match the domain.
Chrome uses CRLsets (curated revocation lists for high-value certs) rather than full CRL/OCSP. Firefox uses CRLite (compressed revocation bitmap). Soft-fail OCSP (proceed if OCSP unreachable) is the default behavior - meaning revocation often provides weak protection.
Why does OCSP stapling improve on direct OCSP queries from the browser?
Let's Encrypt: PKI Automation
Let's Encrypt (2015) automated TLS certificate issuance using the ACME protocol (RFC 8555). Before Let's Encrypt, TLS certificates cost $100-300/year and required manual processes. Let's Encrypt issues free 90-day certificates via automated domain validation and renewal.
Let's Encrypt has issued 4+ billion certificates since 2015 and secures over 300 million websites. The 90-day validity forces automation, which reduces the exposure window of compromised certificates. Competing ACME CAs: ZeroSSL, Buypass.
Why does Let's Encrypt issue 90-day certificates instead of 1-year certificates?
Key Ideas
- **X.509**: certificate = identity + public key + CA signature. Extensions carry SANs, key usage, AIA for OCSP. ASN.1 DER encoded.
- **CA hierarchy**: Root (offline HSM) -> Intermediate (online) -> End-entity. ~150 roots in browser trust stores.
- **Revocation**: CRL (periodic list), OCSP (real-time query with privacy leak), OCSP Stapling (server caches response). Soft-fail means revocation often provides weak guarantees.
- **Let's Encrypt**: free 90-day certificates via ACME protocol. Automation forces renewal before expiry. 90-day validity limits compromise exposure.
Related Topics
PKI underpins all of web security and applied cryptography:
- TLS 1.3 — TLS handshake validates the certificate chain before the session key exchange.
- Digital Signatures — CA signatures on certificates use RSA-PSS or ECDSA. Certificate signing is a digital signature over the certificate structure.
- Signal Protocol — Signal avoids PKI entirely by using out-of-band key verification (safety numbers) instead of trusted CAs.
Вопросы для размышления
- If a Root CA private key is compromised, describe the complete remediation process. How long would it take?
- Certificate Transparency requires every certificate to be logged. How does this prevent a rogue CA from issuing *.example.com without example.com's knowledge?
- Let's Encrypt issues a 90-day certificate. The private key is leaked on day 45. What is the maximum duration an attacker can exploit this?