Year 2038 problem again ...

[DH]

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...

[Chris_Atkinson]

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

[DH]

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...

[israelfds95]

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.

[the_rock]

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

[DH]

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

[the_rock]

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]#

[Bob_Zimmerman]

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.

[the_rock]

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.

[israelfds95]

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

[the_rock]

Agree.

[Bob_Zimmerman]

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

[PhoneBoy]

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.

[the_rock]

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

[WiliRGasparetto]

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