<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal">Shibboleth 3.2.1.1 64-bit</p><p class="MsoNormal">Windows Server 2012 R2</p><p class="MsoNormal">java version "1.8.0_111-b14" (Oracle JDK)</p><p class="MsoNormal">AD on Windows Server 2008 R2, used for both authN and attribute retrieval</p><p class="MsoNormal">Embedded Jetty.</p><p class="MsoNormal"> </p><p class="MsoNormal">A little over a month ago, our dev IdP stopped working with the following error when doing authN/attribute retrieval against our dev AD:</p><p class="MsoNormal"> </p><p class="MsoNormal">[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]]</p><p class="MsoNormal"> </p><p class="MsoNormal">However, it continued to work against AD.</p><p class="MsoNormal"> </p><p class="MsoNormal">InCommon-issued certificate chains are as follows:</p><p class="MsoNormal"> </p><p class="MsoNormal">dev AD:</p><p class="MsoNormal"> </p><p class="MsoNormal"><server cert></p><p class="MsoNormal">InCommon RSA Server CA</p><p class="MsoNormal">USERTrust RSA Certification Authority (root, self-signed, but not included in root CA list for browsers)</p><p class="MsoNormal"> </p><p class="MsoNormal">AD:</p><p class="MsoNormal"> </p><p class="MsoNormal"><server cert></p><p class="MsoNormal">InCommon RSA Server CA</p><p class="MsoNormal">USERTrust RSA Certification Authority (intermediate)</p><p class="MsoNormal">AddTrust External CA Root</p><p class="MsoNormal"> </p><p class="MsoNormal">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.</p><p class="MsoNormal"> </p><p class="MsoNormal">The USERTrust RSA Certification Authority certificate has <a href="http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt">http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt</a> for an Authority Information Access (AIA) location which does chain to AddTrust External CA Root.</p><p class="MsoNormal"> </p><p class="MsoNormal">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.</p><p class="MsoNormal"> </p><p class="MsoNormal">My idp.authn.LDAP.trustCertificates file contains the AddTrust External CA Root.</p><p class="MsoNormal"> </p><p class="MsoNormal">With Java SSL debugging turned on for SSL, I see the following in stderrout.log:</p><p class="MsoNormal"> </p><p class="MsoNormal"><span style="font-family:"Courier New"">adding as trusted cert:</span></p><p class="MsoNormal"><span style="font-family:"Courier New"">AddTrust External CA Root</span></p><p class="MsoNormal"><span style="font-family:"Courier New""> </span></p><p class="MsoNormal"><span style="font-family:"Courier New"">*** Certificate chain</span></p><p class="MsoNormal"><span style="font-family:"Courier New"">chain [0] = [</span></p><p class="MsoNormal"><span style="font-family:"Courier New""><server cert></span></p><p class="MsoNormal"><span style="font-family:"Courier New""> </span></p><p class="MsoNormal"><span style="font-family:"Courier New"">chain [1] = [</span></p><p class="MsoNormal"><span style="font-family:"Courier New"">InCommon RSA Server CA</span></p><p class="MsoNormal"><span style="font-family:"Courier New""> </span></p><p class="MsoNormal"><span style="font-family:"Courier New"">SubjectKeyIdentifier [</span></p><p class="MsoNormal"><span style="font-family:"Courier New"">KeyIdentifier [</span></p><p class="MsoNormal"><span style="font-family:"Courier New"">0000: 1E 05 A3 77 8F 6C 96 E2 5B 87 4B A6 B4 86 AC 71 ...w.l..[.K....q</span></p><p class="MsoNormal"><span style="font-family:"Courier New"">0010: 00 0C E7 38</span></p><p class="MsoNormal"><span style="font-family:"Courier New""> </span></p><p class="MsoNormal"><span style="font-family:"Courier New""> Algorithm: [SHA384withRSA]</span></p><p class="MsoNormal"><span style="font-family:"Courier New""> Signature:</span></p><p class="MsoNormal"><span style="font-family:"Courier New"">0000: 2D 11 06 38 D6 DB D7 58...</span></p><p class="MsoNormal"><span style="font-family:"Courier New""> </span></p><p class="MsoNormal"><span style="font-family:"Courier New"">%% Invalidated: [Session-1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]</span></p><p class="MsoNormal"><span style="font-family:"Courier New"">Thread-18, SEND TLSv1 ALERT: fatal, description = certificate_unknown</span></p><p class="MsoNormal"> </p><p class="MsoNormal">I can "fix" this by adding the self-signed USERTrust RSA Certification Authority cert to my idp.authn.LDAP.trustCertificates file.</p><p class="MsoNormal"> </p><p class="MsoNormal">If I'm sniffing the network after an IdP restart and things are working normally, should I expect to see an HTTP GET for <a href="http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt">crt.usertrust.com/USERTrustRSAAddTrustCA.crt</a> to complete the chain via the AIA? It looks like Shib suddenly lost its ability to use the AIA.</p><p class="MsoNormal"> </p><p class="MsoNormal">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.</p><p class="MsoNormal"> </p><p class="MsoNormal">What I don't get:</p><p class="MsoNormal">The persistent failure.</p><p class="MsoNormal">I wasn't in the middle of configuration changes, it just went poof in the evening.</p><p class="MsoNormal">It was working just fine for many months.</p><p class="MsoNormal">I can't seem to catch Shibboleth or ldp.exe in the act of grabbing the AIA.</p><p class="MsoNormal">OpenSSL connects OK.</p><p class="MsoNormal"> </p><p class="MsoNormal">Any ideas would be appreciated.</p><p class="MsoNormal">Thanks,</p><p class="MsoNormal">--Dave</p><p class="MsoNormal"> </p></div></body></html>