312-50 Question 460
Single answer▪ Public Key Infrastructure (PKI)During an internal assessment, you intercept HTTPS traffic from a corporate web application after importing the organization’s internal root CA certificate into your test workstation. The browser still displays a certificate warning stating that the server certificate is not valid for the site you are visiting. Inspection shows the certificate chain is trusted and the certificate has not expired. The application is accessed as https://portal.finance.corp, but the server certificate was issued to CN=fileserver.corp and contains no Subject Alternative Name (SAN) entry for portal.finance.corp. Which issue best explains the warning?
- A
The certificate is chained to an internal CA instead of a public CA, so modern browsers will reject it
- B
The server certificate’s subject identity does not match the hostname being accessed
- C
The certificate should use the same public/private key pair as the issuing CA to be considered valid
- D
The warning occurs because the certificate lacks a CRL Distribution Point, which browsers require before trusting any certificate
Show answer and explanation
Correct answer: B
Explanation
This question tests practical PKI validation in a real HTTPS assessment scenario. A certificate can be signed by a trusted CA and still be rejected if the certificate identity does not match the requested hostname. In modern PKI and browser validation, the Subject Alternative Name extension is the primary source for DNS name matching; relying only on the Common Name is deprecated. This is aligned with X.509/TLS validation practices and reflected in industry guidance such as RFC 6125 for service identity verification and CA/Browser ecosystem best practices. For CEH candidates, the key takeaway is that certificate trust involves multiple checks: trust chain, validity period, revocation status, intended usage, and hostname matching. A failure in any one of these can produce a warning even when the certificate appears otherwise valid.
- A. Incorrect.
Incorrect. Browsers can trust certificates issued by an internal/private CA if the root CA certificate is installed in the trusted root store. An internal CA is common in enterprise PKI deployments. The problem in the scenario is not the CA type, because the chain is already trusted.
- B. Correct.
Correct. TLS certificate validation includes hostname verification. If the user browses to portal.finance.corp, the certificate must include that exact DNS name in the SAN extension, or in older compatibility cases match the subject CN. Because the certificate is issued to fileserver.corp and does not include portal.finance.corp in SAN, the browser correctly warns about a name mismatch.
- C. Incorrect.
Incorrect. A subordinate or end-entity certificate must have its own key pair. Reusing the CA’s private key for server certificates would be a severe PKI design and security failure. Certificate validity is based on proper issuance, signature verification, trust chain, validity period, and identity matching, not key reuse with the CA.
- D. Incorrect.
Incorrect. Revocation information such as CRL Distribution Points or OCSP URLs is important for checking certificate status, but the absence of a CRL DP does not specifically explain a hostname mismatch warning. Browsers typically distinguish identity errors from revocation checking issues. In this scenario, the trust chain and expiration are fine; the subject name mismatch is the direct cause.