The Problem PKI Solves
Asymmetric encryption works by pairing a public key (shared freely) with a private key (kept secret). Anyone can encrypt a message with your public key; only you can decrypt it with your private key. But there's a fundamental problem: if Alice sends Bob her public key, how does Bob know it's actually Alice's key — and not an attacker who intercepted the message and substituted their own key?
This is the man-in-the-middle problem. PKI solves it by having a trusted Certificate Authority sign Alice's public key along with her identity information. That signed package is a digital certificate. Bob already trusts the CA (it's in his browser's trust store), so when he verifies the CA's signature on Alice's certificate, he knows the public key really belongs to Alice.
PKI Hierarchy — Root CA, Intermediate CA, End-Entity
PKI uses a chain of trust — a hierarchy of Certificate Authorities where each level vouches for the one below it:
| Level | Role | Exam Note |
|---|---|---|
| Root CA | The top of the hierarchy — self-signed certificate, ultimate trust anchor. Kept offline in most enterprise deployments ("air-gapped root CA") to protect it from compromise. | If the root CA is compromised, the entire PKI is compromised. That's why it's kept offline. |
| Intermediate CA | Signed by the root CA — issues certificates to end entities (websites, users, devices). The root CA delegates certificate issuance to intermediates so the root stays offline. | Also called a "subordinate CA." Browsers validate the full chain: end-entity → intermediate → root. |
| End-Entity Certificate | The certificate presented by a website, user, device, or code. Signed by an intermediate CA. Contains the public key and identity information. | This is what you see when you click the padlock in a browser — the server's certificate. |
| Certificate Chain | The full path from the end-entity certificate up through intermediate CAs to the root CA. Browsers validate every link in the chain. | "Chain of trust" — if any link is invalid or revoked, the entire certificate is untrusted. |
Public PKI: Certificate Authorities like DigiCert, Let's Encrypt, and Sectigo are trusted by browsers and operating systems by default — their root certificates are pre-installed. Use for public-facing websites.
Private/Internal PKI: Organisations run their own CA hierarchy (Microsoft Active Directory Certificate Services is common) for issuing certificates to internal systems, VPN clients, and users. Clients must explicitly trust the internal root CA — typically deployed via Group Policy in AD environments.
X.509 — The Certificate Standard
All modern digital certificates follow the X.509 standard. An X.509 certificate contains:
| Field | What It Contains | Exam Note |
|---|---|---|
| Subject | The identity the certificate belongs to — for a website: the domain name (Common Name / CN). For a user: name and email. | The CN field is what browsers check against the URL — mismatch = certificate error |
| Issuer | The CA that signed this certificate — identifies which CA to validate the signature against | Browser walks the chain: subject → issuer → issuer's issuer → root |
| Public Key | The certificate owner's public key — this is the key you encrypt with or use to verify signatures | The whole point of the certificate — binding this key to the subject identity |
| Validity Period | Not Before / Not After dates — the certificate is only valid within this window | Expired certificates cause browser warnings — common A+ support scenario |
| Serial Number | Unique number assigned by the CA — used to identify the certificate in revocation lists | CRLs and OCSP use the serial number to check revocation status |
| Signature Algorithm | The algorithm the CA used to sign the certificate (e.g. SHA-256 with RSA) | Weak signature algorithms (MD5, SHA-1) are a security red flag on Security+ |
| Subject Alternative Name | Additional domains or IPs the certificate is valid for — modern certificates use SAN instead of just CN | Wildcard certs use *.domain.com in the SAN |
| CA Signature | The CA's digital signature over the certificate data — proves the CA verified and endorsed this certificate | If signature verification fails, the certificate has been tampered with |
Certificate Types
| Certificate Type | What It Does | Exam Use Case |
|---|---|---|
| Domain Validation (DV) | Verifies ownership of the domain only — automated, fast, cheap (Let's Encrypt is free DV). No identity verification of the organisation. | Most HTTPS sites use DV — doesn't mean the site is trustworthy, just that the connection is encrypted |
| Organisation Validation (OV) | Verifies domain ownership AND that the organisation is legally registered. CA manually validates the organisation's details. | Shows organisation name in certificate details — more trust than DV |
| Extended Validation (EV) | Strictest vetting — thorough legal and operational verification. Historically showed green address bar, now shows organisation name in cert details. | Highest assurance — banking and financial sites. Most browsers have removed the green bar but the cert still contains richer identity info. |
| Wildcard Certificate | A single certificate covering a domain and all its subdomains — *.company.com covers mail.company.com, vpn.company.com, etc. | Compromise of a wildcard cert exposes all subdomains — broader attack surface than individual certs |
| SAN Certificate | Subject Alternative Name — one certificate valid for multiple specific domains (company.com AND company.net AND shop.company.com) | More flexible than wildcard — lists exact domains rather than a wildcard pattern |
| Code Signing Certificate | Used by software developers to sign executable code — proves the code came from the stated developer and hasn't been modified | Windows SmartScreen checks for code signing — unsigned executables trigger warnings |
| Client Certificate | Issued to individual users or devices — used for mutual TLS authentication where both sides present certificates | Used in 802.1X (EAP-TLS), VPN client authentication, smart card logon |
| Self-Signed Certificate | Signed by the same entity it was issued to — no CA involvement. Not trusted by browsers by default. | Used in internal systems and labs. Browser "certificate not trusted" warnings come from self-signed or unknown CA certs. |
The TLS Handshake — How HTTPS Works
Every HTTPS connection starts with a TLS handshake that uses PKI to authenticate the server and negotiate encryption. Understanding each step is tested on Security+:
TLS uses asymmetric cryptography to establish trust and exchange keys, then switches to symmetric encryption for the actual data. Asymmetric is used because it enables authentication without prior shared secrets. Symmetric is used for data because it's much faster. The handshake is slow; the data transfer is fast.
Forward secrecy (perfect forward secrecy / PFS): Using ephemeral Diffie-Hellman means the session key is never transmitted and is discarded after the session. Even if the server's private key is later compromised, past session recordings cannot be decrypted.
Certificate Revocation — CRL and OCSP
Certificates can be revoked before they expire — if the private key is compromised, the certificate is mis-issued, or the organisation no longer exists. Two mechanisms handle revocation:
| Mechanism | How It Works | Pros/Cons |
|---|---|---|
| CRL Certificate Revocation List | The CA publishes a signed list of all revoked certificate serial numbers. Clients download the CRL and check if a certificate's serial number is on the list. | Simple but inefficient — CRLs can be large and are only updated periodically. A revoked cert may still be trusted until the next CRL download. |
| OCSP Online Certificate Status Protocol | Clients query the CA's OCSP responder in real time with a specific certificate's serial number — responder returns "good," "revoked," or "unknown." | Real-time and efficient. But requires the OCSP responder to be available — if it's down, some clients fail open (still trust the cert). |
| OCSP Stapling | The server periodically fetches a signed OCSP response from the CA and "staples" it to the TLS handshake — the client gets the revocation status without querying the OCSP responder directly. | Faster, more private (client doesn't contact CA), and more reliable. Recommended over basic OCSP. |
Certificate Pinning
Certificate pinning (also called public key pinning) is a defence against rogue or compromised CAs. Normally, a browser trusts any certificate signed by any CA in its trust store — meaning if any CA is compromised, an attacker could get a fraudulent cert for any domain.
With pinning, an application hardcodes (pins) the expected certificate or public key for a specific server. If the presented certificate doesn't match the pin, the connection is rejected — even if the certificate is otherwise valid and CA-signed. Used by high-security applications like banking apps and mobile applications to prevent MITM attacks even in corporate environments that perform SSL inspection.
Common PKI Attacks and Weaknesses
| Attack / Issue | How It Works | Defence |
|---|---|---|
| Rogue CA / CA Compromise | An attacker compromises a CA and issues fraudulent certificates for legitimate domains — the browser trusts them because it trusts the CA | Certificate Transparency logs (public audit trail of all issued certs), CAA DNS records (restrict which CAs can issue for your domain) |
| SSL Stripping | Attacker downgrades HTTPS to HTTP in a MITM position — user's browser communicates in plaintext without the user realising they're no longer on HTTPS | HSTS (HTTP Strict Transport Security) — browser refuses to connect over plain HTTP to known HTTPS sites |
| Expired Certificate | Server's certificate has passed its Not After date — browsers reject it, causing connection errors | Certificate lifecycle management, automated renewal (e.g. Let's Encrypt with certbot), monitoring alerts before expiry |
| Weak Algorithm | Certificate signed with MD5 or SHA-1 — both are cryptographically broken and can be forged | Require SHA-256 or stronger for all new certificates, migrate away from legacy algorithms |
| Private Key Compromise | The server's private key is stolen — attacker can impersonate the server or decrypt recorded past sessions (without PFS) | Revoke certificate immediately, reissue with new key pair, implement PFS to protect past sessions |
Exam Scenarios
Studying for Security+?
See the study guides and practice exams that cover the full SY0-701 exam.