Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> Bug confirmed, and it's systemic. The AJP connector protocol specifically
> passes a single client certificate (and JK extracts it from a specifically
> named CGI header) to the Coyote connector.
>
> There is *no* way to use the standard Java APIs to extract the entire client
> chain.
>
> So, cool. Nothing works. ;-)

At least I wasn't imagining it, but that's little comfort.

> In practice, chains are dumb. The PKIX code doesn't care if the anchor is
> self-signed. So you can trust the issuer directly, and I don't see why
> anybody wouldn't be able to live with that. But fixing it doesn't really
> seem possible in any other way.

I've now tested that in our case, adding the intermediates in question 
to the EntitiesDescriptor /Extensions /KeyAuthority list allows the IdP 
to validate the "path".  I imagine, though, that it is not validating 
the whole path to the self-signed root but only to the immediate signer 
of the end certificate; do you agree?  Is there a way to confirm this 
with the current codebase?

I think you're right, that we should be able to live with this, 
particularly if the alternative is holding our breath until someone 
fixes AJP...  I'm assuming that adding intermediates to the KeyAuthority 
list won't cause trouble for 1.2 entities; do you know of any issues 
that might come up there?

Final question: I'm interested to hear that the code doesn't care if the 
anchor is self-signed, as I thought that OpenSSL (as used by the C++ 
SP?) had just such a limitation?  That implies to me that we need to 
keep the whole chain of intermediates in the metadata even if it 
shouldn't strictly be required (the chain I'm looking at is strictly 
A->B->C->client with no branching, so A and B are superfluous unless a 
self-signed root is required by someone).

        -- Ian