Seeing a lot of this on a customer’s FGT.
Anyone else seen this before?
FZ.
openssl s_client -showcerts -connect 40.68.123.157:443 -servername “sls.update.microsoft.com”
The server certificate chains up to a “Microsoft Root Certificate Authority 2011”, which, at a glance (get vpn certificate ca | grep Microsoft) doesn’t appear to be included in the builtin root CA bundlle in FortiOS (bundle version 1.00050). So from the FortiGate’s POV, it would be seen as untrusted due to not being signed by a known CA.
This is a function of SSL inspection. If you check the details of the logs it should tell you what exactly is wrong with the certificate of the destination.
Certificate is not trusted. SSL Server Test: sls.update.microsoft.com (Powered by Qualys SSL Labs)
This is a good Point… Whats your recommendation? Would you install These as trusted on the forti or would you exclude the url?
That cert isn’t trusted by anything… not even chrome …
Hard to say.
I’m not too keen on trusting random Microsoft CAs. On the other hand, just by using Windows, one inevitably does trust those CAs implicitly, so… eh?
Alternatively, you could handle this with a separate policy, I guess. You could target the destination with an FQDN address object, and not do cert validation for that traffic.
No, this is just a Chrome thing due to Certificate Transparency, as the message in Chrome states. Firefox and Edge trust the certificate.
AFAIK Chrome delegates the management of trusted roots to the Windows OS, and Windows itself trusts that root.
Of course, that doesn’t change anything about FortiOS not trusting it. (and I don’t see any reason why it should, so far)