CRL has expired

[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

[khodorb]

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();
    }
  

[jagradang]

Is this patch still valid or have the changes for this now been rolled into the latest build?

[Gertjan]

@jagradang

Why ? You still use 22.05 from 2022 ?
These days, its 24.11 or 2.7.2 - I don't recall issues from 2022.