A client has accessed an HTTPS server at myhost1.example.com using Chrome. The server sends a certificate that includes these properties: Subject name: myhost.example.com SAN: DNS…

Question

Options

• AThe client does not have the correct trusted CA certificates.
• BThe certificate lacks a valid SAN.
• CThe certificate lacks the correct EKU.
• DThe certificate lacks a valid SAN, and the client does not have the correct trusted CA certificates.

• A
  83% (33)
• B
  3% (1)
• C
  10% (4)
• D
  5% (2)

Explanation

This question is identical to Question 17, with the same certificate properties and scenario. The client (Chrome browser) accesses an HTTPS server at myhost1.example.com, and the server presents a certificate with: Subject name: myhost.example.com SAN: DNS: myhost.example.com; DNS: myhost1.example.com EKU: Server authentication Issuer: MyCA_Signing (intermediate CA) The intermediate CA certificate (MyCA_Signing) is signed by MyCA (root CA). The client's Trusted CA Certificate list does not include MyCA or MyCA_Signing. The certificate validation process is the same as in Question 17: Name Validation: The SAN includes "myhost1.example.com," which matches the server's hostname, so this passes. EKU Validation: The EKU is "Server authentication," which is correct for HTTPS, so this passes. Chain of Trust Validation: The client attempts to build a chain from the server's certificate to a trusted root CA: Server certificate MyCA_Signing MyCA Since MyCA is not in the client's Trusted CA Certificate list, the chain cannot be validated, and the client does not trust the certificate.

No community discussion yet for this question.