<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<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="moz-cite-prefix">On 6/3/22 11:51 AM, Ho, PeiQuan via
users wrote:<br>
</div>
<blockquote type="cite" cite="mid:DM6PR05MB44441C74CBEFD99458BEBEC59EA19@DM6PR05MB4444.namprd05.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<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="WordSection1">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">-PQ<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
<pre class="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>
</body>
</html>