Expiring IDP signing certificate

Wed Jun 8 21:08:30 UTC 2022

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.

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Donald Lohr via users <users at shibboleth.net>
Sent: Wednesday, June 8, 2022 3:31 PM
To: users at shibboleth.net <users at shibboleth.net>
Cc: Donald Lohr <lohrda at jmu.edu>
Subject: Re: Expiring IDP signing certificate

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/e78827c2/attachment.htm>