Certificate Authorities

We currently use the same list of CAs that the CERN WLCG use, that is, the IGTF list of approved CAs: https://repository.egi.eu/sw/production/cas/1/current/dists/egi-igtf/. The list of these CAs is expected to be hashed and include .namespaces and .signing_policy files, which further restrict the issuance to particular subjects.

This is, however, not the complete story. Not all the processes within the DDM ecosystem use this list in isolation, and not all of them enforce the directives from the signing policies, so the behaviour is not consistent.

Lets consider two particularly important processes: a deletion (via Rucio) and transfers (via FTS).

Deletion (Rucio)

A deletion in Rucio is done by direct communication between the server and the RSE. This communication is done using the gfal2 library.

For https, gfal2 builds upon the Davix library, which in turn uses the API provided by the libneon library. By default, this library checks the OS’s CA store e.g. /etc/ssl/certs used as a trust store by browsers. The Davix library also includes the default path for grid certificates (/etc/grid-security/certificates). There is no adherence to the signing policies.

Transfers (FTS)

Transfers in FTS can either be “third-party copy” (TPC) push or pull (where the two RSEs negotiating the transfer talk to each other directly) or “streamed”.

In the case that the transfer is via TPC push/pull, the source RSE must be able to negotiate an SSL handshake with the destination RSE. How the storage service backing the RSE chooses to compile the list of CAs is dependent on implementation. In the case of StoRM, only the grid certificates directory is checked for CAs, and the signing policies must be adhered to.

If both push and pull fail, streaming mode is attempted (if this setting is enabled in FTS). In this mode, the transfer streams through the FTS node. Under the hood, this streaming is achieved using the gfal2 library, which, as mentioned in the section above, includes OS CAs and does not adhere to the signing policies (well, this is certainly the case for https transfers).

What does this all mean?

  • For https transfers where both sites use OS CAs (not IGTF approved) TPC push/pull will not work. It will, however, be possible to stream through FTS if this setting is enabled.

  • For https transfers where one site uses an OS CA and the other uses an IGTF approved CA, either one of push or pull will work.

  • https deletions (via Rucio) where the site uses an OS CA will work.

TL;DR

When two sites that utilise the https protocol have been secured using OS CAs that are not an IGTF approved CA, they will not be able to negotiate third-party copy transfers; streaming through FTS, however, will work.

Deletions work for sites that have been secured using OS CAs.