Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Sukru_isik
Contributor

Https inspection Validation error

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?

23 Replies
Alex_Weldon
Contributor

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.

0 Kudos
Sukru_isik
Contributor

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.

0 Kudos
Alex_Weldon
Contributor

What are your options set to under HTTPS Validation? 

0 Kudos
Sukru_isik
Contributor

the configuration is below:

0 Kudos
PhoneBoy
Admin
Admin

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
Contributor

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

And then try again but I am taking same error.

0 Kudos
PhoneBoy
Admin
Admin

That's a different error from the above.

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

0 Kudos
MartinZ
Contributor

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...

 

0 Kudos
RickHoppe
Advisor

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.

My blog: https://checkpoint.engineer
McGlio
Explorer

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

 

0 Kudos
Jf821
Explorer

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.

 

0 Kudos
PhoneBoy
Admin
Admin

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

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.

 

____________
https://www.linkedin.com/in/federicomeiners/
0 Kudos
Jf821
Explorer

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.

0 Kudos
PhoneBoy
Admin
Admin

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

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.

0 Kudos
Jf821
Explorer

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,

0 Kudos
Benedikt_Weissl
Advisor

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".
0 Kudos
PhoneBoy
Admin
Admin

Can you PM me the ticket number you had with TAC?
0 Kudos
Jf821
Explorer

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.

 

0 Kudos
PhoneBoy
Admin
Admin

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
0 Kudos
Jessie_Rich
Participant

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.

0 Kudos
Carlos_Caraball
Participant

Just upgraded to R81, same issue.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events