312-50 Question 461
Single answer▪ Public Key Infrastructure (PKI)During an internal security assessment, you are asked to review a company's PKI implementation for its public-facing web applications. Users report frequent certificate warnings in browsers after the company recently migrated several applications behind a new load balancer. The security team confirms that the servers are using valid certificates issued by a trusted public CA, but packet captures show that clients are not receiving the intermediate CA certificate during the TLS handshake. Which action would MOST likely resolve the browser trust warnings without replacing the server certificate?
- A
Install and configure the correct intermediate CA certificate chain on the load balancer so it presents the full chain during the TLS handshake
- B
Revoke the current server certificate and generate a new self-signed certificate with the same subject name
- C
Export the CA's private key to the load balancer so the device can validate client trust dynamically
- D
Replace the public CA-issued certificate with the root CA certificate on the server
Show answer and explanation
Correct answer: A
Explanation
In PKI-based TLS deployments, the server presents its end-entity certificate and typically one or more intermediate CA certificates. Clients then validate the chain up to a trusted root already stored in the operating system or browser trust store. If the intermediate certificate is missing, clients may fail chain building and display certificate warnings even when the server certificate itself is valid and not expired. In real environments, this often occurs after moving TLS termination to a load balancer, reverse proxy, or web application firewall where the certificate chain file was not fully imported. Best practice is to configure the full certificate chain correctly on the TLS endpoint. This aligns with standard X.509 path validation behavior described in RFC 5280 and common vendor guidance from web servers, load balancers, and public CA documentation.
- A. Correct.
Correct. If the server or load balancer fails to send the required intermediate CA certificates, many clients cannot build a valid chain from the server certificate to a trusted root in their trust store. Installing the proper intermediate chain on the TLS termination device is the standard fix. This is a common real-world issue after migration to reverse proxies or load balancers because the end-entity certificate may be present, but the chain file is omitted or misconfigured.
- B. Incorrect.
Incorrect. A self-signed certificate would generally increase trust warnings because browsers do not inherently trust a self-signed certificate unless it has been manually added to the trust store. Revoking a valid public CA-issued certificate does not address the actual problem, which is incomplete chain delivery.
- C. Incorrect.
Incorrect. A CA's private key must never be exported to infrastructure devices for this purpose. Clients validate trust by building a chain to a trusted root certificate already in their trust store; the server does not need the CA private key to prove trust. Exporting the CA private key would be a severe PKI security failure.
- D. Incorrect.
Incorrect. The root CA certificate is not a substitute for the server's end-entity certificate. The server must present its own certificate and usually the intermediate certificates needed to complete the chain. Replacing the server certificate with a root certificate would be improper and would break identity binding for the web service.