Ошибка openvpn crl has expired

I’m testing upgrades between 2.4.5p1 to 2.6.0. The upgrade itself seems to go fine, I’m just testing services post-upgrade and found an issue with OpenVPN refusing TLS auth saying the certificate revocation list expired:

Jun 17 17:57:25	openvpn	90723	1.2.3.4:42081 TLS Error: TLS handshake failed
Jun 17 17:57:25	openvpn	90723	1.2.3.4:42081 TLS Error: TLS object -> incoming plaintext read error
Jun 17 17:57:25	openvpn	90723	1.2.3.4:42081 TLS_ERROR: BIO read tls_read_plaintext error
Jun 17 17:57:25	openvpn	90723	1.2.3.4:42081 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Jun 17 17:57:25	openvpn	90723	1.2.3.4:42081 VERIFY ERROR: depth=0, error=CRL has expired: C=GB, ST=London, L=London, O=MyOrg, emailAddress=technical@myorg.com, CN=myuser, serial=2

If I disable the use of the CRL in the OpenVPN server instance, clients can connect fine.

The CRL was created on this very pfSense box and would have used the default lifetime of 9999 days. That may have been on 2.2.6 and carried up through reinstalls to 2.4.5p1 or it may have been created on 2.4.5p1, I can’t remember now.

I think I can see the issue here:

me@myhost:~/$ openssl crl -in Revoked+Certs.crl -noout -text 
Certificate Revocation List (CRL):
<snip>
        Last Update: Jun 17 17:25:44 2022 GMT
        Next Update: Apr 25 17:25:44 1955 GMT

Does that next update field mean the expiry date? If so, it looks like it’s off by about a century.

If I look at the one from the other firewall in the HA pair, which wasn’t upgraded yet, I see this:

        Last Update: Jun 17 18:06:54 2022 GMT
        Next Update: Nov  1 18:06:54 2049 GMT

So the one that got upgraded got messed up, right?

Can anyone advise on how to either extend the date of the existing CRL, or recreate it without losing which certs were revoked? I revoked some certs and deleted the actual certs so I can’t create a new CRL and then revoke the certs again. Googling I’ve seen suggestions to use easyrsa, but that doesn’t appear to be on my pfSense box.

The CRL is rewritten with a fresh date every time it rewrites the OpenVPN configuration.

What hardware is this on? If it’s a 32-bit ARM system it may be having a problem with the date going past 2038.

@jimp Thanks for your reply Jim.

This is AMD64. I’ll make a tweak to the OpenVPN config in that case and see if the issue goes away. It didn’t when I reconfigured the OpenVPN server instance to not use the CRL though, so we’ll see. I also tried adding another entry to the CRL, but that didn’t help. I’ll come back to update on whether it helped or not.

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 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.

@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.

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.

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.

@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

@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?

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.

@jimp

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

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

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

Y2K all over again

had this same problem, applied the patch, fixed

Thanks Jim

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

Those are the changes on the patch

https://github.com/pfsense/pfsense/commit/a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2#diff-d2a6b2f1c6de8faca0eb12c53221e1874fa9943f07f6df127fb153cd1e03ba34

From a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2 Mon Sep 17 00:00:00 2001
From: jim-p jimp@netgate.com
Date: Wed, 17 Aug 2022 12:09:36 -0400
Subject: [PATCH] CRL lifetime fixes to avoid rollover. Fixes #13424

src/etc/inc/certs.inc | 29 +++++++++++++++++++++++—
src/usr/local/www/system_crlmanager.php | 6 ++—
2 files changed, 30 insertions(+), 5 deletions(-)

diff —git a/src/etc/inc/certs.inc b/src/etc/inc/certs.inc
index c73a964f3ab..16a011d21eb 100644
— a/src/etc/inc/certs.inc
+++ b/src/etc/inc/certs.inc
@@ -54,6 +54,9 @@ $cert_altname_types = array(
global $cert_max_lifetime;
$cert_max_lifetime = 12000;

+global $crl_max_lifetime;
+$crl_max_lifetime = 9999;
+
function & lookup_ca($refid) {
global $config;

@@ -978,9 +981,31 @@ function cert_get_max_lifetime() {
return min($max, $cert_max_lifetime);
}

+/* Detect a rollover at 2050 with UTCTime

• • See: https://redmine.pfsense.org/issues/9098 */
    +function crl_get_max_lifetime() {
• global $crl_max_lifetime;
• $max = $crl_max_lifetime;
• $now = new DateTime(«now»);
• $utctime_before_roll = DateTime::createFromFormat(‘Ymd’, ‘20491231’);
• if ($date !== false) {

•   $interval = $now->diff($utctime_before_roll);
  

•   $max_days = abs($interval->days);
  

•   /* Reduce the max well below the rollover time */
  

•   if ($max_days > 1000) {
  

•   	$max_days -= 1000;
  

•   }
  

•   return min($max_days, cert_get_max_lifetime());
  

• }
• /* Cannot use date functions, so use a lower default max. */
• return min(7000, cert_get_max_lifetime());
  +}

function crl_create(& $crl, $caref, $name, $serial = 0, $lifetime = 3650) {
global $config;

• $max_lifetime = cert_get_max_lifetime();

• $max_lifetime = crl_get_max_lifetime();
  $ca =& lookup_ca($caref);
  if (!$ca) {
  return false;
  @@ -1017,7 +1042,7 @@ function crl_update(& $crl) {
  require_once(‘X509_CRL.php’);

  global $config;

• $max_lifetime = cert_get_max_lifetime();

• $max_lifetime = crl_get_max_lifetime();
  $ca =& lookup_ca($crl[‘caref’]);
  if (!$ca) {
  return false;
  diff —git a/src/usr/local/www/system_crlmanager.php b/src/usr/local/www/system_crlmanager.php
  index d471209d3e3..4b3ed0a6f33 100644
  — a/src/usr/local/www/system_crlmanager.php
  +++ b/src/usr/local/www/system_crlmanager.php
  @@ -34,8 +34,8 @@
  require_once(«pfsense-utils.inc»);
  require_once(«vpn.inc»);

-$max_lifetime = cert_get_max_lifetime();
-$default_lifetime = min(9999, $max_lifetime);
+$max_lifetime = crl_get_max_lifetime();
+$default_lifetime = min(730, $max_lifetime);

global $openssl_crl_status;

@@ -255,7 +255,7 @@
}

	if ($pconfig['method'] == "internal") {

•   	$crl['serial'] = empty($pconfig['serial']) ? 9999 : $pconfig['serial'];
  

•   	$crl['serial'] = empty($pconfig['serial']) ? '0' : $pconfig['serial'];
    	$crl['lifetime'] = empty($pconfig['lifetime']) ? $default_lifetime : $pconfig['lifetime'];
    	$crl['cert'] = array();
    }