Sibboleth SP v3.x Metadata Signature validation using PKIX trust engine question

[Pieter van der Meulen]

> On 10 Nov 2023, at 17:48, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> Specifying the name is obviously required, otherwise you'd have no security whatsoever. This isn't TLS, the name can't really come from anywhere else other than the configuration. That's the only thing that designates the actual signer.

That is true if the CA issues different certificates for different purposes, then you'd need an additional mechanism to determine which certificates are allowed to sign the metadata. So with TrustedName you try to do the equivalent of server name validation of a TLS server certificate. That explains the reasoning.

We have an offline root CA that has only one purpose, issue metadata signing certificates. There is not intermediate CA, we were trying to keep the CA as simple as possible. The private key of the metadata signing certificate resides in an HSM and is not exportable. Should something go wrong with the HSM, we must generate a new private key. The root CA is there for continuity.

>> It appears that the signing certificate must be explicitly whitelisted and that
>> it being issued by a trusted CA is not enough. 
> 
> That is not the case if it's configured properly and the necessary intermediates are available to build the path.

I tried adding only the CN of the Root CA as TrustedName, but then the metadata signing certificate issued by the CA is not accepted:

DEBUG XMLTooling.TrustEngine.PKIX : adding to list of trusted names (SURFconext CA 2023)
DEBUG XMLTooling.TrustEngine.PKIX : adding to list of trusted names (https://engine.surfconext.nl/authentication/idp/metadata)
DEBUG XMLTooling.TrustEngine.PKIX : certificate subject: CN=SURFconext metadata signing 2023.0,OU=SURFconext,O=SURF B.V.,ST=Utrecht,L=Utrecht,C=NL
DEBUG XMLTooling.TrustEngine.PKIX : unable to match DN, trying TLS subjectAltName match
DEBUG XMLTooling.TrustEngine.PKIX : unable to match subjectAltName, trying TLS CN match
ERROR XMLTooling.TrustEngine.PKIX : certificate name was not acceptable


Are you saying that you can add de CN/DN of an intermediate CA certificate as TrustedName and that then any certificates that are issue by the intermediate CA are trusted?

> -- Scott

Pieter.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4325 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20231114/ccd35cd4/attachment.p7s>