← Module 06 · Security & Encryption

PKI & Digital Certificates

How a public key belonging to a total stranger gets trusted anyway, without the two of you ever having met.

A passport, not a personal introduction

A passport doesn't work because a border agent personally knows you. It works because a trusted government verified your identity once and issued a document that's extremely hard to forge, and every other country downstream agrees to trust that government's word for it. PKI (Public Key Infrastructure) works the same way for public keys: a Certificate Authority (CA) verifies that a public key genuinely belongs to a specific domain or organization, then issues a digital certificate binding the two together, backed by the CA's own digital signature vouching for it.

What's actually inside a certificate

FieldWhat it holds
SubjectWho or what the certificate was issued to, e.g. a domain name
IssuerWhich CA issued it
Public KeyThe subject's public key
Validity PeriodA not-before and not-after date; expired certificates are rejected
Serial NumberA unique identifier, used for revocation lookups
SignatureThe issuing CA's digital signature over the whole certificate

The chain of trust

Browsers and operating systems don't ship with every website's certificate pre-trusted. They ship with a small, curated list of root CAs they trust unconditionally, called a trust store. A root CA's certificate is self-signed: nobody vouches for it but itself, and that's fine, since it's the trust anchor everything else is built on. Root CAs rarely sign server certificates directly; instead they sign an intermediate CA's certificate, which then signs the actual server certificate. Verifying a certificate means walking that chain, server certificate, up through each intermediate, until it reaches a root already sitting in the trust store.

ROOT CA (self-signed) TRUSTED DIRECTLY BY YOUR OS/BROWSER INTERMEDIATE CA example.com certificate signs signs
Verifying example.com's certificate means checking the intermediate's signature, then checking that the intermediate itself was signed by a root already in the trust store, not trusting example.com's certificate in isolation.

Revocation: When a certificate shouldn't be trusted anymore

A certificate can be compromised or issued in error before its expiry date arrives. Two mechanisms exist to catch that: a CRL (Certificate Revocation List), a published list of revoked serial numbers a client can check, and OCSP (Online Certificate Status Protocol), a live query asking a CA "is this specific certificate still good?" instead of downloading an entire list.

WHY SELF-SIGNED CERTIFICATES TRIGGER BROWSER WARNINGS

A self-signed certificate that isn't a root already in the trust store has nobody vouching for it. The browser has no chain to walk back to anything it already trusts, so it can't tell the difference between a legitimate internal test certificate and an attacker's forged one, and warns either way.