Identify TLS Connection Errors F5N4 Practice Questions (Page 1)

Questions 1–5

1. 1application · medium

   A user reports that they cannot access an internal application through NGINX. The error log shows: 'SSL_do_handshake() failed (SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed)'. The server uses a self-signed certificate. What is the most likely cause of this error?

   • AThe server's hostname does not match the certificate's Subject Alternative Name.
   • BThe server is configured with a cipher suite that the client does not support.
   • CThe server's certificate has expired, and the client is rejecting it.
   • DThe client does not trust the self-signed certificate because it is not in the client's trust store.
   Reveal Solution Discussion Select an answer first
2. 2expert · hard

   An NGINX server is configured with a certificate that is valid for the hostname 'api.example.com'. A client accesses the server using the IP address '192.0.2.10' and receives the error: 'SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed'. The certificate is trusted by the client. What is the most likely cause?

   • AThe server's certificate has expired, and the client is rejecting it.
   • BThe server is not sending the intermediate certificate, causing a chain verification failure.
   • CThe client does not trust the CA that issued the certificate.
   • DThe certificate's Subject Alternative Name does not include the IP address, causing a hostname mismatch.
   Reveal Solution Discussion Select an answer first
4. 3application · medium

   An NGINX server is configured with a certificate from an internal CA. External clients receive the error: 'SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed'. Internal clients on the corporate network connect without issue. What is the most likely cause?

   • AThe server's hostname does not match the certificate's Common Name.
   • BThe server's certificate has expired, and only internal clients have cached the old certificate.
   • CExternal clients do not trust the internal CA that issued the server certificate.
   • DThe server is configured with a cipher suite that external clients do not support.
   Reveal Solution Discussion Select an answer first
5. 4expert · hard

   A client reports intermittent TLS handshake failures with an NGINX server. The error log shows: 'SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure)'. The server is configured with ssl_protocols TLSv1.2 TLSv1.3; and ssl_ciphers HIGH:!aNULL:!MD5;. The client is a modern browser. You suspect the issue is related to the client's cipher suite preferences. Which NGINX directive should you use to log the client's offered cipher suites?

   • ASet error_log to debug level to capture detailed handshake information.
   • BEnable ssl_session_cache to improve handshake performance.
   • CUse ssl_ciphers to add more cipher suites to the server's list.
   • DConfigure ssl_verify_client optional to allow the handshake to proceed without client certificates.
   Reveal Solution Discussion Select an answer first
6. 5application · medium

   A client reports a TLS handshake failure. The NGINX error log shows: 'SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure)'. The server is configured with ssl_protocols TLSv1.2 TLSv1.3; and ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;. The client is a modern browser that supports TLSv1.2 and TLSv1.3. What is the most likely cause?

   • AThe server's ssl_protocols directive is misconfigured and does not include TLSv1.2.
   • BThe client and server cannot agree on a common cipher suite.
   • CThe client's clock is skewed, causing the certificate validation to fail.
   • DThe server's certificate is not trusted by the client.
   Reveal Solution Discussion Select an answer first