PKIX path building failed

[Cantor, Scott]

> >You either have it, or the server sends it, or it fails.
>
> That's very helpful in narrowing down my "suspects."

My guess is that maybe Windows' PKIX code might follow AIA extensions, but I would be surprised if anything else did. OpenSSL definitely does not, and unless I'm deeply mistaken, Java doesn't. We would be pretty concerned about that sort of thing because once you start going HTTP GET operations, you introduce almost guaranteed concerns over timeout settings.

> The server should only send back its chain up to the root (that's
> "working").

It really depends on the chain. If you have a well-defined trust anchor, then the server sends everything but that anchor. When you have intermediates and people splicing into the chain, it gets much less clear what one "should" do. What you have to do is send everything up to and perhaps except for the one anchor used by the client. So you have to know every client or make assumptions.

> The only place Shib will look for the trusted root or an intermediate that
> wasn't sent is in the file pointed to by idp.authn.LDAP.trustCertificates
> (which only contains the AddTrust External CA Root).

If idp.authn.LDAP.sslConfig is defaulted, yes.

> The "proper" way to handle this scenario is for me to include the
> USERTrust RSA Certification Authority (intermediate) in the file pointed
> to by idp.authn.LDAP.trustCertificates since the server is not sending it
> (and shouldn't since it's properly sending its chain up to its root).

That generally means the server should be sending it if it wants to support clients that don't preconfigure that CA.

If this is the Comodo SHA-1 / SHA-2 switch, the appropriate practice according to their transition is that there are additional intermediates that servers need to send.

-- Scott