The trust problem PKI solves
Asymmetric encryption uses a public/private key pair. Anyone can have a public key — but how do you know a public key actually belongs to the person or organization claiming to own it? Without a trust system, an attacker could create a fake public key and impersonate a legitimate website or person.
PKI solves this by introducing a trusted third party called a Certificate Authority (CA). The CA verifies an entity's identity and then digitally signs their public key, creating a digital certificate. Anyone who trusts the CA can then trust the certificate it signed.
The PKI hierarchy — root CA, intermediate CA, and end-entity
Root CA The ultimate trust anchor. Self-signed certificate. Kept offline for security. Pre-installed in operating systems and browsers. | | signs v Intermediate CA Issues certificates on behalf of the root CA. Stays online to handle day-to-day certificate signing. If compromised, can be revoked without touching the root. | | signs v End-Entity Certificate The certificate on a website, user, device, or application. This is what your browser validates when you visit an HTTPS site.
Root CAs are kept offline to protect them. If a root CA is compromised, the entire trust chain collapses. Intermediate CAs take on the online work of issuing certificates. If an intermediate CA is compromised, it can be revoked without affecting the root CA.
Digital certificates — what they contain
A digital certificate is a file in X.509 format that binds a public key to an identity. It is signed by a CA, which is what makes it trustworthy. When your browser sees a certificate, it checks the CA's signature to confirm the certificate is legitimate.
| Certificate Field | What it contains |
|---|---|
| Subject | The entity the certificate belongs to — domain name, organization, or person |
| Public Key | The entity's public key — what clients use to encrypt data or verify signatures |
| Issuer | The CA that signed and issued the certificate |
| Validity Period | The start and expiry dates — certificates expire and must be renewed |
| Serial Number | Unique identifier assigned by the CA — used for revocation tracking |
| Digital Signature | The CA's signature — proves the certificate was issued by a trusted CA |
| Subject Alt Names | Additional domain names the certificate covers (e.g. www.example.com and example.com) |
Key PKI terms — full reference
| Term | What it means |
|---|---|
| CA (Certificate Authority) | Trusted entity that issues and signs digital certificates — e.g. DigiCert, Let's Encrypt, Entrust |
| Root CA | Top-level CA with a self-signed certificate. Pre-trusted by browsers and operating systems. Kept offline. |
| Intermediate CA | CA that sits between root and end-entity. Does day-to-day certificate signing. Can be revoked if compromised. |
| CSR | Certificate Signing Request — a file generated by the entity requesting a certificate. Contains their public key and identity info. Sent to the CA for signing. |
| CRL | Certificate Revocation List — a list published by the CA of certificates that have been revoked before their expiry date. |
| OCSP | Online Certificate Status Protocol — allows real-time checking of whether a specific certificate has been revoked. Faster than downloading a full CRL. |
| OCSP Stapling | The web server fetches and caches the OCSP response and serves it directly to clients, reducing latency and load on the CA's OCSP server. |
| Certificate Pinning | An application hard-codes which certificate or CA it trusts, rejecting any other certificate even if it is technically valid. |
| Self-Signed Certificate | A certificate signed by the same entity that owns it — not by a CA. Trusted only if manually installed. Common in internal/dev environments. |
| Wildcard Certificate | Covers a domain and all its subdomains — e.g. *.example.com covers mail.example.com, app.example.com, etc. |
| SAN Certificate | Subject Alternative Name — a single certificate that covers multiple specific domain names. |
Certificate revocation — CRL vs OCSP
Certificates can be revoked before they expire — for example, if a private key is compromised. There are two mechanisms the exam tests for checking revocation status:
CRL (Certificate Revocation List) CA publishes a list of revoked certificate serial numbers Client downloads the full list and checks it locally Downside: list can be large and may be out of date between updates OCSP (Online Certificate Status Protocol) Client sends a real-time query to the CA's OCSP responder CA responds: "Good", "Revoked", or "Unknown" Faster and more current than CRL — preferred in modern systems OCSP Stapling Server pre-fetches and caches the OCSP response Serves it directly to clients during the TLS handshake Reduces latency and takes load off the CA's OCSP server
How the certificate trust chain is validated
When your browser connects to an HTTPS website, it performs a chain validation to confirm the certificate is legitimate:
1. Browser receives the site's end-entity certificate 2. Browser checks the certificate's issuer (Intermediate CA) 3. Browser checks the Intermediate CA's certificate issuer (Root CA) 4. Browser checks if the Root CA is in its trusted root store 5. Browser verifies signatures at each level of the chain 6. Browser checks the certificate has not expired 7. Browser checks OCSP or CRL to confirm certificate is not revoked If all checks pass → connection is trusted (padlock shown) If any check fails → browser shows a security warning
Exam scenarios
Studying for Security+?
See the best study guides, practice exams, and free resources for SY0-701.