SY0-701 Question 49
Single answerA company is deploying HTTPS for dozens of internally managed web applications hosted on subdomains of corp.example.com. To speed deployment, an administrator generated a certificate signing request (CSR) for *.corp.example.com and submitted it to a public certificate authority (CA). After the CA issued the certificate, some users began receiving browser warnings that the certificate could not be trusted. Investigation shows the web servers present the new wildcard certificate correctly, but several client systems do not trust the issuing CA. Which of the following is the BEST explanation for the warnings?
- A
The clients are missing the appropriate root or intermediate CA certificates in their trust store, so the chain of trust cannot be validated.
- B
Wildcard certificates cannot be used for HTTPS on internal applications, so browsers reject them by default.
- C
The CSR should have contained each individual hostname instead of a wildcard, because CAs do not sign wildcard CSRs.
- D
The certificate has been automatically revoked because all wildcard certificates are placed on a CRL after issuance.
Show answer and explanation
Correct answer: A
Explanation
The best answer is that the client systems do not have the necessary CA trust anchors or intermediate certificates to validate the server certificate chain. In public key infrastructure, the client must be able to build a path from the presented server certificate through any intermediate CA certificates to a trusted root CA in the local trust store. That trusted root serves as the root of trust. A CSR is simply the request generated by the certificate applicant and submitted to the CA; it does not by itself establish trust on client devices. Wildcard certificates are valid and widely used for securing multiple subdomains, but they must still chain to a trusted CA. CRLs are relevant only if a certificate has actually been revoked, not just because it is a wildcard. This aligns with standard PKI validation practices described in vendor and industry documentation such as CA/browser trust models, X.509 certificate path validation guidance, and browser certificate chain requirements.
- A. Correct.
Correct. Certificate validation depends on a chain of trust from the server certificate back to a trusted root of trust on the client. If the client does not have the required trusted root CA certificate, or cannot build the chain through the necessary intermediate CA certificates, it will warn that the certificate is untrusted even when the server is presenting a valid wildcard certificate. This is a common issue when using a CA that is not already trusted on all managed or legacy systems.
- B. Incorrect.
Incorrect. Wildcard certificates are commonly used for HTTPS and are valid for matching first-level subdomains such as app1.corp.example.com and portal.corp.example.com. Browsers do not reject certificates simply because they are wildcard certificates. The real issue in this scenario is trust of the issuing CA, not the wildcard format itself.
- C. Incorrect.
Incorrect. A CSR can request a wildcard certificate, and many commercial and public CAs can issue wildcard certificates after validation. While a certificate can also include specific hostnames through subject alternative names, the inability of clients to trust the certificate is not caused by using a wildcard in the CSR.
- D. Incorrect.
Incorrect. A certificate is not added to a certificate revocation list merely because it is a wildcard certificate. CRLs are used by CAs to publish certificates that have been revoked before expiration, such as after key compromise or improper issuance. Revocation would generally affect all clients that check revocation status, but there is nothing inherent about wildcard issuance that triggers revocation.