PKI & Digital Certificates Explained: Chains of Trust, Revocation, and the TLS Handshake

Every time a browser shows a padlock, a quiet machine has just done something remarkable: proved the identity of a server on the other side of the planet, to a laptop that has never seen it before, in about a tenth of a second. That machine is PKI, and Security+ SY0-701 objective 1.4 expects you to know its moving parts by name: key pairs, certificate authorities, CSRs, root vs. third-party trust, OCSP, and the rest. Here's the whole machine, from the math up.

The problem PKI solves

Encryption itself is old news. Symmetric encryption — one shared key that both locks and unlocks — is fast and effectively unbreakable at modern key sizes. Its fatal weakness is logistics: both sides must already have the key, and you can't send it over the very channel you're trying to protect. That's the key distribution problem, and for most of history the answer was couriers with briefcases.

Asymmetric encryption dissolved it. Every participant generates a key pair — a public key you hand to anyone, and a private key that never leaves you. The keys are inverses: what the public key encrypts, only the private key can decrypt. Now a stranger can send you a secret without any prior arrangement — they encrypt with your public key, and only you can open it.

Run the math in the other direction and you get something even more useful. Encrypt a fingerprint of a message with your private key, and anyone holding your public key can verify that you — and only you — produced it. That's a digital signature, and it delivers three properties at once: the message wasn't altered (integrity), it came from the key holder (authenticity), and the sender can't later deny it (non-repudiation).

But asymmetric crypto alone has a hole you could drive a truck through: when you fetch "the server's public key," how do you know it's really theirs and not an impostor's? A on-path (man-in-the-middle) attacker can hand you their key and relay everything, reading it all. Keys need identity attached. That's what certificates are for.

Certificates: identity stapled to a key

A digital certificate is a small, rigidly formatted document (the standard is X.509) that says: this public key belongs to this subject. It carries the subject name, the public key, validity dates, allowed uses, and — the part that makes it trustworthy — a digital signature from a certificate authority (CA) vouching for the binding.

Getting one is a defined ritual. You generate your key pair, then package the public key and your identity details into a CSR (certificate signing request) and send it to the CA. The CA validates you — anything from proving you control a DNS record to verifying legal documents — and returns the signed certificate. The private key never travels; that's the entire discipline.

The exam expects you to recognize the certificate flavors:

Validation level is a separate axis: DV (domain validation — you control the DNS), OV (organization validation — the company is real), EV (extended validation — heavyweight legal vetting). Cryptographically they're identical; what differs is how hard the CA checked who you are.

The chain of trust

Here's the elegant part. Your laptop doesn't know the CA that signed a given website's certificate — it doesn't need to. It ships with a trust store: a few hundred root CA certificates vetted by your OS and browser vendors. Roots are too precious to use daily — their private keys live offline in vaults — so each root signs a handful of intermediate CAs, and the intermediates do the daily signing of end-entity (leaf) certificates.

When a server presents its certificate, your browser verifies the chain of trust: leaf signed by intermediate, intermediate signed by root, root present in the trust store — plus dates, name matching, and usage constraints at every link. One broken link, and you get the browser's full-page warning. This layered design is also damage control: if an intermediate is ever compromised, it can be revoked and replaced without burning the root — which is why roots live offline in the first place.

The TLS handshake: PKI at work

All of this exists for one everyday moment: the TLS handshake. Modern TLS 1.3 compresses it to a single round trip, and it's the exam's perfect case study because every PKI concept fires in sequence:

Two details elevate this from memorization to understanding. First, the key shares are ephemeral — generated fresh per connection and thrown away — which buys forward secrecy: even if the server's private key is stolen next year, recorded traffic from today stays sealed. Second, the certificate never encrypts any data. It only authenticates the key exchange. Certificates are identity documents, not envelopes.

Revocation: the machine's weakest joint

Certificates expire on a schedule, but sometimes trust has to be withdrawn now — a private key leaked, a CA misissued, a server was breached. That's revocation, and the exam wants you to compare its two mechanisms.

The old way is the CRL: the CA periodically publishes a signed list of every revoked serial number, and clients download and check it. It works, but the lists grow huge and go stale between publications — a revoked cert can keep working for hours or days. The modern answer is OCSP: ask the CA about this one certificate, right now. Fresher, lighter — but it makes the CA a availability bottleneck and quietly tells it which sites you visit. The refinement that fixes both is OCSP stapling: the server fetches a short-lived signed status from the CA and hands it over during the handshake itself.

Keeping the keys: the unglamorous 90%

Operationally, PKI lives or dies on key custody. Three terms from 1.4 close the loop. High-value private keys — CA keys especially — live in an HSM, hardware that will use a key on request but never surrender it. Key escrow keeps a recoverable copy of decryption keys with a trusted custodian — controversial for communications, indispensable for corporate disk encryption when an employee walks out. And certificate pinning flips the trust model for high-stakes clients: instead of accepting anything a trusted root signs, a mobile banking app can insist on the exact key it expects — defeating even a compromised CA, at the cost of breaking itself whenever the key legitimately rotates.

Notice the common thread: every mechanism in this article is a compensating control for the same root fact — whoever holds a private key IS that identity, as far as the math is concerned. Certificates bind keys to names, chains bind names to vetted authorities, revocation unbinds them when things go wrong, and HSMs make sure the binding was never a lie.

PKI anchors the cryptographic-solutions objective (1.4) — the largest single chunk of Security+ Domain 1. It also underpins nearly everything else on the exam: certificates authenticate the Zero Trust enforcement points, and encryption at every level of the data-protection toolkit depends on the key management covered here. For all four Domain 1 objectives with practice questions, start with our Security+ Domain 1 study guide.

#SecurityPlus #SY0701 #PKI #DigitalCertificates #TLS #Encryption #OCSP #CertificateAuthority #Cryptography #CompTIA #CyberSecurity