How do I update the Shibboleth/SAML SSO Signing Certificate that is expiring?

When is the Shibboleth/SAML Single Sign-On (SSO) 10-year signing certificate expiring?

The current Shibboleth/SAML Single Sign-On (SSO) 10-year signing certificate is expiring on July 15, 2021 but Technology Solutions will be installing a new private key on the Shibboleth IDP server in advance on July 10, 2021, at 11:00 AM CT. The new public certificate will be found in our IDP metadata and at https://shibboleth.uic.edu starting June 19.

If your application is not automatically downloading and consuming our IDP metadata from one of three locations, then logins to your application will fail starting on July 10 unless you take action (see below). Our IDP metadata with Entity ID of https://shibboleth.uic.edu/shibboleth is located at:

  1. InCommon - http://md.incommon.org/InCommon/InCommon-metadata.xml
  2. ITrust - https://md.itrust.illinois.edu/itrust-metadata/itrust-metadata.xml
  3. UIC - https://shibboleth.uic.edu/idp/shibboleth

On June 19, Technology Solutions will upload the new public certificate to our IDP metadata at all three locations so that our metadata will contain two public certificates: the expiring one and the new one. We will also upload the certificate itself separately to https://shibboleth.uic.edu and will remove the old certificate from our metadata on July 10.

If you need to manually install the new certificate (or metadata that includes the new certificate), do not do so until after July 10, 2021, at 11:00 AM CT - otherwise application logins will fail.
 

How do I know if my application is using Shibboleth/SAML Single Sign-On?

On a Shibboleth login page, displayed after “Application requesting login," it will display “UIC Shibboleth”. If the login page does not list "UIC Shibboleth", then your application will not be impacted by this certificate expiration.

Below is an example of a Shibboleth SSO log in page:
 

 

ADFS SSO

If your application is redirected to the a URL that begins with "https://sts.uic.edu" and looks like image page below, this indicates the application is using ADFS for authentication. ADFS SSO will not be impacted by this change. 

ITrust Federation Applications

If your application is registered with ITrust, and you configured it per standard ITrust instructions then you should not have to take any action. The metadata refresh time for Shibboleth applications is 4 hours by default so your application should have the new certificate automatically installed shortly after June 19. When the new private key is installed 3 weeks later, logins to your application should proceed normally with no downtime to users.

InCommon Federation Applications

If your application is registered with InCommon it may or may not automatically download and consume our IDP metadata. This depends on the application itself. If our metadata is not automatically consumed then you will need to take action on or after July 10. Logins to your application will start failing after we install the new private key on that date until you take action.

All other Applications

If you are not registered with either ITrust or InCommon then it is most likely that you will need to take action on or after July 10. Logins to your application will start failing after we install the new private key on that date until you take action.

 

How to Take Action (Manually Update Metadata or a Certificate for an Application)

The procedure for updating the certificate (or metadata) in an application varies greatly between applications. You will likely need to log in to your application with administrative privileges. There may be a section in the configuration section titled SSO or SAML. In some cases, you will need to upload our new IDP metadata (which will contain the certificate) and in other cases you will just need to upload our new public certificate (downloadable at https://shibboleth.uic.edu). The new public certificate will be available to you on June 19 but will not be used until July 10 so you will need to make your change on or after the latter date after we install the new private key on our server.

Example of Certificate contained within Metadata

Our public signing certificates appear in our metadata in a stanza like this one:

    <KeyDescriptor use="signing">

      <ds:KeyInfo>

        <ds:X509Data>

          <!-- Serial No. 14547142102731650334, expires on Thu Jul 15 16:43:47 2021 GMT -->

          <ds:X509Certificate>

...certificate data...

          </ds:X509Certificate>

 

The new public signing certificate you will need to install will have an expiration date in 2037. Below is an example of Certificate Configuration in the PeopleGrove application. In this case, it is simply called “SAML Certificate”.

Some applications will have you upload a file with the certificate in it, other applications will have you copy and paste the certificate into a form field (as in the example above). Some applications will require you to upload the entire IDP metadata (which itself contains the certificate) which you can acquire from the three locations mentioned earlier. Be careful using copy and paste as additional characters (like carriage returns or line feeds) may be pasted into a form resulting in an invalid certificate being configured.

Testing and Symptoms of Invalid Certificate

You can test the certificate update even if you don’t have an account to login to the application by simply going to the application URL (and selecting UIC for the organization if that is required). If the certificate you have installed is correct then you will arrive at a website that looks much like the first image in this document. If the certificate is not correct you will usually get an error page (the page might say something like “failed security validation”) - some applications though simply just return a blank page with no indication of what went wrong.

If you have a development/staging site for your application we may be able to coordinate a test of that site with the new certificate during the few weeks before the new private key is installed.

Support

Hundreds of applications will likely be impacted by the Shibboleth private key change. Due to the large number of applications that could be impacted, Technology Solutions may not be able to provide assistance in a timely manner after July 10. We strongly encourage technical contacts to manage and configure their application appropriately on or after July 10. 

If you need additional support, please submit your questions at go.uic.edu/ask-an-IT-question, selecting Single Sign On as the topic.

Details

Article ID: 2196
Created
Mon 5/3/21 3:08 PM
Modified
Wed 6/30/21 2:53 PM