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

Error: Update failed. Contract entitlement check failed. Gateway can not access internet

Error: Update failed. Contract entitlement check failed. Gateway can not access internet ("https://updates.checkpoint.com/WebService/services/DownloadMetaDataService"). Check connectivity and proxy settings.

 

6 SG's and 3 SMS's has at this very time same error - anyone else has it just now or something has happened on the CP Clould side?

would appreciate heads up. 

  Anti-Bot Update Status  
Name Value
Status
 

 

Failed
Description Update failed. Contract entitlement check failed. Gateway can not access internet ("https://updates.checkpoint.com/WebService/services/DownloadMetaDataService"). Check connectivity and proxy settings.
Next update The next try will be within one hour.
Version 2006022334

 

cheers

Jerry
0 Kudos
40 Replies
Jerry
Leader
Leader
indeed:

* servercert: Activated
* servercert: crl_disable from registry: 1
* servercert: CRL validation was disabled
* Server certificate:
* subject: CN=*.checkpoint.com
* start date: Jun 4 13:23:27 2020 GMT
* expire date: Sep 7 13:23:27 2022 GMT

but we shouldn't care much as long as you're having "no CLR checks on your side" - so that means we're on the path not fully recovered though.
Jerry
0 Kudos
Dorit_Dor
Employee
Employee

To sum up 

1. Indeed there was a CRL (Certificate revocation list) challenge (Certificate is naturally 3rd party certificate and therefore CRL check is also dependent on the same 3rd party) that caused failure on updates downloads 

2. Indeed the response took more than desired 

3. During the incident, we did identify the issue fast but it was not as easy to resolve and one would have hoped 

4. We take this incident seriously and I am confident that we will avoid this single point of failure in the future.

Thank you for the feedback and collaboration 

Dorit 

BTW Its also opportunity for other IT leaders in the forum to leverage the same lesson and check if there is critical service that is dependent on CRL check. 

 

 

Jerry
Leader
Leader
Thanks for clarification and very comprehensive update Dorit. We all much appreciate that.

Cheers
Jerry
Jerry
_Val_
Admin
Admin

Thank you Dorit, we appreciate the transparency.

0 Kudos
SerB
Explorer
Does anyone still have update problems? They don't work via our proxy. Appliances that have an internet connection receive their updates without any problems.
0 Kudos
Jerry
Leader
Leader
cpuse via proxy? what sort of proxy is that? is it just http/https one or transparent or proxy-arp type one? please be more specific but indeed I do agree it is worrying as we've stated before CLR is not "enabled" effectively on the wildcard cert on CP side, I guess that will be rectified shortly afair from the past 🙂
Jerry
0 Kudos
SerB
Explorer
Yes, as far as I know, it's just http/https proxy. There are a lot of them. I tried to check a connectivity issue by sk83520 and it seems everything's working. IPS and Anti-bot updates worked yesterday before the accident but they don't work now even though all people say that problem was solved.
0 Kudos
Jerry
Leader
Leader
have you got http trace tool to check how tcp packets travers your network heading towards update services from cp cloud?
you need a decent t-shooting in order to eliminate or rather isolate reasons however, I do agree that not all is fixed based on the certificate CRL list and params currently present on their wildcard cert - let's see what some of our guru's say about it:

@Val
@PhoneBoy
@Tim
@Heiko

anyone have a different thoughts?
Jerry
0 Kudos
SerB
Explorer

Thank you for the advice. Unfortunately, I can't do it right now. Is it possible that the proxy buffered some information or something like that? Is it worth trying to connect an appliance from a test zone to check if it receives an update or not? I mean a new one that doesn't contain any traces on the proxy before the accident.

0 Kudos
Jerry
Leader
Leader
proxy = cache 🙂 try to simply clear its cache (if you know how) and refresh your tcp handshake's. other than that I personaly think it is down to how your proxy process (enc/dec) your https TLS1.3 and CLR params. I'd have try to clear the cache on Proxy but ultimately I'd restart gaia in question (cpstop/cpstart or simply all following:

tellpm process:httpd2
tellpm process:httpd2 t
$DADIR/bin/dastop
$DADIR/bin/dastart
service ntpd restart

in order to see if cpuse will get a glimpse of current cp cert with no CLR enforcement 🙂

cheers!
Jerry
0 Kudos
Jerry
Leader
Leader
slightly worrying indeed: look at this:

* servercert: Activated
* servercert: crl_disable from registry: 1
* servercert: CRL validation was disabled
* Server certificate:
* subject: CN=*.checkpoint.com
* start date: Jun 4 13:23:27 2020 GMT
* expire date: Sep 7 13:23:27 2022 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA DV SSL CA 2018
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* servercert: Finished
Jerry
0 Kudos