CRL has expired

ads76

Issue resolved. After I found that the CRL expiry was getting updated but was still for some reason in 1955 after making tweaks to the OpenVPN config, I looked at what was in config.xml for the CRL and found that the lifetime was 99999 days, rather than 9999 is recommended. Changed it to 9999 and re-imported and it's working properly now.

Thanks for pointing me in the right direction @jimp.

barryboden

Looks like we have a similar issue too. I've got a pair of Netgate 7100's which all of a sudden today are not letting users connect. When I look at the CRL it shows a date of Jan 1950 for the next issue.
I've tried recreating the CRL with 9900 days or setting the vpn server not to use a CRL but its still showing the error.
Is there a fix for the date roll over issue.
22.05-RELEASE (amd64)
built on Wed Jun 22 18:56:13 UTC 2022
FreeBSD 12.3-STABLE

ads76

@barryboden My issue may not be yours and I don't know about 22.05 (we're using CE), but I found if I exported the config (or just looked at it in /cf/conf/config.xml) in the <crl> section there was:

<lifetime>99999</lifetime>

I understand there was a change in OpenVPN between the versions used in 2.4.5p1 and 2.6.0 where the verification of the CRL was moved from being done by OpenVPN to being handled by OpenSSL which was stricter. It would be worth looking at what the CRL lifetime value is in your config.xml.

I found changing it in config.xml and rebooting didn't work, pfSense must write its config out before rebooting. I had to export the config through the GUI, update the lifetime field (to 9999) then reimport it. In a crisis, you can just disable use of the CRL until you figure it out but obviously that would allow users with revoked certs to log in again.

That's as far as I can help you. Hope it does.

mmulqueen

@barryboden See my posts here https://forum.netgate.com/topic/174167/no-clients-can-connect-to-openvpn-due-to-crl-expiry

I'd suggest recreating the CRL with a much shorter lifetime (I did 730 days). Be sure to edit the OpenVPN server settings to point to the new CRL and then restart the OpenVPN service.

barryboden

@ads76 thanks for your reply I did look in there any my config already says 9999, I've created new CRLs and if I set them to 9990 the dates look ok, but 9999 must roll over the year.
Adjusting this has got my clients connecting again, for 9 days.

jimp

I created a Redmine entry for this (https://redmine.pfsense.org/issues/13424) and I'll be working on a fix shortly. When I have one, I'll also create an entry in the System Patches package for it.

maverick_slo

@jimp Applied diff manually and restarted Openvpn server service.
It works after restart of service.

jimp

I merged the fix in yesterday evening.

You can install the System Patches package and then create an entry for a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2 to apply the fix.

It will be added as a "Recommended Patch" in the System Patches package soon, but in the meantime it is safe to add a manual entry to obtain the fix now.

davetick

@jimp I've just applied that patch and restarted OpenVPN. CRL expiry error no longer in OpenVPN logs and clients now connecting again - thanks !

PFSense: 22.05-RELEASE (amd64)
KVM Guest
Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
2 CPUs: 1 package(s) x 1 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No

slu

@jimp said in CRL has expired:

You can install the System Patches package and then create an entry for a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2 to apply the fix.

We run into the same issue, lost all VPN connections.
Can we apply this patch also in 2.6.0 CE?

jimp

The patch applies cleanly to 2.6.0, you can use it there.

slu

@jimp
thank you, the VPN working again.

Risfold

Thank you all for the comments and patch solution here. Many of my haproxy backends went down last week (ssl handshake errors) and diagnosing the issue was very difficult.

A lot of trial and error, I narrowed down the backend SSL verification and CRL, as the culprit. I stumbled upon this issue after searching errors related to a downed OpenVPN client. Applying the patch here (obviously) fixed both haproxy and OpenVPN issues I was having.

Just wanted to add my experience in case any others are having the same issues with haproxy, and are looking for a solution. Hopefully they will also find this thread.

Novacom

@jimp

Thank you ! Worked like a charm on 22.05-RELEASE (amd64)

ChrisHaa

Same issue here. Patch solved it within a minute. Thanks.

This has some additional information: https://blog.nuvotex.de/pfsense-crl-has-expired/

ccb056

Y2K all over again

had this same problem, applied the patch, fixed

Thanks Jim

khodorb

I had the same issue with version 2.5 and 22.05, i wonder if netgate has permanent fix for that

michaelschefczyk

Dear All,

Are we really really shure that the patch does fix this? I did apply it and it did work for the moment. After rebooting one of my four pfSense devices (2.6.0-RELEASE (amd64)), I was shut out of all of OpenVPN. The log did contain many entries like this:

Sep 1 18:09:39 openvpn 91912 xxx.xxx.xxx.185:31089 Certificate does not have key usage extension
Sep 1 18:09:39 openvpn 91912 xxx.xxx.xxx.185:31089 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Sep 1 18:09:39 openvpn 91912 xxx.xxx.xxx.185:31089 TLS_ERROR: BIO read tls_read_plaintext error
Sep 1 18:09:39 openvpn 91912 xxx.xxx.xxx.185:31089 TLS Error: TLS object -> incoming plaintext read error
Sep 1 18:09:39 openvpn 91912 xxx.xxx.xxx.185:31089 TLS Error: TLS handshake failed

The certificate did work before. After unchecking "Client Certificate Key Usage Validation", everything was OK again. Until the reboot today, it was no problem to leave "Client Certificate Key Usage Validation" checked.

Regards,

Michael

ads76

@michaelschefczyk I think that is a separate issue:

https://forum.netgate.com/topic/171697/certificate-does-not-have-key-usage-extension/17?_=1662027477402

michaelschefczyk

@ads76 Thank you very much. I did install the patches and I am "thrilled" to see what will happen next. I also hope that the system patches package will not become the replacement for regular system updates