Public Key Infrastructure (PKI)

What the Exam Is Really Testing

PKI is the system that makes digital trust work. Without PKI, you would have no way to verify that a website is legitimate, that a software update came from the real vendor, or that an email was actually sent by the person claiming to send it.

CompTIA tests whether you understand how certificates are issued, validated, revoked, and managed — and what happens when any of these processes fail.

You need to know the components, the certificate types, the lifecycle, and the trust models. You also need to recognize scenarios where PKI is misconfigured, expired, or compromised.

PKI Components

Certificate Authority (CA)

The CA is the trusted entity that issues digital certificates. It verifies the identity of the certificate requester and signs the certificate with its own private key. This signature is what creates trust.

• Root CA: The top of the trust hierarchy. The root CA's certificate is self-signed and must be inherently trusted. Root CA private keys are stored offline in air-gapped systems for maximum protection
• Intermediate CA (Subordinate CA): Issues certificates on behalf of the root CA. This creates a chain of trust without exposing the root CA's private key to online operations

If the root CA's private key is compromised, every certificate in the entire hierarchy becomes untrustworthy. This is why root CAs are kept offline.

Registration Authority (RA)

The RA handles the identity verification process. When someone requests a certificate, the RA verifies their identity before the CA issues the certificate. The RA does not sign certificates — it validates requests and forwards them to the CA.

Certificate Revocation List (CRL)

A CRL is a published list of certificates that have been revoked before their expiration date. Certificates are revoked when:

• The private key is compromised
• The certificate holder leaves the organization
• The certificate was issued in error
• The CA itself is compromised

CRLs are downloaded and cached by clients. The drawback is that they can become large and may not be immediately current.

Online Certificate Status Protocol (OCSP)

OCSP provides real-time certificate status checking. Instead of downloading an entire CRL, the client sends a query about a specific certificate and receives an immediate response: valid, revoked, or unknown.

• Faster than CRL for individual certificate checks
• Reduces bandwidth compared to downloading full CRLs
• OCSP stapling allows the server to cache the OCSP response and present it to clients, reducing load on the OCSP responder

Certificate Types

CompTIA tests your knowledge of specific certificate types and when to use each one.

Domain Validation (DV) Certificates

The simplest certificate type. The CA verifies only that the requester controls the domain. No organizational identity verification. Quick to issue, lowest cost, lowest assurance level.

Organization Validation (OV) Certificates

The CA verifies the organization's identity in addition to domain control. Provides higher assurance than DV. The organization's name appears in the certificate details.

Extended Validation (EV) Certificates

The highest level of validation. The CA performs thorough verification of the organization's legal identity, operational existence, and authorization. Traditionally displayed a green address bar in browsers (though this visual indicator has been largely deprecated).

Wildcard Certificates

A wildcard certificate covers a domain and all its subdomains at one level. A certificate for *.example.com covers mail.example.com, www.example.com, and api.example.com — but not sub.api.example.com.

• Simplifies certificate management for multiple subdomains
• Risk: if the wildcard certificate's private key is compromised, all subdomains are affected

Subject Alternative Name (SAN) Certificates

A SAN certificate can include multiple domain names in a single certificate. Unlike wildcard certificates, SAN certificates can cover completely different domains: example.com, example.org, and different-domain.com in one certificate.

Self-Signed Certificates

A certificate signed by the entity that created it, rather than by a trusted CA. Self-signed certificates are not trusted by default because there is no third-party verification.

• Used in development and testing environments
• Used for root CA certificates (root CAs sign their own certificates)
• Should not be used for public-facing production systems
• Browsers display security warnings for self-signed certificates

Code Signing Certificates

Used to digitally sign software, scripts, and executables. A code signing certificate proves that the software came from the identified publisher and has not been modified since signing.

If a question describes verifying the authenticity and integrity of downloaded software, the answer involves code signing certificates.

Certificate Lifecycle

Certificates have a defined lifecycle that CompTIA expects you to understand:

1. Certificate request (CSR): The entity generates a key pair and creates a Certificate Signing Request containing the public key and identity information
2. Identity verification: The RA validates the requester's identity according to the certificate type requirements
3. Certificate issuance: The CA signs the certificate with its private key and returns it to the requester
4. Certificate use: The certificate is installed and used for its intended purpose (TLS, code signing, email encryption)
5. Certificate renewal: Before expiration, the certificate is renewed (either reissued or a new certificate is obtained)
6. Certificate revocation: If compromised or no longer needed, the certificate is revoked and added to the CRL or updated in OCSP
7. Certificate expiration: Certificates have a defined validity period. Expired certificates are no longer trusted

Trust Models

PKI uses hierarchical trust models to establish confidence in certificates.

Chain of Trust

The chain of trust links a certificate back to a trusted root CA through one or more intermediate CAs. When your browser validates a website's certificate, it follows the chain:

1. Website certificate → signed by intermediate CA
2. Intermediate CA certificate → signed by root CA
3. Root CA certificate → trusted by the operating system or browser

If any link in the chain is broken (expired, revoked, or untrusted), the entire chain fails and the certificate is rejected.

Certificate Pinning

Certificate pinning restricts which certificates or CAs a client will accept for a specific domain. Instead of trusting any certificate signed by any trusted CA, the client is configured to accept only specific certificates or certificates from specific CAs.

• Protects against compromised CAs issuing fraudulent certificates
• Commonly implemented in mobile applications
• Reduces the attack surface of the PKI trust model
• Requires careful management — a pinned certificate that expires without update breaks connectivity

Key Management

The security of PKI depends entirely on protecting private keys. Key management encompasses the entire lifecycle of cryptographic keys.

• Key generation: Keys must be generated using a cryptographically secure random number generator
• Key storage: Private keys should be stored in hardware security modules (HSMs), trusted platform modules (TPMs), or other secure storage. Never in plaintext on disk
• Key distribution: Public keys can be shared freely. Private keys must never be transmitted
• Key rotation: Keys should be replaced on a regular schedule to limit the exposure window if a key is compromised
• Key destruction: When keys are no longer needed, they must be securely destroyed to prevent future misuse

Key Escrow

Key escrow is the practice of storing a copy of an encryption key with a trusted third party. This ensures that encrypted data can be recovered if the original key holder is unavailable (terminated employee, lost key, legal requirement).

• Common in enterprise environments for data recovery
• Required by some regulations for lawful interception
• Creates a secondary target for attackers — the escrow agent must be protected
• Should only be used for encryption keys, never for signing keys (signing keys in escrow would undermine non-repudiation)

Key escrow enables data recovery but introduces risk. If escrow keys are compromised, all data encrypted with those keys is exposed. The escrow agent becomes a high-value target.

Pattern Recognition

Security+ questions on PKI follow these patterns:

• Component identification: "Which PKI component verifies identity before certificate issuance?" Registration Authority (RA)
• Certificate type selection: "An organization needs a single certificate for mail.example.com, www.example.com, and api.example.com." Wildcard certificate (*.example.com) or SAN certificate
• Revocation checking: "A client needs to check if a specific certificate has been revoked in real time." OCSP provides real-time, per-certificate checks
• Trust chain failures: "Users receive certificate warnings when accessing an internal application." The chain of trust is broken — likely a self-signed or untrusted intermediate CA
• Key escrow scenarios: "An employee leaves and their encrypted files need to be recovered." Key escrow provides the recovery key

Trap Patterns

Common wrong answers and why they are wrong:

• Confusing CA with RA: The CA signs certificates. The RA verifies identity. The RA does not issue or sign anything. If the question asks about identity verification, the answer is RA. If it asks about signing, the answer is CA
• Confusing CRL with OCSP: CRL is a batch download of all revoked certificates. OCSP is a real-time query for a specific certificate. If the question mentions real-time checking, the answer is OCSP
• Thinking wildcard covers all subdomain levels: A wildcard for *.example.com covers one level only. It does not cover sub.sub.example.com. Multi-level coverage requires SAN or multiple certificates
• Suggesting key escrow for signing keys: Key escrow is for encryption keys only. Escrowing a signing key would allow someone else to sign as you, destroying non-repudiation

Scenario Practice

Question 1

A company operates 15 web applications hosted on subdomains of its primary domain (app1.company.com, app2.company.com, etc.). The security team wants to minimize certificate management overhead while covering all current and future subdomains.

Which certificate type is MOST appropriate?

A. Individual DV certificates issued for each subdomain application separately
B. A wildcard certificate covering all subdomains under the primary domain
C. A self-signed certificate generated and installed on each web server
D. An extended validation certificate for the primary domain name only

Question 2

A security analyst discovers that a certificate used by an internal application was issued by an intermediate CA whose certificate has expired. Users are reporting security warnings when trying to access the application.

What is the ROOT CAUSE of the security warnings?

A. The application's own TLS certificate has been revoked by the root CA
B. The chain of trust is broken because the intermediate CA certificate expired
C. The users' browsers do not have the application certificate installed locally
D. The application server needs to regenerate a new self-signed certificate

Question 3

An employee who managed the organization's encrypted file archive has unexpectedly left the company. The encryption keys were stored only on the employee's workstation, which has been wiped according to the offboarding procedure. Critical business files in the archive are now inaccessible.

Which PKI practice would have prevented this data loss scenario?

A. Certificate pinning to restrict which CAs could issue employee certificates
B. OCSP stapling to ensure real-time certificate validation for all file access
C. Key escrow to maintain recoverable copies of encryption keys with a trustee
D. Code signing to verify the integrity of the encryption software application

Key Takeaway

PKI is the trust framework that underpins digital security. The CA issues certificates, the RA verifies identity, CRLs and OCSP handle revocation, and the chain of trust connects everything back to a trusted root. Know the certificate types (wildcard, SAN, self-signed, code signing) and when to use each one. Understand the certificate lifecycle from request to expiration. Remember that key management is the foundation of PKI security — protect private keys, rotate them regularly, and use key escrow only for encryption keys when data recovery is a business requirement.