Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
McEathron
New Contributor

Prevent Certificate Warnings without SSL Deep Inspection (Certificate Inspection only)

I found a great Cookbook article on preventing Certificate Warnings with SSL Deep inspection enabled. It didn't make mention of how to do this without SSL Deep Inspection enabled.

 

Wondering if it's even possible with L2 firewalls, given that the only IP to associate with a cert is the management IP.

6 REPLIES 6
sw2090
Honored Contributor

You get those certificate warnings because SSL Deep inspection is man in the middle. This means the connection from yur FGT on to your client will be encrypted with a certficate on the FGT and only the other half is encryted with the original certificate. By default there is only some self signed cert installed on the FGT.

So you either have tp install the Fortinet CAs on your client to enable them to validate the default cert or install a new one that has a CA already known by the browsers. Keep in mind this requires a Certificate that is able to create Certificates (CA) because of man in the middle.

 

What do you mean without SSL Deep Inspection? The certificate used if you access your FGT via htts? Same issue as above. Install Fortigate CAs or own valid certificate for https. 

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
McEathron

Thank you for jumping in the water so quick, sw! I appreciate the immediate feedback.

 

To answer your question, what I mean about "without SSL Deep Inspection" is when you go to Policy & Objects>Security Profiles>SSL/SSH Inspection>Inspection Method and do not choose "Full SSL Inspection", but instead use "SSL Certificate Inspection".

 

I probably should use the term "Full Inspection" instead of "Deep Inspection", even if so much of the documentation has "Deep" used in it. My apologies for the confusion. Thank you for asking for clarification.

 

This, in conjunction with Flow Based Web Filtering enabled.

McEathron

Basically, The preliminary observation we have is that a component of an application is reaching out to a “doubleclick.net” related domain that is being blocked due to advertising. The block itself is not causing an issue that we know of, it is the security settings in the IE based built-in browser in the application that is throwing up errors caused by the self-signed certificate of the WFC not having a valid CRL URL.

 

We get a Security Alert pop-up that says "Revocation information for the security certificate for this site is not available. Do you want to proceed?"

 

With just SSL Certificate Inspection and Flow Based Web Filetering enabled, we're not sure how best to address this.

 

Dave_Hall
Honored Contributor

Is there anything preventing or stopping you from creating custom firewall rule(s) for the application in question, e.g. tailoring the UTM features applied to that connection only? 

 

 

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
McEathron

Thanks for the reply, Mr. Hall.

 

That is not an option for us, unfortunately. If it were only a few dozen machines with this issue, maybe.

McEathron

A component of an application is reaching out to a “doubleclick.net” related domain that is being blocked due to the advertising category being blocked as per the WCF. The block itself is not causing an issue that we know of, it is the security settings in the IE based built-in browser in the application that is throwing up errors caused by the self-signed certificate of the WFC not having a valid CRL URL. There is a group policy setting to not look at the CRL, and disabling that keeps the error from populating. However, this is not a solution, as much as it is a workaround. We cannot dismiss CRL's. The only way to get rid of the certificate error page for HTTPS, that we know of, is for all workstations to trust the Fortigate’s Built-in Certificate. An alternative is to disable the HTTPS block page but still block HTTPS, however this violates our Security Plan Policy. We have to have that Block Page. We need to determine if there is a fix for the certificate revocation error without having to trust the local Fortigate built in certificate. Also, if that fix is that we have to use our own CA cert, how do we generate an official certificate for a L2 firewall? The only IP is the management interface so how do you generate the CRS and satisfy the DNS piece?

Labels
Top Kudoed Authors