Zusammenfassung

  • Geoff Huston widerrief am 21. April 2026 ein Testzertifikat von Let’s Encrypt und fand dessen Seriennummer in der Sperrliste des Ausstellers. 48 Stunden später akzeptierten die drei von ihm getesteten Browserversionen die Verbindung weiterhin.
  • In seinem späteren Vortrag auf der APNIC 62 lehnte Firefox dasselbe Zertifikat nach einigen Wochen ab; Chrome und Safari akzeptierten es in seinem Test noch. Zwischen Veröffentlichung und Durchsetzung der Sperre lag die eigentliche Lücke.

Auf dem Papier war das Zertifikat erledigt. Am Eingang des Browsers zeigte es noch einen gültig wirkenden Ausweis. Geoff Huston hatte ein Let’s-Encrypt-Zertifikat für eine Testseite ausgestellt und vier Stunden später, am 21. April 2026, widerrufen. Die Seriennummer erschien in der Sperrliste des Ausstellers. Damit war die Warnung veröffentlicht; ob sie bei der nächsten TLS-Verbindung wirkte, war eine andere Frage.

Sein eigener Bericht im APNIC-Blog nennt die geprüften Versionen: Firefox 148.0.2, Chrome 147.0.7727.117 und Safari 25.4 ließen die Verbindung nach 48 Stunden zu. Ein einzelnes Testzertifikat und datierte Softwarestände liefern keine ewige Rangliste. Sie legen aber die Trennlinie offen. Die ausstellende Stelle kann den Status ändern. Der Client entscheidet, ob er dem vorgelegten Schlüssel beim Verbindungsaufbau noch vertraut. Eine Listenzeile schließt keine Verbindung von selbst.

Ein paar Wochen später veränderte sich das Bild. In den Folien zur APNIC 62 zeigte Huston, dass Firefox das Zertifikat nun zurückwies, Chrome und Safari es in seinem Versuch weiterhin zuließen. Der Blogbeitrag vom April und der spätere Vortrag dokumentieren zwei Beobachtungszeitpunkte. Gerade dieser Abstand ist interessant: Während die Sperrung längst registriert war, hatte sie den Ort der letzten Entscheidung nicht überall erreicht.

Huston zerlegt die Zustellwege der schlechten Nachricht. Vollständige Sperrlisten kosten Übertragungsvolumen. Online-Statusabfragen verlängern den Verbindungsaufbau, hängen an einem erreichbaren Antwortdienst und verraten dem Aussteller etwas über besuchte Angebote. Eine vom Server angehängte Statusantwort spart den zusätzlichen Weg, doch ein Server mit wissentlich widerrufenem Zertifikat hat wenig Grund, seine eigene Belastungsurkunde vorzulegen. Vom Browser verteilte Auswahlbestände haben wiederum eine eigene Aktualisierungsfrist.

Kürzere Laufzeiten klingen eleganter als dieser Apparat. Von 90 auf 45 oder sechs Tage zu gehen, verkleinert das mögliche Schadensfenster. Wird ein Schlüssel am ersten Tag kompromittiert, braucht es dennoch einen frühzeitigen Widerruf. Laufzeiten von wenigen Stunden würden das heutige Ausstellungsmodell stark belasten. In seinen Schlussfolien schlägt Huston deshalb DNS als Träger des Dienstschlüssels vor, DNSSEC als Signatur und kurze TTLs als Grenze für alte Antworten; eine validierbare Kette könnte sogar mit dem TLS-Handshake kommen. DANE ist hier ein Vorschlag für ein anderes Frischemodell, keine bereits vollzogene Umstellung des Webs. Seine Frage trifft jede scheinbar sichere Verbindung: Wie alt darf die Auskunft sein, auf die das Vertrauen gerade gebaut wird?