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

UPDATE 3: DigiCert Certificate Expiration Mitigated  

We are pleased to share that we have successfully mitigated the DigiCert certificate issue together with DigiCert’s engineering team. There is no need to urgently install a Hotfix on the Security Gateways.  

Your Check Point Security Gateways using Site-to-Site VPN, Remote Access VPN, and Outbound HTTPS Inspection will continue to operate smoothly beyond the September 8, 2025 timeline, even without applying the hotfix in advance.

That said, our latest Jumbo Hotfix Accumulator changes the communication method from HTTP/1.0 to HTTP/1.1, ensuring long-term compatibility with all certificate authority services. We strongly recommend that you install it at your convenience. More details can be found here.

As always, we remain at your service and are here to support you with this or any other issue.

[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

[Ben_Dunkley]

Just adding for completeness:

R82 jhf 41 and R81.20 jhf 115 were released yesterday (3rd Sept) with the fixes included.

[the_rock]

Correct, already installed them in the lab.

Andy

[796570686578]

FYI everyone:

It doesnt seem to be mentioned in the SK yet but I got confirmation from Check Point Support that the SAML portal and MAB portal are not affected by this issue even if you are using the DigiCert signed certificate.

[philipp_98]

we got the same feedback from CP support

[the_rock]

I also got that confirmation from our SE.

[Alex_Lewis]

I'm curious why there isn't an update to the RA VPN client for this. Does the client not do OCSP/CRL checking, or is it getting OCSP/CRL status from the gateway, or is it already using HTTP/1.1 or HTTP/2?

[Paul_Hagyard]

If you are just doing straight VPN RAS connectivity (not SAML) then the first time you connect (unless you pre-populate the registry, which is what you do for a enterprise deployment) you get prompted to trust the fingerprint of the CA certificate for the CA that signed the gateway's VPN RAS certificate. So if you just use the SmartCenter issued gateway certificate you're trusting the ICA certificate, if you use an external CA you are trusting that. It doesn't use OCSP/CRL.

Things are a bit different with SAML because the VPN client uses a browser to make the connection so it can handle the IDP authentication - in this case the browser or OS certificate store needs to trust the gateway's certificate and it would use OCSP/CRL - but it is the browser doing it, not the VPN client itself. And browsers would have moved to a current protocol a long time ago.

[Moti · Accepted solution]

 UPDATE - DigiCert Certificate Expiration Mitigated  

Hi CheckMates 

We are pleased to share that we have successfully mitigated the DigiCert certificate issue together with DigiCert’s engineering team. There is no need to urgently install a Hotfix on the Security Gateways.  

Your Check Point Security Gateways using Site-to-Site VPN, Remote Access VPN, and Outbound HTTPS Inspection will continue to operate smoothly beyond the September 8, 2025 timeline, even without applying the hotfix in advance.

That said, our latest Jumbo Hotfix Accumulator changes the communication method from HTTP/1.0 to HTTP/1.1, ensuring long-term compatibility with all certificate authority services. We strongly recommend that you install it at your convenience. More details can be found here.

As always, we remain at your service and are here to support you with this or any other issue.

[Thomas_Eichelbu]

Hello Moti!

yes cool info, my critical question is:
At which date DigiCert published this change? 
Or when did Check Point got notice about this issue?

After unsettling all Check Point customers worldwide, finally all concerns are futile now?
Yes i know technical things are complicated and a thorough investigation is always required ...

but please ... 
Dont get me wrong i highly highly appreciate your pro active approach.
But we need to be careful with "near - catastrophic informations" like this ...

Digicert added the following notice

https://docs.digicert.com/en/whats-new/change-log/certcentral-change-log.html#digicert-ending-suppor...

so the issue is NOT entirely resolved, just delayed. Installing the hotfix is of course recommened!

best regards

[spottex]

Yes I'm not confident. We have moved some clients off DigiCert.
sk183884 now states that http/1.0 will work beyond 22 sept.

"There is no need to update your Check Point Security Gateways for Site-to-Site VPN, Remote Access VPN, and Outbound HTTPS Inspection for sites working with a DigiCert-generated certificate. These services will continue to operate smoothly beyond the 22 September 2025 timeline, even without applying the hotfix in advance."

[the_rock]

Thats my understanding as well.

[spottex]

Just noticed this on the DigiCert update

"Beginning September 22, 2025, DigiCert will only support Hypertext Transfer Protocol (HTTP)/1.0 with a proper Host header, HTTP/1.1, and HTTP/1.2 connections for Online Certificate Status Protocol (OCSP) and certificate revocation lists (CRL) checks."

I just need to find out how to check for a proper host header now 🙂

https://docs.digicert.com/en/whats-new/change-log/certcentral-change-log.html

[the_rock]

Just to copy the full thing as well 🙂

Andy

*********************

What do I need to do?

Before September 22, 2025, ensure that all OCSP and CRL integrations for certificate status verification use HTTP/1.0 connections with a proper Host header or HTTP/1.1 or later versions of the protocol.

• Verify every client, agent, and integration that communicates with DigiCert OCSP and CRL services uses HTTP/1.0 with a proper Host header or HTTP/1.1 or HTTP/1.2.

• Update or replace any legacy software that still use HTTP/1.0 without a proper Host header for OCSP and CRL certificate status verification.

• Monitor for blocked OCSP and CRL certificate status verification requests.

Failure to upgrade protocol support may interrupt workflows related to OCSP and CRL certificate status verification.

[PhoneBoy]

An HTTP host header looks something like:

Host: community.checkpoint.com

Host headers in HTTP were optional prior to HTTP/1.1.
SNI effectively serves the same function for HTTPS, namely to tell the remote end what website to serve up.

[spottex]

So as long as CP adds the host name of the OSCP server in its OSCP request it will be considered a proper host heading?

...and does it?

[spottex]

I captured an OCSP request and it did have the host. so Looks good
The host is the URL in the cert converted to ocsp.xxx.xxx. Manual telnet connection to the converted URL connects.
I've pasted it below blacking out the URL as it is an internal CA.

Update: Actually, I found the OCSP URL in the Authority Information Access, as an alternative Name

[PhoneBoy]

Yes and yes.
This was explicitly tested and verified with DigiCert also.
This is why we are no longer requesting impacted users to urgently install a fix.

[the_rock]

Thats what I got from all the emails floating around as far as this issue.

Andy