dCache
Support additional (non-IGTF) trust anchors for server certificates
There are only a few situations where dCache acts as a client and establishes a connection to a remote site. Perhaps most prominently, this happens when transferring data with HTTP-TPC and dCache is the "active party".
Currently (by default), dCache uses the standard set of trust anchors from IGTF, located in the /etc/grid-security/certificates directory.
However, remote sites may have multiple user communities, including those who do not trust IGTF CAs. There is an alternative set of trust anchors (set of CAs) called CAB. The CAB set of trust anchors is accepted by all major web browsers, and is widely adopted by other HTTP clients.
May distributions provide the CAB set of CAs in a standard location; typically as a single file containing all CA certificates in PEM format; for example, see /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem.
It is desirable that dCache somehow (through configuration or a script) is told to accept CAB services in addition to IGTF CAs when validating certificates of a remote site.
For reference: As a fix for the Sectigo IGTF signing fiasco, I have packaged two additional CA certificates for Swestore in the IGTF format. This was a bit hard and the files does not contain all the correct information. Most of the trouble being getting the namespace and signing policy files correct(ish). Just dropping additional CA certificates in a directory would help a lot and make it possible to support communities that are not in the WLCG+IGTF sphere (think Letsencrypt here).
letsencrypt certificates (with policy files) are by default distributed in osg-ca-certs package.
I have a proof-of-principle implementation here: a set of three patches:
Patch: https://rb.dcache.org/r/13064/ Patch: https://rb.dcache.org/r/13065/ Patch: https://rb.dcache.org/r/13066/
The first two are simple preparatory patches, while the last one adds support for CAB (albeit with some caveats).
From my limited testing, it works. I hope to do some more testing "soon".
There is a limitation, though. As-is, the patch doesn't support any form of certificate revocation (e.g., no CRL, no OCSP or OCSP-stapling).