Digitale Identität und Zertifikatsprüfung: Warum ‘stale trust’ nicht nur bei PKI ein Problem ist

Am 5. Oktober 2026 hat Verisign einen neuen Dienst namens Verisign Informed angekündigt, zusammen mit einem Antrag auf die Top-Level-Domain .pki. Klingt erstmal nach einer Randnotiz aus der Zertifikatswelt. Ist es aber nicht.

Das Problem, das Verisign damit adressiert, nennt sich stale trust. Gemeint ist eine Situation, in der Entscheidungen auf Basis veralteter Zertifikatsinformationen getroffen werden, obwohl sich der tatsächliche Status längst geändert hat. Ein Client prüft ein Zertifikat, hält es für gültig, und merkt erst Wochen später, dass es zurückgezogen wurde. Genau dieses Zeitfenster zwischen Status-Änderung und tatsächlicher Erkennung ist der wunde Punkt jeder PKI-Infrastruktur.

Wer in der Windows-Welt mit Zertifizierungsstellen arbeitet, kennt das Muster. Man konfiguriert die CRL-Veröffentlichung, denkt sich nichts weiter dabei, und drei Jahre später fragt man sich, warum ein Client ein längst zurückgerufenes Zertifikat trotzdem akzeptiert hat. Es passiert leise. Es passiert oft unbemerkt. Und genau das macht es gefährlich.

CRL, OCSP und das Zeitfenster der Unwissenheit

Eine Certificate Revocation List (CRL) ist im Grunde eine Blacklist: eine signierte Liste aller Zertifikate, die eine CA vorzeitig für ungültig erklärt hat. Windows-Zertifizierungsstellen veröffentlichen sie in festen Intervallen, typischerweise alle paar Stunden bis Tage, abhängig von der CA-Konfiguration.

Das Problem dabei: Zwischen zwei Veröffentlichungen liegt eine Lücke. Wird ein Zertifikat um 14 Uhr zurückgerufen, die nächste CRL aber erst um Mitternacht veröffentlicht, akzeptieren Clients das kompromittierte Zertifikat bis zu zehn Stunden lang als gültig. Das ist kein theoretisches Risiko. Das ist Standardverhalten.

OCSP (Online Certificate Status Protocol) sollte das lösen, indem es Echtzeit-Abfragen statt statischer Listen anbietet. In der Praxis bringt es eigene Probleme mit: OCSP-Responder können ausfallen, Clients fallen dann auf “soft fail” zurück und akzeptieren das Zertifikat trotzdem. OCSP-Stapling reduziert zwar die Latenz und die Privacy-Implikationen, löst aber nicht das Kernproblem. Der Responder selbst muss aktuelle Daten liefern, und genau da hakt es in vielen produktiven Umgebungen.

Ich habe das selbst bei einem Kunden erlebt. Eine interne CA, CRL-Publishing-Intervall auf 7 Tage eingestellt, weil “das reicht ja”. Ein Mitarbeiter verlässt das Unternehmen, sein Zertifikat wird zurückgerufen, aber die VPN-Gateway-Appliance hatte die alte CRL noch sechs Tage im Cache. Der Zugang funktionierte weiter. Niemand hatte das auf dem Schirm, bis ein Audit es aufdeckte.

Was Verisign Informed konkret ändert

Verisign Informed soll laut eigenen Angaben genau dieses Zeitfenster schließen, indem Zertifikatsstatus in nahezu Echtzeit bereitgestellt wird, statt sich auf starre Veröffentlichungsintervalle zu verlassen. Der Gedanke dahinter: Vertrauen darf kein Schnappschuss sein. Es muss ein laufender Abgleich sein.

Das ist im Grunde dieselbe Lektion, die die Branche schon einmal schmerzhaft gelernt hat. Als Google Chrome 2024 entschied, Zertifikate von Entrust nicht mehr zu vertrauen, war das kein spontaner Vertrauensentzug. Es war das Ergebnis jahrelanger dokumentierter Compliance-Verstöße, die irgendwann die Schwelle überschritten haben. InfoWorld hat damals ausführlich beschrieben, wie viele Entwickler und Admins erst durch den plötzlichen Browser-Fehler bemerkten, dass ihre vermeintlich sichere CA längst auf der Kippe stand.

Genau das ist stale trust in Reinform: Man vertraut einem Status, der schon lange nicht mehr der Realität entspricht, einfach weil niemand aktiv nachgeprüft hat.

Wenn stale trust aus der PKI-Welt ausbricht

Hier wird es interessant. Das Konzept lässt sich nämlich eins zu eins auf andere Bereiche übertragen, in denen Menschen sich auf Vertrauensangaben verlassen, die längst überholt sein könnten.

Denken Sie an die eigene Firewall-Konfiguration. Eine Regel wurde vor zwei Jahren erstellt, weil eine Anwendung damals Port 8080 brauchte. Die Anwendung ist längst migriert, der Port ist offen geblieben, niemand hat es gemerkt. Vertrauen in “das war schon immer so konfiguriert” ist genau dasselbe Muster wie Vertrauen in ein Zertifikat, dessen Revocation-Status man nicht aktiv geprüft hat.

Oder die Berechtigungsstruktur in Active Directory. Eine Gruppe hatte vor Jahren berechtigten Zugriff auf ein Fileshare, der Mitarbeiter ist längst in eine andere Abteilung gewechselt, die ACL wurde nie bereinigt. Über 80 Prozent der dokumentierten Domain-Compromise-Pfade laufen laut aktuellen Analysen über genau solche veralteten Berechtigungsstrukturen, nicht über neue Exploits.

Das Muster zieht sich weiter, deutlich weiter als man zunächst denkt. Die Bank of England musste in ihrem Jahresbericht zum Zahlungssystem sogar einräumen, dass ein abgelaufenes digitales Zertifikat zu einer realen Störung im zentralen Abwicklungssystem geführt hat. Nicht irgendein Testsystem. Die Infrastruktur, über die Milliarden an Zahlungen laufen. Ein einziges überfälliges Zertifikat, das niemand rechtzeitig erneuert hatte.

Und genau hier schließt sich der Kreis zu einem Bereich, der auf den ersten Blick wenig mit PKI zu tun hat: der Prüfung von Lizenzstatus bei Online-Anbietern. Wer im Netz Geld einzahlt, verlässt sich auf eine Vertrauensangabe, oft ein Logo, ein Siegel, eine Behauptung auf der Startseite. Aber ein Lizenzstatus kann sich ändern. Lizenzen laufen aus, werden entzogen, werden nie wirklich erteilt. Genau wie bei einem veralteten Zertifikat reicht ein einmaliger Blick nicht aus. Man muss aktiv prüfen, was Casinos ohne deutsche Lizenz zu deutschen Anbietern unterscheidet, bevor man dort überhaupt Geld hinterlegt. Die Mechanik der Fehleinschätzung ist dieselbe wie bei einer abgelaufenen CRL: Der Nutzer vertraut einem Status, der zum Zeitpunkt der Prüfung schon nicht mehr aktuell ist.

Wer sich mit Glücksspiel beschäftigt, sollte das ohnehin nur mit Bedacht und innerhalb der eigenen finanziellen Grenzen tun.

Was das für die eigene Infrastruktur bedeutet

Zurück zur eigenen Umgebung. Die praktische Konsequenz aus alldem ist simpel, auch wenn die Umsetzung Arbeit macht: Vertrauensentscheidungen brauchen ein Ablaufdatum und einen Prüfmechanismus, nicht nur einen initialen Check.

Für CRL-Publishing bedeutet das konkret: Intervalle überprüfen, nicht nach “haben wir schon immer so gemacht” konfigurieren. Ein ISW CA Operations Manager kann hier helfen, den Rückruf-Workflow sauber zu dokumentieren und CRLs zuverlässig zu veröffentlichen, statt sich auf manuelle RDP-Sessions zu verlassen, die irgendwann vergessen werden.

Für ACL-Strukturen in Active Directory gilt dasselbe Prinzip. Ein Audit, das einmalig im Jahr 2023 durchgeführt wurde, sagt nichts über den Zustand im Oktober 2026 aus. Berechtigungen verändern sich schneller, als man denkt. Mitarbeiter wechseln Abteilungen, Projekte laufen aus, Gruppenmitgliedschaften bleiben bestehen, obwohl der Grund dafür längst verschwunden ist.

Die gute Nachricht: Die technischen Werkzeuge dafür existieren längst. Die schlechte Nachricht: Sie müssen auch tatsächlich genutzt werden, und zwar wiederkehrend, nicht als einmalige Compliance-Übung vor einem Audit.

PKI-Trust, Firewall-Regeln, AD-Berechtigungen, Lizenzstatus bei Dienstleistern. Überall dasselbe Grundproblem: Vertrauen, das einmal etabliert wurde, verfällt leise, wenn niemand aktiv nachschaut. Die Systeme, die stale trust am besten in Schach halten, sind nicht die mit den komplexesten Regeln, sondern die mit der konsequentesten Wiederholung der Prüfung.

Häufig gestellte Fragen

Was genau bedeutet “stale trust” im Kontext von PKI? Stale trust beschreibt eine Situation, in der ein Client einem Zertifikat vertraut, obwohl sich dessen tatsächlicher Status (gültig, widerrufen, abgelaufen) bereits geändert hat. Die Ursache liegt meist in verzögerten CRL-Veröffentlichungen oder ausfallenden OCSP-Respondern.

Wie oft sollte eine Windows-CA ihre CRL veröffentlichen? Das hängt vom Risikoprofil ab, aber viele Admins setzen Intervalle von 24 Stunden bis zu einer Woche an. Kürzere Intervalle reduzieren das Zeitfenster für stale trust, erhöhen aber Last und Komplexität bei der Verteilung.

Was ist der Unterschied zwischen CRL und OCSP? CRLs sind statische, signierte Listen widerrufener Zertifikate, die in Intervallen veröffentlicht werden. OCSP ist ein Protokoll für Echtzeit-Statusabfragen einzelner Zertifikate, bringt aber eigene Ausfallrisiken mit, etwa bei nicht erreichbaren Respondern.

Warum hat Google Chrome Entrust-Zertifikate nicht mehr akzeptiert? Nach Jahren dokumentierter Compliance-Verstöße entschied Google 2024, neu ausgestellte Entrust-Zertifikate nicht mehr als vertrauenswürdig einzustufen. Der Fall zeigt, wie lange ein Vertrauensstatus unbemerkt veralten kann, bevor er korrigiert wird.

Wie lässt sich stale trust in Active Directory vermeiden? Regelmäßige ACL-Audits, kombiniert mit automatisierten Tools, die Berechtigungsänderungen protokollieren, sind der wirksamste Ansatz. Einmalige Prüfungen reichen nicht, weil sich Gruppenmitgliedschaften und Zugriffsrechte laufend verändern.

Vertrauen ist kein Zustand, sondern ein Prozess

Ob Zertifikat, Firewall-Regel, AD-Berechtigung oder Lizenzstatus bei einem externen Dienstleister: Die Lektion bleibt dieselbe. Ein Vertrauensstatus, der einmal geprüft wurde, bleibt nicht automatisch gültig. Verisign hat das mit Verisign Informed für die PKI-Welt adressiert. Für die eigene Infrastruktur bedeutet das, Prüfroutinen so zu bauen, dass sie wiederkehrend laufen, nicht einmalig vor dem nächsten Audit.