Let’s Encrypt verkürzt die Vertrauenskette

 (letsencrypt.org)
2 Punkte von GN⁺ 2023-07-11 | 1 Kommentare | Auf WhatsApp teilen
  • Let’s Encrypt verlängert die am 30. September 2024 auslaufende Cross-Signatur (cross-sign) nicht und stellt auf eine kürzere Zertifikatskette um, die bei ISRG Root X1 endet
  • In der Anfangsphase war die eigene Root noch nicht ausreichend vertrauenswürdig, daher stützte man sich auf DST Root CA X3 von IdenTrust; inzwischen ist die Vertrauensabdeckung von ISRG Root X1 deutlich größer
  • Die 2021 für die Kompatibilität mit älteren Android-Versionen hinzugefügte Root-Cross-Signatur war eine Übergangslösung; dadurch konnten alte Android-Geräte Let’s-Encrypt-Zertifikaten drei weitere Jahre vertrauen
  • In den vergangenen drei Jahren ist der Anteil der Android-Geräte, die ISRG Root X1 vertrauen, von 66 % auf 93,9 % gestiegen; durch den Wegfall der Cross-Signatur sinkt außerdem die Zahl der Zertifikat-Bytes im TLS-Handshake um mehr als 40 %
  • Nutzern von Android 7.0 oder älter wird Firefox Mobile empfohlen; Website-Betreiber und Entwickler von ACME-Clients sollten die Verarbeitung der Zertifikatsketten passend zum Umstellungsplan 2024 überprüfen

Hintergrund zum Ende der Cross-Signatur

  • Let’s Encrypt ließ in der Anfangsphase ein Intermediate-Zertifikat von IdenTrusts DST Root CA X3 cross-signieren, damit die Zertifikate breit vertraut wurden
    • So konnten Zertifikate, die von diesem Intermediate-Zertifikat ausgestellt wurden, als vertrauenswürdig gelten, auch wenn die eigene Root ISRG Root X1 noch nicht breit vertraut war
  • Mit der Zeit wurde ISRG Root X1 eigenständig breit vertrauenswürdig
  • Ende 2021 sollten das cross-signierte Intermediate-Zertifikat und DST Root CA X3 selbst ablaufen
    • Aktuelle Browser vertrauten damals der Let’s-Encrypt-Root, doch mehr als ein Drittel der Android-Geräte nutzte noch eine alte OS-Version
    • Diese Geräte hätten Websites mit Let’s-Encrypt-Zertifikaten plötzlich nicht mehr vertrauen können
  • Let’s Encrypt setzte 2021 nicht beim Intermediate-Zertifikat an, sondern ließ die Root direkt cross-signieren, um eine Übergangslösung zu schaffen, die länger gültig war als DST Root CA X3
    • Dadurch konnten ältere Android-Geräte Let’s-Encrypt-Zertifikaten drei weitere Jahre vertrauen
  • Diese Cross-Signatur läuft am 30. September 2024 ab

Warum auf eine kürzere Kette umgestellt wird

  • Let’s Encrypt holt keine neue Cross-Signatur mehr ein, um die Kompatibilität weiter zu verlängern
    • In den vergangenen drei Jahren ist der Anteil der Android-Geräte, die ISRG Root X1 vertrauen, von 66 % auf 93,9 % gestiegen
    • Android 14 kann den Trust Store aktualisieren, ohne dass ein vollständiges OS-Update nötig ist; dieser Anteil könnte daher weiter steigen
    • Der Wegfall der Cross-Signatur reduziert die Zahl der im TLS-Handshake übertragenen Zertifikat-Bytes um mehr als 40 %
    • Auch die Betriebskosten sinken deutlich, sodass Let’s Encrypt seine Mittel stärker auf Verbesserungen bei Datenschutz und Sicherheit konzentrieren kann

Umstellungsplan 2024

  • Donnerstag, 8. Februar 2024: Bei Anfragen an den API-Endpunkt /acme/certificate wird die standardmäßige Bereitstellung der Cross-Signatur eingestellt
    • Bei den meisten Abonnenten richtet der ACME-Client eine Kette ein, die bei ISRG Root X1 endet, und der Webserver liefert im TLS-Handshake die kürzere Kette aus
    • Die längere Kette, die bei der bald auslaufenden Cross-Signatur endet, konnte weiterhin als alternative Kette angefordert werden
  • Donnerstag, 6. Juni 2024: Die Bereitstellung der längeren cross-signierten Kette wird vollständig eingestellt
    • Dieser Zeitpunkt liegt etwas mehr als 90 Tage vor dem Ablauf der Cross-Signatur und entspricht der Lebensdauer eines Zertifikats
    • Der Zeitplan soll sicherstellen, dass Abonnenten mindestens einen vollständigen Ausstellungszyklus haben, um von der cross-signierten Kette wegzukommen
  • Montag, 30. September 2024: Das cross-signierte Zertifikat läuft ab
    • Für die meisten Nutzer sollte dies kein besonderes Ereignis sein; Client-Ausfälle sollten bereits in den vorangegangenen sechs Monaten aufgetreten sein

Was Nutzer und Betreiber prüfen sollten

  • Nutzer von Android 7.0 oder älter müssen möglicherweise aktiv werden, um weiter auf Websites zugreifen zu können, die mit Let’s-Encrypt-Zertifikaten geschützt sind
    • Let’s Encrypt empfiehlt die Installation und Nutzung von Firefox Mobile, das statt des Android-OS-Trust-Stores einen eigenen Trust Store verwendet
  • Website-Betreiber sollten im 2. und 3. Quartal 2024 die Nutzungsstatistiken ihrer Websites und die aktiven User-Agent-Strings prüfen
    • Wenn Android-Besuche plötzlich zurückgehen, könnte es eine größere Zahl von Nutzern mit Android 7.0 oder älter geben
    • Es wird empfohlen, diesen Nutzern Hinweise zur Verwendung von Firefox Mobile bereitzustellen
  • Entwickler von ACME-Clients sollten bei jeder Zertifikatsausstellung und -erneuerung die von der API bereitgestellte Zertifikatskette korrekt herunterladen und installieren
    • Zu früheren Fehlertypen gehörte, die Kette gar nicht herunterzuladen und nur das End-Entity-Zertifikat bereitzustellen
    • In anderen Fällen wurde keine Kette heruntergeladen, sondern eine hartcodierte Kette bereitgestellt
    • Es gab auch Fälle, in denen die Kette nur bei der Erstausstellung heruntergeladen wurde, nicht aber erneut bei der Erneuerung
  • Fragen zur Umstellung können im Let’s-Encrypt-Community-Forum gestellt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-11
Hacker-News-Kommentare

  • Ich erinnere mich, dass Let's Encrypt diesen Wechsel im Sommer 2019 angekündigt, ihn dann aber nach Community-Feedback verschoben hat.
    Ich war damals einer derjenigen, die stark auf eine Neubewertung gedrängt haben, aber ich hätte nicht gedacht, dass sie es in dieser Angelegenheit um ganze 4,5 Jahre länger hinauszögern würden als erwartet. Danke dafür, dass sie das TLS-Ökosystem so vorsichtig behandeln.

    • Kann das jemand erklären? Ich nutze es, vergesse aber oft, wie wichtig Let's Encrypt für meine Website ist.

  • Um 95 % der Android-Geräte abzudecken, muss man bis zurück zu Android 7.0 Nougat aus dem August 2016 unterstützen.
    https://en.wikipedia.org/wiki/Android_Nougat
    Für 95 % der iOS-Geräte reicht iOS 14 aus dem September 2020, und selbst bei nur 90 % ist Android bei 8.1 (2017), iOS dagegen bei 15 (2021).
    https://iosref.com/ios-usage
    https://en.wikipedia.org/wiki/IOS_14
    Es wirkt so, als sei Apple besser darin, die Leute davon zu überzeugen oder ihnen zu ermöglichen, auf neuere Betriebssysteme zu wechseln.

    • Apple verkauft in Entwicklungsländern keine 10-Dollar-Handys. Wenn man Geräte derselben Preisklasse bei den großen Herstellern oder Netzbetreibern vergleicht, ist der Unterschied wahrscheinlich nicht so extrem.
    • Es ist einfacher. Apple verhindert, dass Dritte iPhones bauen, während Google Dritten erlaubt, Android-Smartphones zu bauen.
      Dass Geräte nicht aktualisiert werden, liegt daran, dass die Hersteller keine Updates mehr liefern.
    • Betriebssystem-Upgrades werden von Google und den Geräteherstellern gemeinsam miserabel gehandhabt, aber es gibt keinen Grund, warum das CA-Bundle an die Betriebssystemversion gebunden sein müsste.
      Laut der Seite zum CA-Bundle von curl ist das Mozilla-Bundle entpackt etwa 200 KB groß, und auf meinem Android ist die Chrome-App 25 MB groß, daher erscheint es vernünftig, mit einer Erhöhung der App-Größe um 1 % aktuell zu bleiben.
      Natürlich könnten auch andere Apps aktuelle CAs brauchen, aber man kann durchaus fragen, ob wirklich alle CAs nötig sind oder nur die, die tatsächlich wahrscheinlich verwendet werden.
    • Wenn man den gesamten Hardware- und Software-Stack kontrolliert, ist es deutlich einfacher, die alten Geräte der Kunden aktuell zu halten.
      Google kann nicht viel tun, wenn irgendein Billighersteller beschließt, seinen Kunden keine Updates zu liefern. Man könnte verlangen, dass für eine gewisse Zeit Updates bereitgestellt werden müssen, um eine Android-Zertifizierung zu bekommen oder zu behalten, aber irgendwann könnte dieser Hersteller Android auch ganz aufgeben.
      Außerdem liefert Qualcomm für ältere Chipsätze mit der Zeit auch keine aktualisierten Kernel und Blobs mehr. Google hat zwar ausgehandelt, dass dieser Zeitraum länger ist als die früher erbärmlichen 18 Monate, aber Qualcomm ist nicht verpflichtet, noch kooperativer zu sein. Seit Google begonnen hat, eigene Chipsätze zu bauen, ist das Interesse an diesem Problem auch etwas gesunken.
      Das soll nicht heißen, dass es gut ist, aber im Android-Modell läuft es meistens zwangsläufig so, während Apples Modell in solchen Punkten mehr Kontrolle erlaubt.
    • Bei mir ist es die verbesserte Kamera.

  • Die Art, wie sie die alte Cross-Signierung weiter funktionsfähig gehalten haben, war ziemlich interessant.
    Die neue Cross-Signierung war insofern etwas ungewöhnlich, als sie über das Ablaufdatum von DST Root CA X3 hinausreichte. Möglich war diese Lösung, weil Android das Ablaufdatum von Zertifikaten, die als Trust Anchor verwendet werden, absichtlich nicht erzwingt.
    Tatsächlich funktionieren Trust Anchors ziemlich anders als andere Zertifikate, was überraschend sein kann.
    [1] https://letsencrypt.org/2020/12/21/extending-android-compati...
    [2] https://alexsci.com/blog/name-non-constraint/

    • Diese Lösung war nicht perfekt. Das meiste wurde zwar recht schnell behoben, aber sie führte zu einem der längsten Threads, die ich je im LE-Forum gesehen habe: https://community.letsencrypt.org/t/help-thread-for-dst-root...
      Wenn ich mich richtig erinnere, war eines der großen Probleme, dass altes OpenSSL das Ablaufdatum des Root-Ankers geprüft hat. Und das war noch nicht alles: In der Firma, in der ich damals war, musste Ubuntu irgendetwas patchen, um mit dieser Situation umzugehen, und der Patch kam erst wenige Tage vor dem Ablaufdatum heraus, sodass einige Systeme kurzzeitig Ausfälle hatten. Um das Problem zu beheben, mussten wir massenhaft Docker-Images neu bauen.
      Dieser Workaround war so drastisch und ohne Präzedenzfall, dass ich annehme, er wurde nur eingesetzt, weil der Unterschied zu den Kosten einer Cross-Signierung durch eine nicht abgelaufene und breit kompatible Root-CA enorm gewesen sein muss. Es dürfte auch sehr viel Testaufwand erfordert haben. Es war nicht perfekt, aber dass es im Großen und Ganzen recht reibungslos ablief, war beeindruckend.
    • Es hat mich etwas überrascht, dass der Android-Ansatz anderswo nicht die übliche Vorgehensweise ist. Ich hatte gedacht, die Zeitprüfung einer TLS-Zertifikatskette C0 -> C1 -> C2 ... -> Cn funktioniere ungefähr nach folgendem Pseudocode:
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 time_check = cert.issue_time
      6 return NOT_EXPIRED
      Nach etwas Recherche stellte sich aber heraus, dass es tatsächlich eher ohne Zeile 5 funktioniert und alle Zeitprüfungen auf Basis der aktuellen Zeit erfolgen. Alle Zertifikate in der Kette müssen jetzt gültig sein.
      Code-Signing-Zertifikate funktionieren so, wie ich fälschlicherweise angenommen hatte, dass es auch bei TLS sei. Mit Zeitstempel signierter Code bleibt gültig, auch wenn das Root-Zertifikat inzwischen abgelaufen ist, solange die Root zum Zeitpunkt des Zeitstempels gültig war.

  • Hoffentlich ist das Auslaufen eines Cross-Signing-Zertifikats für die meisten ein Nicht-Ereignis, aber beim letzten Ablauf der DST-Cross-Signatur war das nicht so.
    Soweit ich mich erinnere, konnte GnuTLS nach dem Ablauf die Pfadbildung nicht korrekt durchführen. Es scheint, als hätte es nur einen Pfad zu dem abgelaufenen Zertifikat aufgebaut, diesen dann als abgelaufen gemeldet und abgebrochen, ohne andere mögliche Pfade zu berücksichtigen.
    Noch schlimmer war, dass GnuTLS die TLS-Bibliothek war, die apt bei HTTPS verwendete. HTTPS ist zwar nicht der Standard, aber unser Security-Team wollte alle Pakete vendoren und sicher ausliefern; das war an sich vernünftig, aber die Kosten waren Ausfälle. Ich glaube, das wurde in Bullseye behoben, und zwar rein zufällig nur etwa eine Woche vor dem Ablauf. Auch Azure hatte im Zusammenhang mit diesem Ablauf mehrere Ausfälle.

    • Erneuern nicht alle Betreiber von apt-Mirrors etwa einmal im Monat ihre LE-Zertifikate mit certbot? Dann müssten sie nach dem 6. Juni 2024 doch ein Zertifikat bekommen, das nicht abläuft und nicht Cross-Signing ist, sondern von der neuen LE-Root signiert wurde — übersehe ich etwas?

  • Gibt es, abgesehen von der Nutzung unverschlüsselten HTTP, eine vorgeschlagene Lösung, damit TLS nicht länger die fragilste Komponente des Webs ist?
    Die ständigen Änderungen wie Protokollabschaltungen, Zertifikatsabläufe und Austausch wirken, als hätten sie geplante Obsoleszenz übermäßig verstärkt.

    • Ich würde TLS nicht als die fragilste Komponente des Webs ansehen. Dieser Titel geht je nach Maßstab wahrscheinlich eher an DNS, BGP oder us-east-1.
    • Das Problem ist nicht, dass sich TLS ständig ändert. Aus Sicherheitsgründen muss es sich ändern.
      Der schlechte Teil, der zu geplanter Obsoleszenz führt, ist, dass Geräte viel zu schnell keine Hersteller-Updates mehr bekommen und Dritte sie auch nicht aktualisieren können.
      Meine bevorzugte Lösung wäre ein Gesetz, nach dem Hersteller Sicherheitsupdates nicht vor Ablauf von 10 Jahren nach Verkaufsende einstellen dürfen, oder — wenn sie sie einstellen wollen — alles Open Source stellen oder allen Käufern den vollen Kaufpreis erstatten müssen.
    • Das meiste Unangenehme an TLS scheint darin zu liegen, dass man der Neuausstellung von Zertifikaten ständig hinterherlaufen muss.
      Der Grund dafür ist, dass verteilte Sperrung im Weltmaßstab ein absurd schwieriges Problem ist. Um abzumildern, dass eine gewisse Bindung zwischen Nutzern und Zertifikaten praktisch nicht widerrufbar ist, verkürzt man die Zertifikatslaufzeiten, damit der Schadensradius kleiner bleibt.
      Das ist natürlich kein großer Trost, aber die Welt kurzlebiger Zertifikate nach ACME bietet immer noch eine bessere Developer Experience als die albtraumhafte Welt langfristiger Verisign-Zertifikate. Es ist auch gut, im Hinterkopf zu behalten, dass jede Alternative zu TLS auf ähnliche Probleme stoßen würde.
    • Grundsätzlich denke ich, dass keine Instanz für immer vertrauenswürdig sein kann. Die beste Lösung ist, Zertifikatsupdates getrennt vom normalen Update-Pfad bereitzustellen.
      Das x509-Zertifikatsformat hat sich in Wirklichkeit über lange Zeit kaum verändert.
      Die Protokolländerungen dürften sich inzwischen stabilisieren. TLS 1.2 wurde 2008 eingeführt und gilt immer noch als in Ordnung, also ist es kaum noch als neu zu bezeichnen. Viele Leute haben es gründlich geprüft, daher darf man hoffen, dass die meisten Probleme inzwischen bekannt sind.
    • DANE: https://wikipedia.org/wiki/DNS-based_Authentication_of_Named...
      Meiner Meinung nach ist das, was Let's Encrypt macht, im Grunde auch eine Form von DANE, daher frage ich mich, warum man es nicht einfach unterstützt. Natürlich kann es Anwendungsfälle geben, für die DANE nicht geeignet ist.
      Es scheint keinen Grund zu geben, warum Perfektion etwas blockieren sollte, das gut genug ist, und wer will, kann einfach DANE verwenden.

  • Bedeutet die Aussage „kann die Betriebskosten erheblich senken und Mittel auf Datenschutz- und Sicherheitsverbesserungen konzentrieren“, dass sie für Cross-Signing Beträge in Millionenhöhe zahlen?

    • Laut Form 990 von 2021 wurden an Identrust unter dem Posten „Internet Services“ 434.000 US-Dollar gezahlt. Ich weiß nicht, ob sie von Identrust außer Cross-Signing noch etwas anderes bezogen haben, aber es scheint möglich, dass dieser Betrag die Kosten für Cross-Signing war.
      Die Gesamtausgaben in demselben Jahr betrugen 5,1 Millionen Dollar, also entsprach dieser Posten fast 10 % des Budgets.
      [0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...

  • Kennt jemand die Hintergrundgeschichte dazu, wie ein Zertifikatsunternehmen zum Cross-Signing bewegt wurde? Tötet Let’s Encrypt nicht ihr Geschäftsmodell komplett?

    • Was Let's Encrypt getötet hat, war das Geschäftsmodell des Verkaufs von domainvalidierten Zertifikaten für 10 Dollar pro Jahr. Wenn man Wildcards wollte, war es deutlich teurer.
      Firmen wie RapidSSL oder GoDaddy hätten Let's Encrypt vermutlich kein Cross-Signing gegeben, außer man hätte ihnen Geld auf dem Niveau von „Kauft unser gesamtes CA-Geschäft“ geboten.
      Aber der Verkauf von DV-Zertifikaten war nicht das Geschäftsmodell von IdenTrust, daher könnten sie, wie anderswo vermutet wurde, durchaus bereit gewesen sein, Cross-Signing für einen Betrag unterhalb von sechs Stellen anzubieten. Aufgrund der Funktionsweise von TLS-Root-Zertifikaten war das Cross-Signing von IdenTrust für LE genauso nützlich wie das Cross-Signing einer extrem profitablen CA.
    • Wenn ich ein Zertifikatsunternehmen wäre, dessen Zielmarkt Großunternehmen sind, die Let's Encrypt eher nicht verwenden, hätte ich Let's Encrypt Cross-Signing gegeben, um Wettbewerber zu schwächen, die stärker von kleinen Unternehmen oder anderen Projekten abhängig sind, die Let's Encrypt attraktiv finden.
    • Wahrscheinlich wurden sie mit Geld überzeugt. Wenn nicht, hätte es jemand anderes getan.
      Es sieht nicht so aus, als wäre IdenTrust daran zugrunde gegangen.
      1 IdenTrust 48.5% 53.6%
      2 DigiCert Group 13.1% 14.5%
      3 Sectigo (Comodo Cybersecurity) 12.1% 13.4%
      4 GlobalSign 6.1% 6.7%
      5 Let's Encrypt 5.8% 6.4%
      6 GoDaddy Group 4.8% 5.3%
      https://en.wikipedia.org/wiki/Certificate_authority
    • Überhaupt nicht. Die großen Zertifizierungsstellen verkaufen alle an Unternehmenskunden und werden das auch weiterhin tun. Die meisten Nutzer von Letsencrypt sind Privatpersonen oder bewegen sich eher im Hobbybereich.

  • Als Ende 2021 das kreuzsignierte Zwischenzertifikat und DST Root CA X3 selbst abliefen, vertrauten alle aktuellen Browser bereits der LE-Root, aber mehr als ein Drittel der Android-Geräte lief noch mit veralteten Betriebssystemen, sodass Websites mit LE-Zertifikaten plötzlich nicht mehr vertrauenswürdig gewesen wären.
    Erst vor ein paar Wochen wurde mir klar, dass wohl auch Ubiquiti-Nutzer betroffen waren.

  • Als ich kürzlich das Backend von AWS auf einen lokalen Server verlegt habe, musste ich statt des sonst genutzten Letsencrypt zu ZeroSSL wechseln.
    Der Grund war, dass die noch unterstützten IoT-Geräte aus dem Jahr 2016 nicht über das für die Prüfung von LE-Zertifikaten nötige Root-Zertifikat verfügten. Vermutlich hing das mit dem Ablauf des von LE genutzten R3-Root-Zertifikats im Jahr 2021 zusammen.
    Es war ziemlich schockierend, dass durch das Ablaufen eines einzigen Zertifikats eine komplette ausgelieferte Produktlinie zu Elektroschrott werden kann. In diesem Fall war es kein großes Problem, weil ein gültiges Root-Zertifikat eines anderen Anbieters vorhanden war.

    • Als SHA-1 schrittweise ausgemustert wurde, haben sich in mozilla.dev.security.policy viele CAs lautstark beklagt, die SHA-1-Zertifikate in Medizinprodukte und POS-Systeme eingebaut hatten und kaum eine Möglichkeit für Updates besaßen.
      Sie haben sogar noch nach dem vom CA/Browser Forum festgelegten Stichtag weiter Zertifikate ausgestellt. Damals dachte ich, allen sei klar geworden, dass die Nutzung der Web PKI nicht damit vereinbar ist, keinerlei Möglichkeit zum Ausrollen von Updates zu haben, aber offenbar doch nicht.

  • Seit kurz nach der Einführung der Kreuzsignierung haben wir auf auf Desktop-Nutzer ausgerichteten Websites kreuzsignierte Zertifikate entfernt.
    Dadurch entstanden zuvor nicht vorhandene Kompatibilitätsprobleme, und einige Zertifikatsprüfer scheiterten an einem abgelaufenen Root-Zertifikat. Die betroffenen Nutzer waren nicht technisch versiert, sodass die eigentliche Ursache letztlich nie ermittelt werden konnte.