Cloudflare chce wydawać certyfikaty wobec koncentracji darmowych CA

Cloudflare od lat polega na 16 partnerskich publicznych CA i sam nigdy nie wydał publicznie zaufanego certyfikatu. Teraz zamierza stać się jednym z nich, a najciekawszy jest projekt: klasyczne certyfikaty i Merkle Tree Certificates w jednym CA, z ograniczaniem skutków awarii wbudowanym od początku.

Odbiorca certyfikatów staje się ich wystawcą #

Większość firm infrastrukturalnych pozostaje po jednej stronie relacji certyfikacyjnej. Zamawiają certyfikaty, instalują je i narzekają, gdy CA ma incydent. Cloudflare stał zdecydowanie po stronie odbiorcy. Jak sam przyznaje, nigdy nie wydał ani jednego publicznie zaufanego certyfikatu.

To ma się zmienić, a przynajmniej Cloudflare twierdzi, że taki ma zamiar. Firma ogłasza zamiar stania się publicznym urzędem certyfikacji. Ogłoszenie starannie opisuje, jak sprawy wyglądają dziś, i ten artykuł też powinien. Cloudflare jeszcze nie wydaje certyfikatów. Wszystko, co dotyczy działania usługi, od interfejsu ACME przez zasady odnawiania po obsługę Merkle Tree Certificates, jest deklaracją planu, a nie opisem działającego systemu.

Wiarygodności ogłoszeniu nie nadaje ambicja, lecz widoczne już przygotowania. Cloudflare złożył wnioski o włączenie do programów certyfikatów głównych Chrome, Apple, Microsoft i Mozilli. Firma mówi, że przechodzi proces składania wniosków i zatwierdzania w każdym z kluczowych programów kluczy głównych sieci, i zaznacza, że procesy te toczą się jawnie. Każdy może w zasadzie śledzić, czy wniosek się powiedzie.

Dlaczego to Cloudflare może postawić to pytanie #

Argumentacja Cloudflare za budową CA zaczyna się od jego pozycji jako klienta. Stoi przed ponad 20 procentami globalnego ruchu żądań w internecie. Kończy połączenia TLS dla milionów domen i polega na milionach certyfikatów rocznie. Dostarcza swoim klientom pakiety certyfikatów w ramach Universal SSL, a także korzysta z certyfikatów wielu różnych CA, aby obsługiwać własne systemy i działania wewnętrzne.

Aby utrzymać usługi klientów, Cloudflare pozyskuje te certyfikaty przez wiele CA, ze ścieżkami podstawowymi i zapasowymi, tak by usługi klientów działały mimo awarii CA i unieważnień. Sieć partnerskich publicznych CA, na której polega od wielu lat, liczy 16 urzędów.

Mechanizm zapasowy zasługuje na bliższe spojrzenie, bo pokazuje, jak Cloudflare myśli o awariach. Każdy certyfikat Universal SSL ma już certyfikat zapasowy, z osobnym kluczem i wydany przez inny urząd. Jeśli podstawowy zostanie kiedyś unieważniony lub naruszony, zapasowy jest gotowy do automatycznego wdrożenia. To zabezpieczenie przed błędem pojedynczego CA, zbudowane od strony klienta.

To również zabezpieczenie z sufitem. Można dywersyfikować tylko między istniejącymi CA, a źródło przekonuje, że podaż urzędów zdolnych do takiej skali jest mniejsza, niż się wydaje.

Problem koncentracji #

Liczby stojące za tym argumentem robią wrażenie. Let's Encrypt wydaje rzędu dziesięciu milionów certyfikatów dziennie. Obsługuje ponad 500 milionów witryn i w 2025 roku przekroczył cztery miliardy aktywnych certyfikatów. To dane jednego darmowego CA i opisują sieć, której szyfrowanie mocno opiera się na jednej organizacji.

Źródło wyciąga oczywisty wniosek, z właściwym zastrzeżeniem: gdyby dominujący darmowy urząd certyfikacji miał zły tydzień, duża część sieci nie miałaby porównywalnej darmowej, zautomatyzowanej alternatywy gotowej przejąć obciążenie. To stwierdzenie o hipotetycznej sytuacji i Cloudflare przedstawia je właśnie tak. Nie twierdzi, że taki tydzień się zdarzył ani że nadchodzi.

Mimo to logikę łatwo śledzić. Darmowy, zautomatyzowany CA jest opcją zwiększającą odporność tylko wtedy, gdy istnieje przed kryzysem. Cloudflare przekonuje, że może dostarczyć drugi taki urząd na dużą skalę. Uważam, że to najmocniejszy handlowy i techniczny argument w ogłoszeniu, i nie zależy on od żadnej z bardziej spekulatywnych części planu. Sieć, która ma jeden dominujący darmowy CA i niewiele poza nim, to sieć z pojedynczym punktem awarii, niezależnie od jakości działania tego CA.

Wymiar	Tradycyjny darmowy zautomatyzowany CA (Let's Encrypt)	Proponowany publiczny CA Cloudflare
Strategia kotwicy zaufania	ISRG Root X1 / X2 (własne certyfikaty główne od 2015 roku)	Nabyty certyfikat główny GlobalSign (zaufany od 2012 roku) + nowy certyfikat główny
Protokół wydawania	Standardowe ACME (RFC 8555)	ACME z obowiązkowym egzekwowaniem ARI (RFC 9773)
Model unieważniania	CRL / OCSP + awaryjna masowa wymiana u subskrybentów	Skoordynowane przyspieszanie odnowień przez punkty końcowe ARI
Ścieżka postkwantowa	Hybrydowe podpisy X.509 w fazie oceny	Natywne Merkle Tree Certificates (MTC) współistniejące z klasycznym X.509
Skala i początkowe obciążenie	~10 mln certyfikatów dziennie dla ponad 500 mln witryn	Weryfikacja na Cloudflare jako kliencie zero, ponad 20% globalnego ruchu w sieci

Kupić certyfikat główny zamiast na niego czekać #

Najbardziej praktyczna decyzja w ogłoszeniu dotyczy certyfikatu głównego. Cloudflare mówi, że podpisał wiążącą umowę nabycia od GlobalSign ugruntowanego, szeroko zaufanego certyfikatu głównego. Źródło podaje powód wprost: zupełnie nowy certyfikat główny przez lata nie jest szeroko użyteczny. Istniejący certyfikat główny GlobalSign jest natomiast zaufany w przeglądarkach, systemach operacyjnych i urządzeniach od 2012 roku.

Zaufanie do certyfikatu głównego narasta powoli, bo jest on instalowany w urządzeniach, a urządzenia aktualizują się powoli. Nowy certyfikat główny może zostać przyjęty przez każdy program, a mimo to nie przejść walidacji na starszym telefonie czy w systemie wbudowanym. Nabycie certyfikatu głównego, który działa w terenie od 2012 roku, omija to czekanie, przynajmniej tak, jak przedstawia to źródło.

Cloudflare nie rezygnuje całkowicie z drogi nowego certyfikatu głównego. Zgłosi również nowy certyfikat główny do programów kluczy głównych i opisuje go jako zbudowany z myślą o kierunku, w którym zmierza ekosystem, w tym o programach, które zaczynają ograniczać dopuszczalny wiek zaufanego certyfikatu głównego. Ten ostatni szczegół przypomina, że wiek działa w obie strony. Wiek zaufanego certyfikatu głównego jest atutem dla pokrycia urządzeń, a niektóre programy zmierzają ku limitom wieku zaufanych certyfikatów głównych. Utrzymywanie zarówno nabytego certyfikatu głównego, jak i nowego zgłoszenia wygląda na odpowiedź na to napięcie, choć źródło nie formułuje rozumowania w tych kategoriach.

Usługa przede wszystkim ACME, z warunkami #

To przy wdrożeniu wiele ogłoszeń CA staje się mgliste. Cloudflare jest konkretny. Jego publiczny CA będzie przede wszystkim oparty na ACME, czyli będzie obsługiwał protokół Automated Certificate Management Environment, którego już używa istniejąca automatyzacja. Twierdzenie brzmi tak, że każdy, kto korzysta już z istniejącego darmowego CA, może przejść do CA Cloudflare, zmieniając adres URL katalogu, bez nowych narzędzi i bez przebudowy architektury. To plan, a nie przetestowana ścieżka migracji, i tak należy go czytać. Ale zmiana konfiguracji w jednej linii to właściwy cel, bo to koszt migracji trzyma ludzi przy domyślnym wyborze.

Haczyk to wymóg, którego większość użytkowników ACME nie musiała dotąd spełniać. Cloudflare będzie wydawał certyfikaty tylko klientom obsługującym ACME Renewal Information, czyli ARI, ustandaryzowane w RFC 9773. Subskrybenci muszą utrzymywać automatyzację, która odpytuje punkt końcowy odnowień Cloudflare, reaguje na publikowane przez Cloudflare okna odnowień i wskazuje certyfikat, który zastępuje.

To stanowcze stanowisko i myślę, że słuszne. Rodzi ono też uzasadnione pytanie o wdrożenie: CA obsługujący tylko klientów zgodnych z ARI ma węższy zasięg niż taki, który obsługuje każdego z biblioteką ACME. Źródło nie mówi, ilu klientów to dziś wyklucza, więc nie będę zgadywał. Mówi natomiast, dlaczego Cloudflare chce tego ograniczenia.

Unieważnianie bez psucia witryn #

Cloudflare twierdzi, że przez ostatnie 16 lat poczynił pewne obserwacje, a jedna z nich kształtuje ten projekt. Widział urzędy certyfikacji rozdarte między szybkim unieważnieniem a utrzymaniem witryn subskrybentów w działaniu.

To napięcie jest realne dla każdego CA. Szybkie unieważnienie certyfikatu chroni ogół, ale może wyłączyć każdą witrynę od niego zależną, jeśli subskrybent nie zdąży go wymienić. CA złapany pośrodku albo unieważnia za późno, albo psuje działanie klientom.

ARI jest odpowiedzią Cloudflare. Gdy certyfikaty trzeba wycofać, Cloudflare mówi, że może przyspieszyć okna odnowień dla tych certyfikatów. Ponieważ subskrybenci muszą odpytywać punkt końcowy odnowień i reagować na publikowane okna, CA może skierować ich do wymiany, zanim nastąpi twarde unieważnienie. Mechanizm ten opisano jako zdolność, którą Cloudflare zamierza mieć, a nie taką, którą wykazał jako CA. Mimo to logika jest spójna: wymóg odpytywania istnieje po to, by ta dźwignia działała.

To samo myślenie widać w szerszym celu projektu. Cloudflare zamierza zbudować urząd certyfikacji, którego niezawodność zależy nie tylko od unikania błędów, ale, jak w przypadku pozostałych produktów Cloudflare, od awarii o małej skali i ograniczania skutków każdego pojedynczego problemu. Unikanie błędów jest dla CA konieczne i żaden CA nie może tego obiecać w pełni. Projektowanie tak, by błąd pozostał ograniczony, to uczciwsza postawa inżynierska.

Przejrzystość wykraczająca poza audyt #

Publiczne CA ocenia się zwykle na podstawie audytów. Źródło mówi otwarcie o ich ograniczeniach: audyty są migawką i mówią, że CA je przeszedł. Nie mówią, co CA robi w dowolny wtorek potem.

Odpowiedzią Cloudflare jest zapowiedź publikowania odtwarzalnych kompilacji oprogramowania, które podpisuje certyfikaty. Przedstawiono to jako zobowiązanie, a nie gotowy produkt. Odtwarzalne kompilacje pozwalają osobom z zewnątrz sprawdzić, że plik binarny działający na ścieżce podpisywania odpowiada opublikowanemu kodowi źródłowemu, co jest właściwością ciągłą w sposób, w jaki raport z audytu nie jest. Czy to wystarczy, zależy od tego, co Cloudflare faktycznie opublikuje, i od tego, czy inni to sprawdzą.

Druga połowa ogłoszenia: Merkle Tree Certificates #

Część postkwantowa to miejsce, w którym ogłoszenie patrzy najdalej w przyszłość. Cloudflare zapowiada, że chce być jednym z pierwszych CA oferujących certyfikaty postkwantowe, i planuje wydać pierwsze Merkle Tree Certificates w pierwszym kwartale 2027 roku. Inny fragment źródła mówi, że pierwsze MTC są oczekiwane na początku 2027 roku. Jedno i drugie to plany.

Źródło opisuje MTC jako nowy i znacznie bardziej zwarty sposób dostarczania publicznie zaufanych certyfikatów. To sformułowanie jest opisem, a źródło nie podaje pomiarów we fragmentach, z których korzystam, więc nie mogę powiedzieć, o ile bardziej zwarty. Cloudflare mówi, że promował w IETF opartą na standardach propozycję MTC. Informuje też, że Chrome na początku tego roku wskazał MTC jako preferowaną ścieżkę uwierzytelniania postkwantowego. To wydarzenie potwierdzone i ma znaczenie, bo deklarowana preferencja producenta przeglądarki zamienia propozycję w coś, wokół czego CA może planować.

Cloudflare nie spodziewa się nagłego przejścia. Oczekuje, że duża część internetu będzie przez wiele kolejnych lat polegać na klasycznych certyfikatach i istniejącym WebPKI. W tym czasie spodziewa się, że MTC będą zajmować stale rosnący udział w wydawaniu. To oczekiwania i źródło tak je oznacza.

Jeden CA, jeden cykl życia #

Wynikający z tego wybór architektoniczny uważam za najbardziej przekonujący. Nowy CA ma obsługiwać klasyczne certyfikaty i Merkle Tree Certificates w jednym CA, z jednym cyklem życia i jednym zestawem gwarancji. Klienci mogą wtedy przechodzić w odpowiadającym im tempie i pomóc sieci dokonać przejścia bez twardego przełączenia.

Alternatywą są dwa równoległe CA, dwa zestawy procedur i w pewnym momencie wymuszona migracja. Twarde przełączenie to najbardziej ryzykowny sposób zmiany ekosystemu certyfikatów, a deklarowanym celem źródła jest jego uniknięcie. Sformułowanie jest ostrożne i słusznie: to zamiar projektowy dla CA, który jeszcze nie wydaje certyfikatów.

Pasuje to też do obrazu bodźców. Cloudflare mówi, że oczekuje dalszego wzrostu liczby certyfikatów, na których polega rocznie, w miarę skracania maksymalnych okresów ważności, wzrostu aktywności agentowej i upowszechniania się certyfikatów postkwantowych. Więcej certyfikatów, wydawanych częściej, przemawia za automatyzacją i za CA, który traktuje odnawianie jako operację pierwszej kategorii. System zbudowany wokół ARI i jednego cyklu życia to rozsądna odpowiedź na to oczekiwanie, choć samo oczekiwanie jest prognozą, a nie pomiarem.

Klient zero #

Jak przetestować CA, zanim zacznie na nim polegać ogół? Odpowiedzią Cloudflare jest bycie własnym pierwszym klientem. Będzie klientem zero dla nowego CA i jego certyfikatów, zarówno WebPKI, jak i MTC. Deklarowany cel to upewnienie się, że wszystkie elementy nowych systemów i procesów spełniają wysokie wewnętrzne standardy Cloudflare oraz że infrastruktura CA jest sprawdzana w skali Cloudflare.

Biorąc pod uwagę wcześniejsze liczby, to wymagające obciążenie wewnętrzne: miliony certyfikatów rocznie w firmie, która stoi przed ponad 20 procentami globalnego ruchu żądań. Czy pierwsze lata działania przebiegną gładko, tego deklaracje nam nie powiedzą. Pokazują natomiast rozsądną kolejność działań. Firma zaczyna jako intensywny użytkownik tego, co buduje, z historią pozyskiwania certyfikatów przez wiele CA, ścieżkami zapasowymi i 16 partnerskimi CA za sobą.

Warto jasno powiedzieć, czego brakuje. Nic w źródle nie podaje wolumenów wydawania, wskaźników błędów, opóźnień walidacji ani historii incydentów własnego CA Cloudflare, bo takiej historii jeszcze nie ma. Ogłoszenie to deklaracja zamiaru poparta wnioskami, umową nabycia i projektem. Nie jest to dorobek.

Na co zwracać uwagę #

O tym, czy będzie to znaczący dodatek do WebPKI, czy tylko ciekawe ogłoszenie, zdecydują trzy rzeczy.

Pierwsza to programy certyfikatów głównych. Cloudflare złożył wnioski do Chrome, Apple, Microsoft i Mozilli, a procesy toczą się jawnie. Śledzenie ich to najbardziej bezpośredni sposób, by zobaczyć, jak daleko zaszedł plan, a wyniku nie pozwala mi przewidzieć żadna z deklaracji.

Druga to wymóg ARI. CA, który nalega na obsługę RFC 9773, stawia na to, że automatyzację odnawiania da się upowszechnić w całej bazie subskrybentów. Jeśli zakład się opłaci, Cloudflare zyska możliwość przyspieszania okien odnowień, gdy certyfikaty trzeba wycofać, co jest deklarowaną odpowiedzią na dylemat unieważniania, który obserwował. Jeśli nie, wdrożenie będzie wolniejsze, niż sugeruje opowieść o migracji w jednej linii.

Trzecia to pierwszy kwartał 2027 roku. Wtedy Cloudflare planuje swoje pierwsze Merkle Tree Certificates. Otwarte pytanie brzmi, jak szybko faktycznie będzie rósł stale rosnący udział, którego oczekuje, skoro sam uważa, że duża część internetu pozostanie przy klasycznych certyfikatach przez wiele kolejnych lat. Firma powiedziała, że przejście nie powinno wymagać twardego przełączenia. Pierwszy kwartał 2027 roku będzie pierwszą okazją, by sprawdzić, czy jeden CA obsługujący oba typy certyfikatów może to urzeczywistnić.

Co to oznacza dla poszczególnych sektorów #

Pojawienie się wysokowolumenowego, zautomatyzowanego publicznego urzędu certyfikacji u dostawcy infrastruktury brzegowej zmienia ryzyko operacyjne i planowanie PKI w kilku dziedzinach technicznych.

Infrastruktura chmurowa i sieci brzegowe #

Prowadzenie publicznego CA w skali brzegowej zmniejsza zewnętrzną zależność od interfejsów API weryfikacji i list CRL podmiotów trzecich. Łącząc kończenie połączeń na brzegowych odwrotnych proxy z automatycznymi odnowieniami ACME ARI, dostawcy infrastruktury mogą chronić klientów przed awariami urzędów certyfikacji wyżej w łańcuchu.

PKI w przedsiębiorstwach i zespoły DevOps #

Organizacje polegające na Let's Encrypt w publicznych punktach końcowych zyskują wiarygodną, zautomatyzowaną alternatywę. Obowiązkowe egzekwowanie RFC 9773 (ARI) oznacza jednak, że zespoły muszą sprawdzić swoich klientów ACME (Certbot, Lego, Caddy, Traefik), aby upewnić się, że obsługa ARI jest aktywna, zanim zmienią punkt końcowy katalogu.

Producenci przeglądarek i nadzór nad certyfikatami głównymi #

Programy certyfikatów głównych (Chrome, Mozilla, Apple, Microsoft) stoją wobec rosnącego ekosystemu wysokowolumenowych, zautomatyzowanych CA. Dwutorowe podejście do certyfikatów głównych (nabycie starszego certyfikatu z 2012 roku przy jednoczesnym zgłoszeniu nowoczesnego) porusza się między politykami przeglądarek, które coraz mocniej ograniczają czas życia certyfikatów głównych, a potrzebą zgodności wstecznej dla starszych urządzeń.

Wnioski #

Krok Cloudflare w stronę publicznego urzędu certyfikacji odpowiada na rzeczywistą strukturalną słabość współczesnego WebPKI: skrajną koncentrację darmowego, zautomatyzowanego wydawania certyfikatów. Łącząc ugruntowany certyfikat główny GlobalSign, ścisłą automatyzację odnawiania z ARI i most ku postkwantowym Merkle Tree Certificates, projekt mierzy się z odpornością operacyjną, a nie tylko z dostarczaniem certyfikatów. O sukcesie zdecydują zatwierdzenia w programach certyfikatów głównych i tempo, w jakim narzędzia klienckie przyjmą standardy ARI przed wdrożeniem w 2027 roku.

Najczęściej zadawane pytania #

Czy mogę już dziś przełączyć klienta ACME na CA Cloudflare?

Jeszcze nie. Cloudflare ogłosił zamiar, podpisał umowę nabycia certyfikatu głównego i złożył wnioski do głównych programów certyfikatów głównych. Publiczne wydawanie ma ruszyć po zatwierdzeniu w tych programach.

Czym jest ACME Renewal Information (ARI) i dlaczego ma znaczenie?

ARI (RFC 9773) to rozszerzenie protokołu ACME, które pozwala urzędom certyfikacji informować subskrybentów, kiedy certyfikat powinien zostać odnowiony. Dzięki temu CA mogą płynnie koordynować wcześniejsze odnowienia przed planowanymi unieważnieniami i zapobiegać awariom witryn.

Czym Merkle Tree Certificates (MTC) różnią się od standardowych certyfikatów X.509?

MTC zastępują tradycyjne indywidualne podpisy kryptograficzne dowodami włączenia do drzewa Merkle'a, zakotwiczonymi w publicznie weryfikowalnym rejestrze. Znacznie zmniejsza to rozmiar certyfikatu i narzut transmisji, co czyni je preferowanym kandydatem do postkwantowego uwierzytelniania TLS.

Bibliografia #

Cloudflare, (2026). Budowa urzędu certyfikacji dla całego internetu ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates dla TLS ⧉. IETF.
Chrome Root Program, (2026). Zasady i uwagi dotyczące uwierzytelniania postkwantowego ⧉. Chromium Projects.

Ostatnia weryfikacja 2026-09-20.

Ostatnia weryfikacja 2026-10-27.

Opublikuj ponownie ten artykuł

Cloudflare chce wydawać certyfikaty wobec koncentracji darmowych CA — Sebastien Rousseau

Cloudflare chce zostać publicznym urzędem certyfikacji, złożył wnioski do programów głównych Chrome, Apple, Microsoft i Mozilli i kupuje root GlobalSign.

Ten artykuł jest objęty licencją Creative Commons Attribution 4.0 International. Ponowna publikacja wymaga przypisania do kanonicznego adresu URL.

Cloudflare chce wydawać certyfikaty wobec koncentracji darmowych CA — Sebastien Rousseau

Cloudflare chce zostać publicznym urzędem certyfikacji, złożył wnioski do programów głównych Chrome, Apple, Microsoft i Mozilli i kupuje root GlobalSign.

Originally published at https://sebastienrousseau.com/pl/2026-09-20-cloudflare-chce-wydawac-certyfikaty-wobec-koncentracji/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER