PKI is one of those Security+ topics that feels simple until the exam hands you four answers that all use the same five words: key, sign, certificate, CA, and trust. Once you can say exactly who holds each key and who signs what, most PKI questions stop being tricky.
Here is the whole flow, in the order it actually happens.
It starts with a key pair you generate yourself
Before any certificate exists, you generate a key pair on your own server: a private key and a matching public key. The private key stays on that server and never leaves it. Write that down, because it is the single fact most missed questions hinge on.
The CSR carries your public key, not your private key
To get a certificate, you create a Certificate Signing Request (CSR). The CSR contains your public key and your identity details like the domain name and organization. You sign the CSR with your private key to prove you actually hold it, but the private key itself is not in the request. If an answer choice says you send your private key to the CA, it is wrong every time.
The CA signs, it does not encrypt
The Certificate Authority checks your request, then issues a certificate. Here is the part people blur together: the CA takes a hash of the certificate and signs that hash with the CA's own private key. It is not encrypting your data and it is not touching your private key. Anyone can then verify that signature using the CA's public key, which is baked into the certificate chain. Signing proves who issued the cert and that it has not been altered. That is integrity and authenticity, not confidentiality.
Chain of trust: leaf, intermediate, root
Your certificate, the leaf, is signed by an intermediate CA, which is signed by a root CA. Your device already trusts the root because it ships in the operating system or browser trust store. The chain lets a client walk from your cert up to a root it already trusts.
This is also a very common real-world failure. If a server only sends its leaf certificate and forgets the intermediate, some clients throw an "unable to verify" error even though nothing is expired or revoked. The cert is fine. The chain is broken.
Revocation: killing a cert before it expires
Say a private key gets stolen. You cannot wait for the certificate to expire on its own, so you revoke it. Two mechanisms show up on the exam:
- A CRL (Certificate Revocation List) is a signed list of revoked serial numbers the CA publishes on a schedule. It works, but it can be large and a little stale between updates.
- OCSP (Online Certificate Status Protocol) lets a client ask about one specific certificate in real time, which is faster and lighter than downloading a whole list.
There is one more worth knowing: OCSP stapling. Instead of every client hitting the CA, the web server itself fetches a recent, timestamped OCSP response and staples it to the TLS handshake. Better privacy, less load on the CA. If a question mentions the server presenting proof of validity during the handshake, that is stapling.
The distinctions the exam loves
A few more that separate a pass from a miss:
- A self-signed certificate is signed by its own key, so no external CA vouches for it. It encrypts traffic fine, but nothing outside trusts it by default. Good for internal or test use, not the public web.
- A wildcard certificate (*.example.com) covers all subdomains at one level. A SAN certificate lists specific names. If the question needs several different domains on one cert, that is SAN, not wildcard.
- Certificate pinning means the client only accepts one specific certificate or key it already knows, which stops an attacker who somehow got a valid cert from a different CA.
How to study this without memorizing blindly
The trap in almost every PKI question is a role mixup: which key is private, who does the signing, what the CSR carries, and whether revocation or expiration is doing the work. When you read a question, name the actor and the key before you look at the options. If you can say "the CA signs a hash with its private key, and the client verifies with the CA's public key" out loud, you have already answered half the domain.
If you want to drill this until it is automatic, I built a practice platform at secplusmastery.com with 1,069 practice questions, 31 reading lessons, hands-on labs, and PBQs aimed at exactly these SY0-701 traps. There is a free diagnostic at secplusmastery.com/diagnostic if you want to see which domains you are actually weak in before you spend hours reviewing.
Learn the roles once and PKI turns from a guessing game into free points.
Top comments (0)