PKIX path building failed

[Dave Bartholomew]

Shibboleth 3.2.1.1 64-bit

Windows Server 2012 R2

java version "1.8.0_111-b14" (Oracle JDK)

AD on Windows Server 2008 R2, used for both authN and attribute retrieval

Embedded Jetty.



A little over a month ago, our dev IdP stopped working with the following
error when doing authN/attribute retrieval against our dev AD:



[Root exception is javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target]]



However, it continued to work against AD.



InCommon-issued certificate chains are as follows:



dev AD:



<server cert>

InCommon RSA Server CA

USERTrust RSA Certification Authority (root, self-signed, but not included
in root CA list for browsers)



AD:



<server cert>

InCommon RSA Server CA

USERTrust RSA Certification Authority (intermediate)

AddTrust External CA Root



On dev AD, USERTrust RSA Certification Authority is self signed with the
same name and public key (and SubjectKeyIdentifier) as the other
incarnation on AD which is signed by AddTrust External CA Root.



The USERTrust RSA Certification Authority certificate has
http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt for an Authority
Information Access (AIA) location which does chain to AddTrust External CA
Root.



Both servers are doing as they are expected in that they both send their
certificates (excluding the root) back to the client, so I can understand
why AD would work since it is getting all the certificates it needs up to
the root.



My idp.authn.LDAP.trustCertificates file contains the AddTrust External CA
Root.



With Java SSL debugging turned on for SSL, I see the following in
stderrout.log:



adding as trusted cert:

AddTrust External CA Root



*** Certificate chain

chain [0] = [

<server cert>



chain [1] = [

InCommon RSA Server CA



SubjectKeyIdentifier [

KeyIdentifier [

0000: 1E 05 A3 77 8F 6C 96 E2   5B 87 4B A6 B4 86 AC 71  ...w.l..[.K....q

0010: 00 0C E7 38



  Algorithm: [SHA384withRSA]

  Signature:

0000: 2D 11 06 38 D6 DB D7 58...



%% Invalidated:  [Session-1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]

Thread-18, SEND TLSv1 ALERT:  fatal, description = certificate_unknown



I can "fix" this by adding the self-signed USERTrust RSA Certification
Authority cert to my idp.authn.LDAP.trustCertificates file.



If I'm sniffing the network after an IdP restart and things are working
normally, should I expect to see an HTTP GET for
crt.usertrust.com/USERTrustRSAAddTrustCA.crt to complete the chain via the
AIA? It looks like Shib suddenly lost its ability to use the AIA.



As far as I'm aware, the only thing that changed that seems like it could
be related was a core router configuration reload earlier in the day.



What I don't get:

The persistent failure.

I wasn't in the middle of configuration changes, it just went poof in the
evening.

It was working just fine for many months.

I can't seem to catch Shibboleth or ldp.exe in the act of grabbing the AIA.

OpenSSL connects OK.



Any ideas would be appreciated.

Thanks,

--Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161027/18627868/attachment.html>