Public Key Infrastructure (PKI) and Certificates

Public Key Infrastructure (PKI) is the framework of policies, roles, hardware, and software that manages digital certificates and the public/private key pairs behind them. On the Security+ (SY0-701) exam, PKI questions test whether you understand how trust is established online: who issues certificates, how a browser verifies one, and how certificates are revoked when something goes wrong. Master the players, the chain of trust, and the revocation mechanisms and this domain becomes predictable.

Core Idea

• PKI binds an identity to a public key. A digital certificate is a signed document that says "this public key belongs to this entity," vouched for by a trusted third party.
• Trust flows down from a root. A root certificate authority (CA) signs intermediates, intermediates sign end-entity (leaf) certificates, forming a chain of trust back to a trusted root.
• Asymmetric keys do the work. The private key stays secret and proves ownership; the public key, distributed in the certificate, is used by others to encrypt to or verify the holder.

The Players: CA, RA, and Root of Trust

• Certificate Authority (CA): the trusted third party that issues and digitally signs certificates.
• Registration Authority (RA): verifies the identity of the requester before the CA issues a certificate; it handles enrollment and vetting but does not issue certificates itself.
• Root CA: the anchor of trust, kept offline for security. Its self-signed root certificate is preinstalled in operating systems and browsers (the trust store).
• Intermediate CA: signed by the root and used to issue day-to-day certificates, so the root's private key rarely has to be used. Compromise of an intermediate can be contained without rebuilding the whole hierarchy.

The Chain of Trust and X.509

Certificates follow the X.509 standard. A certificate binds an identity to a public key and includes the subject name, the public key, the issuer, a validity period, a serial number, and the CA's digital signature. When a client validates a certificate, it walks the chain: the leaf is checked against its issuing intermediate, the intermediate against the root, and the root is trusted because it lives in the local trust store. If any link is missing, expired, or untrusted, validation fails.

Certificate Types

• Root certificate: self-signed certificate of the root CA; the top of the chain.
• Wildcard certificate: covers all first-level subdomains of a domain (e.g., *.example.com) with a single certificate.
• Subject Alternative Name (SAN) certificate: secures multiple specific hostnames or domains listed in the SAN field of one certificate.
• Self-signed certificate: signed by its own key with no external CA; useful for internal/testing use but not trusted by outside parties.
• Code signing certificate: proves software authorship and integrity so users know code has not been tampered with.

Enrollment: The Certificate Signing Request

To obtain a certificate, the requester generates a key pair and creates a certificate signing request (CSR) containing the public key and identifying information (such as the common name). The private key never leaves the requester. The CSR is sent to the CA/RA, which validates the identity, then signs and issues the certificate. Some organizations also use key escrow, storing a copy of private keys with a trusted third party so encrypted data can be recovered if a key is lost.

Revocation: CRL, OCSP, and Stapling

Certificates sometimes must be invalidated before they expire (key compromise, employee departure).

• Certificate Revocation List (CRL): a signed list of revoked serial numbers published by the CA; clients download it, but it can be large and stale.
• Online Certificate Status Protocol (OCSP): lets a client query the CA in real time for the status of a single certificate — faster and fresher than a CRL.
• OCSP stapling: the web server itself obtains a time-stamped, CA-signed OCSP response and "staples" it to the TLS handshake, so the client does not have to contact the CA — improving performance and privacy.
• Certificate pinning: the client hard-associates a host with a specific certificate or public key, rejecting any other even if it chains to a valid CA — defending against fraudulent or mis-issued certificates.

How TLS Uses Certificates

During a TLS handshake, the server presents its certificate to prove its identity. The client validates the chain, checks the name and validity period, confirms the certificate is not revoked, and uses the server's public key to help establish a shared session key. This provides server authentication and sets up the encrypted channel — the everyday purpose of PKI on the web.

High-Yield Exam Patterns

• If a scenario needs real-time, per-certificate status without the client contacting the CA, the answer is OCSP stapling.
• One certificate for many named domains = SAN; one certificate for all subdomains of one domain = wildcard.
• The RA verifies identity; the CA signs and issues. Do not swap these roles.
• The root CA is kept offline; intermediates do the routine signing to protect the root key.
• The private key never appears in a CSR — only the public key and identity information do.
• Pinning defends against a valid-but-fraudulent CA-issued certificate; revocation (CRL/OCSP) handles keys that must be invalidated early.

Common Traps to Avoid

• Confusing the CA with the RA — the RA vets identity but never issues certificates.
• Thinking a self-signed certificate is "insecure encryption"; the encryption is fine, but no external party trusts the identity.
• Assuming an expired certificate and a revoked certificate are the same thing — expiration is time-based; revocation is an active invalidation.
• Believing key escrow means the key is weak; escrow is about recovery, not encryption strength.
• Forgetting that certificate pinning can break legitimate certificate rotation if not managed carefully.