Certificate and CRL validation fails from March 1, 2026

[simonemantovani]

Hello

accidentally, for the firewall infrastructure of a customer we ran into the issue reported in following SK:

https://support.checkpoint.com/results/sk/sk184766#

For the specific customer we planned to install the suggested hotfix.

Hope it could be useful.

[JBhelm]

After installing the hotfix on all nodes, i still got the error on some nodes. But, after 24h, the error fixed itself on all nodes. Software updates are now working again.

[Hugo_vd_Kooij · Accepted solution]

URGENT WARNING!

While the article seems to indicate this only applies to R82 gateways and above the only thing needed is a R82 or above management.

I just fixed a VPN issue where the customer runs R82 MDS with R81.20 gateways and R81.10 spark applances.

The VPN certificate expire date/time was March 3, 2026 13:44 and today (March 2) at exactly 13:44 the VPN went down.

Applied the workaround from the SK and did a renewal after that to resolve the issue.

The error on the Spark appliance was an "internal error" which I tried to solve based on https://support.checkpoint.com/results/sk/sk170141 but then I verified the exact time when the outage began and it was exactly 24 before expiration.

So I urge everyone to considere all gateways regardless of the version as impacted by this SK if your Management system is on R82 or above.

And the certificate was issued in 2021.

[Hugo_vd_Kooij]

Also note that yesterday you could download Take 2 of the hotfix. (About 2 MB)

But today it is take 5: 

Check_Point_R82_JHF_T60_TIME_FIX_655_MAIN_Bundle_T5_FULL.tar (About 41 MB)

[Steffen_Appel]

For Jumbo 60 it is now take 6.

[RemoteUser]

So I have to install the fix on all gateways that I have r82 and above?

[Steffen_Appel]

yes you have and on the management

[Steffen_Appel]

The HFs have been silently updated, were T2 yesterday, now T5 on JHF60 and T4 on JHF73.

[Evert_Kooter]

Hi,

Although not mentioned in the SK, this also applies to HTTPS inspection. Certificates from websites that have been issued in the last 24 hours are signed with a wrong validity on the gateway so are not valid yet... The gateway adds 24 hours to the valid from field.

We applied the workaround which works well for VPN but not yet the hotfix. Will the hotfix fix the behaviour for HTTPS inspection?

Thanks in advance!

Evert.

[jhsdk]

Yes, the hotfix will fix the HTTPS inspection.

The only way we found to mitigate it, before applying hotfix was to bypass the sites with the error from HTTPS Inspection.

The hotfix only took a few minutes to apply, and then a reboot, after that it worked for us with HTTPS inspection for sites with newer certificates.

[Hugo_vd_Kooij]

The short gist. It impacts EVERYTHING that uses X509 certificates. So any Check Point (virtual) appliance with R82 or above MUST be fixed.

Did anyone ever verify if any VPN client version has been impacted?

[RemoteUser]

Info: Initiating verify of Check_Point_R82_10_GA_TIME_FIX_MAIN_Bundle_aarch64_T2_FULL.tgz...
Interactive mode is enabled. Press CTRL + C to exit (this will not stop the operation)
Result: Installation is not allowed. Reason: Installed hotfixes are missing from this package. Contact Check Point Technical Services for further assistance.

Anyone have this issue on quantum 3920? The verify Failed

[Steffen_Appel]

Yes we have the same issue (already posted it above).

[RemoteUser]

did u solved?

[Steffen_Appel]

No I didn't.

[AngelBuxan]

I have just installed the last hotfix (655) right now and the problem was not solved!!!

[_Val_]

Please open a TAC case for your issue.

[Vanness_Chen]

I have also encountered an update failure issue, but in my case the error occurred during the hotfix package import stage.

Currently, I am waiting for TAC assistance to resolve the issue.

[emmap]

If this is a new install you may need to manually update the DA build, because that won't be happening automatically either.

[Vanness_Chen]

Hi @emmap :
I submitted a TAC case, and TAC recommended reinstalling the system.
The issue has since been resolved.

[PatrickHen]

In follow-up on my previous reply 'Same issue on 3920 which was upgraded from previous build to T464 and seems up-to-date':
Just spoke to TAC. They will work on this issue, but recommend the workaround for now.

[morris]

We had some customers with this issue where the workaround solved the issue (93600 seconds) - no hotfix was applied.

One customer rolled out new devices today and the remote access does not work. The certificate was issued today on 4th March.
Error in SmartLog:

"Client Machine Certificate Error: Certificate will be valid only from Thu Mar 5 12:27:33 2026. "

No "old" machines are currently affected - not yet.

Is the workaround not working anymore?

[Hugo_vd_Kooij]

It seems we have multiple takes of this hotfix. And I would bvery muchg appreciate the difference between the various takes so I can determine if we need to revisit certain systems again with a newer builld of the hotfix.

[CaseyB]

I am also finding this very frustrating.

I understand there can be issues with fixes; however, there is lack of communication when a newer hotfix is released and lack of guidance if I need to spend time applying said hotfix. This morning, I see JHF-44 has been silently updated from Take 8 -> 10, but I have no idea if I need to spend time re-patching.

I am grateful for the community otherwise I would not have been aware of these silent hotfixes in the first place.

[Bob_Zimmerman]

At minimum, we need to know if the new version was released because the old version didn't fix everything, or because the old version caused a new problem.

My team has gotten at least 15 separate email threads about this hotfix (all three of our diamond reps, two PS reps, our SE, our reseller, automated notifications from support-do-not-reply, three separate managers asking about separate email threads all about the same hotfix). It has created a huge amount of work for us because the messaging makes it sound hair-on-fire urgent, but as far as I can tell, there's no impact to my environment as long as I don't build whole new firewalls for a bit. Our diamond reps don't know what differs between the hotfix versions, so even the internal messaging is bad.

The emergency remote access hotfix in mid-2024 had similarly awful messaging. Zero clarity, tons of Check Point reps hassling us to install it even though we didn't have the affected features enabled anywhere.

[Bob_Zimmerman]

The hotfix has been updated again, and again there's no description of what is different or how urgent it is to update to the new version. As of when I post:

R82.10 GA Take 464	Take 9	2026-03-05
R82.10 GA Take 271 Jumbo 22	Take 8	2026-03-04
R82 Jumbo 73	Take 8	2026-03-09
R82 Jumbo 60	Take 11	2026-03-09
R82 Jumbo 44	Take 10	2026-03-05
R82 Jumbo 43	Take 7	2026-03-05
R82 Jumbo 41	Take 4	2026-03-03
R82 Jumbo 39	Take 6	2026-03-05
R82 Jumbo 34	Take 4	2026-03-03

[Steffen_Appel]

Some information about the takes is in the sk now:

"

• If you have VSX, Multi-Domain Management (MDM) or Multi-Domain Log Server, LSM, or CloudGuard Network - install Hotfix Take 5 or later.
• If you have already installed Take 2 and you do not have VSX or MDM (and you are not using LSM or CloudGuard Network) - no further installation is needed right now.
• This Hotfix must be installed on both
  • Management Server / Log Server / SmartEvent Server / CloudGuard Network Management,
    and
  • Security Gateway / Maestro Orchestrator / Security Group / Non-Autoscale CloudGuard Gateways.
• For Smart‑1 Cloud users, the Management hotfix is not relevant - it is already included in the latest MaaS update. Install only the Security Gateway / Maestro Orchestrator / Security Group Hotfix."

[Bob_Zimmerman]

My managements are R82 jumbo 60. There's nothing in the SK or anything anybody has yet sent me about why I might need to go from take 6 (released on 2026-03-06) to take 11 (released 2026-03-09). It's newer, okay, but how is it different?

Are we going to see new issues because we installed take 6?

Are there some places which still had bad date math or whatever the problem is?

If so, what functionality isn't fixed by take 6 (or even by take 2)?

Updating management servers in my environment isn't extraordinarily hard, but people still ask us why we're taking the managements down for a third time in a week. We have multiple dedicated diamond reps, and Check Point isn't telling us anything. There's no way our change control people would approve a third update window for all of the firewalls in that span of time without a detailed explanation of what's going on.

[Steffen_Appel]

It say: "If you have already installed Take 2 and you do not have VSX or MDM (and you are not using LSM or CloudGuard Network) - no further installation is needed right now."

[Bob_Zimmerman]

Sure, but it doesn't say why. We do have MDSs and we are using VSX.

Does that note only apply to environments which use both MDS and VSX, or does it apply to environments which use only one or the other?

Why is take 5 or greater so important for MDS environments and VSX environments?

And I really need to know what did take 2 not fix? What did take 6 not fix? Only a few of the potential problems listed in the SK apply to our environment at all. If going from 6 to 11 is fixing features we don't use, then I'll just skip it.

The lack of clarity is irritating. They're saying "Install this, it'll fix the problem.", followed just days later by "You installed that last version? That version didn't fix the problem. Install this, it'll fix the problem." Okay, what's the reason I shouldn't wait a week, and install take 18 instead?

[Alejandro_Lansa]

Today when I have tried to renew the certificate of one of out R81.10 gateways I have received the error message "Failed creating Certificate. General Problem in Certificate Authority." My Management server R82 Take 60 hat the Hotfix Take2 installed. I have removed that Hotfix, installed the version Take 11 and the Problem is now fixed.