An administrator is installing an SSL certificate on a new system. During testing, errors indicate that the certificate is not trusted. The administrator has verified with the issuing CA and has…

Question

Options

• AIf the wildcard certificate is configured
• BIf the certificate signing request is valid
• CIf the root certificate is installed
• DIf the public key is configured

• A
  17% (5)
• B
  7% (2)
• C
  73% (22)
• D
  3% (1)

Explanation

When a browser or system encounters an SSL certificate, it walks a chain of trust from the server's certificate up through any intermediate CAs to a root certificate stored in the system's trusted certificate store. If that root certificate is missing from the local trust store, the entire chain fails - even if the certificate itself is valid and properly signed. This is exactly why the error says "not trusted" rather than "invalid."

Why the distractors are wrong:

• A (wildcard certificate): A misconfigured wildcard would cause a hostname mismatch error, not a general trust failure.
• B (certificate signing request): The CSR is only used during certificate generation; once the cert is issued, the CSR is irrelevant to trust validation.
• D (public key): The public key is embedded in the certificate itself - it doesn't need separate configuration, and a bad public key would cause a different type of error.

Memory tip: Think of it as a "chain of trust" - if your chain has a missing link at the top (the root CA), nothing below it can be trusted. The phrase "not trusted" = "root not found."

No community discussion yet for this question.