PKI & Digital Certificates Explained for Security+

If you've spent any time studying for CompTIA Security+, you've probably encountered terms like "PKI," "certificate authority," "X.509," and "revocation." These concepts intimidate a lot of test-takers, but here's the truth: PKI (Public Key Infrastructure) solves a simple, elegant problem. And once you understand the problem, the entire system makes sense.

Let's start there.

The Problem: How Do You Trust a Public Key?

Imagine you're visiting your bank's website. Your browser receives a public key and thinks, "Great, I can use this to encrypt my login credentials." But wait—how do you know this public key actually belongs to your bank and not to a hacker impersonating your bank?

This is the fundamental problem that PKI solves. Without PKI, anyone could claim to be your bank. They could set up a website that looks exactly like your bank's and hand you a public key saying, "Trust me, I'm your bank." You'd have no way to verify the claim.

PKI creates a chain of trust. It says: "I'm going to introduce you to some organizations I already trust to verify identities. If those organizations say this public key belongs to your bank, then you can trust it too."

That's the entire concept. Everything else builds from there.

The Trust Model: A Chain From Root to Leaf

PKI works through a hierarchical trust structure. Think of it like government authority delegation:

Root Certificate Authority (Root CA) = Government

The ultimate trusted authority
Pre-installed in your operating system and browser
You trust it by default
Issues certificates to intermediate CAs

Intermediate Certificate Authority (Intermediate CA) = Department of Motor Vehicles

Delegated authority from the Root CA
Verifies organizations and individuals
Issues end-entity certificates (like driver's licenses)
Can itself be issued by another intermediate CA

End-Entity Certificate = Driver's License

Issued to the actual website, person, or device
Contains the public key you use for encryption
Valid for a limited time period
Must be traceable back to a trusted root

When your browser connects to a website, it receives the end-entity certificate. The browser then traces the chain: "Who issued this certificate? That CA was issued by whom? And so on..." until it reaches a Root CA that's already installed and trusted on the system. If the chain is unbroken, the certificate is legitimate.

This is why your browser trusts secure.paypal.com but would immediately reject a certificate issued by "John's Totally Legit Bank CA"—because John's CA isn't in the trust store.

What's Actually Inside a Certificate: The X.509 Standard

When you look at a digital certificate, you're looking at a standardized format called X.509. This is the format the CompTIA Security+ exam expects you to know.

A certificate contains:

Subject Name: Who the certificate belongs to (e.g., www.example.com)
Issuer: The Certificate Authority that issued it
Public Key: The actual key for encryption
Serial Number: A unique identifier for this specific certificate
Validity Dates: "Valid from [date] to [date]"
Signature: The CA's digital signature proving they issued and approve this certificate
Extensions: Additional information (like who can use the certificate, what it can be used for, etc.)

The signature is the key part here. The CA signs the certificate with their private key. Anyone who trusts the CA can verify that signature using the CA's public key, confirming the certificate is genuine and hasn't been tampered with.

Certificate Types: Different Validation Levels

Not all certificates are created equal. The CompTIA Security+ exam tests three validation levels:

Domain Validation (DV) Certificates

What it proves: You control the domain (not much else)
How validation works: CA sends an email to admin@yourdomain.com or looks for a verification file on your server
Cost: Cheapest
Time to issue: Minutes to hours
Browser indicator: Green padlock (same as others)
Real-world use: Most of the internet, including many legitimate sites

Organization Validation (OV) Certificates

What it proves: An organization actually exists and you control the domain
How validation works: CA performs deeper checks—verifies business registration, sometimes calls to verify
Cost: More expensive than DV
Time to issue: Days to weeks
Browser indicator: Green padlock, but you can click to see organization details
Real-world use: Medium-to-large organizations, financial services

Extended Validation (EV) Certificates

What it proves: Extensive verification that the organization exists, is legitimate, and is the owner
How validation works: Most thorough process—background checks, business verification, legal review
Cost: Most expensive
Time to issue: Weeks to months
Browser indicator: Green padlock + organization name displayed prominently
Real-world use: Banks, large financial institutions, high-security sites

The exam also tests special certificate types:

Wildcard Certificates: *.example.com matches mail.example.com, ftp.example.com, but not mail.dev.example.com (subdomain limitation)
Subject Alternative Name (SAN) Certificates: One certificate for multiple domains (example.com AND mail.example.com AND ftp.example.com)
Self-Signed Certificates: Issued by the subject to itself, not by a CA (untrusted by browsers, but used internally for testing)

How Certificate Validation Actually Works

When your browser connects to a website via HTTPS, here's what happens under the hood:

Chain Verification: Browser receives the website's certificate and traces the chain backward. "Who issued this? Who issued that? Who issued that?" until reaching a trusted Root CA in the system.
Signature Verification: Browser verifies each certificate's signature using the issuer's public key, confirming no tampering.
Expiration Check: Browser confirms the certificate hasn't expired. If the date is outside the "Valid From" and "Valid To" window, the connection is refused.
Revocation Check: Browser checks whether the certificate has been revoked (we'll cover this next). If it has, the connection is refused.
Name Matching: Browser confirms the domain in the certificate matches the domain you're visiting. example.com certificates won't validate for different-example.com.

If any of these checks fail, you see a big scary warning. If all pass, the padlock appears and you can trust the connection.

Certificate Revocation: When Certs Need to Die Early

Certificates have expiration dates—sometimes years in the future. But sometimes they need to be revoked before expiration:

Compromise: The organization's private key was stolen
Domain Transfer: The domain was sold to a different company
Employee Departure: An employee who held a personal certificate left the company
Incorrect Information: The certificate was issued with wrong details
Policy Violation: The organization violated CA requirements

The question is: how does the browser find out a certificate has been revoked?

CRL (Certificate Revocation List)

Periodic list of revoked certificate serial numbers published by the CA
Browser downloads the list and checks if the certificate serial number is on it
Pros: Clear and straightforward
Cons: Lists can get huge; browsers must regularly download; not real-time (revoked certs might still work briefly)

OCSP (Online Certificate Status Protocol)

Real-time protocol: browser sends the certificate serial number to the CA and asks "Is this revoked?"
CA responds immediately with the status
Pros: Real-time, no huge files to download
Cons: Slower (extra network request), privacy concern (CA sees every site you visit), single point of failure if OCSP responder is down

OCSP Stapling

How it works: The web server periodically fetches the OCSP response from the CA and "staples" it to the certificate it serves to clients
Pros: Real-time revocation checking without privacy concerns or extra network requests
Cons: Server must be configured to staple; if server fails to refresh, clients might accept revoked certs
Modern best practice: This is increasingly the standard for high-security sites

The CompTIA Security+ exam tests your understanding of these methods and when each is appropriate.

Certificate Formats: The Different "Flavors"

Certificates can be encoded in different formats. The exam specifically tests:

PEM (Privacy Enhanced Mail)

File extensions: .pem, .crt, .key
Format: Base64-encoded text (looks like gobbledygook but is human-readable)
Contains: Certificate chain, public key, or private key (depending on the file)
Most common: Yes, especially on Linux/Unix systems
Example use: Web servers, email clients

DER (Distinguished Encoding Rules)

File extensions: .der, .cer
Format: Binary format (looks like random gibberish if you open it in a text editor)
Contains: Usually just the certificate (public information only)
Pros: More compact than PEM
Cons: Less portable; less human-readable

PFX / PKCS#12

File extensions: .pfx, .p12
Format: Binary container
Contains: Certificate chain AND private key (password-protected)
Pros: Everything you need in one file
Cons: Private key is included, so guard these files carefully
Use case: Installing certificates on Windows systems; exporting from browsers

P7B / PKCS#7

File extensions: .p7b
Format: Base64-encoded or binary
Contains: Certificate chain (no private key)
Use case: Distributing certificate chains without the private key

The exam often includes scenarios like: "You need to install a certificate on a Windows server and you have a .pem file. What do you need to do?" Answer: Convert it to PFX or import it differently, because Windows prefers PFX.

Certificate Pinning: Preventing CA Compromise Attacks

Certificate pinning is a security technique where an application "pins" a specific certificate or public key to a host. Instead of trusting any certificate signed by a trusted CA, the app says: "I only trust THIS certificate (or public key) for this domain."

Example: A mobile banking app might pin the bank's certificate. If a hacker somehow compromised a CA and issued a fraudulent certificate for the bank, the app would still reject it because it's not the pinned certificate.

Where it's used:

Mobile apps (iOS and Android apps can implement certificate pinning)
API clients that need high security
Government and military applications

Why it matters: It protects against CA compromise—if a CA is breached and issues fraudulent certificates, pinning prevents those fraudulent certificates from being accepted.

The CompTIA Security+ exam tests whether you understand pinning as a defense against CA compromise attacks.

What CompTIA Security+ Really Tests About PKI

Here's what actually shows up on the exam (focus your study here):

Trust chains and validation: How browsers verify a chain of certificates back to a trusted root
Certificate revocation methods: Differences between CRL, OCSP, and OCSP stapling
Certificate types by validation level: DV vs. OV vs. EV and what each proves
Certificate formats: When to use PEM, DER, PFX, or P7B
Scenario questions: "An employee left the company and had a certificate. What should be done?" (Answer: Revoke it)
Special certificate types: Wildcards, SANs, self-signed certs, and their use cases
Certificate pinning: Why it's used and what it protects against
X.509 components: What fields are in a certificate and what they mean

Most importantly, understand the problem PKI solves: establishing trust in public keys. If you understand the problem, the rest is just implementation details.

Key Takeaways

PKI establishes trust: It proves that a public key belongs to who it claims to belong to
Trust is hierarchical: Root CA → Intermediate CA → End-Entity Certificate
Certificates contain standardized information in X.509 format (subject, issuer, public key, signature, validity dates, serial number)
Validation levels vary: DV proves domain control, OV proves organization existence, EV provides the most thorough verification
Certificates must be validated: Browser checks chain, expiration, and revocation status
Revocation methods differ: CRL is periodic, OCSP is real-time, OCSP stapling is efficient
Format matters: PEM, DER, PFX, and P7B each serve different purposes
Pinning adds defense: It protects against CA compromise by limiting which certificates are trusted

Ready to test your PKI knowledge? Take a free Security+ diagnostic test and see where you stand on certificate-related questions.

Ready to master PKI and the rest of Security+? Start your free diagnostic test with LearnZapp — no signup required. Our 1,543 Security+ SY0-701 questions and 320 Wiley-sourced articles cover everything from PKI to threat intelligence, and they're all built specifically for CompTIA certification success.