Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Kaspars_Zibarts
Employee Employee
Employee
Jump to solution

URLF detect events with "Untrusted Certificate" for Microsoft sites with "HTTPS lite"

Trying to get my head around as we get many URL Filtering detect events for Microsoft sites when using categorization without HTTPS interception, aka "HTTPS lite"

Lets start with the problem:

image.png

 

I read the sk159872 and added missing Trusted CAs manually, cleared cache and installed policy but events keep coming:

image.png

 

Additionally read sk64521 and there were no automatic downloads available.

Looked at https://www.ssllabs.com/ssltest/analyze.html?d=events.data.microsoft.com as well but got none the wiser what would be the problem.

Chrome shows possible problem with validity length:

image.png

 

Not entirely sure why it is showing as Untrusted. Any ideas?

We are running R80.40 T91.

0 Kudos
1 Solution

Accepted Solutions
Kaspars_Zibarts
Employee Employee
Employee

Confirmed! It was the intermediate CA that was missing, 

image.png

 

View solution in original post

0 Kudos
10 Replies
Alex-
Advisor
Advisor

I have a similar error since today with full HTTPS Inspection, luckily just used on a pilot group for now. Working fine yesterday, broken today with warning of reused certificates with similar serial numbers or "Untrusted" source instead of the MITM CA depending of the browser.

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

For us it's only a PoC so no one is really affected. We're evaluating if CP HTTPS Lite can replace our proxy.

0 Kudos
FraP
Contributor

My thought is Chrome doesn't trust the cert provided by events.data.microsoft.com because it's valid for more then 398 days  (link)

Not Before: 10/9/2020, 21:03:31
Not After: 10/12/2021, 20:03:31
Total: 455

events.png

Instead, the cert for teams.events.data.microsoft.com (which is different one) is trusted

Not Before: 14/9/2020, 21:51:29 
Not After: 9/9/2021, 21:51:29
Total 360

teams.events.png

Server side misconfiguration

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

Thanks, I still want this cert to be trusted in Checkpoint solution. I'm not too worried about Chrome

0 Kudos
Alex-
Advisor
Advisor

Here's what I've seen today. The pilot system is an unattended Windows VM which is the only activated source in the HTTPS Inspection policy so there's no company-wide impact.

Categorize HTTPS websites has been running for long along with URLF blades and they work without issues.

The pilot was working until today with HTTPS inspection, the MITM certificate was seen in the browser and HTTPS Inspection logs would show up and everything was working fine.

When I checked again this evening (I didn't during the day), I saw that I couldn't browse anywhere anymore, I either had certificate validation errors from all browsers as the certificate was signed by "Untrusted" instead of the MITM or errors about certificates with similar serials being reused. Also, all logs in HTTPS Inspection would show the validation error of the URL trying to be reached.

If I disable HTTPS Inspection in the gateway properties, browsing works again but the strange thing is that I keep seeing the MITM certificate signing the site, even for sites open in private mode which were never accessed on the pilot machine. No more HTTPS Inspection logs though. I went further by disabling the inspection rule on top of disabling the HTTPS inspection but same behaviour. Maybe I should have first disabled the inspection rule, then disabled HTTPS Inspection on the gateway. I will check further tomorrow.

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

Actually I was trying to stay away from HTTPS interception purposely in this thread 🙂 hence the note about HTTPS Lite at the beginning. 

I think I found my problem thanks to this article https://www.networkoc.net/windows-update-fails-when-check-point-https-inspection-is-enabled/ 

I did import only root CA but not intermediate CA! I have added it now and will report tomorrow. 

We're really interested in "unbroken" HTTPS categorization and filtering for various reasons.

(1)
Kaspars_Zibarts
Employee Employee
Employee

Confirmed! It was the intermediate CA that was missing, 

image.png

 

0 Kudos
the_rock
Legend
Legend

I could be wrong when I say this, but Im pretty sure that using that https categorization without the https inspection enabled is not very helpful. I believe what ends up happening is that firewall really tries to do the categorization, but the problem is, if inspection is off, then there is really nothing to inspect, so block pages would never work. One thing I find odd is why you keep getting the warnings if https inspection is off, that makes no sense at all. Does it show up on all the browsers?

Andy

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

@the_rock actually there is a lot to inspect even with "unbroken" HTTPS 🙂 You need to start thinking about the future when you won't be able to break TLS at all, or think of pinned certs already.

There has been multiple sessions even here on Checkmates regarding it i.e HTTPS-Inspection-Best-Practices 

In nutshell you would inspect TSL handshake:

image.png

 

 

 

 

 

 

 

 

 

And results are surprisingly good:

image.png

0 Kudos
the_rock
Legend
Legend

No, I agree...not saying it wont work, but I know block page will never show without https inspection. Maybe this is way more advanced in R80, but in the old days, it was very basic.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events