PKI is the machinery that lets one computer decide whether a public key belongs to the name it claims. This track starts from that single question and follows it through certificate structure, chain validation, revocation, and operating your own certificate authority.
A certificate is a signed statement that a public key belongs to a subject, made by an authority the verifier already trusts. That is a narrow claim, and keeping it narrow avoids most misunderstandings. A certificate does not prove the holder is honest, that the software behind it is patched, or that the caller is allowed to perform an action.
It proves a key-to-name binding, within the validation rules the verifier applies
It proves the holder controlled the private key at issuance and at handshake time
It does not prove authorisation, intent or code integrity
Trust comes from the verifier's trust store, not from the certificate itself
02
Keys, signatures, and why the private key never travels
Asymmetric cryptography gives each party a key pair: a public key that can be shared and a private key that must not leave its owner. Signatures are made with the private key and verified with the public key, which is why a signature proves origin and integrity without ever sharing a secret.
RSA 3072 or larger, or ECDSA P-256, are defensible defaults for new certificates
Private keys belong in an HSM or the operating system keystore, never in a repository or ticket
A signed certificate shows possession at enrolment; the handshake proves it again
Key rotation limits exposure, and short lifetimes make rotation routine
03
Anatomy of an X.509 certificate
The fields that matter in practice are the subject, issuer, validity period, public key, serial number, and the extensions that constrain how the certificate may be used. Extensions are where most validation failures originate, because clients enforce them strictly.
Field or extension
What it decides
Subject Alternative Name
Which hostnames or addresses a TLS client will accept
Key Usage
Which cryptographic operations the key may perform
Extended Key Usage
The purpose, such as serverAuth, clientAuth or codeSigning
Basic Constraints
Whether the certificate may sign other certificates
Authority Key Identifier
Which issuer key signed this certificate
CRL Distribution Point / AIA
Where to fetch revocation data and the issuer certificate
04
Building the chain from leaf to root
Validation starts at the leaf, follows each issuer signature upward, and stops when it reaches a self-signed root that the verifier already trusts. Servers must send the leaf plus the intermediates; sending the root is unnecessary and can confuse some clients.
A missing intermediate is the most common production chain failure
Browsers often recover by fetching the intermediate, but most SDKs and devices do not
Cross-signing links a new root to an old one while devices catch up
Path validation also checks dates, names, key usage and revocation status
05
Revocation: CRL, OCSP, stapling and transparency
Revocation answers the question a certificate cannot answer itself: was this certificate withdrawn before its expiry date? Every mechanism trades freshness against cost, and none of them is free.
Mechanism
Strength
Weakness
CRL
Simple, cacheable, signed by the CA
Grows large and goes stale between publications
OCSP
Per-certificate freshness
Extra request per connection, plus a privacy leak
OCSP stapling
Fresh and private, served by the server
The server must keep the staple current
Certificate Transparency
Detects unauthorised issuance
Does not revoke anything by itself
Soft-fail OCSP turns revocation checking into best effort
Publish with overlap so a late CRL never breaks validation
SCTs from CT logs are required for publicly trusted certificates
06
Operating a private CA
A private CA is a commitment, not an installation. The root key anchors every certificate you will ever issue, so its custody, documentation and decommissioning plan decide the ceiling on your security.
Use two tiers: an offline root and one or more issuing CAs
Run a key ceremony with witnesses, HSM custody, documented activation and backup
Publish the root through managed policy, never through an email link
Inventory issued certificates, monitor expiry, and plan revocation before you need it
When retiring a CA, keep publishing revocation data until the last certificate expires