Cloudflare хоче стати УЦ через концентрацію безкоштовних центрів

TL;DR. Cloudflare оголосила про намір стати публічним центром сертифікації: подала заявки до кореневих програм і купує корінь GlobalSign, щоб зменшити концентрацію.

Ключові висновки

Споживач сертифікатів стає їхнім емітентом. Більшість інфраструктурних компаній залишаються з одного боку відносин щодо сертифікатів.
Чому Cloudflare має підстави ставити це питання. Аргументи Cloudflare на користь власного УЦ починаються з її становища клієнта.
Проблема концентрації. Цифри за цим аргументом вражають.
Купити корінь, а не чекати на нього. Найпрактичніше рішення в оголошенні стосується кореня.

Cloudflare роками покладалася на 16 партнерських публічних центрів сертифікації й жодного разу сама не випустила публічно довірений сертифікат. Тепер компанія має намір стати таким центром, і найцікавіше в задумі: класичні сертифікати та сертифікати на деревах Меркла в одному УЦ, з ізоляцією збоїв, закладеною від самого початку.

Споживач сертифікатів стає їхнім емітентом #

Більшість інфраструктурних компаній залишаються з одного боку відносин щодо сертифікатів. Вони запитують сертифікати, встановлюють їх і скаржаться, коли в УЦ стається інцидент. Cloudflare міцно стояла на боці споживача. За її власними словами, вона жодного разу сама не випустила жодного публічно довіреного сертифіката.

Це ось-ось зміниться, або принаймні Cloudflare заявляє такий намір. Компанія оголошує про намір стати публічним центром сертифікації. Оголошення обережно описує поточний стан справ, і ця стаття має бути такою ж. Cloudflare поки що не випускає сертифікатів. Усе, що стосується поведінки сервісу, від інтерфейсу ACME до правил поновлення та підтримки сертифікатів на деревах Меркла, є викладом плану, а не описом робочої системи.

Оголошенню надає ваги не амбіція, а вже помітна підготовча робота. Cloudflare подала заявки на включення до кореневих програм Chrome, Apple, Microsoft і Mozilla. Компанія повідомляє, що проходить процес подання й схвалення в кожній з основних кореневих програм вебу, і зазначає, що ці процеси відбуваються відкрито. У принципі будь-хто може стежити, чи буде заявку схвалено.

Чому Cloudflare має підстави ставити це питання #

Аргументи Cloudflare на користь власного УЦ починаються з її становища клієнта. Через неї проходить понад 20 відсотків світового інтернет-трафіку запитів. Вона завершує TLS для мільйонів доменів і покладається на мільйони сертифікатів на рік. Вона надає своїм клієнтам пакети сертифікатів через Universal SSL, а також отримує сертифікати від багатьох різних УЦ для роботи власних систем і внутрішніх операцій.

Щоб сервіси клієнтів залишалися доступними, Cloudflare отримує ці сертифікати через кілька УЦ, з основними й резервними шляхами, щоб сервіси клієнтів переживали збої УЦ і події відкликання. Мережа партнерських публічних УЦ, на яку вона покладалася багато років, налічує 16 центрів.

Резервний механізм заслуговує на пильніший погляд, бо показує, як Cloudflare думає про збої. Кожен сертифікат Universal SSL уже постачається з резервним сертифікатом, на окремому ключі й випущеним іншим центром. Якщо основний сертифікат буде відкликано або скомпрометовано, резервний готовий до автоматичного розгортання. Це страховка від збою будь-якого окремого УЦ, вибудувана з боку клієнта.

Така страховка має й стелю. Диверсифікуватися можна лише між наявними УЦ, а джерело стверджує, що спроможних центрів менше, ніж здається.

Проблема концентрації #

Цифри за цим аргументом вражають. Let's Encrypt випускає близько десяти мільйонів сертифікатів на день. Він обслуговує понад 500 мільйонів сайтів і у 2025 році перевищив чотири мільярди активних сертифікатів. Це показники одного безкоштовного УЦ, і вони описують веб, шифрування якого значною мірою спирається на одну організацію.

Джерело робить очевидний висновок із доречним застереженням: якби в домінантного безкоштовного центру сертифікації видався поганий тиждень, значна частина вебу не мала б порівнянної безкоштовної автоматизованої альтернативи, готової прийняти навантаження. Це твердження про гіпотетичний сценарій, і Cloudflare подає його саме так. Вона не стверджує, що такий тиждень уже був або що він наближається.

І все ж логіка зрозуміла. Безкоштовний автоматизований УЦ є варіантом стійкості, лише якщо він існує до надзвичайної ситуації. Cloudflare пропонує забезпечити другий такий центр у потрібному масштабі. Я сказав би, що це найсильніша комерційна й технічна причина в оголошенні, і вона не залежить від жодної з більш спекулятивних частин плану. Веб з одним домінантним безкоштовним УЦ і майже нічим іншим є вебом з єдиною точкою відмови, хоч якою високою була б якість роботи цього УЦ.

Параметр	Традиційний безкоштовний автоматизований УЦ (Let's Encrypt)	Запропонований публічний УЦ Cloudflare
Стратегія якоря довіри	ISRG Root X1 / X2 (власні корені, створені з 2015 року)	Придбаний корінь GlobalSign (довірений з 2012 року) + новий корінь
Протокол випуску	Стандартний ACME (RFC 8555)	ACME з обов'язковим застосуванням ARI (RFC 9773)
Модель відкликання	CRL / OCSP + екстрена масова заміна в передплатників	Узгоджене перенесення поновлення на раніше через кінцеві точки ARI
Постквантовий шлях	Гібридні підписи X.509 на стадії оцінювання	Нативні сертифікати на деревах Меркла (MTC) поряд із класичними X.509
Масштаб і початкове навантаження	~10 млн сертифікатів на день для 500+ млн сайтів	Перевірка в ролі «Клієнта Нуль» на 20%+ світового веб-трафіку

Купити корінь, а не чекати на нього #

Найпрактичніше рішення в оголошенні стосується кореня. Cloudflare повідомляє, що підписала остаточну угоду про придбання усталеного, широко довіреного кореня в GlobalSign. Джерело прямо називає причину: цілком новий корінь роками не має широкої користі. Наявному кореню GlobalSign, навпаки, з 2012 року довіряють браузери, операційні системи й пристрої.

Довіра до кореня формується повільно, бо корінь встановлюється в пристрої, а пристрої оновлюються повільно. Новий корінь може бути прийнятий усіма програмами й однаково не пройти перевірку на старому телефоні чи у вбудованій системі. Придбання кореня, що працює в реальних умовах з 2012 року, дає змогу оминути це очікування, принаймні в тому вигляді, як це подає джерело.

Cloudflare не відмовляється й від шляху нового кореня. Вона також подасть новий корінь на включення до кореневих програм і описує його як створений з розрахунком на те, куди рухається екосистема, зокрема на програми, які починають обмежувати допустимий вік довіреного кореня. Ця деталь корисно нагадує, що вік діє в обидва боки. Вік довіреного кореня є перевагою для охоплення пристроїв, а деякі програми рухаються до обмежень на вік довіреного кореня. Поєднання придбаного кореня й нової заявки схоже на відповідь на цю суперечність, хоча джерело не викладає міркування в таких термінах.

Сервіс із пріоритетом ACME та умовами #

Саме на темі впровадження багато оголошень УЦ стають розмитими. Cloudflare конкретна. Її публічний УЦ буде насамперед орієнтований на ACME, тобто говоритиме протоколом Automated Certificate Management Environment, який уже використовує наявна автоматизація. Стверджується, що будь-хто, хто вже налаштований на наявний безкоштовний УЦ, зможе перейти на УЦ Cloudflare, змінивши URL каталогу, без нових інструментів і без перебудови архітектури. Це план, а не перевірений шлях міграції, і читати його слід саме так. Але зміна одного рядка конфігурації є правильною метою, бо саме вартість міграції тримає людей на варіанті за замовчуванням.

Підступ у вимозі, з якою більшість користувачів ACME ще не стикалися. Cloudflare випускатиме сертифікати лише клієнтам із підтримкою ACME Renewal Information, або ARI, стандартизованої в RFC 9773. Передплатники мають підтримувати автоматизацію, яка опитує кінцеву точку поновлення Cloudflare, діє відповідно до вікон поновлення, які публікує Cloudflare, і вказує сертифікат, який замінює.

Це тверда позиція, і я вважаю її правильною. Вона також порушує слушне питання щодо впровадження: УЦ, який обслуговує лише клієнтів із підтримкою ARI, вужчий за УЦ, який обслуговує будь-кого з бібліотекою ACME. Джерело не каже, скількох клієнтів це сьогодні виключає, тож вгадувати я не буду. Зате воно каже, навіщо Cloudflare це обмеження.

Відкликання без поломки сайтів #

Cloudflare повідомляє про спостереження за останні 16 років, і одне з них визначає цей задум. Компанія бачила, як центри сертифікації опинялися затиснутими між своєчасним відкликанням і збереженням працездатності сайтів передплатників.

Ця суперечність реальна для будь-якого УЦ. Швидке відкликання сертифіката захищає суспільство, але може покласти кожен сайт, що залежить від цього сертифіката, якщо передплатник не встигне його замінити. УЦ, що опинився посередині, або відкликає із запізненням, або ламає клієнтів.

ARI і є відповіддю Cloudflare. Коли сертифікати треба виводити з обігу, Cloudflare, за її словами, може перенести вікна поновлення відповідних сертифікатів на раніше. Оскільки передплатники зобов'язані опитувати кінцеву точку поновлення й діяти відповідно до опублікованих вікон, УЦ може підвести їх до заміни до настання жорсткого відкликання. Цей механізм описано як можливість, яку Cloudflare має намір мати, а не як продемонстровану нею в ролі УЦ. І все ж логіка складається: вимога опитування існує саме для того, щоб цей важіль працював.

Те саме мислення видно й у ширшій меті проєкту. Cloudflare має намір побудувати центр сертифікації, надійність якого залежить не лише від уникнення помилок, а, як і в решти продуктів Cloudflare, від уміння відмовляти дрібно й обмежувати наслідки будь-якої окремої проблеми. Уникати помилок для УЦ необхідно, і жоден УЦ не може обіцяти цього бездоганно. Проєктувати так, щоб помилка залишалася локалізованою, є чеснішою інженерною позицією.

Прозорість понад аудит #

Публічні УЦ зазвичай оцінюють за аудитами. Джерело прямо говорить про їхні межі: аудити фіксують момент часу й повідомляють, що УЦ їх пройшов. Вони не кажуть, чим УЦ займається в якийсь довільний вівторок після цього.

Відповідь Cloudflare: компанія заявляє, що публікуватиме відтворювані збірки програмного забезпечення, яке підписує сертифікати. Це подано як зобов'язання, а не як готовий результат. Відтворювані збірки дають стороннім змогу перевірити, що двійковий файл на шляху підпису відповідає опублікованому вихідному коду, а це властивість безперервна, на відміну від звіту про аудит. Чи виявиться цього достатньо, залежатиме від того, що Cloudflare справді опублікує, і від того, чи перевірятимуть це інші.

Друга половина оголошення: сертифікати на деревах Меркла #

Постквантова частина оголошення зазирає найдалі вперед. Cloudflare оголошує про плани стати одним із перших УЦ, що випускають постквантові сертифікати, і планує випустити свої перші сертифікати на деревах Меркла в першому кварталі 2027 року. В іншому місці джерела сказано, що перші MTC очікуються на початку 2027 року. І те, і те є планами.

Джерело описує MTC як новий і значно компактніший спосіб доставки публічно довірених сертифікатів. Це формулювання є описом, а у фрагментах, на які я спираюся, джерело не наводить вимірювань, тож я не можу сказати, наскільки вони компактніші. Cloudflare повідомляє, що просуває засновану на стандартах пропозицію щодо MTC в IETF. Вона також повідомляє, що раніше цього року Chrome назвав MTC бажаним шляхом для постквантової автентифікації. Це продемонстрована подія, і вона важлива, бо заявлена перевага розробника браузера перетворює пропозицію на те, на що УЦ може спиратися в планах.

Cloudflare не очікує раптового переходу. Вона очікує, що значна частина інтернету ще багато років покладатиметься на класичні сертифікати й наявний WebPKI. Упродовж цього періоду компанія очікує, що MTC займатимуть неухильно зростальну частку випуску. Це очікування, і джерело саме так їх і позначає.

Один УЦ, один життєвий цикл #

Архітектурний вибір, що з цього випливає, видається мені найпереконливішим. Новий УЦ задумано так, щоб класичні сертифікати й сертифікати на деревах Меркла йшли в одному УЦ, з одним життєвим циклом і одним набором гарантій. Клієнти зможуть переходити у зручному для них темпі й допомогти вебу здійснити перехід без жорсткого перемикання.

Альтернатива: два паралельні УЦ, два набори процедур і в якийсь момент примусова міграція. Жорстке перемикання є найризикованішим способом змінити екосистему сертифікатів, і заявлена мета джерела полягає в тому, щоб його уникнути. Формулювання обережне, і слушно: це задум для УЦ, який поки що нічого не випускає.

Це також узгоджується з картиною стимулів. Cloudflare очікує, що кількість сертифікатів, на які вона покладається щороку, і далі зростатиме в міру скорочення максимальних строків дії, зростання агентної активності й виходу постквантових сертифікатів у маси. Більше сертифікатів, що випускаються частіше, свідчать на користь автоматизації й на користь УЦ, який вважає поновлення першочерговою операцією. Система, побудована навколо ARI й одного життєвого циклу, є розумною відповіддю на це очікування, хоча саме очікування є прогнозом, а не вимірюванням.

«Клієнт Нуль» #

Як перевірити УЦ до того, як на нього покладеться суспільство? Відповідь Cloudflare: стати власним першим клієнтом. Вона буде «Клієнтом Нуль» для нового УЦ і його сертифікатів, як WebPKI, так і MTC. Заявлена мета: переконатися, що всі аспекти нових систем і процесів відповідають високим внутрішнім стандартам Cloudflare і що інфраструктуру УЦ перевірено в масштабі Cloudflare.

З огляду на наведені вище цифри це серйозне внутрішнє навантаження: мільйони сертифікатів на рік у компанії, через яку проходить понад 20 відсотків світового трафіку запитів. Чи пройдуть перші роки роботи гладко, ці заяви сказати не можуть. Зате вони показують розумний порядок дій. Компанія починає як активний користувач того, що будує, з досвідом отримання сертифікатів від кількох УЦ, резервними шляхами й 16 партнерськими УЦ за плечима.

Варто прямо сказати, чого бракує. Джерело не повідомляє ні обсягів випуску, ні частоти помилок, ні затримок перевірки, ні історії інцидентів власного УЦ Cloudflare, бо такої історії поки немає. Оголошення є заявою про наміри, підкріпленою заявками, угодою про придбання й проєктом. Це не послужний список.

За чим стежити #

Три речі вирішать, чи стане це вагомим поповненням WebPKI, чи просто цікавим оголошенням.

Перша: кореневі програми. Cloudflare подала заявки до Chrome, Apple, Microsoft і Mozilla, і процеси відбуваються відкрито. Стежити за ними є найпрямішим способом побачити, як далеко просунувся план, а результат жодна із заяв передбачити мені не дозволяє.

Друга: вимога ARI. УЦ, що наполягає на підтримці RFC 9773, робить ставку на те, що автоматизацію поновлення вдасться просунути по всій базі передплатників. Якщо ставка правильна, Cloudflare отримує змогу переносити вікна поновлення на раніше, коли сертифікати треба виводити з обігу, і це заявлена відповідь на дилему відкликання, яку вона спостерігала. Якщо ні, впровадження йтиме повільніше, ніж передбачає історія про міграцію одним рядком.

Третя: перший квартал 2027 року. Саме тоді Cloudflare планує свої перші сертифікати на деревах Меркла. Відкрите питання в тому, наскільки швидко насправді зростатиме неухильно зростальна частка, на яку вона очікує, з огляду на її ж думку, що значна частина інтернету ще багато років залишатиметься на класичних сертифікатах. Компанія заявила, що переходу не повинно знадобитися жорстке перемикання. Перший квартал 2027 року стане першою нагодою побачити, чи здатен один УЦ, що несе обидва типи сертифікатів, це забезпечити.

Що це означає для галузей #

Поява високопродуктивного автоматизованого публічного центру сертифікації в постачальника периферійної інфраструктури змінює операційні ризики й планування PKI в кількох технічних галузях.

Хмарна інфраструктура й периферійні мережі #

Робота публічного УЦ у периферійному масштабі зменшує зовнішню залежність від сторонніх API перевірки та CRL. Поєднуючи завершення з'єднань зворотного проксі на периферії з автоматизованим поновленням через ACME ARI, постачальники інфраструктури можуть захистити клієнтів від збоїв вищих за ланцюгом центрів сертифікації.

Корпоративна PKI і команди DevOps #

Організації, що використовують Let's Encrypt для публічних кінцевих точок, отримують надійну автоматизовану альтернативу. Однак обов'язкове застосування RFC 9773 (ARI) означає, що командам доведеться перевірити свої клієнти ACME (Certbot, Lego, Caddy, Traefik) і переконатися, що підтримку ARI увімкнено, перш ніж змінювати кінцеві точки каталогу.

Розробники браузерів і управління коренями #

Кореневі програми (Chrome, Mozilla, Apple, Microsoft) стикаються з розширенням екосистеми високопродуктивних автоматизованих УЦ. Двоколійний підхід до коренів (придбання успадкованого кореня 2012 року з одночасним поданням сучасного кореня) враховує політики браузерів, які дедалі сильніше обмежують строк життя кореневих сертифікатів, зберігаючи зворотну сумісність для старих пристроїв.

Висновок #

Крок Cloudflare до статусу публічного центру сертифікації стосується справжньої структурної вразливості сучасного WebPKI: крайньої концентрації безкоштовного автоматизованого випуску сертифікатів. Поєднуючи усталений корінь GlobalSign, сувору автоматизацію поновлення через ARI і міст до постквантових сертифікатів на деревах Меркла, задум розв'язує завдання операційної стійкості, а не просто видачі сертифікатів. Успіх визначать схвалення кореневих програм і те, наскільки швидко клієнтські інструменти опанують стандарти ARI до запуску у 2027 році.

Часті запитання #

Чи можу я вже сьогодні перемкнути свій клієнт ACME на УЦ Cloudflare?

Поки що ні. Cloudflare оголосила про намір, підписала угоду про придбання кореня й подала заявки до основних кореневих програм. Публічний випуск заплановано після схвалення кореневих програм.

Що таке ACME Renewal Information (ARI) і чому це важливо?

ARI (RFC 9773) є розширенням протоколу ACME, яке дає центрам сертифікації змогу повідомляти передплатникам, коли сертифікат слід поновити. Це дає УЦ змогу плавно узгоджувати дострокове поновлення перед плановим відкликанням і запобігати простоям сайтів.

Чим сертифікати на деревах Меркла (MTC) відрізняються від стандартних сертифікатів X.509?

MTC замінюють традиційні окремі криптографічні підписи доказами включення Меркла, прив'язаними до публічно перевірюваного журналу. Це значно зменшує розмір сертифіката й накладні витрати на передавання, що робить їх бажаним кандидатом для постквантової автентифікації TLS.

Джерела #

Cloudflare, (2026). Створення центру сертифікації для всього інтернету ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Інформація про поновлення в Automated Certificate Management Environment (ACME) (ARI) ⧉. IETF.
IETF, (2025). Сертифікати на деревах Меркла для TLS ⧉. IETF.
Chrome Root Program, (2026). Політика й міркування щодо постквантової автентифікації ⧉. Chromium Projects.

Останній перегляд 2026-09-20.

Останній перегляд 2026-10-27.

Перевидати цю статтю

Cloudflare хоче стати УЦ через концентрацію безкоштовних центрів — Sebastien Rousseau

Cloudflare оголосила про намір стати публічним центром сертифікації: подала заявки до кореневих програм і купує корінь GlobalSign, щоб зменшити концентрацію.

Ця стаття поширюється за ліцензією Creative Commons Attribution 4.0 International. Перевидання вимагає посилання на канонічну URL-адресу.

Cloudflare хоче стати УЦ через концентрацію безкоштовних центрів — Sebastien Rousseau

Cloudflare оголосила про намір стати публічним центром сертифікації: подала заявки до кореневих програм і купує корінь GlobalSign, щоб зменшити концентрацію.

Originally published at https://sebastienrousseau.com/uk/2026-09-20-cloudflare-khoche-staty-uts-cherez-kontsentratsiyu/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER