This lesson quickly sets up, for the FOUNDATIONS level, a topic that PRACTITIONER and ADVISOR readers already know (by the brief’s own definition, the “home ground” of this course’s primary learner). PRACTITIONER and ADVISOR readers can skip this lesson and go straight to certificate-chain-bloat.
A certificate is an identity claim
PKI (Public Key Infrastructure) is the umbrella term for the whole system that manages issuing, verifying and revoking certificates (CAs, certificates, revocation mechanisms, and the software that uses them). An X.509 certificate is the basic building block of that infrastructure: a digitally signed document that binds a public key to an identity (for example the domain name bank.example.com). The certificate says: “this public key really belongs to this identity, because I (the signer) verified it.” The certificate itself carries the public key, the subject name, validity dates, and some extensions (such as what the certificate may be used for).
Why trust rests on a chain, not a single certificate
If one party signed every certificate directly, that party’s private key would be used thousands of times a day and the risk of theft would grow. Instead, a three-level structure is built: a root certificate signs itself and becomes the single point browsers and operating systems trust in advance; the root signs an intermediate certificate; and the intermediate signs the leaf certificate that is actually used (for example a website’s certificate). Because the root is used rarely and kept offline in a tightly protected environment, this structure reduces risk: even if the intermediate that does the daily signing is stolen, just that intermediate can be revoked and replaced without regenerating the root.
When a browser connects to a website, it verifies the chain from the leaf up to the root (leaf → intermediate → root): it checks that each certificate’s signature was really made by the one above it, and that the chain ends at a root it already trusts. In the next lesson you will see, with a real measurement, how much this chain grows under PQC.
OCSP and CRL: revoking before expiry
A certificate’s own validity period (for example 90 days) is not enough, because if a private key is stolen, waiting until expiry is an unacceptable risk. So there are two mechanisms: a CRL (Certificate Revocation List) is a file the CA publishes periodically listing the serial numbers of revoked certificates; OCSP (Online Certificate Status Protocol) is a protocol a client uses to ask, in real time, about a specific certificate’s status (“valid or revoked?”). Both answer the same question (is this certificate still valid) in different ways: CRL means downloading a whole list, OCSP means sending a single query. Later in this module you will see how PQC signatures affect the size of both.