IDP 3.4.3 Expiring Signing Certtificate Rollover

[Cantor, Scott]

> Have SPs pointing to expiring signing cert point to new cert when they receive
> updated IDP metadata.

They do, and either key will be accepted, except by all of the SPs that don't support metadata to begin with.

The fact is that the majority of systems that would support metadata also won't care that your key has "expired". There is no such thing. If the key is in a valid metadata instance accepted by a compliant SP, it hasn't expired by definition. Most of the sysems that would improperly expire such a key have no idea metadata exists, or don't use it correctly.

There are three types of systems:

- metadata capable, including some that don't properly handle it and ignore multiple keys
- self-managed with keys manually updated by you
- manual, with no process or recourse other than contacting the owner and likely ending up with an insecure and socially-engineerable/exploitable mechanism to get them the new key

The first step to any key change is inventorying every SP and knowing which category they're in, followed by pinning all of the second and third set to a specific security configuration bean (doable in many different ways) with the old key. Then rolling the first category via metadata update and flipping the default key to the new one once its propagated, and removing the old key from metadata. And then changing all the other systems, one by one by hand and through vendors, flipping the security configuration for each one as they're updated.

That's the process. The work depends on the size of those second and third categories.

The goal of the process should be to prove to management that it can never be done again without a very good reason, and making sure it doesn't need to happen for any bad reasons, such as large numbers of staff with access to the key, raising risks every time any of those staff turn over.

-- Scott