Namespace checking applied to host certificates under HTTP-TPC #65
Labels
Comments
paulmillar
added a commit
to paulmillar/storm-webdav
that referenced
this issue
Nov 26, 2024
Motivation:
For HTTP-TPC, the checking of Subject DN makes no sense, as the identity
being asserted by the EEC is the DNS name of the host.
Modification:
Add configation option to allow different checking modes, as supported
by the CaNL library. The default option, if none specified, is the
existing mode `EUGRIDPMA_AND_GLOBUS_REQUIRE`, providing backwards
compatibility.
Result:
No user or admin visible changes by default. StoRM-WebDAV now supports
an admin configuring the namespace checking mode via:
storm:
tls:
namespace-checking-mode: IGNORE
Closes: italiangrid#65
paulmillar
changed the title
paulmillar
added a commit
to paulmillar/storm-webdav
that referenced
this issue
Nov 27, 2024
Motivation:
Namespace checking rejects certificates if the subject DN is not one of
the allowed values for that certificate's CA. A list of allowed subject
DNs is maintained by IGTF for their trust store.
There are two problems with this approach.
1. it is IGTF specific. There is no equivalent for CA/B, making
interoperability with CA/B-approved CAs non-trivial.
2. for HTTP-TPC, the check is pointless. It protects the
certificate's Subject DN, which plays no role in the identity of
the remote site. Instead, the X.509 v3 Subject Alternative Name is
used, instead.
Modification:
Update the SSLContext (which includes the certificate chain validation)
for the Apache HTTP client. There is (no longer) any namespace checking
for such certificates.
Note that the namespace checking for client X.509 certificates (which is
the intended target of namespace checking) is unaffected by this change.
Result:
HTTP-TPC now works with remote sites that have a CA/B certificate and
using the system standard trust store.
Closes: italiangrid#65
paulmillar
added a commit
to paulmillar/storm-webdav
that referenced
this issue
Nov 27, 2024
Motivation:
Namespace checking rejects certificates if the subject DN is not one of
the allowed values for that certificate's CA. A list of allowed subject
DNs is maintained by IGTF for their trust store.
There are two problems with this approach.
1. it is IGTF specific. There is no equivalent for CA/B, making
interoperability with CA/B-approved CAs non-trivial.
2. for HTTP-TPC, the check is pointless. It protects the
certificate's Subject DN, which plays no role in the identity of
the remote site. Instead, the X.509 v3 Subject Alternative Name is
used, instead.
Modification:
Update the SSLContext (which includes the certificate chain validation)
for the Apache HTTP client. There is (no longer) any namespace checking
for such certificates.
Note that the namespace checking for client X.509 certificates (which is
the intended target of namespace checking) is unaffected by this change.
Result:
HTTP-TPC now works with remote sites that have a CA/B certificate and
using the system standard trust store.
Closes: italiangrid#65
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The CaNL library supports different namespace checking modes; for example, using the Globus
.signing_policyfiles or EuGPMA.namespacesfiles and whether to fail the certificate validation test if the required file(s) are missing.When working with non-IGTF trust anchors (e.g., CA/B trust anchors), these files typically do not exist.
Moreover, with HTTP-TPC, the identity being asserted in the certificate is the DNS name, which is recorded in the X.509 v3 Subject Alternative Name field. The host certificate's DN is irrelevant in this case, so enforcing namespace makes no sense as this protects the EEC Subject DN (and nothing else).
The text was updated successfully, but these errors were encountered: