2.4.6. Certificates and Certificate Management

💡 First Principle: Digital certificates are the identity documents of the digital world. A certificate binds a public key to an identity and is signed by a trusted CA. Without certificates, you can't verify that a public key belongs to who claims to own it.

Certificate Authorities (CAs) verify identity and issue signed certificates. They form a hierarchy: a root CA signs intermediate CAs, which sign end-entity certificates. Your browser trusts a website because it trusts the CA that signed its certificate. The padlock means only that the connection is encrypted and the certificate chains to a trusted CA and matches the domain; it says nothing about whether the site is legitimate or free of malware (phishing sites obtain certificates too). Trust stores hold root CAs, so a server must send its intermediate certificate(s) along with its own; if one is missing, clients that cannot fetch or have not cached that intermediate fail to build the chain and show an untrusted warning, while others succeed.

Certificate Revocation Lists (CRLs) — published lists of certificates revoked before expiration (compromise, key loss, identity change). Clients check CRLs to verify validity. CRLs can grow large and are downloaded periodically.

Online Certificate Status Protocol (OCSP) — real-time certificate status checking. More efficient than CRLs (queries single certificates), but depends on OCSP responder availability.

Self-signed certificates — signed by the entity itself, not a CA. Provide encryption but no third-party identity verification. Appropriate for internal testing; browsers warn on public sites.

Root of trust — the foundational CA whose certificate is inherently trusted (pre-installed in OS and browsers). If a root CA is compromised, every certificate it issued becomes suspect. When a CA's private key is compromised, its own certificate must be revoked or removed from trust immediately — an intermediate is revoked by its issuing CA through CRL/OCSP, while a root has no issuer above it, so it must be removed from trust stores — and everything it signed must then be reissued from a new CA.

Certificate Signing Request (CSR) — generated by the requester, containing public key and identity info. Submitted to a CA for verification and signing.

Wildcard certificates cover a domain and all first-level subdomains. *.example.com covers www.example.com and mail.example.com but NOT sub.mail.example.com.

Certificate file formats: PEM is Base64 ASCII text (BEGIN/END headers) that can hold a certificate, chain or key; DER is the binary encoding of the same data; PFX/PKCS#12 (.pfx/.p12) is a password-protected binary archive bundling the certificate with its private key; P7B/PKCS#7 (.p7b) holds certificates and the chain but never the private key.

Expiration and renewal: an expired certificate makes clients show security warnings or refuse the connection, so track expiration dates and automate renewal.

Internal services: mutual TLS (mTLS) has both client and server present certificates. At scale, organizations run a private CA and automate issuance and rotation of short-lived certificates (for example with ACME or a service mesh): short lifetimes shrink the window in which a stolen key is useful, and automation avoids the expiry outages and untracked, unrevocable keys that manual or self-signed certificates create.

⚠️ Exam Trap: Wildcard = first-level subdomains only. For multiple domains (.com and .org) or multi-level subdomains, the answer is Subject Alternative Name (SAN), not wildcard.