What Is Public Key Infrastructure (PKI)? The Architecture Behind Every HTTPS Connection

Every time a browser connects to a website over HTTPS, it performs a remarkable act of trust. It receives a certificate from a server it has never communicated with before, on a network it does not control, from an entity it cannot physically verify. Somehow, despite all of that uncertainty, the browser decides whether to trust the connection.

The system that makes that decision possible is Public Key Infrastructure, or PKI. But PKI is not a product you install or a protocol you configure. It is an architecture, a set of roles, policies, procedures, and cryptographic mechanisms that together solve one of the fundamental problems in computer security: how do two parties who have never met agree on a shared secret and verify each other’s identity over a network that neither controls?

This article builds the answer to that question from first principles. It starts with the cryptographic properties PKI depends on, works through each component and why it exists, traces how a certificate is born and validated, and explains what happens when that process needs to be reversed through revocation. By the end, the padlock icon in a browser address bar should make technical sense rather than simply representing a feeling of safety.

The Problem PKI Solves: Key Distribution Without Prior Contact

Cryptography has offered symmetric encryption for centuries. A symmetric cipher uses the same key to encrypt and decrypt. The problem is that both parties must already possess the shared key. On the early internet, this meant every pair of servers that needed to communicate securely had to arrange a key exchange through some other secure channel, which did not scale.

Asymmetric cryptography, developed publicly by Diffie, Hellman, and independently by Rivest, Shamir, and Adleman in the 1970s, changed this. In an asymmetric system, each party has two mathematically linked keys: a public key that anyone can know and a private key that must remain secret. Anything encrypted with the public key can only be decrypted with the corresponding private key. Anything signed with the private key can be verified with the corresponding public key.

This solved the distribution problem. You can publish your public key openly. Anyone wanting to send you an encrypted message encrypts it with your public key. Only you, possessing the private key, can decrypt it. No pre-shared secret is required.

Asymmetric cryptography solves distribution but introduces a new problem: authenticity. If I publish my public key, how do you know it is actually mine and not a key published by an attacker who intercepted the channel where I published it? An attacker could publish their own public key and claim it is mine. You would encrypt a message to them thinking you are reaching me. This is the man-in-the-middle attack against key exchange, and it is the problem PKI exists to solve.

Why a phone book of public keys is not enough

The intuitive solution is a trusted directory. Someone maintains a list of every entity’s authentic public key, and before communicating with anyone you look up their key. If you trust the directory, you trust the key.

This fails for the internet at scale. A centralized directory becomes a single point of failure and attack. Who maintains it and how do you trust them? How do you verify the directory itself was not tampered with in transit? How do you handle hundreds of millions of websites, devices, and services across every industry and jurisdiction?

PKI answers all of these questions through a hierarchy of trust combined with cryptographic proof. Instead of a static directory, it uses digital certificates that carry their own proof of authenticity, issued by entities whose trustworthiness is established through public audit and policy rather than through any single point of control.

The Cryptographic Foundation: Asymmetric Key Pairs

Every certificate in PKI exists to bind an identity to a public key. To understand why that binding matters and how it works, the underlying mathematics deserves a brief treatment.

RSA: the first widely deployed asymmetric algorithm

RSA (Rivest-Shamir-Adleman, 1977) generates a key pair based on the difficulty of factoring the product of two large prime numbers. The public key contains the product of the two primes (n) and an exponent (e). The private key contains the two primes and a corresponding exponent (d). Operations using the public key can be reversed only by someone who knows the factorization, which for sufficiently large primes (2048 bits or larger) is computationally infeasible with current technology.

RSA keys can both encrypt data and create digital signatures. For SSL/TLS certificates, RSA is used primarily for signing the certificate content and for key exchange in older TLS configurations. RSA keys at 2048 bits are the current minimum for publicly trusted certificates. Some high-security configurations use 4096-bit RSA, though the performance cost is significant.

ECC: the modern standard for new certificates

Elliptic Curve Cryptography (ECC) generates key pairs based on the algebraic structure of elliptic curves over finite fields. The security of ECC relies on the elliptic curve discrete logarithm problem, which is considered harder than RSA’s factoring problem at equivalent key sizes. A 256-bit ECC key provides roughly equivalent security to a 3072-bit RSA key, making ECC certificates significantly smaller and faster to process.

The named curve P-256 (also called secp256r1 or prime256v1) is the standard for most ECC certificates in TLS today. P-384 provides a larger security margin and is used in some high-assurance contexts. The signature algorithm that uses ECC keys is ECDSA (Elliptic Curve Digital Signature Algorithm). Modern CAs increasingly issue ECC certificates alongside RSA certificates, and TLS 1.3 uses ECDHE (Ephemeral ECDH) for key exchange exclusively.

Digital signatures: the mechanism that makes certificates work

A digital signature over a document is produced by hashing the document content and then encrypting that hash with the signer’s private key. The signature can be verified by anyone who has the signer’s public key: decrypt the signature to get the hash, independently hash the document, compare the two hashes. If they match, the document was not modified after signing and the private key corresponding to the verifier’s copy of the public key was used to sign it.

Every X.509 certificate is a digitally signed document. The certificate authority hashes the certificate’s content (the subject’s name, their public key, the validity period, the covered hostnames, and various extensions) and signs that hash with the CA’s private key. A browser verifying the certificate hashes it again, decrypts the CA’s signature using the CA’s public key, and compares. If they match, the certificate was issued by the CA and has not been modified.

The X.509 Digital Certificate: What Is Actually Inside

An X.509 certificate is a data structure defined by RFC 5280 that binds a public key to an identity through the digital signature of an issuing CA. It is not a container for a private key. The private key is generated by the certificate holder and never leaves their control. The certificate contains only the public key.

The chain of trust flows directly from this structure. The CA signs the certificate with its private key. Anyone with the CA’s public key can verify that signature. But then: how do you trust the CA’s public key? The CA’s public key is itself in a certificate, signed by an even more trusted CA, all the way up to a self-signed root CA certificate that is explicitly trusted by browsers and operating systems through their built-in trust stores.

The Three-Level Trust Hierarchy: Root, Intermediate, and Leaf

PKI for the public web uses a three-level hierarchy almost universally. Understanding why three levels rather than two or four requires understanding the security trade-off being managed.

Root Certificate Authorities

A root CA’s certificate is self-signed. The subject and issuer are the same entity. There is no parent CA signing it. Trust in a root CA is established not through cryptography but through policy: the root CA must meet rigorous security, operational, and audit requirements defined by browser vendors and OS manufacturers. The CA/Browser Forum Baseline Requirements, Apple’s Root Certificate Policy, Mozilla’s CA Policy, and Microsoft’s Trusted Root Program each specify what a CA must do to have its root certificate included in device trust stores.

Root CA private keys are treated as among the most sensitive secrets in internet security. They are typically stored in Hardware Security Modules (HSMs) that are kept offline in physically secured facilities. Root CAs rarely perform day-to-day certificate issuance operations directly. Instead, they sign intermediate CA certificates and go offline. If a root CA’s private key is ever compromised, every certificate that traces its chain to that root is instantly untrustworthy, potentially affecting millions of websites.

Only approximately 50 to 150 root CA certificates are trusted by major browsers at any given time, despite millions of websites having SSL certificates. This relatively small number of root CAs, each subject to constant audit and policy enforcement, forms the foundation of trust for every encrypted HTTPS connection on the public internet. The revocation of any root CA from browser trust stores has happened historically and causes widespread certificate errors across every site that used that CA’s chain.

Intermediate Certificate Authorities

Intermediate CAs are certificates issued by a root CA (or by another intermediate CA) that are authorized to issue certificates to end entities. Every certificate issued by a commercial CA like DigiCert, Sectigo, or GlobalSign is issued by an intermediate CA, not the root directly.

The intermediate layer exists for two reasons. Security: if an intermediate CA is compromised, the root CA can revoke the intermediate’s certificate and issue a new one to a new intermediate. The root itself does not need to come online or be exposed. The damage is contained to certificates issued by the compromised intermediate. Operational efficiency: intermediate CAs can be managed and operated at a faster cadence than roots, with shorter validity periods and more frequent key rotation.

The practical consequence for server administrators is that a complete certificate installation requires both the leaf certificate (issued for your domain) and every intermediate certificate in the chain. A server that presents only the leaf certificate will produce NET::ERR_CERT_AUTHORITY_INVALID in most browsers because the browser cannot build the chain from the leaf to the trusted root without the intermediate. Modern browsers do not automatically download missing intermediate certificates.

Leaf (End-Entity) Certificates

The leaf certificate is what a website owner obtains from a CA and installs on their server. It is called a leaf certificate because it sits at the end of the chain with nothing below it; it is not authorized to issue certificates to others. The Key Usage and Extended Key Usage extensions in the leaf certificate specify what operations it is valid for. For TLS server authentication, the Extended Key Usage extension must include the serverAuth OID (1.3.6.1.5.5.7.3.1).

The leaf certificate contains the public key whose corresponding private key sits on the server. When a browser connects and receives the certificate, it uses the public key in the leaf certificate to verify the server’s TLS handshake signature, confirming that the server possesses the private key and is therefore the legitimate holder of the certificate.

The three-level hierarchy means every TLS certificate validation involves at least three certificates: the leaf (your domain), one or more intermediates, and the root. The browser builds this chain upward from the leaf, following the Issuer field from one certificate to the next, until it reaches a root in its trust store. This path-building process is path validation, and RFC 5280 defines the algorithm browsers must use to do it correctly.

From Key Pair to Trusted Certificate: The Issuance Process

A certificate does not begin with the CA. It begins with the entity that will hold the certificate generating their own key pair. The private key never leaves the holder’s control. What gets sent to the CA is a Certificate Signing Request.

Generating a CSR

A Certificate Signing Request (CSR) is a standardized data structure containing the applicant’s public key, identifying information (organization name, country, domain), and a digital signature made using the corresponding private key. The signature in the CSR proves that the submitter controls the private key associated with the public key being submitted, preventing an attacker from submitting someone else’s public key.

Domain Control Validation (DCV)

Before issuing a certificate, the CA must verify that the applicant actually controls the domain named in the CSR. For Domain Validated (DV) certificates, this is automated through one of three methods defined in the CA/B Forum Baseline Requirements.

Email validation sends a message to a predefined contact address at the domain (admin@, webmaster@, hostmaster@, or the technical contact in WHOIS). The applicant clicks a link or enters a code from the email. DNS validation requires the applicant to add a specific TXT record to the domain’s DNS zone. The CA queries for that record. File-based validation (HTTP-01) requires the applicant to place a specific file at a well-known path on the web server. The CA fetches that path over HTTP or HTTPS.

For OV and EV certificates, domain validation is supplemented by identity verification. OV requires confirming the organization’s registration in a recognized business registry, verifying a working phone number, and confirming a physical address. EV adds verification of the organization’s legal existence, operational existence for a minimum period, and confirmation that the specific person requesting the certificate is authorized to do so on behalf of the organization.

Certificate issuance and signing

Once validation is complete, the CA constructs the TBSCertificate (To Be Signed Certificate) structure containing all the verified fields: subject, public key from the CSR, validity dates, SAN entries, serial number, extensions, and the issuer information. The CA hashes this structure using SHA-256 (or SHA-384 for higher-security configurations) and signs the hash using the intermediate CA’s private key. The resulting signature is appended to the TBSCertificate to produce the complete certificate.

The CA also submits the certificate to at least one Certificate Transparency log before or at the time of issuance. The CT log returns a Signed Certificate Timestamp (SCT), which is embedded in the certificate (or delivered via TLS extension or OCSP stapling). Chrome has required CT logging for all publicly trusted certificates since April 2018.

Certificate Revocation: Ending Trust Before Expiry

Certificates are issued with a validity period, but trust sometimes needs to end before that period expires. A private key is discovered to be compromised. An organization is dissolved. A certificate was issued erroneously. In all these cases, the certificate must be revoked: its serial number added to a list of certificates that should no longer be trusted, even though they are technically within their validity period.

Certificate Revocation Lists (CRLs)

A Certificate Revocation List is a digitally signed file published by a CA at regular intervals. It contains a list of serial numbers of revoked certificates, the date each was revoked, and the reason for revocation. The URL where a certificate’s CRL can be fetched is embedded in the certificate itself in the CRL Distribution Points extension.

CRLs have a fundamental limitation: they are batch files published on a schedule, not real-time status updates. A certificate revoked at 9:00 AM may not appear in a new CRL until the next publishing cycle, which could be hours later. During that window, the revoked certificate can still be used. CRLs also grow large over time as more certificates are revoked, making them slow to download on every validation attempt. For enterprise PKI managing thousands of internal certificates, CRLs remain common. For public web PKI, OCSP has largely replaced them for end-entity certificate checking.

Online Certificate Status Protocol (OCSP)

OCSP provides real-time individual certificate status checks. Instead of downloading a full CRL, a browser sends the certificate’s serial number to the CA’s OCSP responder and receives a signed response stating whether the certificate is good, revoked, or unknown. The OCSP URL is embedded in the certificate’s Authority Information Access extension.

The privacy concern with OCSP is that every certificate check requires the browser to contact the CA, informing the CA which sites the user is visiting. OCSP stapling addresses this: the web server periodically fetches a signed OCSP response for its own certificate from the CA and caches it. The server then sends this stapled response to browsers as part of the TLS handshake, eliminating the need for browsers to make separate OCSP requests. The signed response proves the revocation status without the privacy cost of real-time CA queries.

CRLSets and CRLite are browser-level innovations that download a compressed representation of all known revocations to the browser directly, eliminating the need for per-certificate CRL or OCSP checks at validation time. Chrome’s CRLSets are pushed via the Chrome component updater. Firefox’s CRLite downloads a Bloom filter of all unexpired revocations. These approaches fix both the latency and privacy problems of traditional CRL and OCSP checking.

PKI in the TLS Handshake: Where Theory Meets Practice

Every HTTPS connection uses PKI. The TLS handshake is where the abstract certificate hierarchy resolves into concrete cryptographic operations.

During a TLS 1.3 handshake, the client sends a ClientHello with its supported cipher suites and a key share. The server responds with a ServerHello selecting the cipher suite, its own key share, and the certificate chain: the leaf certificate followed by any intermediate certificates. The client receives the chain and performs path validation: starting from the leaf, it follows the Issuer field through intermediates until it reaches a root certificate in its trust store. It verifies the CA signature at each step using the parent certificate’s public key.

If path validation succeeds, the client uses the leaf certificate’s public key to verify the server’s CertificateVerify message, a signature over the transcript of the handshake so far. Verifying this signature proves two things simultaneously: the server possesses the private key corresponding to the public key in the certificate, and the handshake transcript has not been tampered with in transit. Both conditions must hold for the connection to be trusted.

Private PKI: Internal Certificate Authorities

Not every certificate needs to be publicly trusted. Organizations managing internal networks, internal applications, IoT devices, code signing for internal tools, and mutual TLS (mTLS) authentication between services operate private PKI alongside public PKI.

A private CA issues certificates that are trusted only by devices whose trust stores have been configured to include the private CA’s root certificate. An enterprise IT department pushes the corporate root CA certificate to all managed devices via group policy or MDM. Internal web applications, VPN endpoints, and internal APIs can use certificates from this private CA without paying for public certificates and without the constraints of the CA/B Forum Baseline Requirements.

Private PKI is common in several scenarios: corporate intranets where every device is managed, mutual TLS authentication in microservice architectures where services verify each other’s certificates, IoT device identity where each device has a certificate provisioned at manufacture, and client certificate authentication where users log in with a certificate on a smart card or in their device’s certificate store rather than with a password.

Private PKI should not be used for any externally reachable service or any service where users might reach it from unmanaged devices. The moment a user on a device that does not have the private CA in its trust store visits an internally-CA-signed site, they see a certificate error. Public CA certificates are required for any site accessible by the general public or by unmanaged devices.

The CA/B Forum: Who Governs the Rules

The CA/Browser Forum is a voluntary association of Certificate Authorities and browser/platform vendors that sets the policies governing publicly trusted SSL/TLS certificates. Its Baseline Requirements define the minimum standards every publicly trusted CA must meet: how domains must be validated, what fields certificates must and must not contain, the maximum validity period, which algorithms are acceptable, how revocation must work, and the security requirements for CA operations.

Browser vendors including Google, Apple, Mozilla, and Microsoft have final control over their trust stores. They can and do remove CAs from the trusted list when those CAs violate their policies, commit to rules they do not follow, or are found to have issued certificates in ways that undermine the security model. High-profile CA removals from browser trust (Symantec in 2018, TrustCor in 2022, TrustAsia’s certain intermediates in 2025) demonstrate that membership in the trusted CA ecosystem is contingent on ongoing compliance.

The CA/B Forum is also the source of the certificate validity timeline changes now affecting all certificate holders. Ballot SC-081v3, approved in April 2025, established the schedule reducing maximum certificate validity to 200 days by March 15, 2026, then 100 days by March 15, 2027, then 47 days by March 15, 2029. The motivation is forcing automation: shorter validity periods make manual certificate management untenable, pushing the industry toward ACME-based automated renewal.

Certificate Transparency: The Public Audit Log for PKI

Certificate Transparency (CT) is a system of public, append-only logs that record every certificate issued by publicly trusted CAs. Introduced by Google and now required by all major browsers, CT makes certificate misissuance detectable after the fact and provides the information needed to hold CAs accountable for incorrect issuances.

Before issuing a certificate, CAs submit a precertificate to one or more CT logs. Each log returns a Signed Certificate Timestamp (SCT), cryptographic proof that the certificate was logged. Browsers check for the presence of valid SCTs during certificate validation. A certificate issued by a publicly trusted CA that is not present in any CT log will be rejected by Chrome with NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

CT logs are operated by Google, Cloudflare, DigiCert, and other organizations. They are publicly searchable: anyone can query crt.sh or Google’s CT log search tools to see every certificate issued for any domain, including certificates they did not authorize. This makes it possible for domain owners to detect unauthorized certificate issuances for their domains and report them to the issuing CA and relevant authorities.

Certificate Transparency fundamentally changed the power dynamic between CAs and certificate holders. Before CT, a CA could issue a certificate for any domain it wanted and only the browser and the domain owner would know. With CT, every certificate issued is permanently and publicly visible. An organization can monitor CT logs for any certificate issued for their domains and immediately detect if a CA issued an unauthorized certificate, whether through error, compromise, or intentional misissuance.

Frequently Asked Questions

What is Public Key Infrastructure in simple terms?

PKI is the system that allows two parties who have never met to establish a trusted encrypted connection over an untrusted network. It does this by having a set of trusted organizations called Certificate Authorities vouch for the authenticity of public keys. When your browser connects to a website, it receives the site’s public key inside a certificate. The certificate is signed by a CA whose public key your browser already trusts. By verifying the CA’s signature, your browser confirms that the public key in the certificate genuinely belongs to the website you intended to reach and has not been substituted by an attacker.

What is a Certificate Authority and how does it establish trust?

A Certificate Authority is an organization that issues digital certificates after verifying the identity of the certificate applicant. CAs establish trust through a combination of cryptography and policy: their root certificates are included in browsers and operating systems only after meeting rigorous security and audit requirements defined by browser vendors and the CA/B Forum. The CA’s private key signs every certificate it issues. Browsers verify those signatures using the CA’s public key, which they already trust from the built-in trust store. The policy and audit requirements ensure that CAs only sign certificates after proper identity verification.

What is the difference between a root CA and an intermediate CA?

A root CA sits at the top of the trust hierarchy. Its certificate is self-signed and is embedded directly in browser and operating system trust stores. Root CAs are kept offline and highly secured. An intermediate CA is certified by a root CA and performs day-to-day certificate issuance. The intermediate structure exists for security: if an intermediate is compromised, the root CA can revoke it and issue a new intermediate without the root itself being exposed. The end-entity certificate, the one you install on your web server, is issued by the intermediate.

What is a Certificate Signing Request (CSR)?

A CSR is the data structure you submit to a CA when requesting a certificate. It contains your public key, identifying information about your organization and domain, and a digital signature made with your corresponding private key. The signature in the CSR proves to the CA that you control the private key associated with the public key you are submitting. The CA validates your identity, then uses your CSR’s public key as the basis for the certificate it issues.

How does certificate revocation work?

Revocation ends trust in a certificate before its natural expiry date. The CA adds the certificate’s serial number to a Certificate Revocation List (CRL), a signed file published by the CA at regular intervals. For real-time checking, the CA also supports OCSP (Online Certificate Status Protocol), where browsers can query the CA directly for a specific certificate’s status. OCSP stapling improves on this by having the web server cache the OCSP response and include it in the TLS handshake, eliminating the need for browsers to make separate CA queries. Browsers also receive updated revocation data through CRLSets (Chrome) and CRLite (Firefox), which pre-download compressed revocation databases.

What is OCSP stapling and why does it matter?

OCSP stapling is a TLS extension where the web server proactively fetches its own certificate’s OCSP status from the CA and attaches the signed response to the TLS handshake. Without stapling, browsers must make a separate OCSP request to the CA for each certificate they encounter, revealing the sites users are visiting to the CA. Stapling eliminates this: the server delivers the OCSP response directly, the browser verifies its signature, and no additional CA contact is needed. From a performance perspective, stapling saves the round-trip to the CA’s OCSP server during the handshake. From a privacy perspective, the CA never learns which users visited which sites.

What does Certificate Transparency do for domain owners?

Certificate Transparency creates a permanent public audit trail of every certificate issued by trusted CAs. Domain owners can monitor CT logs using services like crt.sh or Facebook’s cert.transparency.dev to see every certificate issued for their domains. If someone (including a rogue CA employee or an attacker who compromised CA systems) issues a certificate for your domain without your authorization, it will appear in CT logs immediately. This allows domain owners to detect unauthorized issuance and report it to the CA and browser vendors for investigation and revocation. CT transforms what was once an invisible event into an auditable, publicly verifiable act.

How does PKI apply beyond HTTPS?

PKI is the underlying architecture for most of what we consider digital trust. Code signing certificates allow operating systems and browsers to verify that software was published by a specific organization and has not been modified. Email signing using S/MIME uses the same certificate format to sign and encrypt email. Document signing in PDF uses certificates to prove who signed a document and that it has not been altered. VPN client authentication uses certificates to identify connecting devices instead of passwords. IoT devices receive certificates at manufacture to prove their identity to management infrastructure. SSH certificate authentication replaces traditional host-key-based trust with CA-signed certificates. Every one of these applications uses the same X.509 certificate format and the same CA trust model established for HTTPS.