If you ask ten Security+ candidates where they got tripped up on the exam, at least three of them will say PKI. Not because the concept is hard — it isn't — but because the topic is taught backwards in most study guides. Everyone jumps straight into "Root CA, Intermediate CA, end-entity certificate" without explaining what problem any of that is actually solving.
So before we touch a single acronym, here's the question PKI digital certificates exist to answer: when your browser receives a public key from a website, how does it know that key actually belongs to the website it claims to belong to?
That's it. That's the whole problem. Once you internalize that, the rest is plumbing.
The trust problem in one paragraph
You connect to your bank. Server hands you a public key. Without something else in the picture, you have no way to verify whether the key came from your bank or from someone sitting between you and your bank pretending to be them. You can encrypt a message with that key just fine — but you might be encrypting it for the wrong person.
PKI fixes this by introducing a third party your browser already trusts, and having that third party vouch for the key. The Certificate Authority is that third party. The certificate is the vouching.
That's the whole model. Everything below is implementation.
How the trust chain actually works
Browsers ship with a list of root CAs they trust by default. You didn't pick them — Microsoft, Apple, Google, Mozilla picked them on your behalf, and they curate that list pretty aggressively. Get caught misbehaving and your CA gets removed from the trust store, which is essentially a death sentence for a certificate authority.
Root CAs almost never sign end-entity certificates directly. They delegate to intermediate CAs, which then sign the certificate for yourbank.com. So the chain looks like:
Root CA → Intermediate CA → End-entity certificate (the bank's)
When your browser gets the bank's certificate, it walks backward up that chain, verifying each signature with the issuer's public key, until it lands on a root it already trusts. Unbroken chain, valid signatures, you get the padlock. Broken chain anywhere, you get the scary warning page.
One detail that catches people on exam questions: the root CA's certificate is self-signed. It has to be — there's no higher authority to sign it. That's not a flaw, it's the design. The trust comes from the fact that the root cert is pre-installed in your OS/browser, not from a signature.
What's actually in an X.509 certificate
X.509 is the format. When the exam asks about certificate fields, it's asking about X.509 fields. The ones worth memorizing:
- Subject — who the cert belongs to
- Issuer — which CA signed it
- Public key — the actual key the cert is binding to the subject
- Serial number — unique per CA, used heavily in revocation
- Validity period — not before / not after
- Signature — the CA's signature over everything above
- Extensions — the catch-all bucket where things like Subject Alternative Name (SAN), key usage, and basic constraints live
The signature field is the one most people gloss over and then get burned on. It's not the bank signing anything. It's the CA signing the bank's certificate using the CA's private key. That signature is what your browser verifies using the CA's public key (which it gets from the CA's own certificate, further up the chain). Tampering with any field invalidates the signature. That's how you know the cert is genuine.
Certificate types: the validation levels
The exam tests three flavors here, but it doesn't really treat them equally — and neither will I.
DV (Domain Validation) is by far the most common type of cert on the modern internet. The CA confirms you control the domain, usually by having you put a token at a specific URL or by emailing the domain admin. That's it. No human verification, no business check. Let's Encrypt is the canonical example, and it's what most of the web uses now. Issued in minutes.
OV (Organization Validation) adds a verification of the organization itself — business registration lookups, sometimes a phone call. More expensive, slower (days to weeks), used mostly by mid-sized businesses that want a cert with their org name visible in the details.
EV (Extended Validation) used to mean something visible to users — the green company name in the address bar. That UI treatment got removed from Chrome and Firefox a few years back because research showed users didn't actually pay attention to it. EV still exists, banks still buy them, but the "premium UI" justification is mostly gone. The exam still tests it, so know it exists and know it requires the most thorough vetting (legal, business, identity).
What CompTIA loves to test isn't the differences between them so much as scenario questions: an internal-only application, a public banking site, a small business e-commerce store — which validation level fits? Default rule of thumb: DV for anything where you just need encryption, OV/EV for anything where the organization's identity matters to the user.
A few more cert types worth knowing:
Wildcard certs cover one level of subdomain — *.example.com matches mail.example.com but not mail.eu.example.com. People miss this on the exam constantly.
SAN (Subject Alternative Name) certs let one cert cover multiple specific names — example.com, www.example.com, api.example.com. SAN is also how you cover multiple unrelated domains under one cert.
Self-signed certs are signed by the subject itself. No CA, no chain, no trust outside whoever you tell to trust it. Fine for internal lab work, dev environments, internal services where you can manually distribute the cert. Show one to a public browser and you'll get a giant warning. The exam likes scenarios where someone uses self-signed in production by mistake.
The validation handshake (what the browser actually checks)
When you load an HTTPS site, your browser runs through these checks more or less in order:
- Build the chain from the leaf cert back to a trusted root.
- Verify the signature on every cert in the chain.
- Confirm the validity period — current date inside the not-before/not-after window.
- Confirm the certificate's subject (or a SAN entry) matches the hostname you typed.
- Check revocation status.
Any single failure breaks the connection. Step 4 is where you get the "the certificate is for *.example.com but you visited example.org" errors. Step 5 is where things get interesting, which brings us to the messiest part of PKI on the exam.
Revocation: where the system gets ugly
Certs expire on their own, but sometimes you need to kill a cert before its expiration date — the private key got stolen, an employee left, the domain was sold, whatever. The mechanism for that is revocation, and the exam tests three approaches.
CRLs (Certificate Revocation Lists) are exactly what they sound like. The CA publishes a signed list of revoked serial numbers. Your browser downloads it and checks whether the cert's serial is on the list. The problem is obvious: these lists get huge, they're cached, and revocation isn't real-time. A revoked cert can keep working until your browser refreshes the CRL.
OCSP (Online Certificate Status Protocol) was the fix. Instead of downloading a giant list, your browser asks the CA's OCSP responder, "is this serial number revoked?" and gets back a yes/no. Real-time. Smaller. But also: every site you visit triggers a request to the CA's responder, which is a privacy problem, and if the responder is down, you either fail open (insecure) or fail closed (annoying).
OCSP stapling is the modern compromise and the one most exam scenarios point you toward. The web server itself periodically asks the CA for an OCSP response, then attaches ("staples") that response to the TLS handshake when you connect. No extra network call from your browser, no leaking your browsing history to the CA, and revocation status is still recent. Almost every halfway-modern web server supports it.
If you see a revocation question on the exam and aren't sure, OCSP stapling is usually the right answer for "modern best practice" framing. CRL is usually right for "we have an isolated network with no internet access" type scenarios.
Certificate file formats — yes, you have to know them
This is the dumbest part of the exam to memorize, but it shows up. Here's the cheat sheet, learn it once and move on:
PEM is the most common format on Linux. Base64-encoded, starts with -----BEGIN CERTIFICATE-----, ends with -----END CERTIFICATE-----. Extensions: .pem, .crt, .cer, .key. Can hold certs, chains, or private keys.
DER is the binary version of PEM. Same data, different encoding. Extensions: .der, .cer. Common in Java environments and on Windows for individual certs.
PKCS#12 (also called PFX) is the bundle format — cert plus private key plus chain, all in one password-protected file. Extensions: .pfx, .p12. This is what you use to move a complete identity between systems. Guard it carefully because it contains the private key.
PKCS#7 (P7B) bundles certs and chains but no private key. Extensions: .p7b, .p7c. Used for distributing intermediate chains.
The trap on exam scenarios: .cer can be either PEM or DER, depending on encoding. If a question gives you a .cer file and asks how to view it, the answer depends on what's inside, not the extension. Windows is loose about this; Linux usually tells you exactly what you've got.
Certificate pinning
Pinning is the answer to the question, "what if a CA gets compromised and issues a fraudulent cert for my bank?" Without pinning, your browser would happily accept that fraudulent cert because it's signed by a trusted CA. With pinning, the application has been told in advance, "only accept this specific certificate (or this specific public key) for this specific host."
It's used heavily in mobile banking apps and high-security API clients. It's not really a thing in regular browsers anymore — Chrome killed HPKP (HTTP Public Key Pinning) years ago because it was too easy to brick your own site with a misconfiguration. The exam still tests pinning as a concept and as a defense against CA compromise. That's the answer it's looking for.
What the exam actually focuses on
Out of everything above, the exam disproportionately tests four things:
The trust chain. Specifically, scenarios where the chain is broken — missing intermediate, expired root, wrong CA — and you have to identify what failed.
Revocation method tradeoffs. CRL vs OCSP vs stapling, and which fits a given scenario. Pay attention to constraints in the question (offline network, privacy concerns, real-time requirements).
Certificate types in context. "An internal CA issues certs for development servers" — that's self-signed or private CA territory. "A public e-commerce site" — DV at minimum, OV/EV for trust signaling.
Validation failures. Hostname mismatch, expired cert, untrusted issuer, revoked. The exam loves to give you the symptom and ask you for the cause.
Two things the exam under-tests relative to how much study material covers them: the deep internals of how signatures work mathematically (you don't need to know this) and the fine differences between PEM/DER encoding (know they exist, know which one's binary, move on).
A pattern I've noticed with people prepping for this section: they spend hours memorizing the exact bytes of an X.509 extension and then get the revocation question wrong. The exam isn't testing whether you could implement a CA. It's testing whether you'd make the right call as a security analyst.
If certificates are the part of Security+ giving you the most trouble, the related domains worth reviewing alongside it are cryptography (covered in our Security+ cryptography post) and the broader exam domain breakdown (all five Security+ domains here). PKI sits at the intersection of both.
Where to go from here
The honest move at this point is to stop reading about PKI and start answering questions about it. PKI is one of those topics where you can read for hours and still bomb the scenario questions, because reading doesn't train the "spot what's wrong with this chain" instinct that the exam tests.
LearnZapp's free Security+ diagnostic includes PKI and certificate scenario questions in the mix, so you can see whether you actually retained any of this or whether it just felt familiar.
Take the free Security+ diagnostic — no signup, results in about 20 minutes, with a domain-by-domain breakdown so you know where your real weak spots are.