What is Public Key Infrastructure (PKI)?
PKI is the framework of policies, hardware, software, and procedures that manages digital certificates and public-key encryption. It underpins HTTPS, email signing, code signing, and virtually all modern authentication.
What is PKI?
Public Key Infrastructure (PKI) is the system that binds public keys to identities through digital certificates. It provides the trust framework that makes asymmetric encryption usable at scale. Without PKI, you couldn't trust that a website's public key actually belongs to that website.
PKI components include: Certificate Authority (CA — the trusted third party that issues certificates), Registration Authority (RA — verifies identity before the CA issues a certificate), Certificate Repository (a public directory of certificates), and Certificate Revocation List (CRL — a list of revoked certificates).
- PKI binds public keys to verified identities using digital certificates
- Enables trust at scale — you don't need to know every website, just trust the CA
- Essential for HTTPS, email encryption, code signing, and document signing
- The CA is the root of trust in the PKI hierarchy
Digital Certificates (X.509)
An X.509 digital certificate is an electronic document that proves the ownership of a public key. It contains: the subject's identity (domain name, organization, or person), the subject's public key, the issuer (CA) identity, the certificate's serial number, validity period (not before / not after dates), and the CA's digital signature (which authenticates the certificate).
When you visit an HTTPS website, the server presents its X.509 certificate. Your browser checks the CA signature, verifies the domain name matches, and confirms the certificate hasn't expired or been revoked. If all checks pass, the browser establishes an encrypted connection.
- X.509 is the standard format for digital certificates
- Contains: subject, public key, issuer, validity dates, CA signature
- Certificates are verified by checking the CA's digital signature
- Wildcard certificates (*.example.com) cover all subdomains
Certificate Authority (CA) Hierarchy
CAs are organized in a hierarchical trust model. A Root CA sits at the top — it's self-signed and very tightly secured (often kept offline). Intermediate CAs are issued by the Root CA and handle day-to-day certificate issuance. End-entity certificates are the actual certificates issued to websites, users, or devices.
This hierarchy limits damage: if an Intermediate CA is compromised, only its certificates need to be revoked, not the entire Root CA. Modern browsers ship with a list of trusted Root CAs. When a website presents a certificate chain, the browser traces it back to a trusted Root CA.
- Root CA: self-signed, offline, ultimate trust anchor
- Intermediate CA: issued by root, handles real issuance
- End-entity cert: issued to websites, users, devices
- Certificate chaining: browser traces the cert chain back to a trusted root
Certificate Revocation: CRL vs OCSP
Certificates must be revoked before expiry if the private key is compromised or the certificate was issued in error. Two mechanisms handle revocation:
CRL (Certificate Revocation List) — a periodically published list of revoked certificate serial numbers. Clients download the CRL from the CA and check it. The downside: CRLs can be large and there's a delay between revocation and the next CRL publication.
OCSP (Online Certificate Status Protocol) — provides real-time certificate status checking. The client sends the certificate serial number to the OCSP responder and gets back a signed response: good, revoked, or unknown. OCSP is more efficient but requires the OCSP responder to be online. OCSP Stapling improves this by having the web server cache and present the OCSP response to clients.
- CRL: batch list of revoked certs — simple but delayed
- OCSP: real-time per-certificate status — fast but requires online responder
- OCSP Stapling: server fetches OCSP response once, serves it to all clients
- Both are critical for PKI security — without revocation, compromised certs remain trusted
CSR (Certificate Signing Request)
A Certificate Signing Request (CSR) is a message sent to a CA to request a digital certificate. The CSR contains the applicant's public key and identifying information (domain name, organization, country). The applicant generates the CSR along with the private key — the private key never leaves the applicant's system.
The CA verifies the applicant's identity (the level of verification depends on the certificate type), then signs the CSR with the CA's private key to produce the final certificate.
Exam Tip
Know the difference between CRL and OCSP for the exam. Understand the CA hierarchy: Root CA → Intermediate CA → End-entity certificate. Remember that OCSP Stapling improves performance. Wildcard certificates cover one level of subdomains only.