<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I don't think this was mentioned but you can configure the Shibboleth IDP to support more than one signing private key - basing the key off of the relying party. We had to do this for one of our service providers that was having difficulty updating the public
certificate. That SP continued to use the expired private key for a week or so.</div>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div>
<div></div>
<div id="divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<div style="font-family:Tahoma; font-size:13px">---
<div><span id="ms-rterangepaste-start"></span><span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Roberto Ullfig - rullfig@uic.edu</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Systems Administrator</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Enterprise Applications & Services | Technology Solutions</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">University of Illinois - Chicago</span>
<div><span id="ms-rterangepaste-end"></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> users <users-bounces@shibboleth.net> on behalf of Donald Lohr via users <users@shibboleth.net><br>
<b>Sent:</b> Wednesday, June 8, 2022 3:31 PM<br>
<b>To:</b> users@shibboleth.net <users@shibboleth.net><br>
<b>Cc:</b> Donald Lohr <lohrda@jmu.edu><br>
<b>Subject:</b> Re: Expiring IDP signing certificate</font>
<div> </div>
</div>
<div><font face="Helvetica, Arial, sans-serif">We just went through that exercise.<br>
<br>
Grabbing data from our idp-process.log for many months, we built a spreadsheet with information about our applications. Having researched the "key roll-over" docs on InCommon's site and some valuable assistance from their support for questions we had, we began.<br>
<br>
1) We sent emails to our on-site points of contact for each non-InCommon registered application, alerting them of our expiring cert and asked that they get answers to the following questions from their application vendor:<br>
<br>
<i>a) When our SSO IdP </i><i>SAML/XML metadata certificate expires on xx/yy/2022, what issues will that cause in the SAML message / hand-shaking when one of our users tries to login
</i></font><font face="Helvetica, Arial, sans-serif"><i><font face="Helvetica,
Arial, sans-serif"><i>to your application</i></font>?<br>
<br>
b) Can your application properly parse an SSO IdP SAML/XML metadata when it contains an expiring and a new certificate?<br>
<br>
c) Do you want our </i><i>SSO IdP SAML/XML metadata as an emailed file or a url? Or do you just need a cert file containing only our new
</i><i>SSO IdP </i><i>SAML/XML</i><i> certificate?</i><i><br>
</i><i><br>
<br>
</i>2) When then took our 30 heaviest used / critical InCommon registered applications and sent emails to our on-site points of contact for their applications, alerting them of our expiring cert and asked that they get answers to the following questions from
their application vendor:<br>
<br>
<i>a) When our SSO IdP SAML/XML metadata (registered with the InCommon Federation) certificate expires on xx/yy/2022, what issues will that cause in the SAML message / hand-shaking when one of our users tries to login to your application?<br>
<br>
b) Can your application properly parse an SSO IdP SAML/XML metadata when it contains an expiring and a new certificate?
<br>
</i><br>
<br>
3) Having the non-InCommon registered application responses from the vendors, we gleaned:<br>
<br>
a) A very large percentage of these application vendors reported that they could not handle metadata with both an expiring cert and a new cert.<br>
b) Some wanted just the new cert file, some wanted just our IdP metadata file and others wanted a url to our metadata.<br>
c) A number of vendors reported that our on-site application admin could make the change to the application's SSO config panel.<br>
d) A very large number reported that logins would fail when the expiring cert expired.<br>
<br>
<br>
4) Having the InCommon registered application responses from the 30 vendors we asked, we gleaned:<br>
<br>
a) One vendor did not support InCommon's two cert roll-over model.<br>
b) Three/four vendors only pulled our IdP metadata from InCommon at the initial setup and never looked again for changes. So the vendor or an on-site application admin had to make the change to the application's SSO config panel.<br>
c) Many vendors check IdP metadata at each user login for changes, some once a day, some every X number of minutes and we had one that only checked every 50 days.<br>
<br>
We minted a new self-signed cert off of our existing private key that had minted the expiring cert years ago (per InCommon's docs).<br>
<br>
So we announced the date/time that our new cert would be in our InCommon registered IdP metadata (in position #2) following our expiring cert (in position #1) and ready for our vendors to consume. Once our new InCommon IdP metadata (with both certs) was consumable,
we had folks testing logins based on the frequency the vendors reported that they pulled new IdP metadata from InCommon for those 30 most used/critical applications. All logins were successful, as the expiring cert was still being used.<br>
<br>
Several days later (as we were on a time crunch) we replaced the expiring cert in our IdP locally stored metadata file with our new cert and changed our Shib config over to used only the new cert on our go-live morning.<br>
<br>
We addressed all of the apps that had an on-site admin which had access </font><font face="Helvetica, Arial, sans-serif"><font face="Helvetica, Arial, sans-serif">to the application's SSO config panel.<br>
<br>
Based on what the responses were from the polled vendors, we told them the day before, when they could pull our local IdP metadata with the new cert and for those that wanted a metadata or cert file we provided them that so they were ready to change their application
just after our official go-live date/time when we switched our Shib IdP config to use only the new cert.<br>
<br>
We had a few minor application issues on our go-live morning, mostly around those vendors that just wanted the cert in a non-block format (converted into a single line).<br>
<br>
Then on the date/time our expiring cert expired, our InCommon registered apps, no login issues were repoted<br>
<br>
The use of the Firefox "SAML tracer" add-on was very helpful during all of this.<br>
<br>
Don<br>
<br>
<br>
<br>
</font></font>
<div class="x_moz-cite-prefix">On 6/3/22 11:51 AM, Ho, PeiQuan via users wrote:<br>
</div>
<blockquote type="cite">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:DengXian}
@font-face
{font-family:Calibri}
@font-face
{}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
span.x_EmailStyle17
{font-family:"Calibri",sans-serif;
color:windowtext}
.x_MsoChpDefault
{font-family:"Calibri",sans-serif}
div.x_WordSection1
{}
-->
</style><b><span style="font-size:10pt; color:rgb(112,48,160); background:rgb(255,235,156)">CAUTION:
</span></b><span style="font-size:10pt; color:black; background:rgb(255,235,156)">This email originated from outside of JMU. Do not click links or open attachments unless you recognize the sender and know the content is safe.</span>
<hr>
<div>
<div class="x_WordSection1">
<p class="x_MsoNormal">Hi,</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal"> Our IDP signing certificate as used in shibboleth.DefaultSigningCredential is expiring. It is the 10-year self-signed certificate as recommended during installation. What is the process to update/rollover this cert with minimal impact
to SPs?</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">Thanks,</p>
<p class="x_MsoNormal">-PQ</p>
<p class="x_MsoNormal"> </p>
</div>
</div>
<br>
<fieldset class="x_moz-mime-attachment-header"></fieldset> </blockquote>
<br>
<pre class="x_moz-signature" cols="72">--
D o n a l d L o h r
I n f o r m a t i o n S y s t e m s
J a m e s M a d i s o n U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0
</pre>
</div>
</body>
</html>