Question 1: A server administrator generates a new key pair and submits a Certificate Signing Request to a public CA. What does the CSR contain?
Correct answer: B. A CSR contains the server's PUBLIC key and identity claims (domain name, SANs, organization). It is signed with the server's private key to prove possession of the key pair — but the private key itself is never included in or sent with the CSR. The private key never leaves the server. The CA signs the public key + identity information to create the certificate.
Question 2: An organization's web server private key was compromised in a breach. The certificate has 6 months remaining on its validity period. What action is required to prevent attackers from using the stolen key?
Correct answer: C. Certificate revocation is the correct response to a compromised private key. Revocation tells CAs and browsers (via CRL/OCSP) that the old certificate should no longer be trusted — even though it hasn't expired. Without revocation, an attacker with the stolen private key could impersonate the server for the full remaining 6 months. A new key pair must be generated (the old keys are compromised) before requesting a new certificate.
Question 3: Which revocation method does a server use when it pre-fetches its own certificate status from the CA and includes the signed response in the TLS handshake?
Correct answer: C. OCSP Stapling — the server itself queries the CA's OCSP responder and staples the signed, timestamped response to its TLS handshake. The client receives both the certificate and its revocation status in one step — no extra round-trip, no privacy leak, and resilience against OCSP responder outages. This is the key distinction from standard OCSP (B), where the CLIENT makes the query.
Question 4: A company has 30 subdomains (api.company.com, www.company.com, mobile.company.com, etc.) but also needs to cover staging.api.company.com. Which certificate type handles this requirement?
Correct answer: B. A wildcard certificate (*.company.com) only covers ONE subdomain level — it covers api.company.com and mobile.company.com, but NOT staging.api.company.com (which is two levels below company.com). To cover sub-sub-domains, a SAN certificate must explicitly list each domain name. The SAN cert can include *.company.com AND staging.api.company.com AND any other specific names needed.
Question 5: Why do CAs use intermediate CA certificates instead of having the Root CA directly sign server certificates?
Correct answer: B. Defense in depth. Root CAs are extremely valuable — their private keys are stored in HSMs in secured facilities and are used rarely. Intermediate CAs are operationally active and do the day-to-day signing. If an Intermediate CA is compromised (its key stolen, CA misbehaves), the Root CA can revoke the Intermediate CA certificate. All certificates issued by that intermediate become untrusted. The Root CA remains secure and uncompromised, and a new Intermediate CA can be spun up.
Matching: Certificate Concepts
Match each term to its correct description.
TERM
X.509
CSR
OCSP Stapling
Wildcard Certificate
DESCRIPTION
Standard format for digital certificates used in TLS/SSL
Request submitted to a CA containing public key and identity claims — private key never included
Server pre-fetches its OCSP status and includes it in the TLS handshake
Certificate covering all subdomains at one level (*.example.com) but not sub-sub-domains
Performance Task
A large e-commerce company discovers that their TLS private key was exposed in a server breach. They have 12 web servers, each with its own certificate (all issued by the same CA). Their security team must respond within 4 hours. Design the complete incident response procedure for the certificate compromise.
Model Answer:
Immediate actions (first 30 minutes):
1. Contain the breach — isolate the compromised server(s) from the network to prevent further key extraction.
2. Notify the incident response team and management — this is a Severity 1 incident requiring immediate escalation.
3. Document the scope: which servers, which certificates, when was the key potentially exposed, what time window of traffic may be at risk.
Certificate revocation (hours 1-2):
4. Contact the CA's revocation team or use the CA portal to revoke all potentially compromised certificates immediately. Provide the certificate serial numbers.
5. Verify revocation propagation — check OCSP responders return "Revoked" for the old certificates. Check CRL is updated.
6. Communicate to the security team that revocation is in progress — do not wait for revocation to complete before starting key regeneration.
New key pair and certificate generation (hours 2-3):
7. On each server: generate a new RSA 3072-bit or ECDSA P-256 key pair. Each server gets its own unique key pair.
8. Generate CSRs for each server with the appropriate domain names and SANs.
9. Submit CSRs to the CA — for most public CAs, DV certificate reissuance can occur within minutes to an hour.
10. Install new certificates and private keys on each server. Restart the TLS service on each server.
Post-replacement verification (hour 3-4):
11. Verify each server's new certificate: confirm the new cert is in use, check SANs are correct, confirm chain of trust is valid.
12. Confirm old certificates return "Revoked" in OCSP checks — verify revocation is in effect.
13. Check for any cached sessions or session tickets tied to old keys — consider forcing new TLS sessions by rotating session ticket keys.
Follow-up actions:
14. Rotate any secrets that may have been in server memory (API keys, database passwords, session tokens) — the breach may have exposed more than just TLS keys.
15. Determine whether traffic recorded before the breach (if captured) could be decrypted. If forward secrecy was NOT in use, assume past traffic may be compromised. Rotate all user session tokens and force re-login.
16. Review and improve: implement certificate pinning or Certificate Transparency monitoring. Improve key protection (consider HSM-backed key storage). Conduct post-incident review.
Immediate actions (first 30 minutes):
1. Contain the breach — isolate the compromised server(s) from the network to prevent further key extraction.
2. Notify the incident response team and management — this is a Severity 1 incident requiring immediate escalation.
3. Document the scope: which servers, which certificates, when was the key potentially exposed, what time window of traffic may be at risk.
Certificate revocation (hours 1-2):
4. Contact the CA's revocation team or use the CA portal to revoke all potentially compromised certificates immediately. Provide the certificate serial numbers.
5. Verify revocation propagation — check OCSP responders return "Revoked" for the old certificates. Check CRL is updated.
6. Communicate to the security team that revocation is in progress — do not wait for revocation to complete before starting key regeneration.
New key pair and certificate generation (hours 2-3):
7. On each server: generate a new RSA 3072-bit or ECDSA P-256 key pair. Each server gets its own unique key pair.
8. Generate CSRs for each server with the appropriate domain names and SANs.
9. Submit CSRs to the CA — for most public CAs, DV certificate reissuance can occur within minutes to an hour.
10. Install new certificates and private keys on each server. Restart the TLS service on each server.
Post-replacement verification (hour 3-4):
11. Verify each server's new certificate: confirm the new cert is in use, check SANs are correct, confirm chain of trust is valid.
12. Confirm old certificates return "Revoked" in OCSP checks — verify revocation is in effect.
13. Check for any cached sessions or session tickets tied to old keys — consider forcing new TLS sessions by rotating session ticket keys.
Follow-up actions:
14. Rotate any secrets that may have been in server memory (API keys, database passwords, session tokens) — the breach may have exposed more than just TLS keys.
15. Determine whether traffic recorded before the breach (if captured) could be decrypted. If forward secrecy was NOT in use, assume past traffic may be compromised. Rotate all user session tokens and force re-login.
16. Review and improve: implement certificate pinning or Certificate Transparency monitoring. Improve key protection (consider HSM-backed key storage). Conduct post-incident review.