HTTPS Inspection & certificates

[JenniferYado]

I have a issue with certificates

From the security gateway I export the certificate that was created from it. Then I active the HTTPS Inspection checkbox and finally a install the certificate to level host. 

When I try to access to Microsoft services and some internal services, I get the next message:

The certificate that shows the broswer when I enable HTTPS Inspection:

Also I saw some logs with the message that the certificate chain is not signed by a trusted CA.

 

[the_rock]

Hey @JenniferYado 

I made a post about this recently. I actually have 2 perfectly working ssl inspection labs, so if you are free tomorrow, we can do remote and check, Im in EST time zone (GMT-5). Btw, have a look and see if it helps.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Https-inspection-lab-guide/m-p/214429#M40929

[PhoneBoy]

Please show the CA key you exported from management in the Certificate Store of your client system with the various trust settings.

[JenniferYado]

This is the certificate that we installed in the host which was exported from the SMS

     

[the_rock]

See if additional post I made about this helps.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Https-inspection-tip/m-p/219139

[PhoneBoy]

The certificate needs to be explicitly imported into the Trusted Root Certification Authorities.
If you just click through and choose the defaults in the Import Certificate wizard, the certificate will not be trusted (thus the problem you are having).
When done correctly, it should show here (Invoke via Windows Run: certmgr.msc )

[the_rock]

Think of it like this, as trivial as this may sound, but hopefully you will get an idea. If you go to any secure website in the world, you can see what is root CA, then sub CA and then actual "client" cert. So, say in CP context, again, trivial as this is, think of mgmt as root CA, then your fw as sub-CA thats issuing ssl cert for your clients and as @PhoneBoy indicated in his post, all of them has to be TRUSTED in order NOT to get the cert warnings.

Makes sense?

Andy

[the_rock]

To help you even further, I took bunch of screenshots from my lab. PLEASE pay attention to things I pointed out in red, as those are important.

Andy

 

 

 

 

 

 

 

 

 

[CaseyB]

Since you are getting the certificate chain is not trusted, check the following:

• Launch the SmartDashboard HTTPS Inspection settings
• Navigate to the "Trusted CAs" section
• If you click the "add" button up top and you have a bunch of objects listed, that is your issue. Everything in that list is not installed as a Trusted CA and it needs to be, otherwise you will get those navigation errors. It should be empty.

Also, make sure this is enabled:

If you have stuff in the list, you can manually add them or get ahold of TAC, they can help fix that.

[JenniferYado]

We have installed the updates of this section but we still have the same issue.

[the_rock]

Personally, in my experience, those updates have nothing to do with the issue you have. You HAVE TO trust all the certs involved in a "chain" here not to get those warnings. Ie...whatever certs show when you click on untrusted cert on the web page, you need to export them, then install both of them (mgmt and gw one), put them in TRUSTED ROOT, make sure cert shows okay and Im 100% sure it will work just fine.

Andy

[JenniferYado]

I understand that I have to export all certificates from sites that I have issues to access and install it on the gateway, but what happen with Microsoft Teams? 

[the_rock · Accepted solution]

For that, you can bypass it using custom app site group in https policy with bypass rule. Or, before that, examine the logs and see why its failing. If it shows inspect log, theres your answer.

Andy

[JenniferYado]

I was doing some testing and I was able to fix the MS Teams part with the bypass rule.

[the_rock]

Thats easiest/best way to fix those issues.

Good job!

Andy

[the_rock]

Also, forgot to mention, as I find this very IMPORTANT. I always use multiple ordered layers when I build ssl inspection labs, as I find that traffic is processed much faster and inspection always works that way. So, say on 2nd ordered layer, I ONLY enable urlf+appc blades and approach it using blacklist, rather than whitelist. There is even sk about it, cant recall now what it is, but its also due to the reason that traffic has to be allowed via all ordered layers. Yes, you can "cram" it in one layer, but why suffer that way. I did that for one customer while back that came from Cisco world and only reason for it was because their boss did not feel comfortable having layer with any any allow at the bottom. No matter how many times I explaied it to him, did not help : - ). Anyway, we made it work, but probably took 10 extra hours, compared to doing it the way I described.

Andy