A vendor's laptop presents a client certificate during an authentication attempt to the utility's FortiGate, but the certificate was issued by a certificate authority the FortiGate does not trust. What is the most likely outcome?
Select an answer to reveal the explanation.
Short Explanation
A well-formed certificate from a CA nobody trusts is like a beautifully printed ID from an agency that doesn't exist as far as security is concerned. The FortiGate isn't checking whether the certificate looks legitimate — it's checking whether it can trace that certificate back to an authority it already trusts. No trusted chain, no access, no matter how correct the certificate's format is.
Full Explanation
Certificate validation hinges on chain-of-trust verification: the FortiGate must trace the presented certificate back, through any intermediates, to a root or intermediate CA it is explicitly configured to trust, and a well-formed certificate signed by an untrusted CA still fails this check. A correct format is not sufficient on its own — trust comes from the signing authority's relationship to the FortiGate's trust store, not the certificate's structure. FortiGate has no behavior that adds an unrecognized CA to its trust store just because a certificate from it appeared; trusting a new CA is a deliberate administrative action, and auto-trusting unknown issuers would defeat certificate authentication's security model. There is also no automatic fallback to password-only authentication when a certificate fails validation unless the policy was specifically configured with that fallback path — certificate failure is a hard stop, not a silent downgrade. The operational caveat is that certificate deployments require careful CA trust-store management, since adding the wrong CA or omitting a legitimate one breaks authentication for whole populations. To confirm, check the FortiGate's trusted CA list against the CA that actually issued the vendor's certificate.