Project

General

Profile

Actions
Copy link

Bug #13424

closed

CRL expiration date with default lifetime is too long, goes past UTCTime limit

Added by Jim Pingle over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Very High
Assignee:
Jim Pingle
Category:
Certificates
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

The default lifetime on internal CRLs is 9999 which as of now lands the expiration of a CRL past 2050. The CRL library uses a UTCTime string for dates which has a 2-digit year and 2050 dates, shortened to 50, are rolled back to 1950.

Reducing the default lifetime of internal CRLs is safe as they are regenerated as needed not manually, they would rarely approach any CRL expiration date as any time a CRL consumer service restarts it refreshes the CRL contents and gets a fresh expiration date.

2 years (730 days) should be more than sufficient.

Also the backend code should reduce the maximum allowed CRL lifetime so it doesn't cross that time barrier.

This is affecting production systems using CRLs so any fix should also be added to the system patches package so affected users can apply the fix ASAP.

Files

13424.diff (2.49 KB) 13424.diff Jim Pingle, 08/17/2022 11:11 AM
Actions
Copy link
 #1

Updated by Jim Pingle over 2 years ago

Actions
Copy link
 #2

Updated by Greg M over 2 years ago

Applied diff manually.

Restarted OpenVPN server service, bingo, it works!
Thanks!

Actions
Copy link
 #3

Updated by Jim Pingle over 2 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Jim Pingle over 2 years ago

The patch has been committed into the System Patches package and will be available to users there soon once some work on the build system is complete.

In the meantime, users can install the System Patches package and then create an entry for a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2 to apply the fix immediately.

Actions
Copy link
 #5

Updated by Danilo Zrenjanin over 2 years ago

Tested the patch:

22.05-RELEASE (amd64)
built on Wed Jun 22 18:56:13 UTC 2022
FreeBSD 12.3-STABLE

1. The lifetime of the newly created CRLs is 730 days.
2. The backend code didn't allow me to define a lifetime longer than 8996 days.

Yet, the CRL I defined before applying the patch still has a lifetime of 9999 days (at least that's listed in the config.xml file). Shouldn't that be reduced after applying the patch automatically?

Actions
Copy link
 #6

Updated by Jim Pingle over 2 years ago

The patch does not alter the configuration or lifetimes of existing entries, it (a) reduces the default for new CRL entries, (b) prevents a user from manually setting a lifetime too large, and (c) ensures no CRL is generated with a lifetime near the limit, even if configured to do so.

It has protections in place for both the 2050 rollover for all platforms as well as 2038 rollover for 32-bit platforms.

Actions
Copy link
 #7

Updated by Oleg Utkin over 2 years ago

The fix doesn't work after turning off pfsense. After switching on, the error repeats. Restarting the vpn service or the entire pfsense server helps, but after shutting down everything repeats.

Actions
Copy link
 #8

Updated by Jim Pingle over 2 years ago

I can't reproduce that here. Start a thread on the forum to discuss your problem further.

Actions
Copy link
 #9

Updated by Christopher Cope about 2 years ago

  • Status changed from Feedback to Resolved

Tested on

22.05-RELEASE (amd64)
built on Wed Jun 22 18:56:13 UTC 2022
FreeBSD 12.3-STABLE

Marking resolved.

Actions
Copy link
 #10

Updated by Jim Pingle about 2 years ago

  • Plus Target Version changed from 22.11 to 23.01
Actions
Copy link

Also available in: Atom PDF