<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; ">What is my false premise?<span class="Apple-converted-space"> </span><br>Why shouldn't I change the certificate?<span class="Apple-converted-space"> </span><br>What do you think I want it to mean?<br></span></blockquote><div><br></div><div>I think Scott's concerned that you're crossing certificates that are used for front-channel communication with browser users and certificates that are used for encryption and signature in communication with IdP's. There is no technical reason why these certificates need to be the same, and in fact, there are some benefits to making them different, most notably the short expirations of commercial browser-facing SSL certificates.</div><div><br></div><div>I think he's trying to communicate that there may be no need to change this certificate. That said, in your environment, there may very well be one that we don't know about.</div><div><br></div><blockquote type="cite">Plus, I copied the certificate metadata directly from Shibboleth itself:</blockquote><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; "><a href="https://sp-qa-machine01/Shibboleth.sso/Metadata">https://sp-qa-machine01/Shibboleth.sso/Metadata</a><br><br>How do I know if the metadata is accurate? I copied and pasted the relevant KeyDescriptor section, and have double and triple checked.<span class="Apple-converted-space"> </span><br></span></blockquote><div><br></div><div>The metadata is likely to be fine, although I know the dynamic metadata generator is not recommended for anything beyond simple use cases. You just need to ensure that the new certificate is there.</div><div><br></div><div>You may be encountering a situation where the SP is using its old certificate for the actual transaction even though the metadata for the SP contains both certificates, and the IdP only trusts the new SP certificate.</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; ">How do I specify a rule in the IP to use the new certificate? Are you referring to Attribute rules?<br></span></blockquote><div><br></div><div>The SP can be configured to use a non-default certificate with a specific IdP:</div><div><br></div><div><a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRelyingParty">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRelyingParty</a></div><div><br></div><div>The default is the first one listed in shibboleth2.xml.</div><div><br></div><blockquote type="cite">I did 're-order' the certificates in the metadata, because I commented out the first SP certificate so only the new SP certificate would be visible in the metadata.<br></blockquote></div><br></div><div>The order in the metadata doesn't, AFAIK, matter. If you commented out the first SP certificate without modifying the SP's configuration so that it's using the new certificate, then the behavior you experience is exactly what I would expect.</div><div><br></div><div>I'm not sure if you've yet read:</div><div><br></div><div><a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCredentials">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCredentials</a>#NativeSPMultipleCredentials-KeyRollover</div><div><br></div><div>Anyway, I'd try inverting the order of the CredentialResolver elements in your shibboleth2.xml file. You can also look at the logs on the IdP to see exactly what certificate your SP is using for the communication if you continue to encounter problems.</div><div><br></div><div>Take care, and thanks for your use of Shibboleth,</div><div>Nate.</div></body></html>