Https inspection Validation error

[Sukru_isik]

Hello  ,

I have checkpoint with version R80.20.

I have enabled https inspection and using Sophos endpoint agent.

Agents are managed on cloud side. When we want to install agent , we are taking a log like below and  we couldnt install it. 

I have written exception url like "*.sophos.com" on inspection rules, but it is not working.

(When I disable https inspection completely, the agents are installed succesfully.)

How can I solve this problem?

[Alex_Weldon]

It looks like you already have the Sophos IP addresses defined - Try creating an HTTPS bypass using the Objects representing the Sophos IP range rather than the regex bypass.

[Sukru_isik]

I dont know IP adresses. The application is on amazon public cloud. And IP adresses are always changing so I have to write url exception.

[Alex_Weldon]

What are your options set to under HTTPS Validation? 

[Sukru_isik]

the configuration is below:

[PhoneBoy]

The error message is pretty clear: whatever is signing the certificate is not a trusted CA.

The Security Gateway maintains a certificate store of CAs.

Whatever CA signed the site certificate, it needs to be added here:

[Sukru_isik]

I import certificate manually(exported it to *.cer file from browser).

And then try again but I am taking same error.

[PhoneBoy]

That's a different error from the above.

In any case I recommend opening a TAC case so we can troubleshoot what's happening.

[MartinZ]

I had this issue and noticed there was a root CA update waiting to be applied. After applying the update all was good:

Ref: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[RickHoppe]

In cases like this I always check SSL Labs to see what they have to say: https://www.ssllabs.com/ssltest/analyze.html?d=mcs%2dcloudstation%2dus%2deast%2d2.prod.hydra.sophos....

My advise would be to also contact your support contacts at Sophos as there is clearly a trust issue with this certificate.

[McGlio]

I've found a workaround for those who use Sophos like antivirus.
You will not find on the internet the CA used from Sophos for Antivirus update/installation, but if you install a client using an outside connection on your Windows computer, for example doing hotspot with your mobile, you could find the .crt file of the root CA used in the path C:\Program Files (x86)\Sophos\CloudInstaller\Management Certs

[Jf821]

I have run into exactly the same issue.  Having real problems working round it.

Found all the sophos CA's in C:\ProgramData\Sophos\AutoUpdate\Cache\decoded\mcsep\Sophos\Certificates\Management Communications System.   I have uploaded them. 

But.....

Now checkpoint complains it cant get the CRLs.  Without saying where its looking for them, for the life of me I cant find any reference if you can upload a CRL into checkpoint (the sophos CRL files are in the same folder as the certs.

No mater what URLs I add into the SSL bypass rule it does not work.

This has proving to be a real puzzle.

[PhoneBoy]

CRLs are typically downloaded via HTTP (not HTTPS).
The exact location it's looking should be specified in the Sophos certificate itself.

[FedericoMeiners]

Hello,

In one of our customers we always had Sophos install/update issues with HTTPS Inspection enabled with all versions except with R80.40

R80.40 worked out of the box with a bypass rule for Sophos services.

[Jf821]

So I think I'm getting to what the issue is, but I don't understand why it happens

If I debug wstlsd It can correctly read all the cert information.

When I debug the kernal to see the ssli rule processing I see the following:

@;89466575;18Feb2020 17:31:38.369043;[cpu_0];[fw4_1];ws_get_server_ssl_certificate_cn_field: _found = ffffffff8063931c, *_found = 0;

@;89466575;18Feb2020 17:31:38.369049;[cpu_0];[fw4_1];https_inspection_handle_ssl: setting the 'IS_SSL' flag on connection ffffc2001d216bf8;

@;89466575;18Feb2020 17:31:38.369053;[cpu_0];[fw4_1];https_inspection_handle_ssl: Rulebase was matched on syn packet without category column (matched_with_opt: 0);

@;89466575;18Feb2020 17:31:38.369056;[cpu_0];[fw4_1];https_inspection_handle_ssl: domain is missing, handshake will be done without rulebase execution;

@;89466575;18Feb2020 17:31:38.369067;[cpu_0];[fw4_1];fwconn_key_lookup_app_opaque: conn <dir 0, aa.aa.aa.aaa:64187 -> bb.bb.bb.bb:443 IPP 6> found in connections table (id=4);

@;89466575;18Feb2020 17:31:38.369072;[cpu_0];[fw4_1];https_inspection_handle_ssl: setting the 'SSL_TUNNEL_INSPECTED' flag on connection ffffc2001d216bf8;

For some reason, it cant read the CN of the cert, resulting in it dropping to the bottom of the rule set and hitting my inspection rule.  This would explain why I can write an IP based rule it works, but when I write a rule based on a URL it never triggers.  This is on R80.20

I have raised a support ticket, as why this is happening is beyond me.

[PhoneBoy]

Agree, a support ticket is warranted here.
Apologies this message got flagged as spam a couple times. 🙄

[Jf821]

Support has confirmed this a known issue, but it's wider than just sophos.

It would appear that any ssl certificate that the gateway sees as not trusted, cant be bypassed based on common name of the certificate.  The only way to bypass in this situation is based on IP address.

[Jf821]

While R&D appear to confirm there is an issue, as it stand currently, they will not fix it, why they wont fix the bug I cant currently get to the bottom of, despite there being multiple Sophos customers with exactly the same issue. 

To me it's a clear bug, there should no reason why I cant write a rule based on the CN of cert, when the gateway does not trust the cert.

Thus the only option you have if your gateway does not trust a cert is to by pass using IP address.  Which is a complete pain, as sophos change all their ips on a regular basis,

[Benedikt_Weissl]

Maybe the improved https inspection mechanism in r80.30 would help here, for R80.20 have a look at the sk104717 "Improvements in HTTPS Inspection Bypass mechanism - Probe Bypass".

[PhoneBoy]

Can you PM me the ticket number you had with TAC?

[Jf821]

so I the issue is actually covered by sk92888

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Took a while to find this.  Impacts many more things than sophos. 

I have been told is somewhere in R&D queue, but there is no ETA for a fix.  So if this impacts you, best to raise it with your account manager, the more people who raise I guess the quicker it will get done.

[PhoneBoy]

What's not clear from reading the SK is if this is still relevant in R80.30 and R80.40, which have an improved bypass mechanism.
Are people on R80.30+ experiencing this same issue

[Jessie_Rich]

I'm on R80.40 and was having this exact issue today regarding the prod.hydra.sophos.com cert being untrusted, with DNS resolving an AWS hostname. The prod.hydra.sophos.com cert was signed by sophosca1, I found that CA certificate as well as 5 others in the various directories of the client install. Adding all of them to the Trusted CAs in smart dashboard appears to have resolved the issue.

[Carlos_Caraball]

Just upgraded to R81, same issue.