Check Point plans for TLS Certificate Lifetime Reduction

[PhoneBoy]

Yesterday, we published sk184604 which describes our plan to address the transition to a 47-day maximum validity period for publicly trusted SSL/TLS certificates.

These changes impact customers using publicly trusted certificates issued by third-party Certificate Authorities (CAs) that adhere to the updated industry requirements. Affected use cases include, but are not limited to:

• Inbound HTTPS inspection
• Web-based management and service portals (for example: Mobile Access Portal, UserCheck, and other multi-portal websites)
• Additional products and flows that rely on externally issued TLS certificates

TL;DR: We plan to address this as part of releases in 2027.

[Duane_Toler]

Meanwhile, any idea how to handle the "Year 2038" problem?  It's not that far away now... 🫣

[the_rock]

You are 100% right. I keep seeing in my Google photos memories from 13 years ago when my little niece was just 1 year old and now she is a teenager. Time goes by quick...

[JozkoMrkvicka]

Epochalypse (2038 year problem) is semi-fixed in R82.10 and higher versions.

CLI date epoch command didnt fail after 2038 year, but ICA is still limited to 1st of Jan 04:14:07 2038 CEST.

[PhoneBoy]

I didn't say it was actually fixed in R82.10...only that it would be the first release where it would be possible to do so.
The ICA is still limited by the Year 2038 problem per: https://support.checkpoint.com/results/sk/sk158096

[Duane_Toler]

To be fair, the X.509 OID structures aren't using 32-bit integers in their fields. There's a mandate in RFC-5280 for how the fields should be interpreted at 2 different points in time: before 2049 (as UTCTime) and after 2049 (as GeneralizedTime); yes, 2049, not 2038 here.

The problem lies more with the application libraries and software items that try to parse and compute the validity of these fields.  Converting the X.509 OID field to a C library's time_t  structure is where things go off the rails.

A time_t structure is a 32-bit width field (Year 2038 problem), but any library or software that doesn't pay close attention to RFC-5280 is going to hit the Year 2049 problem.  This will manifest as missing the point in time when to change the interpretation of the X.509 OID.  If a host's timeclock isn't in proper sync with NTP or the clock has drifted, madness will ensue.

Parsing of end-host certificates just might be ok because of the 47-day crunch (until they change their mind again and make validities be every 12 hours; oops! don't give them any more ideas!).   Another big issue is going to be in validation against the CA chain, OCSP, and CRLs.  Even worse, those little WiFi gadgets, doohickies, and embedded things are going to be a nightmare.

Get your popcorn, because it's gonna be fun! 🙂

I'm gonna be on vacation for about a week around these two times... in the forest, completely offline, with a paper book.