pfsense - CRL has expired in openvpn server
A few days ago we ran into an issue where pfsense appliances started to refuse openvpn connections by showing "CRL has expired" error messages. As it shows the reason is an overflow a date.
Within the last days we had an issue that affected pfsense installations upon triggering several actions, mostly adding certificates to revocation list on user decommissioning.
The error in the log was like:
VERIFY ERROR: depth=0, error=CRL has expired: C=DE, ST=Bavaria, L=Augsburg, O=Nuvotex Solutions GmbH Co KG, emailAddress=mail@domain.tld, CN=XXX, serial=XXX TL;DR - Fix
The current fix is to apply a patch to the system using the System Patches package.
ID of the patch: a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2
Add the patch using the Commit ID, fetch it and review the associated changes before applying it.
If everything looks fine, apply it. Triggering a CRL update (by adding/removing a certificate or the other way around) will create a valid CRL for you and everything will work again.
Background - what has gone wrong?
During investigation of this issue, I've done a manual validation of a cert against CA & CRL.
To do this, create a combined file (ca.pem) that contains the public CA certificate and the CRL - as PEM. Also take a cert (public part of it) and place this into a file (crt.pem). Now run openssl to verify the cert against the CA.
openssl verify -crl_check -CAfile ca.pem crt.pemThis will reveal the already known message, that the CRL is expired.
So, take a look at the CRL. You can do that using openssl or a tool like XCA (which is actually very great).
As you can see: CRL has a renewal/expiration date of 1950 - which means that it is for sure already expired.
Why does this happen?
If you check out the related incident in the pfsense bugtracker (https://redmine.pfsense.org/issues/13424) you get the relevant information:
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.
Using your favorite shell (powershell ;-)), you can easily see that we have crossed the date just last week:
(Get-Date "2050/01/01").AddDays(-9999)
Wednesday, 17 August 2022 00:00:00So, if you've updated a CRL past 17th of august 2022, you should apply the fix above.
