topic Re: Year 2038 problem again ... in Firewall and Security Management

Year 2038 problem again ...

DH — Fri, 30 Jan 2026 09:18:04 GMT

On R82 JHF 120 the date command is unable to convert a date behind 2038...
date +%s -d"Jan 1, 2038 00:00:01"
2145913201
date +%s -d"Jan 1, 2039 00:00:01"
date: invalid date 'Jan 1, 2039 00:00:01'

Will we run into problems when RootCAs that have expire dates behind year 2038 (like ex. Sertigo) because of validation of trust chains with CP?

I ask, because a other customer with different Firewall vendor runs in this problem some weeks ago...

Re: Year 2038 problem again ...

Chris_Atkinson — Fri, 30 Jan 2026 10:03:49 GMT

R81.20 JHF 120? The 2038 problem (epochalypse) is discussed in sk158096 ...

Re: Year 2038 problem again ...

DH — Fri, 30 Jan 2026 10:12:21 GMT

Sorry, my mistake R82 JHF 60 !
I think about the validation of trustchain, for example by HTTPS inspection or Site2Site VPN with external managed gateways, not with the ICA - here I have the option to fix that - on foreign site I'm not able to change that CAs...

Re: Year 2038 problem again ...

israelfds95 — Fri, 30 Jan 2026 10:44:00 GMT

Just to clarify one thing: R82 doesn’t have JHF 120 yet.
Right now, R82 is on JHF 60, while R81.20 is the one with JHF 120.

From what I’ve researched, this looks more like a Unix 32-bit timestamp limitation than a Check Point–specific issue. Other systems have hit the same problem and usually solve it by moving to 64-bit timestamps, but I couldn’t find any clear Check Point documentation (I couldn’t find any mention of a solution for this issue in the R81.10, R81.20, or R82 release notes yet.) saying this is already fully implemented or fixed everywhere.

I did find SK158096 that have a good answer for this year 2038 bug:
https://support.checkpoint.com/results/sk/sk158096 – How to renew an Internal Certificate Authority (ICA) certificate

It mentions that the ICA certificate is valid for 20 years and includes a note about the Year 2038 issue:

"The expiration date of the renewed ICA certificate is restricted to the year 2038.

This is caused by the Year 2038 Problem. Check Point plans to include a fix in an upcoming major release."

Since this SK was last updated in 2025-03-27, it looks like Check Point is already aware of the 2038 issue and has a fix planned on the roadmap.

Re: Year 2038 problem again ...

the_rock — Fri, 30 Jan 2026 12:46:36 GMT

Just wondering...you have ntp configured or no? I ask this because I had never seen this issue when people set time manually.

Re: Year 2038 problem again ...

DH — Fri, 30 Jan 2026 14:53:19 GMT

I did not set the time - I simply use date to convert a time to timeepoch.

Re: Year 2038 problem again ...

the_rock — Fri, 30 Jan 2026 14:57:25 GMT

I see what you mean. I did same on R82 and R81.20 (latets jumbos on both), exact same output.

[Expert@CP-GW:0]# date +%s -d"Jan 1, 2039 00:00:01"
date: invalid date 'Jan 1, 2039 00:00:01'
[Expert@CP-GW:0]# cpinfo -yfw1

This is Check Point CPinfo Build 914000259 for GAIA
[FW1]
HOTFIX_R80_40_MAAS_TUNNEL_AUTOUPDATE
HOTFIX_R82_JUMBO_HF_MAIN Take: 60
HOTFIX_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE
HOTFIX_UCA_SSH_TUNNELING_APP_AUTOUPDATE
HOTFIX_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE
HOTFIX_UCA_INFRA_LOG_SERVICE_AUTOUPDATE
HOTFIX_UCA_INFRA_AUTOUPDATE
HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE
HOTFIX_INEXT_NANO_EGG_AUTOUPDATE
HOTFIX_GOT_TPCONF_AUTOUPDATE

FW1 build number:
This is Check Point's software version R82 - Build 013
kernel: R82 - Build 010

[Expert@CP-GW:0]#

Re: Year 2038 problem again ...

Bob_Zimmerman — Fri, 30 Jan 2026 15:03:08 GMT

This isn't about setting time, it's about comparing time. If firewall wants to confirm a certificate hasn't expired yet, it has to convert the date to a number for comparison. Dates after 2038 convert to a number too big to fit into a signed 32-bit number (the type of number UNIX and Linux have used to represent dates for decades). It overflows and becomes extremely negative, turning into a date in 1901.

https://en.wikipedia.org/wiki/Year_2038_problem

This can result in the system thinking a cert isn't valid before 2037 and is expired after 1910, so it's never valid. I saw a management get its ICA into that state once due to a series of bugs involving NTP.

Re: Year 2038 problem again ...

the_rock — Fri, 30 Jan 2026 15:06:23 GMT

I get it, makes sense now. I was not even aware of the thing with year 2038, first time I hear about it today - : )

Anyway, good challenge to see if this can be fixed, will work on it in the lab.

Re: Year 2038 problem again ...

Bob_Zimmerman — Fri, 30 Jan 2026 15:09:13 GMT

Confirming, R82 jumbo 60 still has the 2038 issue:

[Expert@DallasSC]# cpinfo -y fw1 This is Check Point CPinfo Build 914000259 for GAIA [FW1] HOTFIX_R82_JUMBO_HF_MAIN Take: 60 HOTFIX_NGM_DOCTOR_AUTOUPDATE HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE HOTFIX_WEBCONSOLE_AUTOUPDATE HOTFIX_VCE_R81_20_AUTOUPDATE HOTFIX_INEXT_NANO_EGG_AUTOUPDATE HOTFIX_GOT_MGMT_AUTOUPDATE HOTFIX_GOT_TPCONF_MGMT_AUTOUPDATE FW1 build number: This is Check Point Security Management Server R82 - Build 009 This is Check Point's software version R82 - Build 013 [Expert@DallasSC]# date +%s -d"Jan 19, 2038 03:14:07Z" 2147483647 [Expert@DallasSC]# date +%s -d"Jan 19, 2038 03:14:08Z" date: invalid date 'Jan 19, 2038 03:14:08Z'

Looks like R82.10 switches to 64-bit time_t:

[Expert@SomeFirewall]# cpinfo -y fw1 This is Check Point CPinfo Build 914000224 for GAIA [FW1] HOTFIX_INEXT_NANO_EGG_AUTOUPDATE HOTFIX_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE HOTFIX_UCA_SSH_TUNNELING_APP_AUTOUPDATE HOTFIX_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE HOTFIX_UCA_INFRA_LOG_SERVICE_AUTOUPDATE HOTFIX_UCA_INFRA_AUTOUPDATE HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE HOTFIX_GOT_TPCONF_AUTOUPDATE FW1 build number: This is Check Point's software version R82.10 - Build 767 kernel: R82.10 - Build 768 [Expert@SomeFirewall]# date +%s -d"Jan 19, 2038 03:14:07Z" 2147483647 [Expert@SomeFirewall]# date +%s -d"Jan 19, 2038 03:14:08Z" 2147483648 [Expert@SomeFirewall]# date +%s -d"Jan 19, 20380 03:14:08Z" 580965016448

Re: Year 2038 problem again ...

the_rock — Fri, 30 Jan 2026 15:29:52 GMT

Can you see if this works?

from expert ->

python3 - <<'PY'
import calendar, datetime
dt = datetime.datetime(2040,1,1,0,0,1, tzinfo=datetime.timezone.utc)
print(calendar.timegm(dt.utctimetuple()))
PY

Re: Year 2038 problem again ...

israelfds95 — Fri, 30 Jan 2026 15:39:43 GMT

This is something that need be fixed on Gaia OS code, I beleave this is a good mission for R&D team.

Re: Year 2038 problem again ...

the_rock — Fri, 30 Jan 2026 15:45:48 GMT

Agree.

Re: Year 2038 problem again ...

WiliRGasparetto — Fri, 30 Jan 2026 18:00:25 GMT

Hi, quick question: is NTP enabled in your environment, or do you manage the time manually?

Re: Year 2038 problem again ...

PhoneBoy — Mon, 02 Feb 2026 15:00:26 GMT

64-bit time support was added in the Linux 5.1 kernel, at least per: https://stackoverflow.com/questions/29085124/64-bit-time-t-in-linux-kernel
That implies that R82.10 is the first release it is POSSIBLE to support dates beyond 2038 for SIC.
Whether it does, at current, is a separate question.