Legit sites with valid SSL certificate are not opening - "Your connection is not private"

[MadDog_2023]

Hi All,

This morning all of a sudden some sites are not opening.

The issue is not related to websites certificate. 

For sure it comes from FortiGate. 

Could you please help to fix it. 

[Lamberts]

Same here on Multiple sites.

If you create a new ssl under ssl/ssh inspection and call it "no inspection 23"

Turn off all the inspect all ports and save it.

In your policy and objects where cert inspection is used swap it to you new no inspection 23.

if you have clients needing access to sites It Works but not ideal, at least until FG sort the issue properly

[lbjust]

I did not have any issues today but I recommend you to enable "Log SSL anomalies" in the SSL/SSH Inspection Profile so you will be able to analyze the log and understand why that profile is blocking access to the website.
Perhaps for some reason is marking the certificate as Expired certificates / Revoked certificates / Validation timed-out certificates / Validation failed certificates and your profile is configured as Block.

[MadDog_2023]

Hi guys,

I checked Security & Profiles - SSL\SSH Inspection and there is no option to create a new certificate.

Tried to contact FortiGate support but was advised that the device's license has expired so no support can be provided.

Is there any other way to fix it?

P.S. Does anyone know why it started to happen all of a sudden?

[MadDog_2023]

Tried to follow this article.

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Fortinet-Untrusted-CA-when-browsing-...

For example the website is news.com.au

I found intermediate certificate DigiCert Global Root CA.

Trying to import.

Certificate is duplicated.

[MadDog_2023]

The issue has been resolved.

Maybe on FortiGate's end.

[sw2090]

Your first screenshots indicate to me that for some reason your traffic has hit a policy that has SSL Deep Inspection turned on. Only then the original certificate will be replaced by a certificate created by the FGT using the CA in the SSL DPI Profile. That is because DPI is a man-in-the-middle. The FGT needs to decrypt the traffic to be able to have the filters check it and then has to re-encrypt it to hand it on to the client that requested it. Since it cannot use the original cert for that (because it doesn't have the private key) it uses the CA in the profile to spawn a new cert using the original dn/subject/san and use that to re-encrypt.

There is no need to create new cert. Either remove the DPI if it is not needed/wanted or download the CA from your FGT and install it to your client(s) as trusted CA.