Principles of Information Security: Public Key Infrastructure (PKI) – Certificates, CAs, CRLs, OCSP

Public Key Infrastructure (PKI) – Certificates, CAs, CRLs, OCSP

Public Key Infrastructure (PKI) – Certificates, CAs, CRLs, OCSP

Study Guide for CISSP, Security+, CEH, and Real-World Security Roles

What This Is

Public Key Infrastructure (PKI) is the framework that manages digital certificates and public-key encryption to secure communications, verify identities, and ensure data integrity. It’s the backbone of HTTPS, VPNs, code signing, and email encryption. Without PKI, attackers could impersonate websites (phishing), intercept traffic (MITM attacks), or forge software updates (supply chain attacks)—like the 2020 SolarWinds hack, where attackers compromised a code-signing certificate to distribute malware as a "trusted" update.

Key Terms & Concepts

• PKI (Public Key Infrastructure): A system of hardware, software, policies, and procedures to create, manage, distribute, and revoke digital certificates. Follows X.509 (ITU-T standard) and RFC 5280.

• Example: When you visit https://bank.com, PKI ensures the site’s certificate is valid and issued by a trusted CA.

• Digital Certificate (X.509): A digital ID card that binds a public key to an entity (user, server, device). Contains:

• Subject (who owns the cert, e.g., CN=google.com).
• Issuer (who signed it, e.g., CN=DigiCert).
• Public Key (used for encryption/signing).
• Validity Period (not before/not after dates).
• Signature Algorithm (e.g., SHA-256 with RSA).

• Tools: OpenSSL (openssl x509 -in cert.pem -text), Windows CertMgr.

• CA (Certificate Authority): A trusted third party that issues and signs certificates. Root CAs (e.g., DigiCert, Let’s Encrypt) are pre-installed in OS/browser trust stores.

• Hierarchy:
  • Root CA (self-signed, offline for security).
  • Intermediate CA (signs end-entity certs, online).
  • End-Entity Cert (issued to users/servers).

• Example: If a CA is compromised (e.g., 2011 DigiNotar breach), attackers can issue fraudulent certs for any domain.

• CSR (Certificate Signing Request): A PKCS#10 file generated by a user/server to request a certificate from a CA. Contains the public key and identity info (e.g., domain name).

• Command: openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr

• CRL (Certificate Revocation List): A blacklist of revoked certificates published by the CA. Clients check this before trusting a cert.

• Problem: CRLs can grow large and are not real-time (updated periodically, e.g., hourly/daily).

• Example: If a private key is stolen (e.g., Heartbleed bug), the CA adds the cert to the CRL.

• OCSP (Online Certificate Status Protocol): A real-time alternative to CRLs. Clients query the CA’s OCSP responder to check if a cert is revoked.

• Port: TCP 80 (HTTP) or TCP 443 (HTTPS).
• Problem: Privacy risk (OCSP requests reveal browsing activity). OCSP stapling (RFC 6066) fixes this by letting the server cache the OCSP response.

• Tool: openssl ocsp -issuer ca.crt -cert server.crt -url http://ocsp.example.com

• PKCS (Public Key Cryptography Standards): A set of standards by RSA Labs for PKI operations. Key ones:

• PKCS#7: Used for signed/encrypted messages (e.g., S/MIME emails).
• PKCS#10: CSR format.

• PKCS#12: PFX/P12 files (stores private key + cert, password-protected).

• Key Pair: A public key (shared) and private key (kept secret). Used for:

• Encryption: Public key encrypts, private key decrypts (e.g., PGP email).
• Signing: Private key signs, public key verifies (e.g., code signing).

• Example: If a server’s private key is leaked (e.g., 2014 Heartbleed), attackers can decrypt past/future traffic.

• Certificate Pinning (HPKP): A security mechanism where a client hardcodes a server’s public key or cert to prevent MITM attacks (e.g., Google Chrome for Gmail).

• Risk: If the pinned key is lost, the site breaks. Deprecated in favor of Certificate Transparency (CT).

• Certificate Transparency (CT): A public log of all issued certificates (RFC 6962). Monitors for fraudulent certs (e.g., 2018 Symantec distrust).

• Tools: crt.sh, Google’s CT Logs.

• RA (Registration Authority): A middleman that verifies identity before a CA issues a cert. Reduces CA workload.

• Example: A bank’s RA verifies a customer’s ID before requesting a cert for online banking.

• HSM (Hardware Security Module): A tamper-resistant device that stores and manages private keys (e.g., AWS CloudHSM, Thales HSM).

• Use Case: Protecting a CA’s root private key (kept offline in an HSM).

Step-by-Step / Process Flow

How PKI Works in Practice (e.g., HTTPS Connection)

1. Certificate Request (CSR Generation)
2. A server admin generates a key pair (openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048).
3. Creates a CSR (openssl req -new -key server.key -out server.csr).

4. Submits the CSR to a CA (e.g., Let’s Encrypt, DigiCert).

5. CA Validation & Issuance

6. The RA verifies the requester’s identity (e.g., domain ownership via DNS TXT record or HTTP challenge).
7. The CA signs the CSR with its private key, creating a digital certificate (e.g., server.crt).

8. The CA publishes the cert in Certificate Transparency logs.

9. Certificate Deployment

10. The server admin installs the cert (server.crt) and private key (server.key) on the web server (e.g., Apache/Nginx).

11. Configures the server to use TLS (e.g., SSLCertificateFile /path/to/server.crt).

12. Client Connection & Verification

13. A user visits https://example.com.
14. The server presents its certificate chain (end-entity cert + intermediate CA certs).

15. The client:

    
    
    • Checks the validity period (not expired).
    • Verifies the signature (using the CA’s public key).
    • Checks revocation status via OCSP or CRL.
    • Ensures the cert is trusted (CA is in the client’s trust store).

16. Secure Communication

17. If all checks pass, the client and server perform a TLS handshake (e.g., ECDHE-RSA-AES256-GCM-SHA384).

18. A symmetric session key is established for encrypted communication.

19. Certificate Renewal/Revocation

20. Renewal: Certs expire (e.g., 90 days for Let’s Encrypt). Admins must renew before expiry.
21. Revocation: If a private key is compromised, the CA adds the cert to the CRL or marks it as revoked in OCSP.

Common Mistakes

Certification Exam Tips

1. CISSP Trap: Questions may ask about PKI management (e.g., "Which is the BEST way to protect a root CA’s private key?"). Answer: Offline HSM in a secure facility.

2. Wrong answers: "Store it in a database" or "Use a password-protected USB drive."

3. Security+ Focus: Know the difference between CRL and OCSP.

4. CRL: Periodic, large file, downloaded by clients.

5. OCSP: Real-time, smaller, but privacy risk (unless stapled).

6. CEH Angle: Attackers target weak PKI implementations (e.g., self-signed certs, expired certs, misconfigured OCSP).

7. Example: A MITM attack succeeds if the client ignores cert warnings.

8. Tricky Distinction: Certificate Pinning vs. Certificate Transparency

9. Pinning: Client hardcodes a cert/key (prevents MITM).
10. Transparency: Public logs monitor for fraudulent certs (detects CA misissuance).

Quick Check Questions

1. A security analyst discovers that a web server’s private key was leaked. What is the FIRST action the CA should take?
2. A) Reissue the certificate with a new key pair.
3. B) Add the certificate to the CRL.
4. C) Notify all users to update their trust stores.
5. D) Revoke the intermediate CA certificate.

6. ✅ Correct Answer: B

   
   
   • Explanation: The immediate step is to revoke the compromised cert (add to CRL/OCSP) to prevent misuse.

7. During a penetration test, an attacker intercepts HTTPS traffic by presenting a self-signed certificate. Which PKI control would have prevented this?

8. A) Certificate Transparency
9. B) Certificate Pinning
10. C) OCSP Stapling
11. D) Key Escrow

12. ✅ Correct Answer: B

    
    
    • Explanation: Certificate Pinning ensures the client only accepts a specific cert/key, blocking self-signed or fraudulent certs.

13. A company’s internal PKI uses a root CA and two intermediate CAs. Which of the following is the MOST secure way to store the root CA’s private key?

14. A) Encrypted on a network-attached storage (NAS) device.
15. B) In a hardware security module (HSM) kept offline.
16. C) On a USB drive in a locked cabinet.
17. D) In a cloud-based key management service (KMS).
18. ✅ Correct Answer: B
    • Explanation: Root CA private keys must be offline and in an HSM to prevent compromise. Cloud KMS or NAS are not secure enough.

Last-Minute Cram Sheet

1. PKI = Public Key Infrastructure – Manages digital certificates for encryption/authentication.
2. X.509 – Standard for digital certificates (used in TLS, S/MIME).
3. CA = Certificate Authority – Issues and signs certificates (e.g., DigiCert, Let’s Encrypt).
4. CSR = Certificate Signing Request – PKCS#10 file sent to a CA to request a cert.
5. CRL = Certificate Revocation List – Blacklist of revoked certs (updated periodically).
6. OCSP = Online Certificate Status Protocol – Real-time revocation check (port 80/443).
7. OCSP Stapling – Server caches OCSP response to improve performance/privacy.
8. HSM = Hardware Security Module – Tamper-resistant device for storing private keys.
9. Certificate Pinning – Client hardcodes a cert/key to prevent MITM (deprecated in favor of CT).
10. ⚠️ Exam Trap: Self-signed certs are not trusted by default (no CA signature). Used for testing/internal use only.

Final Tip: For CISSP, focus on PKI management (key storage, CA hierarchy, revocation). For Security+/CEH, know attack vectors (MITM, weak keys, misconfigured OCSP).