PKI, short for public key infrastructure, is the combination of certificate authorities, digital certificates, policies and software that binds public keys to verified identities so that strangers can trust each other’s keys. In Internet trust it is the foundation behind HTTPS, signed software and secure email: a browser accepts a server’s key because a trusted third party has signed a certificate vouching for it.
Public key cryptography alone solves secrecy and signatures, but not the question of whose key a key really is. PKI answers that question with a hierarchy of signatures that ends in a small set of root certificates that operating systems and browsers ship and trust in advance. The Internet’s public web PKI is one large instance; companies also run private PKIs for internal devices and users.
How PKI establishes trust
Trust in PKI flows along a chain of signatures. A subscriber generates a key pair and sends a certificate signing request to a certificate authority. The CA checks the subscriber’s control or identity, then issues an X.509 certificate that contains the public key, the subject name, a validity period and the CA’s signature. Clients verify that signature with the CA’s own certificate, and continue upward until they reach a root in their trust store.
Roots are kept offline in hardware security modules and sign only intermediate CAs, which perform day-to-day issuance. This limits the damage if an intermediate is compromised, because it can be revoked without replacing roots in billions of devices. The table names the core components.
| Component | Role | Typical protection |
|---|---|---|
| Root CA | Anchors trust, signs intermediates | Offline HSM, ceremony access |
| Intermediate CA | Issues end-entity certificates | Online HSM, audited systems |
| Registration authority | Verifies identity before issuance | Procedural and system controls |
| End-entity certificate | Binds a key to a server, user or device | Private key held by subscriber |
| Revocation service | Publishes CRLs or OCSP responses | Signed responses, high availability |
| Trust store | List of accepted roots on a client | Managed by OS or browser vendor |
Certificate validation levels and lifetimes
Public TLS certificates differ in how much the CA verifies, not in cryptographic strength. Domain validation proves only control of a domain, usually through the automated ACME protocol; organization and extended validation add checks of the legal entity. Browsers no longer display these levels prominently, so the practical security of DV and EV connections is the same.
| Level | What is verified | Issuance time | Typical use |
|---|---|---|---|
| Domain validated (DV) | Control of the domain | Seconds to minutes | Most websites and APIs |
| Organization validated (OV) | Domain plus legal organization | Days | Corporate sites |
| Extended validation (EV) | Stricter legal and operational checks | Days to weeks | Some financial services |
The rules of the public web PKI are set by the CA/Browser Forum Baseline Requirements and by root programs of browser vendors. Certificate lifetimes have shrunk from years to a maximum of 398 days, and an adopted schedule reduces them further, reaching 47 days by 2029. Short lifetimes limit the value of stolen keys and make automated renewal mandatory in practice.
Revocation and transparency
When a private key leaks or a certificate was issued in error, the CA revokes it before expiry. Clients learn about revocation through certificate revocation lists (CRLs) or the Online Certificate Status Protocol (OCSP). Both have weaknesses: CRLs grow large, OCSP adds latency and privacy exposure, and many clients soft-fail when the check cannot be completed, which an attacker can exploit.
| Mechanism | Problem addressed | Main limitation |
|---|---|---|
| CRL | Publishes revoked serial numbers | Large files, delayed updates |
| OCSP | Live status for one certificate | Latency, privacy, soft-fail |
| OCSP stapling | Server delivers signed status itself | Requires server support |
| Certificate Transparency | Makes all issued certificates public | Detects misissuance, does not prevent it |
| CAA DNS record | Limits which CAs may issue | Checked only by compliant CAs |
Certificate Transparency requires public CAs to log every certificate in append-only logs, and browsers reject certificates without proof of logging. Domain owners monitor these logs to detect certificates issued without their consent. Several large CAs have been distrusted after audits revealed misissuance, showing that root programs actively enforce the rules.
Public and private PKI in practice
Organizations choose between the public web PKI and a private PKI depending on who must trust the certificates. A private PKI gives full control over names, lifetimes and policies, but its root must be distributed to every client, and the organization bears the operational burden.
| Need | Recommended PKI | Reason |
|---|---|---|
| Public website or API | Public PKI | Trusted by all browsers out of the box |
| Internal service mesh with mutual TLS | Private PKI | Short-lived certificates at high volume |
| Corporate Wi-Fi with 802.1X | Private PKI | Device certificates under company control |
| Code signing for distribution | Public code-signing CA | Operating systems trust it |
| Lab or development hosts | Private PKI | Avoids public logging of internal names |
Common failures and misconceptions
- Expired certificates remain the most frequent cause of outages; renewal must be automated and monitored.
- Missing intermediate certificates on a server cause failures in some clients while others succeed by fetching the chain themselves.
- A valid certificate does not mean a trustworthy site. It proves control of a name, not honest intent.
- Private keys stored without protection undermine every other control; keys belong in HSMs or protected key stores.
- Disabling certificate validation in code to fix an error removes all protection against interception.
A non-technical view
PKI works like a system of passports and passport offices. Anyone can claim to be someone, but a passport issued by a recognized authority convinces a border officer who has never met the traveler. On the Internet, the passport is a certificate, and the officer is your browser.
Your device carries a short list of passport offices it trusts. When a website shows a certificate signed by one of them, the browser accepts that the site really owns its name and sets up an encrypted connection. If the signature is missing, forged or expired, the browser shows a warning instead.
A concrete example
A regional hospital runs a patient portal, internal laboratory systems and several hundred medical devices on its network. For the portal it uses domain-validated certificates from a public CA, renewed automatically through ACME every 60 days, with CAA records that allow only that CA to issue for its domain.
For internal systems it operates a private PKI with an offline root stored in a safe and one online intermediate in a hardware security module. Devices receive certificates valid for 30 days through an automated enrollment protocol, and the hospital’s management tools install the private root on every workstation. When a laboratory server is decommissioned, its certificate is revoked the same day. Monitoring of Certificate Transparency logs alerts the security team if any public certificate for the hospital’s domain appears unexpectedly.