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

[Jerry]

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]

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.

[Dorit_Dor · Accepted solution]

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]

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

Cheers
Jerry

[_Val_]

Thank you Dorit, we appreciate the transparency.

[SerB]

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.

[Jerry]

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 🙂

[SerB]

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.

[Jerry]

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?

[SerB]

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.

[Jerry]

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]

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