This chapter covers Public Key Infrastructure (PKI) and digital certificates, a foundational security concept that enables secure communication, authentication, and non-repudiation across networks. For the SY0-701 exam, this maps to Objective 1.4 (General Security Concepts) and appears in multiple domains, including cryptography, authentication, and secure protocols. Understanding PKI is critical because it underpins HTTPS, email encryption, code signing, and smart card authentication—technologies you will configure, troubleshoot, and defend in the field.
Jump to a section
Think of PKI as a global passport system. A Certificate Authority (CA) is like a passport office—a trusted entity that verifies your identity and issues a passport (digital certificate). Your passport contains your photo, name, and a hologram (digital signature) that proves it was issued by a legitimate office. When you travel, border agents don't need to know you personally; they trust the passport because they trust the issuing authority. Similarly, when you visit a secure website, your browser trusts the website's certificate because it was signed by a CA that the browser already trusts. The chain of trust works like this: your browser has a list of trusted root CAs (like a database of known passport offices). If a website presents a certificate signed by one of those CAs, your browser checks the signature using the CA's public key. If valid, it knows the website's public key is authentic. Now, what if someone forges a passport? They'd need to replicate the hologram, which is computationally hard. In PKI, forging a signature requires the CA's private key. That's why private keys must be kept secret. But what if a corrupt passport office issues a fake passport? That's a rogue CA. To counter this, browsers maintain Certificate Revocation Lists (CRLs) or use Online Certificate Status Protocol (OCSP) to check if a certificate has been revoked—like a passport being flagged as stolen. The analogy breaks down slightly because digital certificates also include validity periods and can be revoked in real-time, but the core idea of a trusted third party issuing verifiable credentials is identical.
What is PKI and Why Does It Matter?
Public Key Infrastructure (PKI) is a framework of policies, procedures, hardware, software, and people that creates, manages, distributes, uses, stores, and revokes digital certificates. The primary threat PKI addresses is the man-in-the-middle (MITM) attack—an attacker intercepting communications and impersonating a legitimate party. Without PKI, you have no way to verify that the public key you receive actually belongs to the entity you think it does. PKI solves this by binding a public key to an identity (person, server, device) through a trusted third party: the Certificate Authority (CA).
How PKI Works Mechanically
Key Pair Generation: A user or server generates a public/private key pair. The private key is kept secret; the public key is sent to a CA for certification.
Certificate Signing Request (CSR): The entity creates a CSR containing its public key and identifying information (e.g., domain name, organization). The CSR is digitally signed with the private key to prove possession.
Identity Verification: The CA verifies the requester's identity according to its validation policy (domain validation, organization validation, or extended validation).
Certificate Issuance: The CA creates a digital certificate containing the public key, identity info, validity period, and the CA's digital signature. The signature is created by hashing the certificate contents and encrypting the hash with the CA's private key.
Certificate Distribution: The certificate is sent to the requester and can be freely distributed (e.g., during TLS handshake).
Certificate Validation: When a client receives a certificate, it validates the signature using the CA's public key (which is pre-installed or obtained from a trusted root). It also checks the validity period, revocation status (via CRL or OCSP), and that the certificate is not expired or revoked.
Chain of Trust: The client builds a chain from the end-entity certificate to a trusted root CA, verifying each intermediate CA's signature along the way.
Key Components, Variants, and Standards
Certificate Authority (CA): The trusted entity that issues certificates. Root CAs are self-signed; intermediate CAs are signed by root CAs and issue end-entity certificates.
Registration Authority (RA): Optional component that handles identity verification before the CA issues the certificate.
Certificate Revocation List (CRL): A list of revoked certificates published by the CA. Clients download and check it periodically.
Online Certificate Status Protocol (OCSP): A real-time protocol to check revocation status without downloading the full CRL. OCSP stapling allows the server to present a timestamped OCSP response during the TLS handshake, reducing load on the CA.
Digital Certificate Format: Defined by X.509 standard (RFC 5280). Fields include version, serial number, signature algorithm, issuer, validity period, subject, public key, extensions (e.g., Key Usage, Extended Key Usage, Subject Alternative Name).
Common Algorithms: Signature algorithms include RSA (2048-bit or higher), ECDSA (P-256, P-384), and DSA (deprecated). Hashing algorithms include SHA-256 (SHA-2 family). SHA-1 is deprecated due to collision attacks.
Wildcard Certificates: Cover a domain and all subdomains (e.g., *.example.com). Subject Alternative Name (SAN) certificates allow multiple domains in one certificate.
Self-Signed Certificates: Used internally or for testing; not trusted by default by external clients.
How Attackers Exploit PKI and Defenders Deploy It
Attack Vectors: - Rogue CA: An attacker compromises a CA or tricks it into issuing a fraudulent certificate. Example: the 2011 DigiNotar breach, where attackers issued fake Google certificates. Defenders respond by revoking the CA's trust (removing root certs from trust stores). - Certificate Spoofing: An attacker creates a certificate with the same subject name as a legitimate site but signed by a different (malicious) CA. Browsers will warn if the CA is not trusted. - Private Key Theft: If a server's private key is stolen, the attacker can decrypt traffic or impersonate the server. Defenders use Hardware Security Modules (HSMs) to protect private keys. - Man-in-the-Middle (MITM) with Fake CA: An attacker installs their own CA certificate on a victim's device (e.g., through malware) and then intercepts traffic using certificates signed by that rogue CA. This is common in corporate SSL inspection proxies. - Revocation Bypass: Attackers exploit clients that skip revocation checks (e.g., due to performance) or use expired CRLs.
Defensive Deployments: - HTTPS: Websites use TLS certificates to encrypt traffic. Browsers validate the certificate chain. - Code Signing: Developers sign software with a certificate to prove authenticity and integrity. Windows checks signatures before running drivers. - Email Signing and Encryption: S/MIME uses certificates to sign and encrypt emails. - Smart Card Authentication: Certificates stored on smart cards authenticate users to networks and systems. - VPN and 802.1X: Certificates authenticate devices and users in VPNs and wireless networks.
Real Command/Tool Examples
OpenSSL: Generate a private key and CSR:
openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csrView certificate details:
openssl x509 -in cert.pem -text -nooutCheck revocation via OCSP:
openssl ocsp -issuer ca.pem -cert cert.pem -url http://ocsp.example.comWindows: Use certmgr.msc to manage certificates, certutil for command-line operations.
Linux: Certificates stored in /etc/ssl/certs/, manage with update-ca-certificates.
Standards and RFCs
X.509 (RFC 5280): Certificate and CRL profile.
PKCS #10 (RFC 2986): Certification request syntax.
PKCS #12 (RFC 7292): Personal Information Exchange Syntax (stores private key and certificate).
OCSP (RFC 6960): Online Certificate Status Protocol.
CRL (RFC 5280): Certificate Revocation List.
CA/Browser Forum Baseline Requirements: Industry standards for CA operations.
Generate Key Pair and CSR
The server administrator generates a 2048-bit RSA key pair using OpenSSL or a similar tool. The private key is stored securely, often with file permissions 600. A Certificate Signing Request (CSR) is created, containing the public key and identifying information like Common Name (CN) = www.example.com, Organization (O), and Country (C). The CSR is signed with the private key to prove possession. The admin then submits the CSR to a CA. Logs: OpenSSL output shows 'writing new private key to server.key' and 'You are about to be asked to enter information...'.
CA Verifies Identity and Issues Certificate
The CA validates the requester's control over the domain (Domain Validation) by sending an email to admin@example.com or requiring a DNS TXT record. For Organization Validation, the CA checks business registration. Once verified, the CA creates an X.509 certificate with the public key, serial number, validity period (typically 1 year), and signs it with the CA's private key. The certificate is returned to the requester. Logs: CA system logs show 'Certificate issued for CN=www.example.com, serial=0x...'.
Install Certificate on Server
The admin installs the certificate file (e.g., server.crt) and the private key on the web server (e.g., Apache, Nginx, IIS). The certificate chain (intermediate and root) is also installed. Configuration files specify paths to the certificate and key. The server is restarted to enable HTTPS. Logs: Web server logs show 'AH01914: Configuring server to listen on port 443' and 'AH00094: Command line: '/usr/sbin/httpd -D SSL''.
Client Initiates TLS Handshake
A user's browser connects to https://www.example.com. The server sends its certificate (and intermediate certificates) during the TLS handshake. The browser receives the certificate and begins validation: checks the current date is within the validity period, verifies the signature using the CA's public key (pre-installed in the trust store), and checks revocation status via OCSP. If the certificate is valid, the browser proceeds with key exchange. Logs: Browser developer tools show 'Certificate is valid' or 'This certificate is trusted'.
Certificate Chain Validation
The browser builds a chain from the server's certificate to a trusted root CA. It checks that each certificate in the chain is signed by the next one. The root CA certificate is self-signed and must be in the browser's trust store. If an intermediate certificate is missing, the browser cannot validate the chain and shows an error. The browser also checks Key Usage and Extended Key Usage extensions (e.g., 'Server Authentication' must be present). Logs: OpenSSL s_client output shows 'verify return:1' for each certificate in the chain.
Secure Session Established
After successful validation, the browser generates a symmetric session key, encrypts it with the server's public key, and sends it to the server. The server decrypts with its private key. Both sides now use the symmetric key for encrypted communication (e.g., AES-256-GCM). The session is secure. Logs: Wireshark shows 'TLSv1.3 Handshake: Finished' and 'Application Data' encrypted packets.
Scenario 1: SSL/TLS Certificate Expiry Causes Outage
A large e-commerce site experiences a certificate expiry at 2 AM. Users see a browser warning: 'Your connection is not private' with error 'NET::ERR_CERT_DATE_INVALID'. The SOC receives alerts from monitoring tools (e.g., Nagios, PRTG) that the certificate expires in 0 days. The engineer checks with openssl s_client -connect example.com:443 and sees 'verify error:num=10:certificate has expired'. The correct response: immediately renew the certificate with the CA, install it, and verify. Common mistake: assuming the certificate auto-renews (it does not unless automated). The engineer should have set up monitoring with 30-day, 7-day, and 1-day alerts. Logs: Web server error logs show 'SSL: error:0A000086:SSL routines::certificate verify failed'.
Scenario 2: Man-in-the-Middle via Rogue CA on Corporate Network
A company uses an SSL inspection proxy to decrypt employee HTTPS traffic for security monitoring. The proxy installs its own CA certificate on all company devices. An attacker compromises the proxy and uses it to issue a fraudulent certificate for 'bank.com'. Employees visit bank.com and see no warning because the rogue CA is trusted. The SOC detects the attack when an employee reports a phishing-like page. The investigator checks the certificate details and sees the issuer is the corporate CA, not a legitimate bank CA. The correct response: revoke the compromised proxy's CA certificate from all devices, rebuild the proxy, and rotate keys. Common mistake: assuming the proxy is secure because it's internal, neglecting to protect its private key.
Scenario 3: OCSP Responder Failure Causes Performance Issues
A financial institution uses OCSP to verify certificate revocation in real-time. The OCSP responder goes down due to a DDoS attack. Clients attempting to connect to the bank's website experience delays because they wait for OCSP responses. Some browsers fail open (allow connection) while others fail closed (block). The SOC sees increased latency and failed connections. The engineer checks OCSP responder logs and sees '503 Service Unavailable'. The correct response: implement OCSP stapling on the server, which caches OCSP responses and presents them during the handshake, reducing reliance on the responder. Common mistake: relying solely on OCSP without a fallback to CRL or stapling.
What SY0-701 Tests on This Objective
Objective 1.4 covers 'Explain the importance of using appropriate cryptographic solutions.' PKI and digital certificates are a major sub-topic. The exam expects you to:
Understand the purpose of PKI (binding public keys to identities).
Know the components: CA, RA, CRL, OCSP, certificate chain.
Identify types of certificates: wildcard, SAN, self-signed, code signing, email (S/MIME).
Understand revocation mechanisms (CRL vs. OCSP) and when to use each.
Recognize the role of certificates in HTTPS, code signing, and smart cards.
Know the X.509 standard and common fields (subject, issuer, validity, serial number).
Common Wrong Answers and Why Candidates Choose Them
'A self-signed certificate is more secure than a CA-signed certificate.' Candidates think self-signed avoids CA costs, but self-signed offers no third-party validation; it's vulnerable to MITM unless distributed securely.
'OCSP is more secure than CRL because it is real-time.' While OCSP is more current, it has privacy issues (the CA learns which sites you visit) and can be blocked. Both are revocation methods; security depends on implementation.
'The private key is included in the certificate.' Certificates contain only the public key. The private key is kept separate and secret.
'Wildcard certificates can be used for multiple unrelated domains.' Wildcards cover only one domain and its subdomains (e.g., *.example.com). For multiple domains, use a SAN certificate.
Specific Terms, Values, and Acronyms
X.509: The standard for digital certificates.
PKCS #12: File format for storing private key and certificate together (password-protected).
OCSP stapling: Server presents a timestamped OCSP response during TLS handshake (RFC 6066).
CRL: List of revoked certificates; downloaded periodically.
CA/Browser Forum: Sets rules for CA operations.
Key lengths: RSA 2048-bit minimum; ECDSA P-256 recommended.
Hashing: SHA-256 (SHA-2) is required; SHA-1 is deprecated.
Common Trick Questions
'Which of the following is used to validate a digital certificate?' Answer: The CA's public key (not the subject's public key).
'What is the purpose of a CRL?' Answer: To list revoked certificates (not expired ones; expiry is checked via validity period).
'Which protocol allows real-time revocation checking?' Answer: OCSP (not CRL, which is batch).
Decision Rule for Eliminating Wrong Answers
When a question asks about PKI, first identify the core need: authentication, encryption, or non-repudiation. Then look for the component that directly provides that. For revocation questions: if the scenario involves real-time checking, choose OCSP; if batch updates, choose CRL. For certificate types: if multiple domains, SAN; if one domain and subdomains, wildcard. If a choice says 'self-signed' for external use, eliminate it unless the scenario explicitly mentions internal or testing.
PKI binds a public key to an identity using a trusted third-party Certificate Authority (CA).
Digital certificates follow the X.509 standard and contain the subject's public key, identity, validity period, and CA signature.
Certificate revocation is checked via CRL (batch) or OCSP (real-time).
A certificate chain consists of end-entity, intermediate, and root CA certificates.
Self-signed certificates are not trusted by default; they are used internally or for testing.
Wildcard certificates cover a domain and all subdomains (e.g., *.example.com).
SAN certificates support multiple domain names in a single certificate.
Private keys must be protected; HSMs provide hardware-level security.
SHA-1 is deprecated; use SHA-256 or higher for signatures.
OCSP stapling improves performance and privacy by having the server present a cached OCSP response.
These come up on the exam all the time. Here's how to tell them apart.
Certificate Revocation List (CRL)
List of revoked certificates published by CA
Downloaded and cached by clients periodically
No privacy concerns (client downloads list)
Can be large, causing bandwidth issues
Not real-time; depends on update frequency
Online Certificate Status Protocol (OCSP)
Real-time status check per certificate
Client sends OCSP request to responder
Privacy issue: CA learns which sites client visits
Smaller response per query
Requires OCSP responder to be available
Mistake
A digital certificate contains the private key of the subject.
Correct
A digital certificate contains only the public key and identity information. The private key is stored separately and must never be shared.
Mistake
Self-signed certificates are as trustworthy as CA-issued certificates.
Correct
Self-signed certificates provide no third-party validation; they are only suitable for internal testing. For production, a CA-signed certificate is needed to establish trust with external parties.
Mistake
OCSP is always better than CRL for revocation checking.
Correct
OCSP provides real-time status but has privacy and availability drawbacks. CRL is simpler and can be cached. The best choice depends on the environment.
Mistake
A wildcard certificate can secure multiple different domain names.
Correct
A wildcard certificate covers only one domain and all its subdomains (e.g., *.example.com). It cannot cover example.org or other unrelated domains.
Mistake
Certificate revocation is immediate once a CA revokes a certificate.
Correct
Revocation is not immediate; it depends on how quickly the CRL is updated or OCSP responder is refreshed. Clients may use cached data, leading to a window of vulnerability.
A root CA is the top-level CA that is self-signed and trusted by clients. An intermediate CA is signed by the root CA and issues end-entity certificates. Using intermediates allows the root CA's private key to be kept offline, reducing risk. On the exam, remember that the chain of trust starts at the root CA and goes through intermediates to the end-entity certificate.
In OCSP stapling, the web server periodically obtains a timestamped OCSP response from the CA and caches it. During the TLS handshake, the server includes ('staples') this response along with its certificate. The client verifies the stapled response instead of contacting the OCSP responder directly. This reduces load on the CA and improves privacy. On the exam, know that OCSP stapling is a performance and privacy enhancement.
A certificate chain is a sequence of certificates from the end-entity certificate up to a trusted root CA. Each certificate in the chain (except the root) is signed by the next one. The client validates the chain by checking each signature. If any link is missing or invalid, the chain is broken and trust fails. On the exam, you may be asked to identify the correct order of certificates in a chain.
The SAN extension allows a certificate to specify multiple domain names, IP addresses, or other identifiers that it is valid for. For example, a SAN certificate can secure both 'example.com' and 'www.example.com'. Without SAN, a certificate is valid only for the Common Name (CN). On the exam, SAN is the correct answer when a question involves multiple domains in one certificate.
The browser checks: (1) the current date is within the validity period, (2) the certificate is signed by a trusted CA (using the CA's public key), (3) the certificate has not been revoked (via CRL or OCSP), (4) the domain name matches the certificate's CN or SAN, and (5) the certificate chain is complete. If any check fails, the browser shows a warning. On the exam, remember that the signature is verified using the CA's public key, not the subject's.
A wildcard certificate is valid for a domain and all its subdomains (e.g., *.example.com covers www.example.com, mail.example.com). Limitations: it cannot cover multiple top-level domains (e.g., example.org), it does not cover the bare domain (example.com without www) unless explicitly added, and it is less secure because compromising the private key exposes all subdomains. On the exam, wildcard is appropriate for securing multiple subdomains of a single domain.
DV certificates only verify control over a domain (e.g., via email or DNS). EV certificates require a rigorous identity verification process, including legal entity checks. EV certificates display the organization name in the browser address bar (green bar). On the exam, EV provides the highest level of trust for e-commerce sites.
You've just covered PKI and Digital Certificates — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?