Rotating SAML Signing Certificates with Zero Downtime (SSO)

Background

OneAegis, like all SAML based Single Sign On (SSO) systems, relies on X509 certificates to sign and secure the flow of information between the identity provider (IdP) and the service provider (SP). These certificates have an expiration date associated with them, often one- or three-years in length. Once a signing certificate expires, we will no longer trust the SAML response from the IdP, so these certificates must be updated (rotated) before they expire for SSO to continue to work.

The Problem

A common approach to this rotation is for the IdP to start using a new certificate and then provide that certificate to each service provider. The problem with this approach is that there is a period of time between when the IdP has started using the new certificate and when the SPs have imported this new certificate. During this period of time SAML requests will not be signed with a trusted certificate, and therefore login attempts will fail. This means the IdP and SP must synchronize the change, typically over a phone or Zoom meeting, commonly after hours, or there can be an extended period of downtime. Neither of these approaches is ideal.

Zero Downtime

OneAegis (like may SPs) supports multiple signing certificates. That is, we can accept SAML responses signed by either certificate A or certificate B. This opens the door to a staged certificate rotation resulting in no need to synchronize certificate rotation and zero downtime -- a win! The steps to do this are rather simple. The IdP generates (but does not activate) a new signing certificate. This is the certificate they will start using later, but it is not in use yet. This new certificate is provided to the SPs who import it into their system, leaving the old certificate in place too. At this time the SPs will now accept SAML responses signed by the old (A) or new (B) certificate. Once this is done the IdP can change to use the new (B) certificate and since the SPs already have this certificate there is no need to synchronize the change and there is zero downtime. 

Entra (AzureAD) Example

While this approach is possible with a multitude of IdPs, Entra is an extremely common IdP, so we show an example here.

In the application in Entra the IdP administrator Edits the SAML Certificates section of the application and generates a new certificate. This new certificate will be shown as "inactive" and should be left that way, the old (expiring) certificate is still the active one. At this time both certificates will be listed in the SAML metadata and the IdP admin can distribute this metadata to the SPs. The metadata should be the one from the "App Federation Metadata Url" on the SAML screen.

Once the SPs have imported the metadata the IdP can activate the new certificate and remove the old one. 

This IdP->SP->IdP step by step process allows certificate rotation without downtime.