<div dir="ltr">As I understand message from SalesForce, they will not sign requests with the expired cert;<div>so if you want signed requests, you have to generate a new cert from within Salesforce. <br>(That may be implicit in what Scott wrote.)</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 11, 2017 at 7:10 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Thank you for your quick response. Salesfoce’s signing certificate is going to<br>
> expire. In their document, they say “If you do SP-initiated SAML and your<br>
> Identity Provider validates signatures, you must select a new Request Signing<br>
> Certificate.”. I guess it’s a good practice to use a valid certificate, but not<br>
> required.<br>
<br>
</span>Just because Shibboleth doesn't break doesn't mean SalesForce won't. The systems using the keys typically enforce the same inappropriate rules on themselves, which is even dumber than the recipient doing it, so chances are it will break.<br>
<br>
That's why if you see a short term cert for encryption you're probably advised to consider whether you really want to turn on encryption, or expect to manually manage the rollover on some arbitrary schedule.<br>
<br>
I just federated with Oracle's cloud stuff, and they have a cert expiring in 2019. I left encryption on, but they use the same key for signing their requests (which I can't turn off) so no matter what I do, I'm either around in 2019 or it breaks.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a></div></div></blockquote></div><br></div>