Expiring IDP signing certificate

[Donald Lohr]

We just went through that exercise.

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.

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:

/a) When our SSO IdP //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 ///to your application/?

b) Can your application properly parse an SSO IdP SAML/XML metadata when 
it contains an expiring and a new certificate?

c) Do you want our //SSO IdP SAML/XML metadata as an emailed file or a 
url? Or do you just need a cert file containing only our new //SSO IdP 
//SAML/XML//certificate?//
//

/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:

/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?

b) Can your application properly parse an SSO IdP SAML/XML metadata when 
it contains an expiring and a new certificate?
/

3) Having the non-InCommon registered application responses from the 
vendors, we gleaned:

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.
b) Some wanted just the new cert file, some wanted just our IdP metadata 
file and others wanted a url to our metadata.
c) A number of vendors reported that our on-site application admin could 
make the change to the application's SSO config panel.
d) A very large number reported that logins would fail when the expiring 
cert expired.


4) Having the InCommon registered application responses from the 30 
vendors we asked, we gleaned:

a) One vendor did not support InCommon's two cert roll-over model.
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.
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.

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).

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.

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.

We addressed all of the apps that had an on-site admin which had access 
to the application's SSO config panel.

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.

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).

Then on the date/time our expiring cert expired, our InCommon registered 
apps, no login issues were repoted

The use of the Firefox "SAML tracer" add-on was very helpful during all 
of this.

Don



On 6/3/22 11:51 AM, Ho, PeiQuan via users wrote:
> *CAUTION: *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.
> ------------------------------------------------------------------------
>
> Hi,
>
>   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?
>
> Thanks,
>
> -PQ
>
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220608/8db096a2/attachment.htm>