Ein SAML-Zertifikat in Entra ID lässt sich ohne Downtime erneuern

In vielen Tenants, die ich betreue, trifft irgendwann dieselbe Erinnerungsmail ein: Das SAML-Token-Signaturzertifikat einer Enterprise Application läuft bald ab. Das klingt technisch, und das ist es auch. Dabei ist die Erneuerung eines SAML-Zertifikats eigentlich klar geregelt. Probleme macht selten das Zertifikat selbst. Meist fehlt irgendwo zwischen Entra ID, Service Provider und der Abstimmung unter den Admins ein Glied der Kette.

Mit zwei parallelen Zertifikaten gelingt die Erneuerung ohne Ausfall

Standardmäßig laufen SAML-Token-Signaturzertifikate in Enterprise-Anwendungen von Entra ID nach drei Jahren ab. Die Erneuerung starte ich im Entra Admin Center unter Enterprise-Anwendungen → App → Single Sign-On → SAML-Zertifikate → Bearbeiten. Dort lässt sich ein neues Zertifikat hinzufügen, während das alte weiterhin aktiv bleibt. Und an genau dieser Stelle entscheidet sich alles. Das alte Zertifikat darf ich erst entfernen oder deaktivieren, wenn alle Service-Provider-Instanzen das neue akzeptieren. Einige Anwendungen holen sich die Metadaten automatisch über eine URL, viele erwarten dagegen einen manuellen Upload. Bleiben beide Zertifikate so lange wie nötig parallel in den Metadaten stehen, sinkt das Ausfallrisiko erheblich.

Aus meinen Projekten weiß ich, dass Notfallkontakt-Mails für SAML-Zertifikate an echte Teams gehen sollten und nicht an Einzelpersonen. Tragen Sie diese Adressen am besten gleich im Abschnitt „Benachrichtigungs-E-Mail-Adressen“ der SAML-Konfiguration ein. Im Ernstfall ersparen Sie sich damit die hektische Suche.

Die Metadaten-URL nimmt dem Wechsel fast jedes Risiko

Am bequemsten wird es, wenn der Service Provider die SAML-Metadaten-URL direkt übernimmt. Dann genügen wenige Klicks. Sie erstellen das neue Zertifikat, veröffentlichen es und warten, bis die Applikation die Metadaten selbstständig importiert. Das Ausfallrisiko sinkt damit praktisch auf null. Häufig begegnen mir allerdings Applikationen, die die Metadaten nur beim Start einlesen oder einen manuellen Upload verlangen. In diesem Fall müssen Sie den richtigen Zeitpunkt abpassen und beide Zertifikate für eine Übergangsphase parallel anbieten. Den Ablauf und die Unterschiede je nach Anwendungstyp beschreibt Microsoft sehr sauber in der offiziellen Anleitung.

Im folgenden Diagramm ist dieser Ablauf dargestellt:

flowchart TD
    Zertifikat_alt["altes Zertifikat aktiv"] --> Neuerstellen["neues Zertifikat hinzufügen"]
    Neuerstellen --> Beide_aktiv["beide Zertifikate gültig"]
    Beide_aktiv --> SP_Aktualisiert["Service Provider lädt neue Metadaten"]
    SP_Aktualisiert --> Alt_entfernen["altes Zertifikat entfernen"]

Abbildung: Erneuerung eines SAML-Zertifikats ohne Unterbrechung – beide Zertifikate bleiben gültig, bis der Service Provider gewechselt hat.

Ein PowerShell-Skript findet ablaufende SAML-Zertifikate im Tenant

Bei vielen Applikationen oder in großen Tenants verliert man schnell den Überblick, welches SAML-Zertifikat wann erneuert werden muss. Eine Auswertung mit dem Microsoft-Graph-PowerShell-Modul schafft hier zuverlässig Ordnung. Die folgende Abfrage findet alle Zertifikate, die innerhalb der nächsten 60 Tage ablaufen. Voraussetzung sind PowerShell 7, das Modul Microsoft.Graph.Applications und die Rolle Application Administrator oder höher:

Connect-MgGraph -Scopes "Application.Read.All"
$apps = Get-MgServicePrincipal -Filter "servicePrincipalType eq 'Saml'"
$today = Get-Date
$expiring = $apps | Where-Object {
  $_.KeyCredentials | Where-Object { $_.EndDateTime -lt ($today.AddDays(60)) }
}
$expiring | Select-Object Id, DisplayName, @{N='Expires';E={$_.KeyCredentials.EndDateTime}}

Als Ergebnis erhalten Sie App-ID, Anzeigenamen und Ablaufdatum. Wer mehr als eine Handvoll SAML-Apps betreut, sollte dieses Reporting aus meiner Sicht einmal im Monat laufen lassen. Wie Sie ablaufende App-Zertifikate und Secrets aller Anwendungstypen automatisiert überwachen, habe ich bereits im Beitrag Ablauf von App-Credentials mit Reporting und Warnungen in Entra ID überwachen beschrieben.

Veraltete Kontaktadressen sind die eigentliche Stolperfalle

Die organisatorische Seite wird gern unterschätzt, obwohl gerade dort die meisten Fehler entstehen. In vielen Tenants fehlen Notfallkontakte ganz, oder die Benachrichtigungsadresse gehört einer Person, die das Unternehmen längst verlassen hat. Die Warnung von Entra liest dann niemand, das Zertifikat läuft ab, und die Anmeldung schlägt scheinbar ohne Grund fehl. Mein pragmatischer Rat lautet deshalb, beim nächsten Erneuern gleich zu prüfen, ob die Kontaktadressen im SAML-Abschnitt noch stimmen. Wer viel mit Drittanbietern arbeitet, sollte außerdem festhalten, wie die Metadaten gepflegt werden, also per automatischem Abruf oder per manuellem Upload.

Mit fester Routine bleibt die Erneuerung unspektakulär

Technisch ist die Erneuerung eines SAML-Zertifikats keine große Sache. Fehlen jedoch abgestimmte Prozesse und eine regelmäßige Kontrolle der Ablaufdaten, folgen erfahrungsgemäß schnell böse Überraschungen. Wer die Metadaten-URL nutzen kann, hat meist wenig Stress. In allen anderen Fällen helfen nur Disziplin und Reporting. Entscheidend bleibt, beide Zertifikate parallel vorzuhalten, bis die Applikation sicher umgestellt hat. Außerdem müssen die Verantwortlichen hinter den Apps erreichbar und informiert sein. Dann bleibt das Thema zwar technisch, im besten Fall aber angenehm unspektakulär.

Weitere Informationen und Details zum Ablauf finden Sie auch in der offiziellen Dokumentation (Verwalten ablaufender Zertifikate für föderiertes Single Sign-On).