OpenVPN 2.4.4: Cannot connect with external CRL

sepp_huber

Hi,

I have something similar to this:
Re: OpenVPN (2.4.x?) fails with pfSense 2.4.0 if CRL is specified

After upgrading from 2.3.5 to 2.4.4 my openVPN clients cannot connect anymore.
When the clients connect I get this message ... "CRL has expired".

Nov 19 13:55:01	openvpn	27942	XXX.YYY.200.13:59373 VERIFY ERROR: depth=0, error=CRL has expired: C=DE, ST=Monaco, L=Monaco, O=YYYYY, OU=System Administration, CN=mycert3, name=NNNNN, emailAddress=myemail@XXXXXX.YY

Our certificates and also the CRL are managed and created outside pfsense and were just uploaded.
If the CRL is not used it, the connection is working...

Unfortunately, this is not an option, because we already have several revoked certificates.

Any ideas?

jimp

What hardware is this on?

netblues

There has been a change in openvpn about a year ago, enforcing crl's to 30 days.
Previously crls' wouldnt expire. (or it wouldn't be enforced anyways)
I suppose the code has been migrated to pf, and the issue resurfaced.
You should re-create the CRL at regular intervals. By default, the CRL expires after 30 days. This is controlled by the default_crl_days option in the [ CA_default ] section.

I was bittern by this last summer on a fresh openvpn install.

jimp

@netblues said in OpenVPN 2.4.4: Cannot connect with external CRL:

You should re-create the CRL at regular intervals. By default, the CRL expires after 30 days. This is controlled by the default_crl_days option in the [ CA_default ] section.

OP said their CRL was generated externally, so that could be the case, but here is some additional info that may be relevant:

pfSense defaults the CRL lifetime to be several years. The default is 9999 days on 2.4.4, though 2.4.4-p1 lowers that to 3650 and even lower in some cases to avoid 32-bit UNIX timestamp overrun on some ARM systems.

If the ending validity timestamp is beyond the UNIX timestamp rollover in 2038, some processes on ARM could miscalculate the date and think it's invalid when it's not.

We also changed the CRL processing library on 2.4.4. Before, it was using a patched version of the PHP openssl library that added CRL support, but that no longer worked on PHP 7.x. So we moved to a pure PHP CRL implementation. It's possible there is some quirk here nobody else has hit, but we need to eliminate other more likely causes first.

sepp_huber

@jimp said in OpenVPN 2.4.4: Cannot connect with external CRL:

OP said their CRL was generated externally, so that could be the case, but here is some additional info that may be relevant:

Yes, that is the case! In my openssl.cnf I found:

default_crl_days= 30

Thanks for the hint, I will try to regenerate it ... never used this before ;-)

sepp_huber

@sepp_huber said in OpenVPN 2.4.4: Cannot connect with external CRL:

default_crl_days

One pitfall for me was, that "default_crl_days" must be set in the environment where the CRL is generated and NOT on the pfSense instance.

Which is just logical ;-)