Entra SAML-Signaturzertifikat abgelaufen: Warum die föderierte Anmeldung ausfällt

Entra SAML-Signaturzertifikat abgelaufen: Was das bedeutet

Wenn ein SAML-Signaturzertifikat in Entra abgelaufen ist, bricht die föderierte Anmeldung für diese Anwendung mandantenweit zusammen — nicht wegen eines Angriffs, sondern wegen einer routinemäßigen administrativen Aufgabe, die niemand eingeplant hat. Jede Unternehmensanwendung, die für föderiertes Single Sign-On (SSO) über SAML in Microsoft Entra ID konfiguriert ist, verlässt sich auf ein Signaturzertifikat: Entra ID verwendet dessen privaten Schlüssel, um die ausgestellten SAML-Assertions kryptografisch zu signieren, und der Dienstanbieter validiert diese Assertions anhand des passenden öffentlichen Schlüssels. Dies ist der Vertrauensanker der gesamten Föderationsbeziehung — ist das Zertifikat ungültig, ist die Assertion für den Dienstanbieter wertlos, egal wie korrekt der Rest des Authentifizierungsablaufs ist.

„Zertifikatszustand" umfasst drei unterschiedliche, aber verwandte Risikozustände, die im EtcSec-Schwachstellenkatalog für Azure-Anwendungen erfasst werden:

• Abgelaufen — die Gültigkeitsdauer des Zertifikats ist bereits verstrichen. Dies ist ein funktionaler Ausfall, nicht nur eine Sicherheitsschwäche.
• Läuft bald ab — das Zertifikat läuft innerhalb von 30 Tagen ab, und es wurde noch keine Erneuerung vorbereitet.
• Lange Lebensdauer — das Zertifikat wurde mit einem übermäßig langen Gültigkeitsfenster ausgestellt (Entra ID setzt standardmäßig drei Jahre an), was den Wirkungsradius vergrößert, falls das private Schlüsselmaterial jemals unsachgemäß gehandhabt wird, und die Wahrscheinlichkeit erhöht, dass die für die Rotation zuständige Person das Unternehmen inzwischen verlassen hat, versetzt wurde oder es schlicht vergessen hat.

Standardmäßig generiert Entra ID beim Konfigurieren von SAML-basiertem SSO für eine Katalog- oder Nicht-Katalog-Anwendung automatisch ein selbstsigniertes Zertifikat mit einer Gültigkeit von drei Jahren (Microsoft Learn). Anders als ein Anwendungsgeheimnis mit kurzer Standardlebensdauer, das häufige Aufmerksamkeit erzwingt, lässt sich ein dreijähriges SAML-Zertifikat einmal konfigurieren und danach vergessen — bis es still und leise abläuft.

Wie das Zertifikat die föderierte Anmeldung stützt

Wenn Entra ID als Identity Provider (IdP) für eine SAML-Anwendung fungiert, hängt der Anmeldeablauf an zwei Stellen vom Zertifikatszustand ab:

1. Entra ID signiert die SAML-Assertion (oder die Antwort) mit dem privaten Schlüssel des aktiven Signaturzertifikats des Service Principal der Unternehmensanwendung.
2. Der Dienstanbieter validiert diese Signatur anhand des öffentlichen Zertifikats, das ihm vorliegt (entweder manuell hochgeladen oder dynamisch von der Föderationsmetadaten-URL der Anwendung abgerufen).

Ist das Zertifikat, mit dem Entra ID signiert hat, abgelaufen, stoppt Entra ID das Signieren damit nicht — es verwendet weiterhin, was immer als aktives Zertifikat markiert ist. Es ist der Dienstanbieter, der die Assertion ablehnt, sobald er feststellt, dass das Zertifikat nicht mehr innerhalb seines Gültigkeitsfensters liegt, und diese Ablehnung erleben Benutzer als fehlgeschlagene Anmeldung (Microsoft Learn). Mit anderen Worten: Entra ID „bemerkt" den Ablauf nicht und blockiert die Anmeldung nicht proaktiv — der Fehler tritt nachgelagert bei der Anwendung auf, und zwar erst, nachdem Benutzer davon betroffen sind.

Metadaten-Polling und E-Mail-Benachrichtigungen

Es gibt zwei Abhilfen, je nach den Fähigkeiten der Anwendung:

• Föderationsmetadaten-Polling. Bei Anwendungen, die dies unterstützen, prüft Entra ID die Föderationsmetadaten der Anwendung etwa 35 Tage vor Ablauf des Signaturzertifikats; ist dort ein neues Zertifikat auffindbar, ist kein manueller Eingriff und keine Benachrichtigung nötig (Microsoft Learn).
• E-Mail-Benachrichtigungen. Für alles andere sendet Entra ID 60, 30 und 7 Tage vor Ablauf E-Mails an die konfigurierten Benachrichtigungsadressen der Unternehmensanwendung, von [email protected] — bis zu fünf Adressen, standardmäßig nur an den Administrator, der SSO ursprünglich konfiguriert hat (Microsoft Learn).

Beide Abhilfen setzen voraus, dass sie überhaupt jemand korrekt konfiguriert hat, und beide werden häufig übersprungen: Metadaten-Polling funktioniert nur, wenn die Anwendung es tatsächlich unterstützt und konsumiert, und die Benachrichtigungsliste bleibt trivialerweise beim Postfach eines einzelnen, längst ausgeschiedenen Administrators stehen.

Was passiert, wenn das Zertifikat abläuft oder zu lange besteht

Die Auswirkung eines abgelaufenen SAML-Signaturzertifikats betrifft die Verfügbarkeit, nicht die Vertraulichkeit: Die föderierte Anmeldung für diese Anwendung schlägt für jeden Benutzer fehl, bis das Zertifikat erneuert und auf beiden Seiten reaktiviert wird. Bei einer unternehmensweit genutzten Line-of-Business-SaaS-Anwendung ist das ein vollständiger Ausfall, ausgelöst allein durch ein administratives Versehen, nicht durch eine Angreiferaktion.

Langlebige Zertifikate bergen ein anderes, leiseres Risiko. Ein Gültigkeitsfenster von drei Jahren (oder länger) bedeutet:

• Die Rotation erfolgt so selten, dass der manuelle Prozess — generieren, herunterladen, beim Dienstanbieter hochladen, aktivieren, verifizieren, altes Zertifikat entfernen — bei jedem Bedarf ungewohnt bleibt, was die Fehlerwahrscheinlichkeit während der eigentlichen Rotation erhöht.
• Eigentümer-Drift: Der Administrator, der es eingerichtet hat, ist möglicherweise nicht mehr im Unternehmen, wenn die Erneuerung fällig wird.
• Ein längeres Zeitfenster, in dem privates Schlüsselmaterial exponiert sein kann, falls das Zertifikat oder dessen Export jemals unsachgemäß gehandhabt wird, ohne erzwungene Auffrischung.

Microsofts eigene Empfehlung an ISVs, die SAML-Integrationen entwickeln, bestätigt dies direkt: Manuelles Rollover werde bei Skalierung „untragbar", da Zertifikatslebensdauern branchenweit tendenziell kürzer werden, und empfiehlt Anwendungen, automatisiertes metadatenbasiertes Rollover mit primären/sekundären Signaturzertifikaten zu unterstützen, gerade um die operative Fragilität langer, manuell verwalteter Lebensdauern zu beseitigen (Microsoft Learn).

Das ist auch der Grund, warum diese Lücke aus Abdeckungssicht relevant ist: Der SAML-Zertifikats-Lebenszyklus ist ein eigenständiges Risiko, getrennt von der Hygiene der Anwendungsberechtigungen. Ein verwandtes, aber unterschiedliches Applications-Risiko — überprivilegierte App-Registrierungen mit übermäßigen delegierten Berechtigungen — wird behandelt in Azure App-Registrierungen: Sicherheitsrisiken; der Zertifikatszustand ist ein orthogonales, verfügbarkeitsorientiertes Anliegen innerhalb derselben Kategorie.

Erkennung: Ablaufende und langlebige SAML-Zertifikate finden

Warten Sie nicht auf eine Flut von Helpdesk-Tickets, um zu entdecken, dass ein Zertifikat abgelaufen ist. Entra ID stellt den Zertifikatszustand über mehrere Kanäle bereit:

Für einen umfassenderen Überblick, wie Sie eine vollständige Entra-Sicherheitsprüfung über Zertifikate hinaus strukturieren, siehe Microsoft Entra ID-Sicherheit auditieren: praktischer Leitfaden. Für mandantenweite Standardhärtung, die die Exposition neben der Zertifikatshygiene reduziert, siehe Azure Tenant-Härtung: Unsichere Defaults.

Behebung: Erneuern ohne Ausfallzeit

Microsofts dokumentierte Erneuerungsreihenfolge existiert genau deshalb, um einen Ausfall während der Rotation zu vermeiden — Schritte auszulassen oder in falscher Reihenfolge auszuführen ist der häufigste Weg, wie Teams aus einer geplanten Erneuerung eine ungeplante machen.

Schritt 1 — Neues Zertifikat frühzeitig erstellen

Erstellen Sie das neue Zertifikat mit einem Ablaufdatum, das sich mit der verbleibenden Gültigkeit des aktuellen Zertifikats überschneidet, über Enterprise-Apps → [App] → Single Sign-On → SAML-Zertifikate → Neues Zertifikat. Es wird als Inaktiv gespeichert — dieser Schritt allein verursacht keine Unterbrechung (Microsoft Learn).

Schritt 2 — Zuerst beim Dienstanbieter hochladen

Laden Sie das neue Zertifikat herunter und laden Sie es beim Dienstanbieter hoch, im Kodierungsformat, das der SSO-Konfigurationsleitfaden der Anwendung vorgibt, bevor Sie es in Entra ID aktivieren.

Schritt 3 — Aktivieren, verifizieren und aufräumen

Aktivieren Sie das neue Zertifikat in Entra ID (über das …-Menü des neuen Zertifikats → Zertifikat als aktiv festlegen) — dies markiert das vorherige Zertifikat automatisch als inaktiv. Verifizieren Sie, dass die Anmeldung für die Anwendung durchgängig funktioniert, bevor Sie die Rotation als abgeschlossen betrachten, und entfernen Sie das alte Zertifikat erst nach der Verifizierung, damit es nicht versehentlich später reaktiviert werden kann.

# Microsoft Graph PowerShell — aktuellen SAML-Signaturzertifikatszustand für einen Service Principal prüfen
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -ServicePrincipalId "<service-principal-object-id>" `
    -Property "keyCredentials,preferredTokenSigningKeyThumbprint" |
    Select-Object -ExpandProperty KeyCredentials |
    Select-Object DisplayName, Usage, StartDateTime, EndDateTime

Um programmatisch ein neues Token-Signaturzertifikat hinzuzufügen, verwenden Sie die Graph-servicePrincipal-Aktion addTokenSigningCertificate und setzen Sie anschließend preferredTokenSigningKeyThumbprint auf den Fingerabdruck des neuen Zertifikats, damit Entra ID damit signiert (Microsoft Learn — SAML-SSO über Microsoft Graph konfigurieren).

✅ Hinweis: Schließen Sie die Lücke der langen Lebensdauer gleichzeitig mit jeder Erneuerung. Setzen Sie den Ablauf des neuen Zertifikats auf ein kürzeres, bewusst gewähltes Fenster statt den Drei-Jahres-Standard zu akzeptieren, und tragen Sie die nächste Erneuerung mit ausreichend Vorlauf in einen Kalender ein, um eine erneute Hektik zu vermeiden.

Wiederholung verhindern

Über das Zertifikat selbst hinaus verhindern zwei aufwandsarme Kontrollen eine Wiederholung:

• Füllen Sie das Feld für Benachrichtigungs-E-Mail-Adressen bei jeder föderierten Anwendung mit einer Verteilerliste, nicht dem Postfach einer Einzelperson — bis zu fünf Adressen werden unterstützt, und Entra ID sendet dorthin die 60/30/7-Tage-Warnungen (Microsoft Learn).
• Setzen Sie die Empfehlung Ablaufende Service-Principal-Anmeldeinformationen erneuern auf der Übersichtsseite des Entra Admin Centers als feste, mandantenweite Prüfung um, statt sich auf das Gedächtnis pro Anwendung zu verlassen.

Für App-Berechtigungsrisiken, die oft neben Zertifikatsfehlkonfigurationen auf denselben Unternehmensanwendungen bestehen, siehe OAuth Consent Phishing: Wie bösartige Apps Passwortdiebstahl umgehen. Für die umfassenderen Conditional-Access-Kontrollen, die regeln, wie föderierte Apps überhaupt erreicht werden können, siehe Entra ID bedingter Zugriff Luecken: welche Fehlkonfigurationen reale Angriffsflaechen lassen.

Wie EtcSec dies erkennt

EtcSecs Azure-Audit prüft bei jedem Mandanten-Scan den SAML-Signaturzertifikatszustand jeder Unternehmensanwendung. SAML_CERTIFICATE_EXPIRED markiert jede Anwendung, deren aktives Signaturzertifikat bereits abgelaufen ist — ein kritischer, verfügbarkeitsrelevanter Befund, da die föderierte Anmeldung für diese App aktiv unterbrochen ist. SAML_CERTIFICATE_EXPIRING_SOON markiert Zertifikate, die sich dem Ablauf nähern, damit die Erneuerung geplant statt überstürzt erfolgen kann, und SAML_CERTIFICATE_LONG_LIFETIME markiert Zertifikate, die mit einem übermäßigen Gültigkeitsfenster ausgestellt wurden, damit Sie es bei der nächsten Rotation verkürzen können, statt dieselbe mehrjährige Uhr zurückzusetzen.