Questions: Public Key Infrastructure

Question 1

Your browser trusts hundreds of root CAs from dozens of countries. Why is this a security concern, and what mitigation does Certificate Transparency provide?

Model answer: Any single root CA can issue a valid certificate for any domain — a compromised or coerced CA in any country can create a certificate for google.com that your browser will accept. Certificate Transparency (CT) requires CAs to log all issued certificates in public, append-only logs. Domain owners and monitors can detect unauthorized certificates by watching these logs. CT doesn't prevent mis-issuance but makes it publicly visible, enabling rapid detection and revocation.

The fundamental problem is that PKI trust is as strong as its weakest CA. CT shifts the security model from 'trust all CAs to behave' to 'detect and respond when they don't.' Since Chrome requires CT for all new certificates, any secretly issued certificate is detectable. The DigiNotar (2011) and Symantec (2017) incidents demonstrated that CA misbehavior is not hypothetical.

Question 2

A website's certificate has expired. A user argues that since the cryptographic key hasn't changed, the connection is still secure. What does the user miss?

• A. Expired certificates use weaker encryption algorithms
• B. Certificate expiration serves multiple purposes: it limits the window of exposure if a private key is compromised without detection, forces regular re-validation of domain ownership, and ensures the certificate's cryptographic algorithms stay current. An unexpired certificate provides assurance that these checks were recent
• C. The encryption key automatically weakens over time due to mathematical properties
• D. Expired certificates cannot perform the TLS handshake at all

Answer: (B)

Expiration is a time-bounded trust assertion. Without it, a certificate for a domain you sold years ago, signed with a key that may have been stolen, using obsolete algorithms, would remain valid forever. Short certificate lifetimes (Let's Encrypt uses 90 days) reduce the blast radius of compromise and ensure certificates stay aligned with current security practices. The cryptographic strength doesn't change, but the trust context does.

Question 3

The chain of trust in PKI is: root CA signs intermediate CA certificate, intermediate CA signs end-entity certificate. Why use intermediate CAs instead of having root CAs sign all certificates directly?

• A. Intermediate CAs encrypt the certificates while root CAs only sign them
• B. Root CA private keys are stored offline in hardware security modules and used rarely. Intermediate CAs handle day-to-day signing. If an intermediate CA is compromised, the root can revoke it without replacing the root key, which would require updating every browser and OS trust store
• C. Root CAs can only sign a limited number of certificates due to mathematical constraints
• D. Intermediate CAs provide faster signature verification

Answer: (B)

The root key is the ultimate anchor of trust — its compromise would be catastrophic. Keeping it offline (in an HSM, used only to sign intermediate certificates) dramatically reduces its attack surface. Intermediate CAs are more exposed but more replaceable: revoking an intermediate CA and issuing a new one is operationally feasible, while replacing a root CA requires coordinated updates across all browsers and operating systems worldwide.

Question 4

OCSP stapling improves certificate revocation checking by having the web server include a recent, CA-signed OCSP response in the TLS handshake, rather than requiring the client to contact the CA directly.

• T. True
• F. False

Answer: True

Without stapling, the client must contact the CA's OCSP responder to check revocation status, which adds latency, creates a privacy leak (the CA learns which sites you visit), and fails if the OCSP responder is unreachable (most browsers then accept the certificate anyway, defeating the purpose). With stapling, the server periodically fetches its own OCSP response and includes it in the TLS handshake. The response is signed by the CA, so the server cannot forge a 'good' status for a revoked certificate. This is faster, more private, and more reliable.

Question 5

Let's Encrypt revolutionized PKI by offering free, automated certificates. How did this change the HTTPS adoption landscape?

Model answer: Before Let's Encrypt (2015), certificates cost money and required manual installation, so HTTPS was mainly used for login pages and e-commerce. Let's Encrypt provided free certificates with automated issuance and renewal (via the ACME protocol), removing both cost and complexity barriers. HTTPS adoption went from ~40% of web traffic to >90% within a few years. The tradeoff is that Let's Encrypt only validates domain control (DV certificates), not organizational identity — it proves you control the domain but not who you are.

Let's Encrypt's contribution was making the operational barrier to HTTPS near zero. The 90-day certificate lifetime (requiring automated renewal) also pushed the ecosystem toward better certificate management practices. The shift to ubiquitous HTTPS means network-level surveillance and content injection are significantly harder, though phishing sites can also get certificates just as easily.