PKI Explained: The Foundation of Digital Identity and Security

This is the complete guide to Public Key Infrastructure (PKI).

In this guide you will learn what PKI actually is, the five components that make it work, how a certificate gets issued and verified step by step, and why every HTTPS connection and every signed application on your computer depends on it.

If you have ever wondered what really happens when your browser shows a padlock, or how Windows knows who published a program, this guide answers it.

Let’s get started.

What Is PKI?

Public Key Infrastructure (PKI) is the system of hardware, software, policies, and organizations that creates, distributes, verifies, and revokes digital certificates. PKI is what makes it possible to trust a public key: it binds a cryptographic key to a verified real-world identity.

Here’s the problem PKI solves.

Public key cryptography is powerful. Anyone can verify a signature using a public key. Anyone can encrypt a message that only the private key holder can read.

But there’s a catch: how do you know whose public key you’re holding?

A key is just a number. Nothing about the number itself tells you it belongs to your bank, to Microsoft, or to an attacker pretending to be either.

PKI is the answer. It adds a layer of verified identity on top of raw cryptography. A digital certificate says: ‘This public key belongs to this verified entity.’ And a trusted third party (a Certificate Authority) puts its own signature on that statement.

That’s the whole game. Everything else in PKI is machinery to make that statement trustworthy at internet scale.

The 5 Core Components of PKI

1. Certificate Authority (CA)

The CA is the trusted third party at the heart of PKI.

Its job: verify that an entity is who it claims to be, then issue a certificate binding that identity to a public key. The CA signs the certificate with its own private key. Anyone who trusts the CA can now trust the certificate.

DigiCert, Sectigo, GlobalSign, SSL.com, and Let’s Encrypt are public CAs. Enterprises also run private CAs (like Microsoft Active Directory Certificate Services) for internal certificates.

2. Registration Authority (RA)

The RA handles the verification work before issuance.

When you request an OV code signing certificate, someone has to check that your company legally exists, confirm your address, and call a verified phone number. That validation work is the RA function. In many CAs, the RA is an internal department rather than a separate organization, but the role is distinct: the RA verifies, the CA issues.

3. Digital certificates

The certificate is the product of PKI.

It’s a structured file (X.509 format) containing: the subject’s identity, the subject’s public key, the validity period, the intended usage (the EKU field that separates TLS certificates from code signing certificates), and the CA’s signature over all of it.

Change any byte of the certificate and the CA’s signature no longer verifies. That’s what makes certificates tamper-evident.

4. Certificate stores and root programs

Your computer ships with a list of CAs it trusts. That list is the root store.

Microsoft, Apple, Mozilla, and Google each run a root program: a vetted list of CA root certificates their software trusts by default. A CA earns a place in these programs through audits, compliance with CA/Browser Forum requirements, and ongoing scrutiny. Lose the trust, lose the spot. It has happened (Symantec’s CA business was distrusted by browsers in 2018).

5. Revocation infrastructure (CRL and OCSP)

Certificates sometimes need to die early.

A private key gets stolen. A company is dissolved. A certificate was issued in error. Revocation is how PKI handles this: the CA publishes the certificate’s serial number on a Certificate Revocation List (CRL) or answers live status queries via OCSP (Online Certificate Status Protocol). Clients that check revocation reject revoked certificates even though the signature still technically verifies.

How PKI Works: From Key Pair to Trusted Connection

Here’s the full lifecycle, step by step.

Step 1: Generate a key pair

The applicant generates a public/private key pair. The private key never leaves the applicant’s control. For code signing since June 2023, that means it’s generated inside FIPS 140-2 Level 2+ hardware (a USB token or cloud HSM).

Step 2: Submit a certificate signing request (CSR)

The applicant sends the CA a CSR: the public key plus identity information, signed with the private key to prove possession.

Step 3: Validation

The CA (through its RA function) verifies the identity. For a domain-validated TLS certificate this takes minutes (prove you control the domain). For an OV code signing certificate it takes days (verify the legal entity, address, and phone in independent databases). For EV, deeper still.

Step 4: Issuance

The CA creates the certificate and signs it with an intermediate CA key. The intermediate is itself signed by the root. This creates the chain of trust: your certificate, then the intermediate, then the root that lives in everyone’s trust store.

Step 5: Use

The certificate holder uses the private key: a web server proves its identity during the TLS handshake, or a software publisher signs an executable. The relying party (browser, operating system) walks the chain from the presented certificate up to a trusted root, checks validity dates, checks revocation, and checks that the usage matches the EKU.

Step 6: Expiry or revocation

Every certificate has an end. TLS certificates now max out at 200 days (heading to 47 by 2029). Code signing certificates max out at 460 days. At expiry the certificate is renewed with fresh validation. If the key is compromised before then, revocation kills it early.

The Chain of Trust (Why You Trust Sites You’ve Never Seen)

Think about this for a second.

You’ve never met the operators of most websites you use. You’ve never verified Microsoft’s identity yourself. Yet your browser and your operating system trust thousands of certificates from entities you have no relationship with.

The chain of trust makes this work.

Your device trusts a small number of root CAs (a few dozen to a couple hundred). Each root signs intermediates. Each intermediate signs end-entity certificates. When a certificate is presented, your device walks the chain upward. If it reaches a trusted root and every link verifies, the certificate is trusted.

One root anchors millions of certificates. That’s the scaling trick of PKI: you maintain trust in a handful of roots, and the cryptographic chain extends that trust to everything they’ve signed.

This is also why root key compromise is catastrophic. If a root CA’s private key is stolen, the attacker can issue trusted certificates for anything. Root keys are therefore kept offline in physical vaults, used only on rare ceremonial occasions to sign intermediates. Day-to-day issuance always happens from intermediates, which can be revoked and replaced without burning the root.

PKI in Code Signing (Where This Hits Your Software)

Everything above applies directly to code signing.

When you buy an OV code signing certificate, you’re a PKI participant: your organization is validated by an RA, your certificate is issued by a CA, your private key sits in hardware, and your signature on an executable is verified by Windows walking the chain to a Microsoft-trusted root.

The pieces map one to one:

• The UAC publisher name: comes from the Subject field of your certificate, verified by the CA before issuance. That’s PKI identity binding in action.
• ‘Unknown Publisher’ warnings: mean the chain of trust failed: unsigned, self-signed, or signed by a CA the machine doesn’t trust.
• Timestamps: extend PKI through time. Your certificate expires in 460 days, but a timestamped signature stays valid because a Timestamp Authority (another PKI participant) attested to when the signing happened.
• Revocation: is the kill switch if your signing key is stolen. Windows checks revocation when verifying signatures, which is why a compromised certificate gets revoked rather than just abandoned.

Public PKI vs Private PKI

The rule of thumb: if strangers need to trust it, use public PKI. If only your own machines need to trust it, private PKI is cheaper and gives you full control.

Frequently Asked Questions

Is PKI the same thing as SSL?

No. SSL/TLS is one application of PKI. PKI is the trust infrastructure: CAs, certificates, chains, revocation. TLS uses that infrastructure to authenticate servers and encrypt connections. Code signing uses the same infrastructure to authenticate software publishers. S/MIME uses it for email. PKI is the foundation; TLS, code signing, and S/MIME are buildings on top of it.

Who controls PKI?

No single entity. The CA/Browser Forum (a voluntary body of CAs and browser/OS vendors) sets baseline requirements. Root program operators (Microsoft, Apple, Mozilla, Google) decide which CAs their software trusts and can remove CAs that fail audits. CAs operate under those constraints. The system is governed by overlapping accountability rather than central control, and a CA that misbehaves loses root program membership, which effectively ends its business.

What happens to PKI when quantum computers arrive?

PKI’s structure survives; the algorithms inside it change. NIST has standardized post-quantum algorithms (ML-KEM and ML-DSA among them), and CAs and root programs are planning migrations to quantum-resistant signatures. Certificates, chains, CAs, and revocation all work the same way regardless of which signature algorithm is underneath. The transition is an algorithm swap inside the existing infrastructure, comparable in shape to the SHA-1 to SHA-256 migration, though larger in scope.

Gloria Bradford

Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.

Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.