PKI and certificate PBQs test your ability to troubleshoot TLS/SSL problems, understand certificate chains, and identify why secure connections fail. This guide teaches you the systematic approach to diagnosing certificate issues.
Interactive simulation — no account required
PKI (Public Key Infrastructure) PBQs present you with certificate information, error messages, or PKI architecture and ask you to identify problems or select the correct certificate for a scenario. You're essentially troubleshooting why a secure connection is failing or designing a certificate hierarchy.
These questions test whether you understand how certificates actually work—validation chains, expiration, revocation, key usage, and trust relationships. You might be asked to:
A certificate is only trusted if every certificate in its chain—from the server certificate up to a trusted root CA—is valid, unexpired, unrevoked, and present. One broken link anywhere in the chain causes the entire connection to fail.
When presented with a certificate problem, work through these checks in order:
The exam tests whether you can match the right certificate to the right scenario:
Verifies domain ownership only. Fast to issue, lowest assurance level. Used for basic website encryption.
Use case: Blog, small business website, internal toolsVerifies domain ownership plus organization identity. Moderate assurance level.
Use case: Corporate websites, business applicationsRigorous verification of organization identity. Highest assurance level. Shows organization name in browser.
Use case: Banking, e-commerce, financial servicesCovers a domain and all subdomains at one level (*.example.com covers www, mail, api).
Use case: Multiple subdomains on same serverSingle certificate covering multiple distinct domains listed in Subject Alternative Names.
Use case: example.com, example.net, example.org on one serverValidates software publisher identity. Used to sign executables, scripts, drivers.
Use case: Software distribution, driver signingA user reports they can't access https://portal.company.com and see a certificate warning. Here's what the certificate shows:
Issued by Company Internal CA
Current date: Jan 27, 2026 — Certificate expired 12 days ago
User accessing portal.company.com — not listed in SAN
Issue 1: Certificate expired. The "Valid To" date is January 15, 2026, but the current date is January 27, 2026. The certificate is 12 days expired and will be rejected by all browsers.
Issue 2: Name mismatch. The user is accessing portal.company.com, but the certificate's Subject Alternative Names only lists www.company.com. The browser will show a "certificate name mismatch" error.
Issue 3: Incomplete chain. The intermediate CA certificate is missing from the chain. Even if the other issues were fixed, the browser can't build a trust path to the root CA.
Resolution: The organization needs to: (1) Renew the certificate immediately, (2) Include portal.company.com in the SAN or use a wildcard certificate (*.company.com), and (3) Configure the server to send the complete certificate chain including the intermediate CA.
A certificate chain (or chain of trust) connects your server certificate to a trusted root certificate authority. Here's how it works:
Root CA — The ultimate trust anchor. Root CA certificates are pre-installed in browsers and operating systems. Organizations like DigiCert, Let's Encrypt, and Comodo operate root CAs. Root certificates are self-signed.
Intermediate CA — Issues certificates on behalf of the root CA. This protects the root—if an intermediate is compromised, only its certificates are affected, and it can be revoked without replacing the root.
Server/End-Entity Certificate — The certificate installed on your web server. It's signed by an intermediate CA (or sometimes directly by a root for internal CAs).
Validation process: When a browser connects, the server sends its certificate plus any intermediate certificates. The browser builds a chain from the server cert up to a root it trusts. If any link is missing, expired, or revoked, validation fails.
A common misconfiguration is failing to include intermediate certificates. The server certificate alone isn't enough—the browser needs the full chain.
Know what each error message indicates:
When analyzing a certificate in a PBQ, focus on these key fields:
Subject — Who the certificate identifies. For server certs, this includes the CN (Common Name) which should match the domain.
Issuer — The CA that signed the certificate. Should chain to a trusted root.
Valid From / Valid To — The certificate's validity period. Most public certificates are valid for 1 year (some CAs now limit to 90 days).
Subject Alternative Name (SAN) — Additional domains covered by the certificate. Modern certificates rely heavily on SANs rather than just the CN.
Key Usage / Extended Key Usage — What the certificate can be used for: Server Authentication, Client Authentication, Code Signing, Email Protection, etc.
CRL Distribution Points — Where to check if the certificate has been revoked.
Serial Number — Unique identifier for the certificate, used in revocation checking.
A PKI (Public Key Infrastructure) PBQ presents you with certificate information, error messages, or PKI scenarios and asks you to identify problems or select the correct solution. You might troubleshoot why a TLS connection fails, select the right certificate type for a use case, or identify what's wrong with a certificate chain.
A certificate chain is the sequence of certificates from your server certificate to a trusted root CA. The server cert is signed by an intermediate CA, which is signed by the root CA. Browsers validate this entire chain—if any certificate is missing, expired, or revoked, the connection fails.
A wildcard certificate (*.example.com) covers all subdomains at one level—www.example.com, mail.example.com, api.example.com. A SAN (Subject Alternative Name) certificate lists specific different domains that may be completely unrelated—example.com, example.net, different-company.com.
Certificate expiration limits the damage from compromised keys and ensures organizations periodically reverify their identity. Shorter validity periods (now typically 1 year or less) mean stolen certificates become useless faster and cryptographic best practices can be updated more frequently.
Apply these concepts with an interactive PKI & Certificates simulation.