312-50 Question 459
Single answer▪ Public Key Infrastructure (PKI)During an internal assessment, you connect to https://portal.example.com and receive a browser warning that the certificate is not trusted. When you inspect the server certificate, you find that it is issued to portal.example.com by an intermediate CA named Example-Issuing-CA. The certificate's validity dates and hostname are correct. The Windows server administrator says, "The certificate is fine because it chains to our internal root CA, which is already trusted on domain-joined workstations." However, the site is also accessed by contractors using unmanaged devices, and those devices continue to show trust warnings. Which action is the MOST appropriate to resolve the trust problem without replacing the server certificate?
- A
Install the internal root CA certificate into the Trusted Root Certification Authorities store on each unmanaged client that must trust the site
- B
Regenerate the server certificate with a longer key length so browsers will automatically trust it
- C
Disable certificate revocation checking in the browser because the warning is caused by an incomplete chain
- D
Replace the intermediate CA certificate on the server with a self-signed certificate for portal.example.com
Show answer and explanation
Correct answer: A
Explanation
This question tests practical PKI troubleshooting. A certificate can be technically valid for hostname and dates yet still be untrusted if the client does not trust the CA chain. In an enterprise PKI, domain-joined systems often trust the internal root CA via Group Policy, while unmanaged devices do not. The correct remediation is to establish trust for the root CA on those unmanaged clients or use a publicly trusted CA if broad external trust is required. According to common PKI best practices and browser trust models, clients must be able to build a chain from the end-entity certificate through any intermediate CA certificates to a trusted root in the local trust store. Key length, revocation settings, or substituting a self-signed server certificate do not solve the underlying trust-anchor problem.
- A. Correct.
Correct. In PKI, trust is established from a certificate chain to a trusted root CA. If unmanaged contractor devices do not already trust the organization's internal root CA, they will continue to warn even if the server certificate and intermediate CA are otherwise valid. Installing the internal root certificate on those clients establishes trust without needing to replace the existing server certificate. In practice, the server should also provide the intermediate certificate so clients can build the chain, but the scenario specifically states the core issue is that unmanaged devices do not trust the internal root.
- B. Incorrect.
Incorrect. Increasing key length may improve cryptographic strength, but it does not cause a browser or operating system to trust a private PKI hierarchy. Trust is based on whether the issuing chain terminates at a root CA in the client's trusted root store, not on key size alone.
- C. Incorrect.
Incorrect. Disabling revocation checking is not an appropriate fix and weakens security. Also, revocation warnings and trust-chain warnings are different problems. If the root CA is not trusted by unmanaged devices, turning off revocation checking will not create trust in the issuing CA.
- D. Incorrect.
Incorrect. Replacing the intermediate CA certificate with a self-signed certificate for the host would break the current chain design and likely create a different trust problem. A self-signed server certificate is only trusted if that exact certificate is manually trusted on each client, which is typically worse than distributing the internal root CA certificate.