SY0-701 Question 50
Single answerA company is deploying a new public-facing web platform with servers named app1.example.com, app2.example.com, and api.example.com. The security administrator wants to reduce certificate management overhead by using one certificate across these hosts. During testing, some client systems reject the certificate chain after an intermediate CA key compromise was announced. The administrator must both request the correct certificate type for the web hosts and verify whether the presented server certificate should still be trusted. Which action BEST meets these requirements?
- A
Generate a CSR for a wildcard certificate for *.example.com and check the certificate's revocation status against the CA's CRL before trusting it
- B
Generate a self-signed root certificate on each web server and compare the server certificate serial number to the local hosts file
- C
Generate a CSR for a code-signing certificate for example.com and trust it if the server presents the full certificate chain
- D
Generate a CSR for a wildcard certificate for ..example.com and trust it as long as the certificate was issued by any intermediate CA
Show answer and explanation
Correct answer: A
Explanation
This question tests practical PKI decision-making. In a real deployment, the administrator would generate a certificate signing request (CSR) containing the appropriate subject information and submit it to a certificate authority (CA). For hosts like app1.example.com, app2.example.com, and api.example.com, a wildcard certificate for *.example.com is commonly used to simplify management across single-level subdomains. However, wildcard certificates do not generally cover the base domain example.com itself or deeper nested names such as dev.api.example.com unless explicitly included through SAN entries or separate certificates.
The trust decision depends on the certificate chain terminating at a trusted root of trust in the client's trust store. If an intermediate CA is compromised, clients and administrators should verify revocation status. One standard method is checking the certificate revocation list (CRL) published by the CA; another is OCSP. A valid chain alone is not sufficient if a certificate in that chain has been revoked. These practices align with common PKI guidance from sources such as NIST SP 800-57 for key management concepts and NIST SP 800-52 for TLS certificate deployment and validation considerations.
- A. Correct.
Correct. A wildcard certificate for *.example.com can cover single-level subdomains such as app1.example.com, app2.example.com, and api.example.com, which reduces certificate administration in this scenario. The proper way to obtain it is to generate a CSR and submit it to a trusted CA. Because an intermediate CA compromise was announced, the administrator should verify whether the server certificate has been revoked, commonly by consulting the CA's CRL or another revocation mechanism such as OCSP. Trust depends on a valid chain to a trusted root of trust and confirmation that none of the certificates in the chain have been revoked.
- B. Incorrect.
Incorrect. Creating a self-signed root certificate on each web server would break the public trust model because clients would not inherently trust those certificates unless the self-signed root was manually installed as a trust anchor on every client. The hosts file has nothing to do with certificate revocation or certificate validation. This option reflects a misunderstanding of root of trust and certificate status checking.
- C. Incorrect.
Incorrect. A code-signing certificate is intended for signing software or scripts, not for authenticating TLS web servers. Presenting the full certificate chain is important for validation, but it does not prove the certificate is appropriate for server authentication or that it has not been revoked. This distractor targets the misconception that any certificate issued by a CA can be used for any purpose.
- D. Incorrect.
Incorrect. Standard wildcard certificates typically cover only one label level, such as *.example.com, not multiple nested levels like ..example.com. Also, trust should not be granted merely because any intermediate CA issued the certificate. The intermediate must chain back to a trusted root of trust, and revocation status must be considered, especially after an intermediate CA compromise. This option combines two common mistakes: overestimating wildcard scope and misunderstanding CA trust.