search

dlgroep / fetch-crl

The fetch-crl utility will retrieve certificate revocation lists (CRLs) for a set of installed trust anchors, based on crl_url files or IGTF-style info files. It will install these for use with OpenSSL, NSS or third-party tools.
https://www.nikhef.nl/pdp/fetchcrl3/
Apache License 2.0
6 stars 0 forks source link

Fetch-crl doesn't work on EL9 with IGTF CAs #4

Closed vokac closed 2 months ago

vokac commented 3 months ago

I have clean installation of EL9

[root@localhost ~]# rpm -qa ca-policy-egi-core fetch-crl
ca-policy-egi-core-1.128-1.noarch
fetch-crl-3.0.22-1.el9.noarch

and fetch-crl fails to download CRLs for several IGTF core CAs

[root@localhost ~]# /usr/sbin/fetch-crl | grep ^ERROR
ERROR CRL verification failed for ArmeSFo/0 (ArmeSFo)
ERROR CRL verification failed for DigiCertGridRootCA-Root/0 (DigiCertGridRootCA-Root)
ERROR CRL verification failed for IHEP-2013/0 (IHEP-2013)
ERROR CRL verification failed for LIPCA/0 (LIPCA)
ERROR CRL verification failed for PK-Grid-2007/0 (PK-Grid-2007)
ERROR CRL verification failed for RDIG/0 (RDIG)
ERROR CRL verification failed for RomanianGRID/0 (RomanianGRID)
ERROR CRL verification failed for SRCE/0 (SRCE)
ERROR CRL verification failed for TRGrid/0 (TRGrid)
maarten-litmaath commented 2 months ago

Hi Petr, that looks compatible with the known issue & workaround we need on EL9:

https://twiki.cern.ch/twiki/bin/view/LCG/EL9vsSHA1CAs

vokac commented 2 months ago

Hi Maarten,

I'm fully aware of workarounds, but I hope we agree that we don't want to keep workarounds forever. So I'm trying to push WLCG to get from IGTF official timeline when they will drop Root CAs that are no longer "actively maintained" and were not able to move away from SAH1.

Just because IGTF keeps few bad Root CAs we have to deal with operational issues everywhere and we already wasted too much time because the lack of effort of just few Root CA operators.

dlgroep commented 2 months ago

The issue is not with fetch-crl, but in the way that the distribution (EL9, assuring RedHat here) has put specific constraints on their products and how those interact with the CAs whose CRLs are being retrieved. For chain validation fetch-crl uses the system-provided OpenSSL version by default, but you configure it to use another build of OpenSSL that is not encumbered in this way. In the general section of the config file (/etc/fetch-crl.conf or in a file in /etc/fetch-crl.d/) set

openssl=/usr/local/bin/openssl

and provide a build of OpenSSL (v1+) that continues to recognise self-signed roots for what they are (i.e. the signature and hash function used for these is immaterial to their security).

Unfortunately, there is nothing fetch-crl itself can solve here, since it uses the openssl version as available on the system. RedHat (case 03335679) provided a work-around that they themselves use for the system CAs (many of which also are SHA-1 based. This involves changing the certificates on-disk to a RedHat/OSSL proprietary format "BEGIN TRUSTED CERTIFICATE" that appends specific trust bytes to the certificate binary blob that will override the bespoke crypto-policies limitation that RedHat built into OpenSSL. While in itself a simple operation (see e.g. https://www.nikhef.nl/~davidg/tmp/make-trusted.sh) be aware that this results in a non-standard on-disk certificate format that will not be recognised by any other software apart from RedHat's OpenSSL. It depends on your use cases whether this is an acceptable solution.

@maarten-litmaath already provided a reference to the system-wide work-around:

update-crypto-policies --set DEFAULT:SHA1

but whether that is acceptable depends on policy alignment so that your other use of SHA-1 is controlled, and on any regulatory requirements that apply to you.

Meanwhile, there is unfortunately nothing fetch-crl itself can do to alleviate the RedHat EL9 issues.