Let’s Encrypt, eine von Cloudflare zur Ausstellung von TLS-Zertifikaten verwendete, öffentlich als vertrauenswürdig eingestufte Zertifizierungsstelle, nutzt zwei gesonderte Zertifikatsketten. Eine verfügt über eine Cross-Zertifizierung mit IdenTrust, einer seit dem Jahr 2000 bestehenden, weltweit als vertrauenswürdig geltenden Zertifizierungsstelle. Bei der anderen handelt es sich um die Root-Zertifizierungsstelle von Let’s Encrypt selbst, ISRG Root X1. Seit dem Start von Let’s Encrypt hat ISRG Root X1 nach und nach eine eigene Gerätekompatibilität erreicht.
Die Zertifikatsketten von Let’s Encrypt, die über eine Cross-Zertifizierung mit IdenTrust verfügen, werden am 30. September 2024 auslaufen. Nach Verfall der Cross-Zertifizierung können Server keine Zertifikate mehr bereitstellen, die von der Cross-zertifizierten Kette zertifiziert wurden. Stattdessen werden dann alle Let’s Encrypt-Zertifikate die ISRG Root X1-Zertifizierungsstelle verwenden.
Bei den meisten nach 2016 veröffentlichten Geräte- und Browserversionen wird die Änderung keine Probleme verursachen, da ISRG Root X1 bereits in den Trust Stores dieser Clients installiert ist. Das liegt daran, dass diese modernen Browser und Betriebssysteme auf Agilität und Flexibilität hin konzipiert wurden. Daher lassen sich Trust Stores so aktualisieren, dass neue Zertifizierungsstellen eingebunden werden.
Für ältere Geräte und Systeme – etwa solche mit der (im Jahr 2016 veröffentlichten) Android-Version 7.1.1 oder älteren Versionen –wird die Änderung bei der Zertifikatskette aber sehr wohl Auswirkungen haben, da sich diese ausschließlich auf die Cross-Signatur-Kette stützen und ISRG Root X1 in ihrem Trust Store fehlt. Diese Clients werden beim Zugriff auf Domains, die durch ein Let’s Encrypt-Zertifikat abgesichert sind, mit TLS-Fehlern oder Warnmeldungen konfrontiert sein. Wir haben uns die Daten selbst angesehen und festgestellt, dass 2,96 % aller Android-Anfragen von Geräten stammen, die von der Änderung betroffen sind. Somit würde ein nicht unerheblicher Teil des Traffics den Zugang zum Internet verlieren. Wir möchten das verhindern und werden unsere Zertifikatspipeline so anpassen, dass auch Nutzer mit älteren Geräten ohne manuelle Änderungen seitens unserer Kunden unsere Dienste weiterhin nutzen können.
Ein besseres Internet für alle
Wir haben in der Vergangenheit in Initiativen wie „No Browsers Left Behind“ investiert, um sicherzustellen, dass wir auch nach der Ausmusterung von SHA-1-basierten Algorithmen unseren Kunden weiterhin Support bieten konnten. Den gleichen Ansatz wenden wir jetzt für die bevorstehende Änderung bei Let’s Encrypt an.
Wir haben die Entscheidung getroffen, Let’s Encrypt als Zertifizierungsstelle aus allen Abläufen zu entfernen, bei denen Cloudflare die Zertifizierungsstelle vorgibt. Das wirkt sich auf Kunden aus, die Universal SSL-nutzen, und solche, die „default CA“ (Standard-Zertifizierungsstelle) ausgewählt haben und somit SSL for SaaS verwenden.
Ab Juni 2024 – also einen Zertifikatslebenszyklus (90 Tage) vor Ablauf der Cross-Zertifizierungskette – werden wir mit der Migration von demnächst zu erneuernden Let’s Encrypt-Zertifikaten zu einer anderen Zertifizierungsstelle beginnen. Damit wird sichergestellt, dass ältere, von der Änderung betroffene Geräte kompatibel bleiben. Somit erhalten Kunden künftig nur noch Let’s Encrypt-Zertifikate, wenn sie Let’s Encrypt ausdrücklich als Zertifizierungsstelle anfordern.
Die Änderung bei Let’s Encrypt ist notwendig. Um neue Standards und Protokolle unterstützen zu können, müssen wir das Ökosystem der öffentlichen Schlüssel-Infrastruktur (Public Key Infrastructure – PKI) agiler machen. Durch die Abschaffung der Cross-Zertifizierungskette zwingt Let’s Encrypt Geräte, Browser und Clients, anpassungsfähige Trust Stores zu unterstützen.
Wir haben allerdings in der Vergangenheit bei Anpassungen dieser Art beobachtet, dass dadurch zwar die Einführung neuer Standards vorangetrieben wurde, die Änderungen sich aber unverhältnismäßig stark auf Nutzer in wirtschaftlich benachteiligten Regionen mit begrenzter Verfügbarkeit neuer Technologien ausgewirkt haben.
Unser Ziel ist es, ein besseres Internet zu schaffen. Das bedeutet, dass wir Nutzer weltweit unterstützen. In einem früheren Blogbeitrag über die Änderung bei Let’s Encrypt haben wir Kunden aufgefordert, ihre Zertifizierungsstelle zu wechseln, falls sie Auswirkungen erwarten. Allerdings sind die Folgen im Voraus nur schwer absehbar. Die durch Inkompatibilität mit Trust Stores verursachten Fehler werden hauptsächlich auf dem Client erfasst, wodurch sich die Transparenz für Domaininhaber verringert. Auch wenn heute möglicherweise keine Anfragen von inkompatiblen Geräten eingehen, garantiert dies nicht, dass der Nutzer auch morgen einen störungsfreien Zugang haben wird.
Die Zertifikatspipeline von Cloudflare ist im Lauf der Jahre belastbarer und flexibler geworden. Deshalb können wir uns mühelos an Veränderungen wie diese anpassen, ohne dass dies negative Auswirkungen für unsere Kunden mit sich bringt.
Wie Cloudflare eine robuste Pipeline für TLS-Zertifikate geschaffen hat
Cloudflare verwaltet heute mehrere zehn Millionen Zertifikate im Auftrag von Kunden. Folgende Merkmale zeichnen aus unserer Sicht eine erfolgreiche Pipeline aus:
- Ständige Möglichkeit zur Anforderung von TLS-Zertifikat für Kunden-Domain
- Keine Beeinträchtigung der Anforderbarkeit von Zertifikaten durch Probleme mit der Zertifizierungsstelle
- Anwendung der besten Sicherheitspraktiken und moderner Standards
- Optimierung für zukünftige Skalierung
- Unterstützung einer großen Auswahl an Clients und Geräten
Wir nehmen jedes Jahr weitere Optimierungen an unserer Zertifikatspipeline vor, um den bestmöglichen Dienst zu gewährleisten. So gehen wir dabei vor:
Sicherstellung der ständigen Anforderbarkeit von TLS-Zertifikaten für Kunden-Domains
Seit Einführung von Universal SSL im Jahr 2014 ist Cloudflare für die Ausstellung und Bereitstellung eines TLS-Zertifikats für jede Domain verantwortlich, die durch unser Netzwerk geschützt wird. Das klingt vielleicht trivial, aber damit eine Domain ein Zertifikat erhält, sind einige Schritte erforderlich:
- Domaininhaber müssen für jede Zertifikatsausstellung und -erneuerung die Domain Control Validation (Validierung zur Domainkontrolle) durchführen.
- Um das Zertifikat ausstellen zu können, muss die Zertifizierungsstelle den Domain Control Validation-Token verifizieren.
- CAA (Certification Authority Authorization)-Einträge, die vorschreiben, welche Zertifizierungsstellen für eine Domain verwendet werden können, müssen überprüft werden, damit das Zertifikat nur von autorisierten Parteien ausgestellt werden kann.
- Die Zertifizierungsstelle muss für die Ausstellung des Zertifikats zur Verfügung stehen.
Jeder dieser Schritte erfordert eine Koordinierung zwischen mehreren Akteuren: Domaininhabern, CDN und Zertifizierungsstellen. Bei Cloudflare möchten wir den Erfolg unserer Plattform selbst in der Hand haben. Deshalb haben wir es uns zur Aufgabe gemacht, dafür zu sorgen, dass jeder dieser Schritte durchgeführt werden kann.
Wir sorgen dafür, dass jede Ausstellung und Erneuerung eines Zertifikats für unsere Kunden nur mit minimalem Aufwand verbunden ist. Um ein Zertifikat zu erhalten, muss der Domaininhaber die Domain Control Validation (DCV) absolvieren. So weist er nach, dass ihm die Domain tatsächlich gehört. Sobald die Zertifikatsanfrage initiiert wurde, sendet die Zertifizierungsstelle einen DCV-Token zurück, den der Domaininhaber in einen DNS-Eintrag oder einen HTTP-Token einfügen muss. Wenn Sie Cloudflare als DNS-Provider nutzen, führt Cloudflare die DCV in Ihrem Namen durch, indem der von der Zertifizierungsstelle zurückgesandte TXT-Token automatisch in Ihren DNS-Eintrag eingefügt wird. Sollten Sie einen externen DNS-Anbieter nutzen, bieten wir alternativ die Möglichkeit, die DCV an Cloudflare zu delegieren. Das erlaubt eine automatische Zertifikatserneuerung ohne Zutun des Kunden.
Sobald die DCV-Token eingefügt sind, werden sie von Zertifizierungsstellen überprüft. Diese Überprüfung wird von mehreren Blickwinkeln aus durchgeführt, um Spoofing-Versuche zu verhindern. Da diese Prüfungen jedoch von mehreren Ländern und ASN (autonomen Systemen) aus vorgenommen werden, lösen sie eventuell die Anwendung einer Cloudflare WAF-Regel aus, was die Blockierung der DCV-Prüfung zur Folge haben kann. Wir haben deshalb unsere WAF und unsere Sicherheits-Engine aktualisiert. Diese erkennen nun, dass diese Anfragen von einer Zertifizierungsstelle kommen und blockieren sie nicht, sodass die DCV abgeschlossen werden kann.
Einige Kunden haben aufgrund interner Anforderungen oder Compliance-Vorschriften Präferenzen hinsichtlich der Zertifizierungsstelle. Um zu verhindern, dass eine nicht autorisierte Zertifizierungsstelle ein Zertifikat für eine Domain ausstellt, kann der Domaineigentümer einen DNS-Eintrag für die Autorisierung der Zertifizierungsstelle (Certificate Authority Authorization – CAA) erstellen. Darin wird angegeben, welche Zertifizierungsstellen ein Zertifikat für diese Domain ausstellen dürfen. Um sicherzustellen, dass Kunden immer ein Zertifikat erhalten können, überprüfen wir vor Anforderung eines Zertifikats die CAA-Einträge. Diese verraten uns, welche Zertifizierungsstelle verwendet werden sollte. Falls durch die CAA-Einträge alle verfügbaren Zertifizierungsstellen in der Cloudflare-Pipeline gesperrt sind und der Kunde kein Zertifikat der Zertifizierungsstelle seiner Wahl hochgeladen hat, fügen wir in seinem Namen CAA-Einträge hinzu, damit auf jeden Fall ein Zertifikat ausgestellt werden kann. Wenn möglich optimieren wir die Präferenz. Ansonsten ist es unsere Aufgabe, Ausfälle zu verhindern, indem wir sicherstellen, dass immer ein TLS-Zertifikat für die Domain verfügbar ist – auch wenn es nicht von einer bevorzugten Zertifizierungsstelle kommt.
Derzeit ist Cloudflare nicht als öffentlich vertrauenswürdige Zertifizierungsstelle eingestuft. Deshalb sind wir zur Gewährleistung von Hochverfügbarkeit auf die von uns verwendete Zertifizierungsstelle angewiesen. Eine 100 %ige Verfügbarkeit ist jedoch eine unrealistische Erwartung. Deshalb muss unsere Pipeline gerüstet sein, falls unsere Zertifizierungsstellen einmal nicht verfügbar sind.
Sicherstellung der Anforderbarkeit von Zertifikaten auch bei Problemen mit der Zertifizierungsstelle
Bei Cloudflare denken wir gern vorausschauend. Das bedeutet, Vorfälle zu von vornherein zu unterbinden, noch bevor sie eintreten. Es ist nicht ungewöhnlich, dass Zertifizierungsstellen einmal nicht verfügbar sind. Manchmal ist dies auf einen Ausfall zurückzuführen, aber vor allem kommt es hin und wieder vor, dass Zertifizierungsstellen aufgrund von Wartungsmaßnahmen für einige Zeit nicht zur Verfügung stehen.
Da wir eine Zertifizierungsstellen-Redundanz gewährleisten müssen, stehen uns immer mehrere Zertifizierungsstellen zur Zertifikatsausstellung zur Auswahl. So können wir jederzeit hohe Verfügbarkeit bieten. Sollte Ihnen aufgefallen sein, dass Ihre Universal SSL-Zertifikate von verschiedenen Zertifizierungsstellen ausgestellt werden, ist das so beabsichtigt. Wir verteilen die Last gleichmäßig auf unsere Zertifizierungsstellen, um Single Points of Failure zu vermeiden. Außerdem behalten wir die Latenz und die Fehlerquoten genau im Auge, um etwaige Probleme frühzeitig zu erkennen und automatisch zu einer anderen verfügbaren und leistungsfähigen Zertifizierungsstelle zu wechseln. Ihnen ist das vielleicht nicht bewusst, aber bei einer unserer Zertifizierungsstellen werden jeden Monat viermal Instandhaltungsmaßnahmen durchgeführt. Wenn das geschieht, greifen unsere automatisierten Systeme nahtlos ein und sorgen dafür, dass alles reibungslos läuft. Dies klappt so gut, dass unsere internen Teams gar nicht mehr benachrichtigt werden, weil alles einfach funktioniert.
Anwendung der besten Sicherheitspraktiken und moderner Standards
Sicherheit war und ist für Cloudflare das Allerwichtigste, weshalb die Aufrechterhaltung der höchsten Sicherheitsstandards zum Schutz der Daten unserer Kunden und von privaten Schlüsseln für uns maßgebliche Bedeutung hat.
In den letzten zehn Jahren hat sich das CA/Browser Forum dafür eingesetzt, den Branchenstandard bei der Geltungsdauer von Zertifikaten von fünf Jahren auf 90 Tage zu verkürzen. Dies trägt dazu bei, das Risiko einer Schlüsselkompromittierung zu minimieren. Wenn Zertifikate alle 90 Tage erneuert werden, bleiben ihre privaten Schlüssel nur für diesen Zeitraum gültig. Dadurch verkleinert sich das Zeitfenster, in dem ein Angreifer von dem kompromittierten Material profitieren kann.
Wir begrüßen diese Änderung uneingeschränkt und haben die Gültigkeitsdauer von Zertifikaten deshalb standardmäßig auf 90 Tage festgelegt. Das erhöht unser Sicherheitsniveau, weil dadurch eine regelmäßige Änderung der Schlüssel gewährleistet wird. Außerdem hat es uns dazu veranlasst, Tools wie DCV Delegation zu entwickeln, die bei häufigen Zertifikatserneuerungen eine Automatisierung ohne zusätzlichen Aufwand ermöglichen. So können wir Kunden, die ihre privaten Schlüssel häufig wechseln möchten, Zertifikate mit einer Gültigkeitsdauer von nur zwei Wochen anbieten, ohne dass dies zu Fehlern bei der Zertifikatserneuerung führt.
Cloudflare war schon immer ganz vorn mit dabei, wenn es um neue Protokolle und Standards geht. Es ist kein Geheimnis, dass die Akzeptanz eines neuen Protokolls rasant steigt, wenn es von uns unterstützt wird. Ab diesem Monat werden die von Google Trust Services ausgestellten Zertifikate ECDSA unterstützen. Mit ECDSA erhalten Sie das gleiche Maß an Sicherheit wie mit RSA, jedoch mit kleineren Schlüsseln. Kleinere Schlüssel bedeuten kleinere Zertifikate und weniger Daten zum Aufbau einer TLS-Verbindung, was zu schnellerer Konnektivität und kürzeren Ladezeiten führt.
Optimierung für zukünftige Skalierung
Aktuell stellt Cloudflare fast 1 Million Zertifikate pro Tag aus. Auch nach der jüngsten Umstellung auf kürzere Gültigkeitsdauern von Zertifikaten setzen wir die Optimierung unserer Pipeline fort, um die Ausfallsicherheit weiter zu erhöhen. Doch selbst wenn unsere Pipeline eine erhebliche Last bewältigen kann, sind wir für die Skalierung auf unsere Zertifizierungsstelle angewiesen. Wenn wir eine Zertifizierungsstelle einbinden, werden wir damit augenblicklich zu einem ihrer größten Kunden. Wir stellen hohe Anforderungen an unsere Zertifizierungsstellen und drängen sie zu skalierungsbezogenen Verbesserungen ihrer Infrastruktur. Davon profitieren nicht nur Cloudflare-Kunden, sondern auch das Internet als Ganzes, da die Zertifizierungsstellen dann ein höheres Ausstellungsvolumen bewältigen können.
Und nun, wo Let’s Encrypt die eigene Vertrauenskette verkürzt hat, nehmen wir eine weitere Verbesserung an unserer Pipeline vor, die beste Gerätekompatibilität für alle gewährleisten wird.
Unterstützung aller Clients – ob veraltet oder modern
Die bevorstehende Änderung bei Let’s Encrypt wird verhindern, dass ältere Geräte Anfragen an Domains oder Anwendungen stellen, die durch ein Let’s Encrypt-Zertifikat geschützt sind. Wir möchten den Internetzugang nirgendwo auf der Welt abschneiden und werden unseren Kunden trotz der Änderung weiterhin die beste Gerätekompatibilität bieten.
Dank der jüngsten Verbesserungen sind wir in der Lage, unsere Abhängigkeit von Let’s Encrypt zu verringern, ohne dass die Zuverlässigkeit oder die Servicequalität unserer Zertifikatspipeline darunter leidet. Einen Zertifikatslebenszyklus (90 Tage) vor der Änderung werden wir beginnen, die Zertifikate auf eine andere, mit den betroffenen Geräten kompatible Zertifizierungsstelle umzustellen. So mildern wir etwaige Auswirkungen ab, ohne dass unsere Kunden dafür etwas unternehmen müssen. Weiter genutzt wird Let’s Encrypt dann nur noch von den Kunden, die den Anbieter ausdrücklich als Zertifizierungsstelle ausgewählt haben.
Was Sie von der Migration von Let’s Encrypt erwarten können
Die Cross-Zertifizierungskette von Let’s Encrypt wird am 30. September 2024 ihre Gültigkeit verlieren. Let’s Encrypt plant zwar, die Ausstellung von Zertifikaten dieser Kette am 6. Juni 2024 einzustellen, doch Cloudflare wird die Cross-Zertifizierungskette für alle Let’s Encrypt-Zertifikate bis zum 9. September 2024 weiter unterstützen.
90 Tage bzw. einen Zertifikatslebenszyklus vor der Änderung werden wir damit beginnen, die Let’s Encrypt-Zertifikate umzustellen und eine andere Zertifizierungsstelle zu nutzen. Diese Änderung wird für alle Produkte vorgenommen, bei denen Cloudflare für die Auswahl der Zertifizierungsstelle verantwortlich ist. Für Kunden, die Universal SSL und durch die Auswahl von „default CA“ (Standard-Zertifizierungsstelle) SSL for SaaS verwenden, erfolgt dies automatisch.
Alle Kunden, die ausdrücklich Let’s Encrypt als Zertifizierungsstelle ausgewählt haben, erhalten eine Benachrichtigung per E-Mail mit einer Liste ihrer Let’s Encrypt-Zertifikate und der Angabe, ob wir Anfragen von älteren Geräten auf diese Hostnamen verzeichnen.
Nach dem 9. September 2024 stellt Cloudflare alle Let’s Encrypt-Zertifikate über die Kette IRG Root X1 bereit. Folgendes können Sie auf Grundlage des von Ihnen verwendeten Zertifikatsprodukts erwarten:
Universal SSL
Bei Universal SSL wählt Cloudflare die Zertifizierungsstelle aus, die für das Zertifikat der Domain verwendet wird. So können wir das Zertifikat auswählen, das für unsere Kunden jeweils am besten geeignet ist. Wenn Sie Universal SSL nutzen, müssen Sie daher nichts weiter unternehmen, um sich auf diese Änderung vorzubereiten. Ihr Zertifikat wird von Cloudflare automatisch auf eine Zertifizierungsstelle mit höherer Kompatibilität umgestellt.
Erweiterte Zertifikate
Mit dem Advanced Certificate Manager wählen die Kunden gezielt aus, welche Zertifizierungsstelle sie verwenden möchten. Wenn Let’s Encrypt ausdrücklich als Zertifizierungsstelle für ein Zertifikat festgelegt wurde, halten wir uns daran, weil Kunden sich möglicherweise aus einem bestimmten Grund für diese Zertifizierungsstelle entschieden haben – entweder wegen interner Anforderungen oder, weil sie Certificate Pinning implementiert haben, wovon wir allerdings dringend abraten.
Wenn wir feststellen, dass eine Domain von der Änderung betroffen ist, die ein von Let’s Encrypt ausgestelltes erweitertes Zertifikat nutzt, informieren wir den betreffenden Kunden per E-Mail darüber, welche Zertifikate Let’s Encrypt als Zertifizierungsstelle verwenden und ob diese Domains Anfragen von Clients erhalten, die von der Änderung betroffen sind. Wenn ein Kunde die Zertifizierungsstelle wechseln möchte, steht ihm diese Entscheidung frei.
SSL für SaaS
Mit SSL für SaaS haben Kunden zwei Möglichkeiten: Sie können eine Standard-Zertifizierungsstelle verwenden und Cloudflare die ausstellende Instanz auswählen lassen, oder sie müssen angeben, welche Zertifizierungsstelle verwendet werden soll.
Wenn Sie die Wahl der Zertifizierungsstelle Cloudflare überlassen, setzen wir automatisch eine Zertifizierungsstelle mit höherer Gerätekompatibilität ein.
Falls Sie eine bestimmte Zertifizierungsstelle für Ihre benutzerdefinierten Hostnamen angeben, respektieren wir diese Wahl. Wir unterrichten in diesem Fall SaaS-Anbieter und Plattformen per E-Mail darüber, welche benutzerdefinierten Hostnamen Anfragen von älteren Geräten erhalten. Wenn ein Kunde die Zertifizierungsstelle wechseln möchte, steht ihm diese Entscheidung frei.
Benutzerdefinierte Zertifikate
Wenn Sie eine direkte Integration mit Let’s Encrypt und benutzerdefinierte Zertifikate nutzen, um Ihre Let’s Encrypt-Zertifikate bei Cloudflare hochzuladen, werden Ihre Zertifikate mit der Cross-Zertifizierungskette gebündelt, solange Sie die Bündelmethode „compatible“ (kompatibel) oder „modern“ wählen und diese Zertifikate vor dem 9. September 2024 hochladen. Nach diesem Datum werden wir alle Let’s Encrypt-Zertifikate mit der ISRG Root X1-Kette bündeln. Bei der Bündelungsmethode „user-defined“ (benutzerdefiniert) stellen wir immer die bei Cloudflare hochgeladene Kette bereit. Beim Hochladen von Let’s Encrypt-Zertifikaten mit dieser Methode müssen Sie darauf achten, dass nach dem 30. September 2024 – dem Datum, an dem die Zertifizierungsstelle ihre Gültigkeit verliert – hochgeladene Zertifikate die richtige Zertifikatskette enthalten.
Wenn Sie die Clients kontrollieren, die sich mit Ihrer App verbinden, empfehlen wir außerdem, den Trust Store so zu aktualisieren, dass er ISRG Root X1 enthält. Sollten Sie Certificate Pinning nutzen, löschen oder aktualisieren Sie Ihre Pin. Im Allgemeinen raten wir allen Kunden vom Pinning ihrer Zertifikate ab, weil dies bei Zertifikatserneuerungen oder Änderungen von Zertifizierungsstellen in der Regel zu Problemen führt.
Fazit
Internetstandards werden sich weiter wandeln und verbessern. Wir begrüßen diese Veränderungen. Doch wir müssen ebenfalls anerkennen, dass es in unserer Verantwortung liegt, den Internetzugang der Nutzer auch in den Teilen der Welt aufrechtzuerhalten, in denen neue Technologien nicht ohne weiteres verfügbar sind. Durch die Nutzung von Cloudflare haben Sie immer die Möglichkeit, die Einstellungen zu wählen, die für Ihre Anwendung am besten geeignet sind.
Weitere Informationen zu dieser Änderung finden Sie in unserer Dokumentation für Entwickler.