PKIX path building failed
Dave Bartholomew
Dave.Bartholomew at csueastbay.edu
Fri Oct 28 19:23:51 EDT 2016
>I don't know what that URL is from, but if it's some certificate
extension
Yes, it's from the Authority Information Access (AIA) extension.
>You either have it, or the server sends it, or it fails.
That's very helpful in narrowing down my "suspects."
>When Java just breaks randomly, it means there was a Java update.
Not in this case, as I control that.
>If OpenSSL works, then it's using different trust anchors.
Right, as does ldp.exe which is able to find the intermediate it requires
based on, I assume, some combination of name/public
key/SubjectKeyIdentifier and which breaks if I disable that certificate
even though it's not in the direct path that the dev AD server maintains.
Here's my "corrected" understanding of how things work:
The server should only send back its chain up to the root (that's
"working").
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).
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).
Please let me know if the above is not correct, but assuming it is, the
only way I can make sense out of what happened is that the dev AD server
suddenly stopped also sending the root back. I don't think it was sending
it in the first place, but I can look for any saved Wireshark capture
files that might tell a different story.
If that's not it, then I'm still as lost as ever as to what went poof in
the night...
More information about the users
mailing list