N10-009 Question 13
Single answerLayer 6 - PresentationA company has deployed a new web application over HTTPS. Users can reach the server and complete the TCP three-way handshake, but some clients receive certificate warnings and fail to establish a secure session. Packet captures show the TLS handshake starts, but negotiation stops when the client cannot validate the server certificate. Which action is the BEST way to resolve this Layer 6 presentation issue?
- A
Install the missing intermediate/root CA certificates in the clients' trust store or configure the server to present the full certificate chain
- B
Replace the Ethernet cables between the client and the access switch to reduce packet corruption during the TLS handshake
- C
Change the server's default gateway so the encrypted traffic takes a shorter path to the clients
- D
Disable DNS caching on the client so the browser can resolve the server name more accurately during certificate negotiation
Show answer and explanation
Correct answer: A
Explanation
This scenario targets Layer 6 (Presentation), which in the OSI model handles translation, encryption/decryption, and data representation. In modern network troubleshooting, SSL/TLS is commonly associated with Presentation-layer functions because it manages certificate-based encryption and session data formatting for secure application exchanges. When clients cannot validate a server certificate, administrators should verify that the server presents the full certificate chain and that clients trust the issuing root/intermediate CAs. This aligns with common PKI and TLS deployment best practices documented by browser vendors, public CA guidance, and server platform documentation such as Microsoft IIS, Apache HTTP Server, and NGINX TLS configuration guides. The other options focus on lower-layer or unrelated issues and do not address the certificate trust problem described.
- A. Correct.
Correct. The Presentation layer is responsible for data formatting, encryption, and translation functions, including SSL/TLS certificate handling in practical Network+ context. If the TLS handshake fails because the client cannot validate the server certificate, the most likely fix is to ensure the client trusts the issuing CA and that the server sends the complete certificate chain, including any required intermediate certificates. This is a common real-world issue with HTTPS deployments.
- B. Incorrect.
Incorrect. Faulty Ethernet cabling would more likely cause link errors, retransmissions, CRC errors, or complete connectivity instability rather than a specific certificate validation failure during the TLS handshake. The scenario states that clients reach the server and start TLS negotiation, which makes a physical-layer fault unlikely as the root cause.
- C. Incorrect.
Incorrect. The default gateway affects Layer 3 routing, not certificate validation. A routing issue could prevent connectivity altogether or cause asymmetric paths, but it would not cause a client to reject a certificate because the issuing CA is untrusted or the certificate chain is incomplete.
- D. Incorrect.
Incorrect. DNS resolution problems can cause users to connect to the wrong host or produce hostname mismatch symptoms in some cases, but the scenario specifically says negotiation stops when the client cannot validate the server certificate. Disabling DNS caching does not address missing CA trust or an incomplete certificate chain.