SY0-701 Question 36
Single answerA company is rolling out mutual TLS for a customer-facing payment API. During a security review, the team identifies two requirements: the API's server private key must be generated and stored so administrators cannot export it in plaintext, and clients must be able to check in near real time whether the server certificate has been revoked without downloading an entire revocation list. Which solution best meets BOTH requirements?
- A
Use a self-signed certificate for the API server and publish a certificate revocation list (CRL) on the web server
- B
Generate the server key pair in a hardware security module (HSM) and configure clients to use OCSP to validate certificate status
- C
Store the server private key in key escrow and configure clients to trust the certificate indefinitely
- D
Generate the certificate on the server's TPM and require clients to verify revocation by comparing certificate serial numbers manually
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use an HSM for server private key generation and storage, combined with OCSP for revocation checking. In PKI, the private key must be strongly protected because compromise of that key undermines confidentiality, authentication, and trust. HSMs are purpose-built devices that perform cryptographic operations and protect keys against extraction, making them a common choice for web servers, payment systems, and certificate authorities. OCSP is designed to let a client check the status of an individual certificate in real time or near real time, which is more efficient than downloading a full CRL. By contrast, self-signed certificates are generally unsuitable for public-facing payment services because they lack trust from a recognized third party. TPMs are useful for endpoint and platform-bound keys, but they are not typically the best answer when the scenario emphasizes high-assurance server key custody for an enterprise or public service. These practices align with common PKI guidance such as NIST recommendations on key management and industry use of HSM-backed key storage for sensitive TLS deployments.
- A. Incorrect.
This is incorrect because a self-signed certificate does not provide the third-party trust model typically required for a public customer-facing payment API. While CRLs are a valid PKI revocation mechanism, the scenario specifically requires near real-time revocation checking without forcing clients to download a full list. CRLs can become large and are generally less efficient than Online Certificate Status Protocol (OCSP) for this use case.
- B. Correct.
This is correct. An HSM is specifically designed to generate, store, and use private keys in tamper-resistant hardware, helping prevent plaintext export of the server private key. OCSP allows clients to query the revocation status of a specific certificate in near real time, which satisfies the requirement to avoid downloading an entire CRL. This combination addresses both key protection and efficient revocation checking for a production PKI deployment.
- C. Incorrect.
This is incorrect because key escrow is used to retain access to certain keys under controlled conditions, often for recovery or legal requirements, but it does not by itself protect a live server private key from administrator export in the way an HSM does. The second part is also wrong because clients should not trust certificates indefinitely; certificate status must still be validated through mechanisms such as OCSP or CRLs.
- D. Incorrect.
This is incorrect because a TPM can protect keys on a specific host and is commonly used for platform integrity and device-bound key storage, but for a customer-facing payment API, an HSM is the more appropriate and standard control for centralized, high-assurance server key generation and protection. Manual serial-number comparison is not a practical or valid revocation-checking process for clients and does not meet PKI best practices.