PKI and certificates, and the key management that decides whether any of it works

Objective 1.3 asks you to explain why the appropriate cryptographic solution matters -- which tool fits which requirement, and what goes wrong when the wrong one is chosen or a key is mishandled. This course splits it across three lessons. This one takes public key infrastructure: key pairs, certificates and the authorities that issue them, revocation, certificate types and key escrow. Encryption itself is the next lesson, and hashing, salting, signatures and obfuscation the one after.

Why this matters

Cryptography is one objective out of twenty-seven, but certificates are examined far beyond it: they appear in secure communication and zero trust in Domain 3, in identity and access management in Domain 4, and as expired or mis-issued certificates behind outages and attacks throughout. Getting PKI solid pays for itself repeatedly.

The exam does not ask you to do mathematics. It asks which certificate or mechanism fits a stated requirement, and what breaks when a key or certificate is mishandled. That is a much smaller thing to learn than people fear, and it is mostly about being exact with vocabulary.

The lesson

Public and private keys, and what a certificate authority actually asserts

An asymmetric key pair is two mathematically related keys. Data protected with one can only be recovered or verified with the other. The public key is published; the private key never leaves its holder.

That gives two distinct operations, and confusing them is the single biggest source of lost marks here:

• Encrypt with the recipient's public key. Only the recipient's private key opens it. This gives confidentiality.
• Sign with your own private key. Anyone with your public key can verify it. This gives authenticity, integrity and non-repudiation -- and no confidentiality at all, because the public key is public.

The weak point is obvious once stated: how do you know a public key really belongs to the person or server it claims to? Anyone can generate a key pair and announce that it belongs to your bank. Public key infrastructure (PKI) is the system of policies, roles, software and hardware that answers that question at scale.

A certificate binds a public key to an identity -- a domain name, a person, a device -- along with a validity period and permitted uses. A certificate authority (CA) is the party that vouches for that binding: it has checked, by some process, that the key belongs to the named subject, and it signs the certificate with its own private key to say so.

Be precise about what the CA asserts. For a common domain-validated web certificate, it asserts control of the domain name -- nothing about the organisation behind it, and nothing about whether the site is trustworthy. A phishing site can hold a perfectly valid certificate for its own look-alike domain. An exam option claiming that a certificate proves a site is safe is wrong.

Root of trust, intermediate CAs, and generating a certificate signing request

Trust in a certificate is inherited along a chain.

• The root of trust is the root CA's certificate. It is self-signed, because nothing sits above it, and it is trusted because it was placed in the operating system's or browser's trust store in advance. Everything else chains to it, so its private key is the most valuable key in the whole system and is normally kept offline.
• Intermediate CAs sit between the root and the end-entity certificates that servers and users hold. They do the day-to-day signing, so the root key can stay offline, and a compromise can be contained by revoking one intermediate instead of replacing a root on every device that trusts it.
• A client validating a certificate walks the chain upward -- server certificate, then intermediate, then root -- checking each signature, each validity period and revocation status. If any link is missing, expired or untrusted, validation fails.

"Root of trust" is also used more broadly for any component that is trusted without being verified by something else -- a hardware chip, for example, that anchors a device's boot process. The idea is the same: everything above it is only as trustworthy as it is.

To get a certificate you generate a certificate signing request (CSR):

1. Generate a key pair on the system that will use it -- ideally inside protected hardware.
2. Build the CSR: the public key plus the identity details you want certified, such as the domain names.
3. Sign the CSR with the new private key, which proves to the CA that you hold it.
4. Send the CSR to the CA, which validates your claim and returns a signed certificate.

The private key never goes in the CSR and never goes to the CA. If a process asks you to send a private key anywhere in order to get a certificate, the process is wrong.

Revocation through CRLs and OCSP, and why stapling exists

Certificates sometimes have to stop being trusted before they expire: the private key was exposed, the CA itself was compromised, the certificate was replaced, or the service it named no longer exists. That is revocation, and there are two ways for a client to learn about it.

• A certificate revocation list (CRL) is a list, signed and published by the CA, of certificates it has revoked before expiry. Clients download it periodically. Its weakness is freshness -- a client may be working from a list that is hours or days old -- and lists can grow large.
• The Online Certificate Status Protocol (OCSP) asks the CA (or its responder) about one certificate in real time and gets a signed answer: good, revoked or unknown. Its weaknesses are privacy and availability: the responder learns which sites a client is visiting, and if it cannot be reached the client must decide whether to fail open (accept the certificate anyway) or fail closed (refuse it).
• OCSP stapling fixes both weaknesses. The server periodically fetches a signed, time-stamped OCSP response for its own certificate and presents it during the TLS handshake. The client gets fresh revocation status without contacting the CA at all, and the CA no longer sees who is visiting.

The exam angle is usually a trade-off: CRL for simplicity, OCSP for timeliness, stapling when the scenario mentions privacy or performance.

Wildcard, self-signed and third-party certificates, and where each is the right choice

• A wildcard certificate (*.example.com) covers any single-level subdomain of one domain. It is convenient and it concentrates risk: one stolen private key compromises every host using it, and it does not cover deeper names such as a.b.example.com. When the names are known and few, a certificate listing each one in its subject alternative name (SAN) field limits the blast radius instead.
• A self-signed certificate is signed with its own key, so nothing independent vouches for it. Encryption still works; identity assurance does not, and clients warn unless the certificate has been placed in their trust store by hand. It is acceptable for a lab or a closed internal system where you control every client, and wrong for anything the public reaches.
• A third-party certificate is issued by an external, publicly trusted CA. It is what public services need, precisely because browsers and operating systems already trust that CA.

Between these sits the internal CA an organisation runs for itself: certificates for employee devices, internal web services and VPN clients, trusted because the organisation pushes its own root to its own managed devices. That is the grown-up version of self-signing -- one root you protect, rather than hundreds of individually trusted certificates.

Two operational points generate real incidents: certificates expire, and an expiry looks like a network fault until someone checks; and a certificate is only as trustworthy as its private key, so a key left on a shared drive is a compromised certificate waiting to be noticed. Inventory, monitoring for expiry, and automated renewal are the controls.

Key escrow, and the recovery problem it solves at the cost of a second copy

Encryption has an uncomfortable failure mode: lose the key and the data is gone, for you as surely as for an attacker. An employee leaves, a laptop's key store corrupts, or a user forgets a passphrase, and the organisation's own records become unreadable.

Key escrow solves that by keeping a copy of the key with a trusted party -- a dedicated recovery service, a security team, sometimes an outside agent -- under strict conditions for its release. Recovery keys for managed laptops held in a directory service are a familiar example.

The cost is the second copy. The key is now exposed wherever it is escrowed, so the escrow store becomes a high-value target and needs its own controls: strong access control, separation of duties or a requirement for more than one person to release a key, logging of every retrieval, and protected hardware where possible.

There is also a design rule worth knowing. Escrow encryption keys, so that data can be recovered; avoid escrowing signing keys. If someone else holds a copy of your signing key, you can credibly say that someone else signed, and non-repudiation is gone. Many organisations issue separate key pairs for the two purposes for exactly this reason.

What to take into the exam

• Encrypt with the recipient's public key for confidentiality; sign with your own private key for authenticity and non-repudiation.
• A CA asserts that a key belongs to a name -- not that the site is safe.
• Trust flows from the root down through intermediates; the root key stays offline.
• A CSR carries the public key and the identity, is signed by the private key, and never contains it.
• CRL is a periodic list; OCSP is a live query; stapling has the server fetch and present the signed status.
• Wildcard concentrates risk; self-signed suits closed internal use; third-party is for the public.
• Escrow encryption keys for recovery, not signing keys.