Okta SAML IdP certificate rotation without downtime
An expiring signing certificate on a federated identity provider used to mean a scheduled outage and a nervous, minute-by-minute swap with your IdP partner. Okta now lets a SAML identity provider connection hold two active signing certificates at the same time, so rotating the certificate, or cutting over to a whole new external IdP, happens with no downtime. Here is what the feature does, exactly where to configure it, and why it matters.
What the signing certificate actually does
On an inbound SAML identity provider, the external IdP signs its assertions and Okta verifies that signature using the IdP signing certificate you uploaded. When you set up a SAML 2.0 IdP, that certificate goes in the SAML protocol settings. Okta's own instruction is to "Click Browse files to upload a certificate from the IdP used to sign the assertion." The rule underneath it is simple: if the certificate Okta holds does not match the key the IdP is actually signing with, verification fails and sign-in breaks. That is the whole reason a certificate change is risky, and why the timing of it has always been the hard part.
The old way: one certificate, one coordinated swap
With a single credential, updating the certificate is a hard cutover. Okta's documentation is blunt about the failure mode: after you update the key credential, "your users can't access the SAML app or the Identity Provider until you upload the new certificate." So the new key on the IdP side and the new certificate on the Okta side have to line up almost to the minute, or federation goes dark in between. In practice that means a maintenance window, a coordination call with the IdP partner, and the standing risk that a certificate quietly expires before anyone rotates it and takes sign-in down with no warning.
The better way: two active certificates during the overlap
Okta now supports up to two active signing certificates per IdP connection. You add the new certificate alongside the old one and both are trusted at the same time, which removes the timing problem entirely. The external IdP can switch to signing with the new key on its own schedule, because Okta accepts either certificate during the overlap. Once the IdP is fully on the new key, you go back and remove the old certificate. In Okta's words, supporting two certificates at once "eliminates the need for tightly coordinated swaps with IdP partners and reduces the risk of authentication failures due to expired certificates." No window, no swap call, no dead zone.
Where you configure it
To add a SAML identity provider, go to Security, then Identity Providers, then Add identity provider, and choose SAML 2.0 IdP. You upload the IdP signing certificate in the protocol settings during that flow. To add or replace a certificate on an existing connection, open Security, then Identity Providers, select the IdP, then Actions, Configure IdP, Edit, and use the IdP Signature Certificate field. If you automate rotation, the same capability lives in the API: you upload the X.509 certificate to the IdP key store to get a key id, then reference that key id on the connection (the additionalKids parameter). Console or API, the model is the same. Two live certificates, then retire the old one.
Why this makes IdP-to-IdP cutover easy
The same mechanism does more than routine rotation. Migrating your users from one federated external IdP to another is, mechanically, a change of which signing key Okta trusts plus the routing that sends users there. Two active certificates let you stand up trust for the new IdP's signing key while the old IdP still works, verify that real logins succeed, and only then retire the old certificate. It is the federation version of a blue-green deploy: the new path is live and proven before you tear down the old one, instead of a single flip and hope.
Gotchas worth knowing
Two is a ceiling, not a running count, so do not try to stack several rotations at once. The overlap only saves you if the IdP actually starts signing with the new key before you delete the old certificate, so confirm the switch with a real login before you remove anything. And be clear about direction: this is the inbound side, where Okta is the service provider verifying an external IdP. Okta's own app-signing certificates, where Okta is the IdP to downstream apps, are a separate rotation done on each app's Sign On tab. The signature settings still have to match what the IdP actually sends.
Certificate trust between identity providers never shows up in a role review and gets forgotten until the day it breaks. We read your Okta org read-only and inventory the whole federation picture, the inbound identity providers, the routing rules, and the trust behind them, so a change like a certificate rotation or an IdP cutover starts from a real map instead of a guess. We read and categorize, we never touch your configuration. See it on your own org, the demo is open, no signup: demo.atomation.io.