IMPORTANT - Action Required For VPN/Remote Access Security Gateways Using DigiCert - by Sep 8, 2025

[_Val_]

Hi CheckMates!

This message is relevant only for customers using VPN Site-to-Site and Remote Access VPN Security Gateways using certificates issued by DigiCert External CA.

No action is required if DigiCert External CA is not deployed on your Security Gateways. 

To check if your VPN/Remote Access Security Gateways use DigiCert External CA, follow these simple steps in the sk183884.

On September 8, 2025, DigiCert will stop supporting HTTP/1.0 for OCSP and CRL checks. Without upgrading protocol support, DigiCert certificate validation may fail, and will affect Site-to-Site and Remote Access VPNs on Check Point gateways.

To maintain VPN continuity, a tool has been provided to identify VPN/Remote Access gateways using the DigiCert External Certificate, followed by a hotfix update to be applied on the gateway, upgrading communication to HTTP 1.1.

All information regarding affected Security Gateways, using the discovery tool, and the hotfix is available here.

Support services are available for questions or assistance at https://www.checkpoint.com/support-services/contact-support/.

UPDATE: The SK now has all hotfixes you might need directly linked, as we al the scripts and verification steps to make sure you might need them

UPDATE 2: For those with outbound HTTPS Inspection, there is another SK available: https://support.checkpoint.com/results/sk/sk183887

[Scott_Paisley]

Hi

We were just alerted to this which requires action in the next week. Looking at the SK it says the remediation for gateways is to open a ticket with support

Is there a better way?

Thanks

[_Val_]

The mentioned SK is still a work in progress. All required hotfixes and also a script to check whether you even need them should be available in the SK quite soon.

The better way is to wait till it is finalized and all tools to get everything under control are available there. 

[Scott_Paisley]

ok, thanks

[_Val_]

Once everything is in place, we will create a post and merge all related discussions

[the_rock]

Thanks for that Val.

[Alex_Lewis]

I contacted Digicert support, and this affects all Digicert brands, which include GeoTrust and RapidSSL. The discovery tool provided in the SK only checks for a string provide on the command line so it should be run three times for each CA string:

•  ./DigiCert_CA_search.sh DigiCert
• ./DigiCert_CA_search.sh GeoTrust
• ./DigiCert_CA_search.sh RapidSSL

[the_rock]

Thanks for that @Alex_Lewis 

[baby79]

how to check this via cli if firewalls have site to site and remote access and digicert. i only have 2 firewalls i am literally new to checkpoint and i wamt to check this manually i also dont have smart console. 

[_Val_]

Read https://support.checkpoint.com/results/sk/sk183884, it has all the information you need. 

[PhoneBoy]

While there may be some additional updates to the SK, including the script that tests whether a hotfix is needed, we now have patches that can be deployed on top of the most recent JHF for releases going back to R80.40 as well as updated firmware for Quantum Spark appliances.
This fix will be rolled into Jumbo Hotfixes also.

[Paul_Hagyard]

The SK article is not that clear... I just posted the following under "was this page helpful":

"The SK article mentions a hotfix to fix issues with site-to-site VPNs or remote access VPNs with user certificates signed by Digicert, but it then discusses checking the GATEWAY certificate to see if it is signed by Digicert. Is the issue with VPN RAS user certs, gateway certs, or both?"

We have a customer using a Digicert certificate on the gateway side in conjunction with SAML for VPN RAS. In such a scenario it should only be the client doing OCSP/CRL checks, not the gateway. Endpoint Security simply trusts the site's CA certificate fingerprint (which always seemed inadequate), but with SAML the client launches a browser (OS now by default I think) to connect so THAT should handle the OCSP/CRL check.

It sounds like it should only be an issue for the gateway if it is doing checks itself - for site-to-site VPNs or with user certificates, correct?

[the_rock]

I believe those scripts mentioned should verify that.

Andy

[Paul_Hagyard]

Where are the scripts mentioned? Looking through sk183884 I can only see CLI commands like "enabled_blades"

[the_rock]

I believe ones @Alex_Lewis  mentioned should be there. Hard to check it on my phone, but will have a look in a bit.

Andy

[the_rock]

You are 100% correct, my apologies. I could have sworn I saw one script mentioned on Friday, but guess must have been removed.

Andy

[Thomas_Eichelbu]

Hello Check Mates

what about Digicert Certificates which are used on portals?
like for Mobile Access blade or other platform portals?

do we face the same issue here?

[Paul_Hagyard]

It looks like it is when the gateway is doing the OCSP/CRL, so it should only apply:

1. Site-to-site VPNs where the remote party to the Check Point environment is using Digicert certificates (instead of PSK).
2. Remote access VPNs where the remote user is using Digicert certificates as part of the authentication.
3. Outbound HTTPS inspection.

So all other scenarios, such as Digicert certificates on gateway portals (server certificates) should not be an issue.

[796570686578]

Hi,
we had the same question and opened a ticket for it. We got confirmation yesterday that SAML and MAB portals are not affected by the issue even if you use DigiCert signed certificates.

[Hugo_vd_Kooij]

I checked the Article on saterday and today (monday) but there is no script attached to the SK article.

As we need to put automation to work to go over our installed base we are in serious need of a way to avoiud many hours of work just to learn which customer are effected by this issue.

[the_rock]

Im 100% positive there was a script there on Friday, August 29th, I saw it myself.

[Hugo_vd_Kooij]

I peeled down the onion a bit and decided it can be simplified to this:

1. Open each CMA and Smartcenter in turn.
2. Open Object List, Goto Server then goto Certificat CA
3. If only internalCA is listed your done withthis one, Next customer please.
4. If other CA's are listed then check if they are still valid and contain the relevant organisation (DigiCert or ...), If none found ... Next customer
5. Investigate if the certificate is used. If not, Next customer.
6. Call customer to get Maintenance window.

[the_rock]

Yea, thats actually very good simplified process.

[Alex-]

So, does this fix apply to Digicert or others will be necessary if/when any other emitter follow suit?

Is this going to be integrated in maintain JHF? Why is HTTP 1.0 still so absolutely mandatory after all that time that a dedicated fix is required?

[the_rock]

The sk is not clear to me about section for fixes where its fixed, it lists hotfixes, but then says on top of below fixes.

Little confusing...

Andy

[Alex-]

It's just been released in today's JHF for R81.10 I see.

PRJ-63340, PRHF-41560

HTTPS Inspection, VPN

UPDATE:Updated CRL and OCSP validation in Remote Access VPN, Site-to-Site VPN (sk183884), and HTTPS Inspection (sk183887) to use HTTP/1.1 instead of HTTP/1.0. This ensures continued compatibility with DigiCert's updated requirements and prevents certificate validation failures.

[the_rock]

Included in hotfix or fix on top of hotfix?

[the_rock]

Nm, I see its part of jumbo 181 for R81.10. Released today, September 1st. I checked jumbo 39 for R82, no mention there or anything for R81.20 yet.

Andy

[MatanYanay]

Hi all 

Just to be clear, the fix plan is to be part of all our upcoming jubmos

as mention it was already released in R81_10_jumbo_hf_main take 181  

and will be part of the next R81.20 and R82 jumbos 

Thanks 

Matan.

[the_rock]

Thanks for clarifying that Matan!

Andy