<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Warren,<div><br></div><div>Silly question, perhaps, but did you add another CredentialResolver?</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>It'd explain the behavior you're witnessing perfectly. The Wiki article has a sentence talking about your experience:</div><div><br></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Helvetica, Arial, sans-serif; font-size: 13px; line-height: 17px; ">So in this case, you <b>MUST</b> configure both the old and new credentials into the SP so that either key can be available for decryption.</span></div><div><br></div><div>Give that a try if you haven't already,</div><div>Nate.</div><div><br><div><div>On Sep 22, 2011, at 0:38 , Leung, Warren wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,<br><br>We have a SP where a certificate is expiring soon, so we wanted to do an<br>SP key rollover. We added another KeyDescriptor(2 total) into the IdP<br>metadata both with no use attribute. After the metadata is refreshed into<br>the IdP we get the following error on the SP<br><br>2011-09-21 15:51:01 ERROR Shibboleth.SSO.SAML2 [1]: Unable to resolve any<br>key decryption keys.<br><br>The relying-party.xml is configured like the following for SAML2. No<br>errors appear on the IdP logs.<br><br> <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"<br>includeAttributeStatement="true" assertionLifetime="PT30M"<br>assertionProxyCount="0" signResponses="never" signAssertions="always"<br>encryptAssertions="conditional" encryptNameIds="never"/><br><br>I could get things to work to by making sure the valid certificate is the<br>2nd KeyDescriptor in the metadata. It would also work if I made<br>encryptAssertions="never".<br><br><br>Since we are pushing attributes to the SP, the IdP will pick a certificate<br>to encrypt the assertion to the SP and if it is wrong then the error<br>occurs. If it was a pull the SP would present a cert and thus the IdP<br>would know what to use to encrypt it back to the SP. Is my understanding<br>of this correct?<br><br>Is there some configuration or a step I missed that would resolve this?<br><br>Thanks<br><br>Warren Leung<br><br>--<br>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></div></blockquote></div><br></div></body></html>