PKI 101: A Plain-English Guide to Digital Certificates

Public Key Infrastructure sounds forbidding. The idea underneath it is not.

PKI solves one problem: how do you know that the thing on the other end of a connection is what it claims to be, when you have never dealt with it before and have no way to ask?

This guide explains how that works in plain English. No mathematics, no jargon without a definition. If you want the full technical treatment afterwards, our guide to what PKI is goes considerably deeper.

Start with the problem

You type your bank's address into a browser. Something answers. How do you know it is your bank and not someone pretending?

You cannot rely on the address, because addresses can be spoofed. You cannot rely on the page looking right, because anyone can copy a design. And you cannot phone the bank to check, because this needs to happen in milliseconds, billions of times a day, across the whole internet.

What you need is a third party you already trust, vouching for the bank. That is the entire idea behind PKI.

The passport analogy

When you travel, a border official who has never met you accepts your identity. Not because they trust you, but because they trust the government that issued your passport, and the passport has features that are hard to forge.

A digital certificate works the same way.

• The certificate is the passport. It states who the holder is.
• The Certificate Authority is the passport office. It checks identity before issuing.
• The digital signature on the certificate is the anti-forgery feature. It cannot be faked without the issuer's private key.
• Your browser's trust store is the border official's list of governments whose passports are acceptable.

The analogy holds well. It also has one limitation worth knowing: a passport proves who you are, whereas most certificates on the web only prove control of a domain name. More on that below.

The two keys

PKI depends on key pairs. Two keys, mathematically linked, generated together.

• The public key is shared openly. Anyone can have it.
• The private key is kept secret and never shared. Ever.

What makes this useful is that the two work as a pair in a specific way. Something encrypted with the public key can only be decrypted with the private key. And something signed with the private key can be verified by anyone holding the public key.

That second property is the important one for certificates. It means a server can prove it holds the private key matching the public key in its certificate, without ever revealing the private key itself.

Deriving the private key from the public key is computationally infeasible with current technology. That is the whole basis of the security, and it is why protecting private keys matters more than almost anything else in PKI.

What actually happens when you visit a secure website

The padlock in your browser is the visible result of a process that takes milliseconds.

1. Your browser asks for identification. It connects to the server and requests its certificate.
2. The server presents its certificate. This contains its public key, the name it claims, a validity period, and the issuing authority's signature.
3. Your browser checks the signature. Was this certificate signed by an authority in my trust store? If not, you get a warning.
4. Your browser checks the details. Does the name on the certificate match the site I asked for? Has it expired? Has it been revoked?
5. The server proves it holds the private key. Anyone can copy a certificate. Only the legitimate holder has the matching private key.
6. Both sides agree a session key. The certificate work is done. From here the connection is encrypted with a faster method.

That final step is worth understanding. The certificate establishes identity and helps negotiate a key. The actual data is then protected by symmetric encryption, which is far faster. Certificates handle the introduction; something else does the heavy lifting.

The vocabulary

PKI has more terminology than it strictly needs. These are the terms worth knowing.

• Certificate — an electronic document binding a public key to an identity, signed by an authority.
• Certificate Authority (CA) — the organisation that issues certificates after verifying identity.
• Registration Authority (RA) — handles the identity checking on the CA's behalf. Often built into the CA platform rather than separate.
• Public key — shared openly, used to encrypt data for the holder or verify their signature.
• Private key — kept secret, used to decrypt data or create signatures.
• Root CA — the top of the trust chain. Its certificate is self-signed and sits in trust stores.
• Intermediate CA — sits between root and end certificates, so the root can stay offline and protected.
• Trust store — the list of CAs your browser or operating system already trusts.
• CSR (Certificate Signing Request) — what you send to a CA to ask for a certificate.
• Revocation — cancelling a certificate before it expires, usually because the private key was compromised.
• CRL and OCSP — the two mechanisms for publishing and checking revocation status.
• X.509 — the standard defining what a certificate contains. Practically every certificate you encounter follows it.

Our guide to digital certificates, SSL/TLS and X.509 covers the certificate structure in detail.

Three things people commonly get wrong

"SSL certificate" and "TLS certificate" are different things

They are not. SSL is the original protocol and every version of it is deprecated. TLS replaced it. The certificates are X.509 certificates in both cases. The industry kept saying "SSL certificate" out of habit, and the term outlived the protocol.

A certificate proves who a company is

Usually not. Most certificates on the web are domain validated, which means the CA confirmed the applicant controls the domain and nothing more. It says nothing about who is behind it. Organisation and Extended Validation certificates do verify the entity, but they are a minority.

So the padlock tells you the connection is encrypted and the site is the one at that address. It does not tell you the site is trustworthy.

PKI is only for websites

The web is the most visible use, not the largest. Certificates authenticate devices on networks, sign software so your operating system knows it has not been tampered with, secure email, prove document authorship, and increasingly identify workloads and containers inside cloud environments.

In most enterprises the internal certificate estate is considerably larger than the public-facing one. Our article on everyday examples of PKI in action covers where it turns up.

Where organisations run into trouble

PKI is reliable technology. The problems are almost always operational rather than cryptographic.

Certificates expire. Every certificate has a fixed validity period, and when it passes, whatever depends on it stops working immediately. Not gradually — immediately. Most certificate-related outages are simply a renewal that nobody tracked.

Nobody knows how many there are. Certificates get issued by different teams, embedded in appliances by suppliers, and created for short-term projects that quietly become production. Organisations consistently find more than their records show.

Private keys end up in the wrong places. Hardcoded in source code, sitting in configuration files, copied between systems. A certificate is only as trustworthy as the protection around its private key.

These are the problems certificate lifecycle management exists to solve. PKI establishes trust; CLM keeps it working — through discovery, monitoring, automated renewal and revocation across the whole estate.

That distinction matters more each year, because public certificate lifetimes are shortening. A renewal that used to happen annually will happen roughly eight times a year by 2029, which is not something a spreadsheet and a calendar reminder can absorb.

Where to go next

• What is PKI? — the full technical treatment, including hierarchy design, revocation infrastructure and post-quantum considerations.
• Understanding digital certificates — what is inside an X.509 certificate and how to get one.
• What is encryption? — the underlying mechanics.
• The importance of digital trust — why this matters commercially, not just technically.

How Unsung helps

PKI is all we do. We are a UK-based, vendor-neutral consultancy working across central government, defence, financial services, healthcare and transport, and our consultants hold SC and DV clearance.

If you are earlier in this than you would like to be, a PKI health check establishes what you actually have before any decisions get made. PKI consultancy and certificate lifecycle management cover the work from there.

Talk to our team if you would rather just ask someone.