General Security Concepts · Topic 5 of 7
PKI and Digital Certificates
Understand PKI: public and private keys, key escrow, certificate authorities, root of trust, CSRs, wildcard and self-signed certificates, CRL and OCSP.
- 6 min
- Includes a diagram
- The public key is shared. The private key is never shared.
- PKI issues and manages certificates, and a CA signs them.
- A certificate links a public key to an identity.
What it is
A public key infrastructure (PKI) is the set of people, software, policies and hardware that issue, manage and revoke digital certificates.
PKI is built on key pairs. The public key can be shared with anyone, and the private key is kept secret by its owner. Data encrypted with one key of the pair can only be decrypted with the other.
A digital certificate binds a public key to an identity, such as a web site name. A trusted party called a certificate authority (CA) signs the certificate, so that others can rely on it without having met the owner.
How it works
Public key, private key and key escrow
| Item | Who holds it | Used to |
|---|---|---|
| Public key | Anyone, published in the certificate | Encrypt data for the owner, verify the owner's signatures |
| Private key | Only the owner | Decrypt data sent to the owner, create signatures |
| Key escrow | A trusted third party holds a copy of a key | Recover encrypted data if the owner's key is lost |
Key escrow is useful when an employee leaves or loses a key, or when the business must always be able to read its own encrypted data. The escrow store must be protected like any other secret, because anyone who gets into it can decrypt the data.
Certificate signing request generation
The owner generates a key pair and builds a certificate signing request (CSR) that contains the public key and identity details, such as the domain name and organization. The CA checks the request and signs the certificate with its own private key.
The private key stays on the server and is never sent. If a private key is ever exposed, the certificate must be revoked and a new key pair and CSR created.
Certificate authorities and root of trust
A browser or operating system holds a store of trusted root CA certificates. A server certificate is normally signed by an intermediate CA, which is signed by the root.
The root CA is the root of trust. Its private key is guarded closely, often offline, so that a compromise does not spread. A client checks each link of the chain up to a root it already trusts.
A root of trust can also be hardware. A trusted platform module (TPM) or hardware security module (HSM) can anchor trust in a device, because its keys cannot easily be copied out.
Third-party, self-signed and wildcard certificates
| Type | What it is | When to use it |
|---|---|---|
| Third-party | Issued by a public CA whose root is already in browsers and operating systems | Public web sites and services used by outside clients |
| Self-signed | Signed by its own private key, so no outside CA vouches for it | Labs, testing, some internal systems |
| Wildcard | Covers all subdomains at one level, such as *.example.com | Many hosts under one domain |
Self-signed certificates are not trusted by clients unless they are added to the trust store by hand. Organizations can also run their own internal CA, whose root they push to company devices.
A wildcard certificate is convenient, though a stolen key exposes every subdomain that uses it. It covers only one level, so *.example.com does not cover a.b.example.com.
Checking whether a certificate is still valid
Certificates can be withdrawn before they expire, for example after a key theft. A certificate revocation list (CRL) is a list published by the CA of revoked certificate serial numbers. Clients download it and check whether a certificate appears on it.
The Online Certificate Status Protocol (OCSP) lets a client ask for the status of one certificate in real time. OCSP stapling lets the server attach a fresh, signed status response to the handshake, which saves the client from contacting the CA.
| Method | How it works | Trade off |
|---|---|---|
| CRL | Client downloads the full list from the CA | Can be large and only as fresh as the last publication |
| OCSP | Client asks about one certificate | Real time, but needs a responder to be reachable |
How the exam asks about this
- "A browser must check right now whether one server certificate has been revoked." -> OCSP.
- "One certificate must cover every current and future host one level under the company domain." -> A wildcard certificate.
- "Encrypted files must be recoverable if an employee loses their private key." -> Key escrow.
What to remember for the exam
- The public key is shared. The private key is never shared.
- PKI issues and manages certificates, and a CA signs them.
- A certificate links a public key to an identity.
- The CSR contains the public key and identity details, never the private key.
- The root CA is the root of trust. Intermediate CAs do the daily signing so the root can stay offline.
- A CRL is a published list of revoked certificates. OCSP checks one certificate on demand.
- Third-party certificates are trusted by browsers by default. Self-signed certificates are not.
- Key escrow keeps a copy of a key with a trusted party for recovery.
When a question describes a client checking whether one certificate has been revoked right now, the answer is OCSP, not a CRL.
Common mistakes
Sending the private key to the CA. The CA only needs the public key in the CSR. The private key must stay with the owner.
Assuming expiry and revocation are the same. Expiry is a planned end date. Revocation ends trust early and is announced through a CRL or OCSP.
Trusting a certificate because it exists. A client must also check the name, the validity dates, the chain and the revocation status.
Using one wildcard certificate everywhere. A single key leak then affects every host that shares it.
Thinking key escrow weakens nothing. It creates a second place where the key lives, so that store becomes a high value target.
A self-signed certificate on a public site makes users click through browser warnings, which trains them to ignore real warnings.
Check yourself
What does a CSR contain?
The public key and the identity details of the requester. The private key is not included.
How is OCSP different from a CRL?
OCSP queries the status of a single certificate on demand, while a CRL is a published list of all revoked certificates.
Why are intermediate CAs used?
They sign day to day certificates, so the root CA key can stay protected and often offline.
Topic 5 of 7 in General Security Concepts
Test yourself on General Security Concepts
The full CompTIA Security+ SY0-801 question bank has 998 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.