AusweisApp-Website: D-Trust sperrt TLS-Zertifikat ohne…

Wer am Freitag oder Samstag die Website der AusweisApp aufgerufen hat, konnte in Firefox und anderen Browsern mit Sperrprüfung auf eine Zertifikatswarnung stoßen. Die Zertifizierungsstelle D-Trust der Bundesdruckerei hat das TLS-Zertifikat von ausweisapp.bund.de am 25. September 2026 gesperrt, der Betreiber hat erst am 26. September ein neues Zertifikat eingespielt. Betroffen war die Informations- und Download-Website, nicht die AusweisApp selbst und nach allen vorliegenden Daten auch nicht die Online-Ausweisfunktion.

Handlungsbedarf besteht heute für Admins nicht: Die Website liefert seit dem 26. September wieder ein gültiges Zertifikat, ein App-Update ist nicht erschienen und nicht nötig. Den Grund für die Sperrung haben weder D-Trust noch Governikus öffentlich genannt. Der Vorfall ist aber ein guter Anlass, die eigene Zertifikatsüberwachung zu prüfen, denn eine Sperrung vor Ablauf zeigt kein Monitoring an, das nur auf das Ablaufdatum schaut.

Was ist passiert?

Heise online berichtete am 26. September 2026, dass die X.509-Zertifikate für ausweisapp.bund.de und www.ausweisapp.de zurückgezogen wurden und Browser mit korrekter Sperrprüfung der Website nicht mehr vertrauten. Die Angaben lassen sich an der öffentlichen Sperrliste von D-Trust nachprüfen. S-EDV hat die Sperrliste der ausstellenden Zwischen-CA „D-TRUST BR CA 2-23-1 2023“ am 28. September abgerufen und ausgewertet:

Das Zertifikat für www.ausweisapp.bund.de und ausweisapp.bund.de mit der Seriennummer 7D0D9F5C1471C81F53BFFF2626EF925918217A35 wurde am 25. September 2026 um 13:55:06 Uhr GMT gesperrt. Ausgestellt war es am 5. April 2026, gültig gewesen wäre es bis zum 20. Oktober 2026.
Das D-Trust-Zertifikat für www.ausweisapp.de (Seriennummer 528B9F7DB7983C24870231F252FD17BFD62F82FB) wurde vier Sekunden früher gesperrt, um 13:55:01 Uhr GMT.
Als Sperrgrund steht in beiden Fällen „Privilege Withdrawn“.
Laut Zertifikatstransparenz-Logs und direkter Abfrage liefert ausweisapp.bund.de inzwischen ein neues D-Trust-Zertifikat aus, ausgestellt am 26. September 2026 um 15:48 Uhr GMT. Heise nennt denselben Zeitpunkt (17:48 Uhr MESZ).
www.ausweisapp.de liefert bei unserer Abfrage ein gültiges Zertifikat einer anderen CA (DigiCert) aus. Ob das gesperrte D-Trust-Zertifikat dort zuvor überhaupt aktiv war, ist nicht bekannt.

Zwischen Sperrung und neuem Zertifikat lagen damit gut 26 Stunden. Heise hatte zunächst von zwei weiteren gültigen Zertifikaten berichtet und diese Angabe später korrigiert: Auch diese seien ungültig. Ein Blick in die Sperrliste bestätigt das für das im Februar 2026 ausgestellte Vorgängerzertifikat, es wurde bereits im April mit dem Grund „Superseded“ gesperrt. Eine Anfrage von heise bei der Bundesdruckerei blieb am Samstag zunächst unbeantwortet.

Wer ist betroffen?

Betroffen waren Besucher der Websites ausweisapp.bund.de und www.ausweisapp.de, also Menschen, die Informationen, FAQ oder die Installationsdateien der AusweisApp gesucht haben. Ob sie eine Warnung sahen, hing vom Browser ab. Heise nennt Firefox als Beispiel für einen Browser mit korrekter Sperrprüfung. Andere Browser prüfen den Sperrstatus nicht bei jedem Zertifikat live, was erklären dürfte, warum ein Teil der Nutzer nichts bemerkt hat.

Nach aktuellem Stand nicht betroffen sind:

Die installierte AusweisApp auf Windows, macOS, Android und iOS. Die App bezieht Updates und Konfigurationsdaten laut ihrem öffentlichen Quellcode von updates.autentapp.de. Dieser Server nutzt ein Zertifikat einer eigenen Governikus-CA und war von der Sperrung nicht erfasst.
Die Codesignatur der Installationspakete. Gesperrt wurden TLS-Serverzertifikate, keine Code-Signing-Zertifikate.
Die Berechtigungszertifikate, mit denen sich Diensteanbieter gegenüber dem Ausweis ausweisen. Sie stammen aus der eID-PKI des BSI und haben mit Browser-Zertifikaten nichts zu tun. Hinweise auf Störungen der Online-Ausweisfunktion gibt es in keiner der Quellen.

Eine offizielle Bestätigung dieser Abgrenzung durch Governikus oder das BSI lag bei Redaktionsschluss nicht vor. Die Einordnung beruht auf Sperrliste, Zertifikatstransparenz-Logs, dem öffentlichen Quellcode der App und eigenen Verbindungstests.

Wie kritisch ist das?

Für die Sicherheit der Nutzer ist der Vorfall nach allem, was bekannt ist, gering einzustufen. „Privilege Withdrawn“ bedeutet nach den Regeln von Mozilla und den Baseline Requirements des CA/Browser Forums ausdrücklich, dass der private Schlüssel nicht kompromittiert wurde. Der Grund wird verwendet, wenn der Inhaber gegen Nutzungsbedingungen verstoßen hat, wenn sich Angaben im Zertifikat geändert haben, etwa durch eine Umfirmierung, oder wenn das Zertifikat so nicht hätte ausgestellt werden dürfen.

Die Sperrliste liefert einen Hinweis, aber keine Bestätigung: Am 25. September zwischen 13:54 und 13:57 Uhr GMT hat D-Trust in dieser Zwischen-CA 40 Zertifikate mit „Privilege Withdrawn“ gesperrt. Bei allen 16 Zertifikaten aus diesem Block, die S-EDV über Zertifikatstransparenz-Logs auflösen konnte, lautet der Inhaber „Governikus GmbH & Co. KG“, darunter Hosts wie *.governikus.de, prod.governikus-eid.de und wsp.governikus-eid.de. Die jeweils aktuell ausgelieferten Nachfolger tragen als Inhaber „Governikus Service GmbH“ und wurden zwischen dem 21. und 26. September ausgestellt. Das passt zu einer geänderten Firmierung im Zertifikat, bei der die alten Zertifikate gesperrt werden müssen. Offiziell bestätigt ist diese Ursache nicht.

Praktisch heißt das: Bei den meisten Governikus-Diensten war der Austausch vor der Sperrung erledigt, bei ausweisapp.bund.de offenbar nicht. Kritisch war der Vorfall damit vor allem für das Vertrauen. Wer Nutzern beibringt, Zertifikatswarnungen auf einer Behördenwebsite wegzuklicken, schafft genau das Verhalten, das Phishing-Seiten ausnutzen.

Was sollten Admins jetzt tun?

Installierte Version prüfen: In der Softwareverteilung oder per Inventar die AusweisApp-Version auf verwalteten Windows-Clients abfragen. Aktuell ist laut offizieller Downloadseite das Paket AusweisApp-2.5.5.msi. Ein neues Update wegen der Zertifikatssperrung gibt es nicht, ein Neuverteilen ist nicht nötig.
Keine Ausnahmen anlegen: Falls Helpdesk-Tickets zur Zertifikatswarnung eingegangen sind, keine Ausnahmen im Browser, Proxy oder in der TLS-Inspektion für ausweisapp.bund.de setzen. Die Website ist mit dem neuen Zertifikat wieder regulär erreichbar.
Proxy und TLS-Inspektion testen: Wenn Ihr Proxy Sperrlisten oder OCSP selbst prüft und Ergebnisse zwischenspeichert, einmal ausweisapp.bund.de aufrufen und prüfen, dass keine veraltete Sperrinformation mehr greift.
Installationsquellen festlegen: Das MSI für die Softwareverteilung nur von ausweisapp.bund.de oder aus den GitHub-Releases von Governikus beziehen und die Signatur vor dem Import prüfen, nicht von Spiegelseiten, die Nutzer bei einer Zertifikatswarnung ersatzweise finden.
Nutzer informieren: Eine kurze Info an Mitarbeitende, die eID für ELSTER, Mein Unternehmenskonto oder andere Behördenportale nutzen: Warnung am Freitag und Samstag war ein Website-Problem, der Ausweis und die App sind nicht betroffen, Warnungen grundsätzlich nicht wegklicken.
Eigene Zertifikate auf Sperrung überwachen: Monitoring um eine Prüfung des Sperrstatus ergänzen, nicht nur des Ablaufdatums. Ein Zertifikat mit gültiger Laufzeit kann trotzdem gesperrt sein.
Organisationsänderungen mit der PKI verknüpfen: Umfirmierung, Umzug oder Rechtsformwechsel lösen bei OV- und EV-Zertifikaten eine Sperrpflicht aus. Solche Termine gehören in die Checkliste, bevor die CA die alten Zertifikate sperrt.

Einordnung für Unternehmen

Für KMU ist der Vorfall kein Sicherheitsproblem, aber ein lehrreiches Betriebsbeispiel. Zertifikate mit Organisationsangaben hängen an Handelsregisterdaten. Ändert sich dort etwas, muss die CA nach den Baseline Requirements sperren, und zwar innerhalb weniger Tage, unabhängig davon, ob der Kunde schon ausgetauscht hat. Wer seine Zertifikate an Firmenname und Adresse bindet, sollte bei jeder gesellschaftsrechtlichen Änderung eine Zertifikatsinventur einplanen.

Genauso wichtig ist die Frage, wer im Unternehmen eine Sperrmitteilung der CA überhaupt erhält. Oft landet sie in einem persönlichen Postfach eines ehemaligen Mitarbeiters oder im Spamordner. Ein Funktionspostfach für Zertifikatsverwaltung und ein Monitoring, das OCSP oder Sperrlisten abfragt, schließen diese Lücke mit wenig Aufwand.

Für die eID-Nutzung im Unternehmen ändert sich nichts. Wer die Online-Ausweisfunktion für Behördenportale nutzt, kann das weiter tun. Offen bleibt, warum ausgerechnet die öffentlich sichtbarste Website mehr als einen Tag ohne gültiges Zertifikat lief. Sollten D-Trust oder Governikus sich äußern, ergänzen wir die Meldung.

Passende Anleitungen auf S-EDV

TLS-Zertifikate mit Let's Encrypt und Certbot: Automatischer Austausch verhindert, dass ein Wechsel am Zertifikat liegen bleibt.
Nginx als Reverse Proxy mit TLS einrichten: Zertifikate zentral an einer Stelle tauschen statt auf jedem Dienst einzeln.
Serverüberwachung mit Uptime Kuma, lokal oder extern: Grundlage für ein Monitoring, das auch Zertifikatsprobleme meldet.

Was ist passiert?

Wer ist betroffen?

Wie kritisch ist das?

Was sollten Admins jetzt tun?

Einordnung für Unternehmen

Passende Anleitungen auf S-EDV

Quellen

Weiter lesen

KI-Stimme und WhatsApp-Fake: Fideuram-Präsident überweist 95 Millionen Euro

Citrix NetScaler: Zwei Zero-Days CVE-2026-88771 und CVE-2026-88772 aktiv ausgenutzt

Datenleck bei Flink: Kunden werden per Mail erpresst