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

[Kaspars_Zibarts]

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:

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

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:

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

We are running R80.40 T91.

[Alex-]

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.

[Kaspars_Zibarts]

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

[FraP]

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

 

 

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

 

 

Server side misconfiguration

[Kaspars_Zibarts]

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

[Alex-]

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.

[Kaspars_Zibarts]

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.

[Kaspars_Zibarts · Accepted solution]

Confirmed! It was the intermediate CA that was missing, 

[jennyado]

I do not understand, which certificate you installed? and where your downloaded it?

[VIKAS1]

Hi,

we are facing same issue here, we have got the below step from tac & also the CAs zip file, we have flow the step but still we are facing Certificate Validation is Untrusted.

1. How to run / Sanity test the script:

•  

• Get / Attach a zip file which contains 2 files (jar,sh)

•  

• Take a GAIA snapshot of the Management server / MDS machine
• Close Smart Console
• Download the attached zip file.
• Extract the zip file.
• Make sure the management server / MDS is up and running
• Place the 2 files from the zip file in the home directory (/home/admin) of the management server / MDS.
• On the management server / MDS, run:
  # cd /home/admin
  # chmod +x RunAccessClient.sh
  # chmod +x AccessClient.jar
  # In case of SMS: ./RunAccessClient.sh -a fixOrphanTrustedCAs 
• After fixOrphanTrustedCAs has ended successfully, remove both script files from the machine.

[the_rock]

Saw your message you sent, but cant respond from little phone screen lol. Anyway, you dont need to unzip anything, its simply upload via smart console. That file is from $CPDIR/database folder.

Is that where it was given to you from?

Andy

[VIKAS1]

Hi,

We have received the zip file from tac and also step to flow, but after flowing the step we are still getting the same error.

Certificate Validation   Untrusted Certificate

[Kaspars_Zibarts]

Hi! Did you try to follow the steps described in this article? https://www.networkoc.net/windows-update-fails-when-check-point-https-inspection-is-enabled/ it's really well written

[the_rock]

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

[Kaspars_Zibarts]

@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:

And results are surprisingly good:

[the_rock]

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.