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

Also available in: Atom PDF