What is PKI?
Public key cryptography lets anyone encrypt data for you or verify your signatures using your public key, but it leaves one question open: how does a stranger know a public key really belongs to you? Public key infrastructure answers it. A trusted certificate authority checks an identity, then signs a certificate that binds that identity to a public key. Any device that trusts the CA can then trust the certificate without ever having met its owner. HTTPS, VPNs, Wi-Fi with EAP-TLS, S/MIME email, smart card logon and code signing all depend on PKI.
The components of a PKI
- Certificate authority (CA): issues and signs certificates. The root CA sits at the top; intermediate, or subordinate, CAs do the day-to-day issuing.
- Registration authority (RA): an optional role that verifies requesters' identities before passing approved requests to the CA.
- Certificates: X.509 version 3 documents holding the subject, public key, validity dates, serial number, permitted uses and the issuer's signature.
- Certificate signing requests (CSRs): how a requester submits a public key and names without revealing the private key.
- Revocation services: certificate revocation lists (CRLs) and OCSP responders that report certificates cancelled before they expire.
- Trust stores: the root certificates an operating system, browser or application accepts in advance, which act as the root of trust.
- Policies: a certificate policy and certification practice statement that define how identities are checked and keys are protected.
How a two-tier PKI is built
Most enterprises run an offline root CA and one or more online issuing CAs, often with Microsoft Active Directory Certificate Services. A typical layout:
| Tier | Where it lives | What it signs | Typical lifetime |
|---|---|---|---|
| Root CA | Offline, key in an HSM | Intermediate CA certificates and its own CRL | Long, commonly 10 to 25 years |
| Issuing CA | Online | Server, user, device and code signing certificates | Several years |
| Leaf certificate | On the server or device | Nothing (CA:FALSE) | Days to a few years; for public TLS certificates, the CA/Browser Forum maximum shrinks in steps to 47 days by March 2029 |
Keeping the root offline means a compromised issuing CA can be revoked and replaced without touching the root that every device trusts. If the root key itself leaked, every certificate beneath it would be suspect and the root would have to be replaced on every device. The offline root still needs to be powered on periodically to re-sign its CRL before that list expires.
Public PKI vs. private PKI vs. web of trust
Public CAs have their roots preinstalled in browsers and operating systems, so customers trust their certificates with no setup. In exchange they follow the CA/Browser Forum Baseline Requirements, issue only for public domain names you can prove you control, and record every TLS certificate in public Certificate Transparency logs. A private, internal CA can issue for any name, including internal hostnames, but only devices you configure, usually through Group Policy or MDM, trust its root. PGP takes a different approach altogether: a web of trust, in which users vouch for one another's keys instead of relying on a central CA.
The 2011 DigiNotar breach shows what is at stake. Attackers used the Dutch CA to issue fraudulent certificates, including one for Google domains, and browser vendors removed DigiNotar's roots, so every certificate it had issued stopped being trusted.
PKI on the CompTIA Security+ exam
PKI is covered by SY0-801 objective 1.3, which asks you to explain how cryptographic solutions such as certificates and certificate authorities are chosen and used. Expect questions about which component does what: the CA signs, the RA verifies identity, the CSR carries the public key, CRLs and OCSP report revocation, and the trust store holds the roots. "Limit the damage if a CA is compromised" points to an offline root with online intermediates. "Customers must trust it with no configuration" points to a public CA, and "thousands of internal devices with internal hostnames" points to an internal CA. A common distractor is any answer in which the server's private key is sent to the CA to get a certificate; the requester keeps the private key and sends only a CSR.