Vendor-neutral design pattern
Enterprise PKI and the certificate trust chain
Why a browser trusts one web server and rejects another comes down to a signature chain that ends at a root you already trust, and a revocation check that catches the certificate that went bad early.
A root you already trust, and a chain that leads back to it
Public key infrastructure (PKI) turns 'I received a public key' into 'I trust this key belongs to this server.' It does that with a chain of signatures that ends at a root of trust the relying party already has.
A certificate authority (CA) hierarchy has three layers. The root CA has a self-signed certificate: nobody signs it, so it must be trusted on its own, which is why operating systems and browsers ship a fixed trust store of root certificates. Below it sits one or more issuing (intermediate) CAs, whose certificates are signed by the root. At the bottom are leaf (end-entity) certificates for individual servers, gateways, and users, signed by an issuing CA.
The defining move in a serious enterprise design is keeping the root CA offline: powered off and air-gapped, brought out only to sign an issuing CA's certificate. Day-to-day issuance happens on the online issuing CA. If that issuing CA is ever compromised, you revoke and replace it without the far more painful job of rebuilding the root and reseeding every trust store on earth.
How a certificate is born: CSR, keys, and signing
A leaf certificate starts on the server that will use it, not on the CA. The server generates its own key pair and builds a certificate signing request (CSR) containing the public key and the identity it is claiming (the subject name, such as the fully qualified domain name). The private key stays on the server and is never sent anywhere.
The CSR goes to the issuing CA, which verifies the request and then signs it, producing the leaf certificate that binds the public key to the name. Because only the public key ever traveled, the CA can vouch for identity without ever holding the server's private key.
One certificate can cover a whole subdomain with a wildcard (for example *.example.com), which is convenient but concentrates risk: a single stolen private key then covers every host the wildcard matches. Separately, some organizations run key escrow for encryption keys so data can be recovered if a key is lost, but signing keys are generally not escrowed, to preserve non-repudiation.
Validation and revocation: what the client actually checks
During the TLS handshake the server presents its leaf certificate together with the issuing CA's certificate. The client then builds and validates the chain: each certificate must be signed by the next one up, the chain must terminate at a root already in the client's trust store, every certificate must be inside its validity dates, and the leaf's subject or subject alternative name must match the host the client asked for. If any link fails, the connection is refused. This is why a self-signed server certificate triggers a warning: it chains to nothing the client trusts.
Expiry is not the only way a certificate dies. A private key can leak or an employee can leave, so a certificate must be revoked before its natural expiry. Revocation is published two ways: a certificate revocation list (CRL), a signed list of revoked serial numbers the client can download, and the Online Certificate Status Protocol (OCSP), a lighter query about a single serial number. OCSP stapling lets the server fetch and attach a fresh, CA-signed status during the handshake, so the client gets revocation proof without contacting the responder itself. A validated chain that skips the revocation check is exactly how a stolen-but-unexpired certificate keeps working.
For the exam, hold these apart: the root is trusted because it is in the store (not because something signed it), the intermediate exists so the root can stay offline, the leaf's private key never leaves its host, and CRL/OCSP answer a question validity dates cannot: 'was this certificate pulled early?'
Sources
Practice what you just read