HTTPS Inspection Bypass via URL vs IP Address

[Cypress]

Hello Wonderful Check Mates users, I am back with some more questions again!

In our environment (R81.10) we have a Custom Application/Site object that we use to bypass HTTPS Inspection for certain domains.  We typically only bypass domains when the HTTPS Inspection seems to be breaking something (which seems to be the case now for a growing number of vendors our business uses.)

Typically to bypass Inspection is a simple matter of opening the Custom Application/Site referenced in the rule, entering in the Domain, saving and installing policy.

Lately, though, within the last couple of weeks, we have encountered some domains that this does not fix.  Despite adding the Domain into the Custom Application/Site, the Logs indicate the website was still hitting HTTPS Inspection (seeing the yellow Action: Inspect in the logs) and it is saying there is "Untrusted Certificate."

If I do NSLOOKUP for the website, and create an IP-based Host Object, and use that in a Bypass Rule, (same results if i create a FQDN Domain object) now suddenly it successfully Bypasses inspection, and fixes the site for our user.

My question is why is this happening?  Is this something upgrading to R81.20 could possibly fix?  I am guessing bypassing inspection based on an IP Address (Host and/or FQDN objects) invokes the bypass "earlier" than doing it by Custom Application/Site URL List?

By the way, the symptom I've been seeing more and more is that when HTTPS Inspection is turned on, the website loads with a certificate error for the user, and the server certificate just says "Issued By: Untrusted."  Once we successfully bypass HTTPS Inspection, then the certificate presented to the user is the "real" Cert from the vendor, signed by one of the big CAs.

[the_rock]

Thats a bit of a tricky situation, for the lack of a better term. This is the way I look at it...if we have SOLID proof its the fqdn that needs to be exempted, thats easy, we just bypass it, BUT, if fqdn gets resolved to multiple IP addresses, then you may need tyo add those as well, in some scenarios.

Im willing to test this in my lab, if you wish to provide good examples. I have R81.20 jumbo 98 ssl inspection lab, as well as R82, but we can stick with R81.20 for now.

Let me know.

Best,

Andy

[Cypress]

Thank you for the offer of testing this in a lab environment.  I have sent you a private message with the URL to re-create the issue.

[the_rock]

Thanks brother, just saw it. Let me test right now while I wait on some Fortinet lab to finish 🙂

I will update you soon.

Andy

[the_rock]

I really believe this is website issue... tried it on my cell phone, just on data, and it gave EXACT same message below, like on windows 11 in the lab, thats behind the cluster with ssl inspection on.

Andy

{ "statusCode": 404, "message": "Resource not found" }

[Cypress]

OK but no "Untrusted Certificate Error" warning in the browser?  

[the_rock · Accepted solution]

Nope, nothing like that.

Andy

[the_rock]

Just for the context, this is what I did on bypass rule.

Andy

[CaseyB]

Since you are seeing the "Untrusted Certificate Error" on your side and @the_rock is not, have you validated that the correct RootCA is listed in your managements Trust CA list? 

There were some bugs in R81.10 with Trusted CAs not installing automatically.

Edit: Looks like it should be this one:

[the_rock]

That certainly makes sense!

[the_rock]

@Cypress What @CaseyB said is an excellend point. I actually attached some screenshots about it in legacy smart console and just in case, how to get there. Be free to message me directly if need be as well.

Andy

[the_rock]

One more thing...just for your reference, I attached what I see when going to that site in the lab.

Andy