CRL's not found, revoked cert still able to log in

gnieboer

System Config:
pfSense 2.4.4_3
LDAP authentication to an MS Active Directory.
MS Root CA installed as trusted CA for LDAP
pfSense Intermediate CA installed using cert from Root
pfSense Server Certificate issued by Root (but also tried with a server cert issued by intermediate CA)
VPN user Certificate issued by Intermediate CA
User added to AD
Client is iOS OpenVPN, config exported using tool.
CRL manually downloaded from Root CA and added to Cert Manager
CRL for Intermediate CA created by pfSense GUI

OpenVPN Server key config:
TLS + User Auth.
Use AD for Authentication Backend
Use TLS static key
Peer Cert Authority: Intermediate CA
Peer CRL: Intermediate CA CRL
Max Cert Depth set to 2

Client is able to log in fine and access sites just fine, so that's good.
But when I revoked the certificate, the user is still able to log in.
Examination of the logs revealed:
VERIFY WARNING: depth=2, unable to get certificate CRL: CN=Root CA ...
VERIFY WARNING: depth=1, unable to get certificate CRL: CN=Intermediate CA ...
VERIFY WARNING: depth=0, unable to get certificate CRL: CN=vpnuser ...

After the warning the TLS verification succeeded, I assume because the CRLs weren't loaded so the certificate was assume to still be valid.

Using SSH, I found the certificates in the config.xml file, and the reference ID for the CRL in the OpenVPN config seems to match the ID later on the file. I've tried various configurations of server certs and CRLs with no change.

This appears to have been reported previously:
https://forum.netgate.com/topic/142156/certificate-revocation-issue-when-using-intermediate-ca (Apr 2019)
https://forum.netgate.com/topic/136672/openvpn-crl-verification-fails (Oct 2018)
but neither post seems to have generated a response, both appear to be using an intermediate CA as I am.

EDIT: Found a bug reported in the pfSense tracker here: https://redmine.pfsense.org/issues/9889
so this appears to be a "known" issue related to intermediate CAs and may be inherited from OpenSSL. A bit surprising it's a "Very Low" priority since it is a significant security issue that revoking a certificate is ineffective.

jimp

It's "Very Low" because there is very little that we can do about it. It needs to be fixed in OpenSSL and/or OpenVPN.

gnieboer

OK, I see the logic. Thanks.