Zusammenfassung

  • Let’s Encrypt setzte am 9. November 2015 eine Höchstlaufzeit von 90 Tagen fest und empfahl die Erneuerung nach 60 Tagen: kürzere Gültigkeit nach Schlüsselkompromittierung oder Fehlausstellung und mehr Anreiz für automatisiertes HTTPS.
  • Drei Tage später meldete die Ankündigung zur öffentlichen Beta mehr als 11.000 Zertifikate aus der begrenzten Beta. Zugleich räumte sie ein, dass die Client-Erfahrung auf vielen Plattformen noch zuverlässig funktionieren musste.

Analyse

Das Ablaufdatum eines Zertifikats ist im Alltag eine stille Zeile in einer Datei. Für einen Webdienst wird daraus eine Frist. RFC 5280 definiert die Gültigkeit von notBefore bis notAfter, einschließlich beider Zeitpunkte. Ist das Ende erreicht, braucht der Dienst ein neues Zertifikat, das er tatsächlich verwendet.

Am 9. November 2015 erklärte Josh Aas, Geschäftsführer der Internet Security Research Group, warum Let’s Encrypt keine Laufzeit von mehr als 90 Tagen anbieten wollte. Der Höchstwert hatte zwei Aufgaben. Ein gestohlener privater Schlüssel oder ein fehlerhaft ausgestelltes Zertifikat sollte kürzer gültig bleiben. Und häufigere Erneuerungen sollten Automatisierung fördern, die Aas als Voraussetzung für einfach zu nutzendes HTTPS bezeichnete.

Die Empfehlung, nach 60 Tagen zu erneuern, macht den Kompromiss sichtbar. Let’s Encrypt forderte niemanden auf, bis zum letzten Tag zu warten. Bis zur Höchstlaufzeit blieb ungefähr ein Monat, in dem ein Administrator einen Fehler bemerken und manuell eingreifen konnte. Aas schrieb, der Dienst sei jung und Automatisierung für viele Abonnenten neu. Die Frist sollte Software wichtig machen und zugleich einen menschlichen Rückweg offenhalten.

Der Beta-Kalender zeigt, wie früh diese Festlegung fiel. Am 12. November berichtete Aas, dass die begrenzte Beta am 12. September begonnen und bis dahin mehr als 11.000 Zertifikate ausgegeben hatte. Die öffentliche Beta war für den 3. Dezember angekündigt. Dieselbe Mitteilung nannte Automatisierung einen Eckpfeiler der Strategie, verwies aber auf noch notwendige Arbeit an einer zuverlässigen Client-Erfahrung über viele Plattformen hinweg. Die Ausgabe hatte Beta-Maßstab erreicht; ein reibungsloser Erneuerungsablauf überall war noch nicht fertig.

Die Begründung war nüchtern: Administratoren konnten nicht jedes Zertifikat im gesamten Web von Hand erneuern. Sobald Ausstellung und Erneuerung automatisch liefen, sollte eine kürzere Laufzeit den täglichen Aufwand für einen Website-Betrieb nicht erhöhen. Sicherheitsfrist und Betriebsmodell gehörten zusammen. Die Uhr lief schneller; der Client musste sie im Blick behalten.

Manuelle Erneuerung blieb möglich, war aber als Rückfall gedacht. Der normale Ablauf hing von Client-Software, Zeitplanung, Plattformkompatibilität und der tatsächlichen Installation des Ersatz-Zertifikats ab. Der 60. Tag war eine Kalenderregel. Automatisierung sollte daraus eine wiederholbare Routine für viele Server machen.

Die Beta-Zahl zählt Zertifikate, die bis zum 12. November ausgestellt worden waren. Erfolgreiche und fehlgeschlagene Erneuerungen zählt sie nicht. Eine datierte Erfolgsreihe würde zeigen, ob die manuelle Reserve genügte; die beiden Mitteilungen enthalten diese Reihe nicht.

Quellen