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.

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.

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

Loading diagram...

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.

⚠️ 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.