SSL Certificate Inspection causing connection issues with certain sites

[daccu]

We have SSL Certificate Inspection enabled (we are NOT using DPI-SSL, so we don't have the MITM invalid certificate problem).  Certain services such as Amazon Echo, credit card POS devices, and PRTG application updates error out on connection with this enabled.  If I simply remove the certificate inspection from the IP4 rules everything works.  Are there any tweaks that will make just the services we're having trouble with connect?  I know with DPI-SSL you can set exclusions, but that option doesn't seem to be available for the certificate inspection option.  As a secondary question, what exactly is the Fortigate doing during certificate inspection that breaks these services?

[hmtay_FTNT · Accepted solution]

Hello,

To answer daccu's question first,

Certificate Inspection should not break any SSL connections. The Fortigate only inspects the SNI on the Client Hello or the Server Certificate when Certificate Inspection is used. It does not attempt a MitM. Could you post the output of the CLI commands, "config firewall ssl-ssh-profile", "edit <your profile>", "show"?

E.g.

edit "certificate-inspection" set comment "SSL handshake inspection." config https set ports 443 set status certificate-inspection end config ftps set ports 990 set status disable end config imaps set ports 993 set status disable end config pop3s set ports 995 set status disable end config smtps set ports 465 set status disable end config ssh set ports 22 set status disable end next

This is the default certificate-inspection profile.

SteveG, 

TLS 1.3 would have affected the engine if you used deep-inspection - not widespread yet, recently added into Chrome 56 (would require the server to support the protocol too).  It should not affect it if certificate-inspection is used. Our dev team has released a new engine to address TLS 1.3. It is not released to the public yet as it is undergoing beta tests. 

LewisBowerbank,

You can disable the replacement message. 

If you are using the Web Filter profile and FortiOS 5.4, here's how:

Go to "config webfilter profile", "edit <profile name>", "set https-replacemsg disable".

If you are using the Application Control profile and FortiOS 5.4,

Go to "config application list", "edit <application name>", "set app-replacemsg disable".

[hmtay_FTNT]

Hello Jond,

I have worked out the problem with LewisBowerbank in private after looking at the configuration file. Are you using the Fortigate in flow-based or proxy-based inspection mode? The https-replacemsg only works on proxy-based inspection. If it is not working for you, can you send me your configuration file? 

[Jond]

Thank you - I've sent a message to you.

[bobm]

I'm having a similar but not quite identical problem.  90D running 5.2.7 with Cert inspection in Proxy mode.  All users are local sign-on using un/password first thing in the morning. 

If they have their default home page set to Google, or anything else https, they get a Cert Error instead of the FG login screen.  As soon as they go to an unencrypted page, they log in just fine. And once they're through the FG, no issues and Web Filter works just fine.

I have installed both Fortinet CA and Fortinet CA SSL Proxy certs on all machines, but they still get the error. 

Thanks

[ivanindic]

Hi hmtay_FTNT,

After reading the discussion I am not sure if I understood the solution correctly. The issue is that during certificate inspection (SNI and CN) some website access breaks - right? Typically the issue occures on those sites where there are some embedded links which are beeing loaded after the first URL request. The issue only occures if some of those emmeded links are categorized by the webfilter to be blocked  (e.g. advertising). When the webfilter blocks access to those https sites the fortigate will send the https-replacemsg to the client with the own fortigate certificate. Typically this is untrusted and the client will get the unknown certificate issuer error. This can be solved for managed clients with certificate rollout. But for BYOD devices thats not possible.

My question:

What actually happens if the fortigate does not send the https-replacemsg as suggested by you? Will the website be partially loaded? (Like loading a news pages without the Ad Banners)

Thx a lot. Ivan

[hmtay_FTNT · Accepted solution]

Hello Ivan,

>>After reading the discussion I am not sure if I understood the solution correctly. The issue is that during certificate inspection (SNI and CN) some website access breaks - right? Typically the issue occures on those sites where there are some embedded links which are beeing loaded after the first URL request. The issue only occures if some of those emmeded links are categorized by the webfilter to be blocked  (e.g. advertising). When the webfilter blocks access to those https sites the fortigate will send the https-replacemsg to the client with the own fortigate certificate. Typically this is untrusted and the client will get the unknown certificate issuer error. This can be solved for managed clients with certificate rollout. But for BYOD devices thats not possible.  

Yes, this is correct.  >>My question: What actually happens if the fortigate does not send the https-replacemsg as suggested by you? 

If the Fortigate does not seed the https-replacemsg, it will send a TCP RST packet to close the session. 

>>Will the website be partially loaded? (Like loading a news pages without the Ad Banners)

Yes, it will be partially loaded. Let's say you load a YouTube page. If you have Google Ads blocked, you will noticed there are patches on the page that looks like the typical error message you get. I attached a sample screen.

One important thing to note is you may notice the page might load slower than usual. This is caused by non-asynchronous loading of the HTML content. For e.g., in the YouTube case, if the HTML page is written in a way as to load the Google Ads first, if the browser receives a RST packet, it may (or may not) keep requesting for the content until the timeout value is reached. If the HTML page is not written in a way to allow asynchronous loading of other content at the same time while it is trying to load the Google Ads, the page will load slowly. This is because the browser is trying to load the ads before everything else.  However, if the Google Ads code is at the very end, you will see the rest of the page loads like usual minus the ads.  If the code is somewhere in the middle of the page, then you might have 60-70% of the page loaded, then it will slow down for a while to try to get the Google Ads, and once the timeout is done, the remaining page will be loaded. This is unfortunately not something we can control. On many of the major browsers today, a RST packet will stop the browser from resending the GET request for a resource. So you are not likely going to see a slowdown. In short:

If https-replacemsg is enabled, you may see a slowdown if a content on a page is blocked because the Fortigate does not send a RST packet right away. The browser will wait until the timeout value is reached.

If https-replacemsg is disabled, you most likely will not see a slowdown. A RST packet will be sent immediately, the browser knows not to wait, and the rest of the page will load after that.

I hope this clears up some confusion you have. Thanks!

HoMing

[ivanindic]

Hi HoMing,

Thx for your quick response. Very useful!

Just one more thing:

[ul]

If I disable the https-replacemsg the TCP RST will be send immediately and because the webbrowers are smart enought they will not resend the HTTP GET for the AD. So no loading slowness. Cool!

If I enable the https-replacemsg the TCP RST will not be sent immediately. That means TCP RST will be send once, but when? I thought with https-replacemsg Fortigate will always immediately send the self issued certificate for blocked content? So here I will not really have the slow partially loading webpages, I will have the unknown cert issuer error page beeing displayed, right?[/ul]

Have a good day.

Thx.

Ivan

[hmtay_FTNT]

>>If I enable the https-replacemsg the TCP RST will not be sent immediately. That means TCP RST will be send once, but when? I thought with https-replacemsg Fortigate will always immediately send the self issued certificate for blocked content? So here I will not really have the slow partially loading webpages, I will have the unknown cert issuer error page beeing displayed, right?

If https-replacemsg is set to enable AND you have the Fortigate CA added as the Trusted Root CA, then there will not be a delay. The error page will load instead of let's say the ads. The delay happens when you do not have the Fortigate CA added as the Trusted Root CA. In this case, the Fortigate cannot replace the certificate and the session will end after a certain timeout value - could be a TCP RST or TCP FIN. With background traffic (which is what causes the delay), on Chrome and Firefox, I believe they do not pop up a box like IE that ask if you would like to trust the Fortigate CA. If a page has HSTS enabled, then there will be no box and the session ends after the timeout value. 

You are welcome! Let me know if you have more questions.

HoMing

[edralev]

One of the best explained answers not only about why certificate warning are seen while using web filtering, but the whole process itself.

Thanks a lot for your time. Kudos!

[ShiveshM]

hi,

One of my companies client is not able to access gotomeeting when ssl inspection is used.

client is able to login to gotomeeting and initiate a session, but after initiating the session seems like its redirecting on some other site, and when the remote screen appears client is getting an error stating "internet error. unable to connect to internet". when we are not using ssl inspection its working fine.

https://kb.fortinet.com/kb/documentLink.do?externalID=FD38882:- i referred this article and made changes accordingly and exempted the wildcard entries mentioned in this article. i have no follow up on whether the client is able to access gotomeeting after this change, but will it work?

and if it will not work, then can anyone tell me whats wrong? what else can be done? what is that error? and whats causing it?

thanks.

[ireyes]

Hi everyone, i have an issue with the portal www.bb.com.mx, this site belongs to a category named Finance & Banking, which i have allowed in my filter, but when a user in my office try to connect to the electronic banking, the portal refuse the connection.

In the application control i have allowed the SSL, the user already have installed the certificate SSL downloaded from the fortigate.

I already see the forward traffic and the problem is the SSL, i already try to configure in the policy with no-inspection and certificate inspection profile but it did not work, anyone can help me with this issue.

Thanks.