Cloudflare will selbst CA werden, weil Gratis-CAs zu konzentriert sind

Cloudflare stützt sich seit Jahren auf 16 öffentliche Partner-CAs, ohne selbst je ein öffentlich vertrauenswürdiges Zertifikat ausgestellt zu haben. Nun will das Unternehmen selbst eine werden, und das Interessante ist der Entwurf: klassische Zertifikate und Merkle Tree Certificates unter einer CA, mit Fehlereindämmung von Anfang an.

Ein Zertifikatsnutzer wird zum Zertifikatsaussteller #

Die meisten Infrastrukturunternehmen bleiben auf einer Seite der Zertifikatsbeziehung. Sie beantragen Zertifikate, installieren sie und beschweren sich, wenn eine CA einen Vorfall hat. Cloudflare stand fest auf der Seite der Nutzer. Nach eigener Darstellung hat das Unternehmen nie selbst ein einziges öffentlich vertrauenswürdiges Zertifikat ausgestellt.

Das soll sich ändern, oder zumindest sagt Cloudflare, dass es das beabsichtigt. Das Unternehmen kündigt seine Absicht an, eine öffentliche Zertifizierungsstelle zu werden. Die Ankündigung ist vorsichtig darin, wo die Dinge heute stehen, und dieser Artikel sollte es auch sein. Cloudflare stellt noch keine Zertifikate aus. Alles am Verhalten des Dienstes, von seiner ACME-Schnittstelle über seine Erneuerungsregeln bis zur Unterstützung von Merkle Tree Certificates, ist eine Absichtserklärung und keine Beschreibung eines laufenden Systems.

Glaubwürdig macht die Ankündigung nicht der Ehrgeiz, sondern die bereits sichtbare Vorarbeit. Cloudflare hat die Aufnahme in die Root-Programme von Chrome, Apple, Microsoft und Mozilla beantragt. Das Unternehmen sagt, es durchlaufe den Bewerbungs- und Genehmigungsprozess bei jedem der zentralen Root-Key-Programme des Webs, und es weist darauf hin, dass diese Prozesse öffentlich ablaufen. Jeder kann im Prinzip verfolgen, ob die Bewerbung Erfolg hat.

Warum Cloudflare die Frage stellen kann #

Cloudflares Argument für eine eigene CA beginnt bei seiner Rolle als Kunde. Das Unternehmen steht vor mehr als 20 Prozent des weltweiten Internet-Anfrageverkehrs. Es terminiert TLS für Millionen von Domains und ist auf Millionen von Zertifikaten pro Jahr angewiesen. Über Universal SSL stellt es seinen Kunden Zertifikatspakete bereit, und es bezieht außerdem Zertifikate von vielen verschiedenen CAs, um seine eigenen Systeme und internen Abläufe zu betreiben.

Damit die Dienste der Kunden laufen, bezieht Cloudflare diese Zertifikate über mehrere CAs, mit primären und Ausweichpfaden, damit die Dienste auch bei CA-Ausfällen und Widerrufsereignissen verfügbar bleiben. Das Netz öffentlicher Partner-CAs, auf das es sich seit vielen Jahren stützt, umfasst 16.

Der Ausweichmechanismus verdient einen genaueren Blick, weil er zeigt, wie Cloudflare über Ausfälle denkt. Jedes Universal-SSL-Zertifikat wird bereits mit einem Ersatzzertifikat ausgeliefert, das mit einem separaten Schlüssel versehen und von einer anderen Stelle ausgestellt ist. Wird das primäre Zertifikat je widerrufen oder kompromittiert, steht der Ersatz zur automatischen Bereitstellung bereit. Das ist eine Absicherung gegen das Versagen einer einzelnen CA, gebaut von der Kundenseite der Beziehung aus.

Es ist aber auch eine Absicherung mit einer Obergrenze. Man kann nur über die CAs streuen, die es gibt, und die Quelle argumentiert, dass das Angebot an leistungsfähigen CAs dünner ist, als es aussieht.

Das Konzentrationsproblem #

Die Zahlen hinter diesem Argument sind eindrücklich. Let's Encrypt stellt in der Größenordnung von zehn Millionen Zertifikaten pro Tag aus. Es bedient mehr als 500 Millionen Websites und hat 2025 die Marke von vier Milliarden aktiven Zertifikaten überschritten. Das sind Zahlen einer einzigen kostenlosen CA, und sie beschreiben ein Web, dessen Verschlüsselung stark auf einer einzigen Organisation ruht.

Die Quelle zieht den naheliegenden Schluss, mit einer angemessenen Einschränkung: Hätte die dominierende kostenlose Zertifizierungsstelle eine schlechte Woche, hätte ein Großteil des Webs keine vergleichbare kostenlose, automatisierte Alternative, die die Last übernehmen könnte. Das ist eine Aussage über einen hypothetischen Fall, und Cloudflare stellt sie auch so dar. Es behauptet nicht, dass eine solche Woche stattgefunden hat oder bevorsteht.

Trotzdem ist die Logik leicht nachzuvollziehen. Eine kostenlose, automatisierte CA ist nur dann eine Resilienzoption, wenn sie vor dem Notfall existiert. Cloudflares Angebot lautet, dass es eine zweite in großem Maßstab bereitstellen kann. Ich halte das für den stärksten kommerziellen und technischen Grund in der Ankündigung, und er hängt von keinem der spekulativeren Teile des Plans ab. Ein Web mit einer dominierenden kostenlosen CA und wenig sonst ist ein Web mit einem Single Point of Failure, ganz gleich, wie gut diese CA betrieben wird.

Dimension	Klassische kostenlose automatisierte CA (Let's Encrypt)	Geplante öffentliche CA von Cloudflare
Strategie für den Vertrauensanker	ISRG Root X1 / X2 (eigene Roots, ab 2015 aufgebaut)	Erworbene GlobalSign-Root (vertrauenswürdig seit 2012) + neue Root
Ausstellungsprotokoll	Standard-ACME (RFC 8555)	ACME mit verpflichtender ARI-Durchsetzung (RFC 9773)
Widerrufsmodell	CRL / OCSP + Notfall-Massenaustausch bei Abonnenten	Koordiniertes Vorziehen der Erneuerung über ARI-Endpunkte
Post-Quanten-Pfad	Hybride X.509-Signaturen in Prüfung	Native Merkle Tree Certificates (MTCs) neben klassischem X.509
Größenordnung und Anfangslast	~10 Mio. Zertifikate pro Tag für über 500 Mio. Websites	Customer-Zero-Validierung über mehr als 20 % des weltweiten Webverkehrs

Eine Root kaufen statt auf eine warten #

Die praktischste Entscheidung der Ankündigung betrifft die Root. Cloudflare sagt, es habe eine verbindliche Vereinbarung unterzeichnet, eine etablierte, breit vertrauenswürdige Root von GlobalSign zu erwerben. Die Quelle nennt den Grund direkt: Eine brandneue Root ist jahrelang kaum nützlich. Die bestehende GlobalSign-Root hingegen gilt seit 2012 in Browsern, Betriebssystemen und Geräten als vertrauenswürdig.

Vertrauen in eine Root entsteht langsam, weil es in Geräten installiert ist, und Geräte werden langsam aktualisiert. Eine neue Root kann von jedem Programm akzeptiert sein und trotzdem auf einem älteren Telefon oder einem eingebetteten System nicht validieren. Eine Root zu erwerben, die seit 2012 im Feld ist, umgeht diese Wartezeit, zumindest so, wie die Quelle es darstellt.

Den Weg einer neuen Root gibt Cloudflare dennoch nicht ganz auf. Das Unternehmen will auch eine neue Root zur Aufnahme in die Root-Key-Programme einreichen, die es als ausgerichtet auf die Richtung des Ökosystems beschreibt, einschließlich Programmen, die beginnen, das Alter einer vertrauenswürdigen Root zu begrenzen. Dieses letzte Detail erinnert daran, dass Alter in beide Richtungen wirkt. Das Alter einer vertrauenswürdigen Root ist ein Vorteil für die Geräteabdeckung, und einige Programme bewegen sich auf Grenzen für das Alter vertrauenswürdiger Roots zu. Sowohl eine erworbene Root als auch eine neue Einreichung zu betreiben, wirkt wie eine Antwort auf diese Spannung, auch wenn die Quelle die Überlegung nicht in diesen Worten ausführt.

Ein ACME-first-Dienst mit Bedingungen #

Bei der Einführung werden viele CA-Ankündigungen vage. Cloudflare ist konkret. Seine öffentliche CA soll ACME-first sein, also das Protokoll Automated Certificate Management Environment sprechen, das bestehende Automatisierung bereits nutzt. Die Aussage lautet, dass jeder, der schon auf eine bestehende kostenlose CA zeigt, durch Ändern einer Verzeichnis-URL zur CA von Cloudflare wechseln kann, ohne neue Werkzeuge und ohne Umbau der Architektur. Das ist ein Plan, kein erprobter Migrationspfad, und so sollte man es lesen. Eine Konfigurationsänderung in einer Zeile ist aber das richtige Ziel, denn Migrationskosten halten Menschen bei einer Voreinstellung.

Der Haken ist eine Anforderung, die die meisten ACME-Nutzer bisher nicht erfüllen mussten. Cloudflare will nur an Clients ausstellen, die ACME Renewal Information, kurz ARI, unterstützen, standardisiert in RFC 9773. Abonnenten müssen eine Automatisierung betreiben, die den Erneuerungsendpunkt von Cloudflare abfragt, nach den von Cloudflare veröffentlichten Erneuerungsfenstern handelt und das Zertifikat benennt, das sie ersetzt.

Das ist eine klare Haltung, und ich halte sie für richtig. Sie wirft aber auch eine berechtigte Frage zur Verbreitung auf: Eine CA, die nur ARI-fähige Clients bedient, ist enger als eine, die jeden mit einer ACME-Bibliothek bedient. Die Quelle sagt nicht, wie viele Clients das heute ausschließt, also werde ich nicht raten. Was sie sagt, ist, warum Cloudflare diese Einschränkung will.

Widerruf, ohne Websites lahmzulegen #

Cloudflare gibt an, in den vergangenen 16 Jahren einiges beobachtet zu haben, und eine Beobachtung treibt diesen Entwurf. Es hat Zertifizierungsstellen gesehen, die zwischen rechtzeitigem Widerruf und dem Erhalt der Websites ihrer Abonnenten gefangen waren.

Diese Spannung ist für jede CA real. Ein Zertifikat schnell zu widerrufen, schützt die Öffentlichkeit, kann aber jede Website lahmlegen, die von diesem Zertifikat abhängt, wenn der Abonnent es nicht schnell genug ersetzen kann. Eine CA in dieser Klemme widerruft entweder zu spät oder legt Kunden lahm.

ARI ist Cloudflares Antwort. Müssen Zertifikate ausgemustert werden, kann Cloudflare nach eigener Aussage die Erneuerungsfenster der betroffenen Zertifikate vorziehen. Weil Abonnenten verpflichtet sind, den Erneuerungsendpunkt abzufragen und nach den veröffentlichten Fenstern zu handeln, kann die CA sie zum Austausch lenken, bevor ein harter Widerruf eintritt. Dieser Mechanismus wird als Fähigkeit beschrieben, die Cloudflare haben will, nicht als eine, die es als CA nachgewiesen hat. Die Logik ist dennoch schlüssig: Die Abfragepflicht existiert, damit dieser Hebel funktioniert.

Dasselbe Denken zeigt sich in einem breiteren Entwurfsziel. Cloudflare will eine Zertifizierungsstelle aufbauen, deren Zuverlässigkeit nicht nur davon abhängt, Fehler zu vermeiden, sondern, wie bei den übrigen Produkten von Cloudflare, klein zu scheitern und die Auswirkungen jedes einzelnen Problems zu begrenzen. Fehler zu vermeiden, ist für eine CA notwendig, und keine CA kann das vollkommen versprechen. So zu entwerfen, dass ein Fehler eingedämmt bleibt, ist die ehrlichere Ingenieurshaltung.

Transparenz über das Audit hinaus #

Öffentliche CAs werden normalerweise nach Audits beurteilt. Die Quelle ist deutlich, was deren Grenzen angeht: Audits sind Momentaufnahmen und sagen einem, dass eine CA bestanden hat. Sie sagen nicht, was die CA danach an einem beliebigen Dienstag tut.

Cloudflares Antwort ist die Zusage, reproduzierbare Builds der Software zu veröffentlichen, die Zertifikate signiert. Das ist als Verpflichtung formuliert, nicht als fertige Leistung. Reproduzierbare Builds lassen Außenstehende prüfen, ob die Binärdatei im Signierpfad dem veröffentlichten Quellcode entspricht, und das ist eine fortlaufende Eigenschaft, wie es ein Auditbericht nicht ist. Ob das ausreicht, wird davon abhängen, was Cloudflare tatsächlich veröffentlicht und ob andere es prüfen.

Die zweite Hälfte der Ankündigung: Merkle Tree Certificates #

Beim Post-Quanten-Teil blickt die Ankündigung am weitesten voraus. Cloudflare kündigt an, eine der ersten CAs sein zu wollen, die Post-Quanten-Zertifikate ausliefert, und plant, seine ersten Merkle Tree Certificates im ersten Quartal 2027 auszustellen. An anderer Stelle sagt die Quelle, die ersten MTCs würden Anfang 2027 erwartet. Beides sind Pläne.

Die Quelle beschreibt MTCs als einen neuen und weit kompakteren Weg, öffentlich vertrauenswürdige Zertifikate auszuliefern. Diese Formulierung ist eine Beschreibung, und die Quelle liefert in den Passagen, auf die ich mich stütze, keine Messwerte, daher kann ich nicht sagen, wie viel kompakter. Cloudflare sagt, es setze sich bei der IETF für den standardbasierten Vorschlag für MTCs ein. Es berichtet außerdem, dass Chrome MTCs Anfang dieses Jahres als bevorzugten Weg für die Post-Quanten-Authentifizierung benannt hat. Das ist ein belegtes Ereignis, und es zählt, denn die erklärte Präferenz eines Browserherstellers macht aus einem Vorschlag etwas, worauf eine CA planen kann.

Cloudflare erwartet keinen plötzlichen Übergang. Es rechnet damit, dass ein Großteil des Internets noch viele Jahre auf klassische Zertifikate und die bestehende WebPKI setzt. In diesem Zeitraum erwartet es, dass MTCs einen stetig wachsenden Anteil der Ausstellung übernehmen. Das sind Erwartungen, und die Quelle kennzeichnet sie als solche.

Eine CA, ein Lebenszyklus #

Die Architekturentscheidung, die daraus folgt, finde ich am überzeugendsten. Die neue CA ist darauf ausgelegt, klassische Zertifikate und Merkle Tree Certificates unter einer CA zu tragen, mit einem Lebenszyklus und einem Satz von Garantien. Kunden können dann in ihrem Tempo umsteigen und dem Web helfen, den Übergang ohne harten Stichtag zu schaffen.

Die Alternative wären zwei parallele CAs, zwei Verfahrenswerke und irgendwann eine erzwungene Migration. Ein harter Stichtag ist die riskanteste Art, ein Zertifikatsökosystem zu verändern, und das erklärte Ziel der Quelle ist es, ihn zu vermeiden. Die Formulierung ist vorsichtig, und das zu Recht: Es handelt sich um eine Entwurfsabsicht für eine CA, die noch nicht ausstellt.

Es passt auch zum Anreizbild. Cloudflare erwartet, dass die Zahl der Zertifikate, auf die es jährlich angewiesen ist, weiter wächst, weil maximale Gültigkeitsdauern sinken, agentische Aktivität zunimmt und Post-Quanten-Zertifikate in den Mainstream kommen. Mehr Zertifikate, häufiger ausgestellt, sprechen für Automatisierung und für eine CA, die Erneuerung als vorrangige Operation behandelt. Ein System, das um ARI und einen einzigen Lebenszyklus gebaut ist, ist eine vernünftige Antwort auf diese Erwartung, auch wenn die Erwartung selbst eine Prognose und keine Messung ist.

Customer Zero #

Wie testet man eine CA, bevor sich die Öffentlichkeit auf sie verlässt? Cloudflares Antwort lautet, sein eigener erster Kunde zu sein. Es wird Customer Zero für die neue CA und ihre Zertifikate, WebPKI wie MTC. Erklärter Zweck ist sicherzustellen, dass alle Aspekte der neuen Systeme und Prozesse Cloudflares hohe interne Standards erfüllen und dass die Infrastruktur der CA im Maßstab von Cloudflare beansprucht wird.

Angesichts der früheren Zahlen ist das eine anspruchsvolle interne Last: Millionen von Zertifikaten pro Jahr, in einem Unternehmen, das vor mehr als 20 Prozent des weltweiten Anfrageverkehrs steht. Ob die ersten Betriebsjahre reibungslos verlaufen, können die Aussagen nicht verraten. Sie zeigen aber eine vernünftige Reihenfolge. Das Unternehmen beginnt als intensiver Nutzer dessen, was es baut, mit einer Geschichte der Bereitstellung über mehrere CAs, mit Ausweichpfaden und 16 Partner-CAs im Rücken.

Man sollte klar sagen, was fehlt. Nichts in der Quelle berichtet über Ausstellungsvolumen, Fehlerraten, Validierungslatenz oder eine Vorfallhistorie für Cloudflares eigene CA, weil es eine solche Historie noch nicht gibt. Die Ankündigung ist eine Absichtserklärung, gestützt auf Bewerbungen, eine Erwerbsvereinbarung und einen Entwurf. Eine Erfolgsbilanz ist sie nicht.

Worauf zu achten ist #

Drei Dinge werden entscheiden, ob dies eine bedeutende Ergänzung der WebPKI oder bloß eine interessante Ankündigung ist.

Das erste sind die Root-Programme. Cloudflare hat sich bei Chrome, Apple, Microsoft und Mozilla beworben, und die Prozesse sind öffentlich. Sie zu verfolgen, ist der direkteste Weg zu sehen, wie weit der Plan gekommen ist, und das Ergebnis lässt sich aus keiner der Aussagen vorhersagen.

Das zweite ist die ARI-Anforderung. Eine CA, die auf Unterstützung von RFC 9773 besteht, wettet darauf, dass sich Erneuerungsautomatisierung in ihrer Abonnentenbasis durchsetzen lässt. Geht die Wette auf, kann Cloudflare Erneuerungsfenster vorziehen, wenn Zertifikate ausgemustert werden müssen, und das ist die erklärte Antwort auf das Widerrufsdilemma, das es beobachtet hat. Geht sie nicht auf, wird die Einführung langsamer verlaufen, als es die Geschichte von der Migration in einer Zeile nahelegt.

Das dritte ist das erste Quartal 2027. Dann plant Cloudflare seine ersten Merkle Tree Certificates. Offen ist, wie schnell der erwartete stetig wachsende Anteil tatsächlich wächst, angesichts der eigenen Einschätzung, dass ein Großteil des Internets noch viele Jahre bei klassischen Zertifikaten bleiben wird. Das Unternehmen hat gesagt, der Übergang solle keinen harten Stichtag brauchen. Das erste Quartal 2027 wird die erste Gelegenheit sein zu sehen, ob eine CA, die beide Zertifikatstypen trägt, das einlösen kann.

Was das für einzelne Branchen bedeutet #

Das Auftreten einer automatisierten öffentlichen Zertifizierungsstelle mit hohem Volumen aus den Reihen eines Edge-Infrastrukturanbieters verändert das operative Risiko und die PKI-Planung in mehreren technischen Bereichen.

Cloud-Infrastruktur und Edge-Netzwerke #

Eine öffentliche CA im Edge-Maßstab zu betreiben, verringert die externe Abhängigkeit von Prüf-APIs und CRLs Dritter. Indem Infrastrukturanbieter die Edge-Terminierung über Reverse Proxys mit automatisierten ACME-ARI-Erneuerungen koppeln, können sie ihre Kunden gegen Ausfälle vorgelagerter Zertifizierungsstellen abschirmen.

Unternehmens-PKI und DevOps-Teams #

Organisationen, die für öffentliche Endpunkte auf Let's Encrypt setzen, erhalten eine glaubwürdige, automatisierte Alternative. Die verpflichtende Durchsetzung von RFC 9773 (ARI) bedeutet jedoch, dass Teams ihre ACME-Clients (Certbot, Lego, Caddy, Traefik) prüfen müssen, um sicherzustellen, dass die ARI-Unterstützung aktiv ist, bevor sie den Verzeichnisendpunkt wechseln.

Browserhersteller und Root-Governance #

Die Root-Programme (Chrome, Mozilla, Apple, Microsoft) stehen vor einem wachsenden Ökosystem automatisierter CAs mit hohem Volumen. Der zweigleisige Root-Ansatz (eine ältere Root von 2012 erwerben und zugleich eine moderne Root einreichen) bewegt sich zwischen Browser-Richtlinien, die die Laufzeit von Root-Zertifikaten zunehmend beschränken, und der Rückwärtskompatibilität für ältere Geräte.

Fazit #

Cloudflares Schritt, eine öffentliche Zertifizierungsstelle zu werden, setzt an einer echten strukturellen Schwachstelle der modernen WebPKI an: der extremen Konzentration bei der kostenlosen, automatisierten Ausstellung von Zertifikaten. Durch die Verbindung einer etablierten GlobalSign-Root, strikter ARI-Erneuerungsautomatisierung und einer Brücke zu Post-Quanten-Merkle-Tree-Certificates zielt der Entwurf auf operative Resilienz statt auf bloße Zertifikatsbereitstellung. Über den Erfolg entscheiden die Genehmigungen der Root-Programme und die Frage, wie schnell Client-Werkzeuge ARI-Standards vor dem Start 2027 übernehmen.

Häufig gestellte Fragen #

Kann ich meinen ACME-Client schon heute auf Cloudflares CA umstellen?

Noch nicht. Cloudflare hat seine Absicht angekündigt, die Vereinbarung zum Erwerb der Root unterzeichnet und Bewerbungen bei den großen Root-Programmen eingereicht. Die öffentliche Ausstellung soll nach den Genehmigungen der Root-Programme anlaufen.

Was ist ACME Renewal Information (ARI) und warum ist es wichtig?

ARI (RFC 9773) ist eine Erweiterung des ACME-Protokolls, mit der Zertifizierungsstellen Abonnenten mitteilen können, wann ein Zertifikat erneuert werden sollte. So können CAs vorgezogene Erneuerungen vor geplanten Widerrufen geordnet koordinieren und Ausfälle von Websites verhindern.

Worin unterscheiden sich Merkle Tree Certificates (MTCs) von üblichen X.509-Zertifikaten?

MTCs ersetzen herkömmliche einzelne kryptografische Signaturen durch Merkle-Inklusionsnachweise, die in einem öffentlich überprüfbaren Log verankert sind. Das verringert die Zertifikatsgröße und den Übertragungsaufwand deutlich und macht sie zu einem bevorzugten Kandidaten für die Post-Quanten-Authentifizierung bei TLS.

Quellen #

Cloudflare, (2026). Eine Zertifizierungsstelle für das gesamte Internet aufbauen ⧉. Cloudflare-Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates für TLS ⧉. IETF.
Chrome Root Program, (2026). Richtlinie und Überlegungen zur Post-Quanten-Authentifizierung ⧉. Chromium Projects.

Zuletzt überprüft 2026-09-20.

Zuletzt überprüft 2026-10-27.

Diesen Artikel republizieren

Cloudflare will selbst CA werden, weil Gratis-CAs zu konzentriert sind — Sebastien Rousseau

Cloudflare will öffentliche Zertifizierungsstelle werden: Bewerbung bei den Root-Programmen, Kauf einer GlobalSign-Root, ARI als Pflicht und Merkle Tree Certificates.

Dieser Artikel ist lizenziert unter Creative Commons Attribution 4.0 International. Eine Republikation erfordert Attribution zur kanonischen URL.

Cloudflare will selbst CA werden, weil Gratis-CAs zu konzentriert sind — Sebastien Rousseau

Cloudflare will öffentliche Zertifizierungsstelle werden: Bewerbung bei den Root-Programmen, Kauf einer GlobalSign-Root, ARI als Pflicht und Merkle Tree Certificates.

Originally published at https://sebastienrousseau.com/de/2026-09-20-cloudflare-will-selbst-ca-werden-weil/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER