<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Chloe,<div><br></div><div><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Thanks Nate. I was under the impression that the IDP picked and chose which certificate it used for encrypting, and that the SP must be ready to decrypt with any certificate that was currently in the metadata, based on the information I found here:<br><br><a href="https://www.switch.ch/aai/docs/shibboleth/SWITCH/sp-certificate-rollover.html">https://www.switch.ch/aai/docs/shibboleth/SWITCH/sp-certificate-rollover.html</a><br></span></blockquote><div><br></div><div>The IdP does, and the SP should. Your understanding here was correct. However, the rough inverse is also true: the SP can pick and choose a certificate it uses for trusted communications, and the IdP must trust that certificate for that SP when it's presented based on a comparison with the SP's metadata.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Since I controlled the metadata file on the IDP, I thought I could just comment it out and the IDP would not use it when talking to the SP.<span class="Apple-converted-space"> </span><br></span></blockquote><div><br></div><div>You could, and that would be the the effect. Your errors relate to the SP using an SP certificate that the IdP doesn't trust, not the IdP using an SP certificate that the SP doesn't trust. If that makes any sense. :D</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">I guess it's the other way around, and the SP sends encrypted messages to the IDP instead.<br></span></blockquote></div></div><br><div>The SP does utilize its own certificate in communications with the IdP(not necessarily to "encrypt messages" specifically, but similar idea). In this specific event, the SP is trying to issue a back-channel query for a SAML Artifact to your IdP. The query is issued over a mutually authenticated SSL/TLS tunnel, which means the SP needs to present a trusted certificate to the IdP in that conversation.</div><div><br></div><div>The IdP will determine whether it trusts that certificate for that SP based on metadata. However, the IdP's web server handles the query first, and unless configured to do otherwise, it will decide to reject the connection before it even gets to the IdP.</div><div><br></div><div>Typically, you'll want to tell the IdP's web server to leave all the SSL/TLS trust work to the IdP. An example of how to do that in a pure Tomcat environment is here under "Supporting SOAP Endpoints":</div><div><br></div><div><a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare</a></div><div><br></div><div>With Apache, you can handle this with SSLVerifyClient optional_no_ca. There are several examples on the web, but it's not an officially supported deployment configuration.</div><div><br></div><div>Finally, you could always teach the IdP's web server to trust the SP's certificates. That's just usually a large configuration hassle that's best avoided, though.</div><div><br></div><div>Hope this helps,</div><div>Nate.</div></body></html>