PKI and Certificates

The problem PKI solves

Asymmetric encryption says "encrypt with the recipient's public key." Fine, but when a website hands your browser a public key, how do you know it belongs to your bank and not to an attacker sitting in the middle? You need someone you already trust to vouch for it. That is a certificate: the public key, the identity, and a signature from a trusted authority, all in one document.

The trust chain

Root CA (offline, in every browser's trust store)
   |  signs
Intermediate CA (online, does the daily work)
   |  signs
Leaf certificate (www.bank.example, public key, validity dates, purpose)

Your browser trusts the root because it shipped with it. The root signed the intermediate, the intermediate signed the bank's certificate, so the browser trusts the bank's public key. That is the root of trust and the chain. Keeping the root offline protects the whole system: if an intermediate is compromised, it can be revoked without replacing every browser's trust store.

The registration authority is the part of the CA's operation that checks identity before issuance: proving you control the domain, or for higher assurance, that the company exists.

Getting a certificate, in order

1. On the server, generate a key pair. The private key never leaves the server.
2. Build a certificate signing request (CSR): the public key plus the identity details, signed with the private key to prove you hold it.
3. Send the CSR to the CA. The RA validates. The CA signs and returns the certificate.
4. Install the certificate and the intermediate chain on the server.

If a question asks what is sent to the CA, the answer is the CSR containing the public key. Never the private key.

Revocation: CRL versus OCSP

Certificates expire, but sometimes they must die early: the private key leaked, or the server was retired.

CRL     the CA publishes a list of revoked serial numbers; clients download it on a schedule
        simple; can be hours or days stale; large lists
OCSP    the client asks the CA "is this one certificate still good?" in real time
        current; adds a round trip; reveals what sites you visit to the CA
OCSP stapling   the server fetches a fresh signed OCSP answer and attaches it to the handshake
        current and fast, no client round trip, no privacy leak

Kinds of certificates

• Self-signed: signed by its own private key. Nobody vouches for it, so browsers warn. Fine for an internal test box or a lab, never for users on the internet.
• Third-party: issued by a public CA; trusted automatically.
• Wildcard: *.example.com covers mail.example.com, www.example.com, any single label. Convenient; one compromised key affects every subdomain.
• Subject alternative name (SAN): a list of specific hostnames on one certificate.
• Purpose-specific: code signing (proves software came from the publisher), email (S/MIME), user and device certificates for 802.1X.

Formats

PEM      Base64 text between BEGIN and END lines; .pem, .crt, .cer     certificate or key
DER      the same data in binary; .der, sometimes .cer                 certificate
PFX/P12  a password-protected bundle WITH the private key; .pfx, .p12  moving a cert plus key
P7B      a chain of certificates, NO private key; .p7b                 distributing a chain

Key escrow

A trusted third party, often the organization itself, keeps a copy of private keys. If an employee leaves or loses a key, encrypted data can still be recovered. The trade-off is that the escrow becomes a high-value target and must be protected.

How the exam asks it

• "Users receive a certificate warning on the internal portal." Self-signed, or the intermediate chain is missing.
• "Check revocation status without downloading a large list." OCSP.
• "Improve performance of revocation checking on the server." OCSP stapling.
• "One certificate for all subdomains." Wildcard.
• "Export the certificate together with its private key." PFX or P12.
• "Recover files encrypted by a former employee." Key escrow.

What to memorize

• Chain: leaf, intermediate, root. Root is the trust anchor and stays offline.
• CSR carries the public key; the private key never leaves the server.
• CRL is a list, OCSP is a question, stapling is the answer attached in advance.