Cloudflareが自ら証明書発行へ、背景に無料CAの集中問題

TL;DR. Cloudflareがパブリック認証局になる意向を表明した。Chrome、Apple、Microsoft、Mozillaのルートプログラムに申請し、GlobalSignのルート取得で最終合意に署名した。

主な要点

証明書の利用者が発行者になる. インフラ企業の多くは、証明書をめぐる関係の片側にとどまる。証明書を申請し、導入し、CAが障害を起こせば不満を言う。Cloudflareはしっかりと利用者の側にいた。同社自身の説明によれば、公的に信頼される証明書を自ら発行したことは一度もない。.
Cloudflareがこの問いを立てられる理由. CloudflareがCAを構築する根拠は、顧客としての立場から始まる。同社は世界のインターネットリクエストトラフィックの20パーセント超の前段に位置する。数百万のドメインのTLSを終端し、年間数百万件の証明書に依存している。顧客向けにはUniversal SSLを通じて証明書パックを提供し、自社のシステムと社内業務を動かすためにも多数のCAから証明書を調達している。.
集中という問題. この議論を支える数字は目を引く。Let's Encryptは1日あたり1,000万件規模の証明書を発行している。5億を超えるサイトにサービスを提供し、2025年には有効な証明書が40億件を超えた。これは無料CA一つの数字であり、暗号化を一つの組織に大きく依存するウェブの姿を表している。.
ルートは待たずに買う. 発表の中で最も実務的な判断はルートに関するものだ。Cloudflareは、広く信頼された既存のルートをGlobalSignから取得する最終合意に署名したと述べている。出典は理由を率直に示す。まったく新しいルートは何年も広く役立たない。対照的に、既存のGlobalSignルートは2012年からブラウザ、OS、端末の全体で信頼されている。.

Cloudflareは長年、16社の提携パブリックCAに頼り、公的に信頼される証明書を自ら発行したことは一度もない。そのCloudflareがCAになろうとしている。注目すべきは設計で、従来型の証明書とMerkle Tree Certificatesを一つのCAで扱い、障害の封じ込めを最初から組み込んでいる。

証明書の利用者が発行者になる #

インフラ企業の多くは、証明書をめぐる関係の片側にとどまる。証明書を申請し、導入し、CAが障害を起こせば不満を言う。Cloudflareはしっかりと利用者の側にいた。同社自身の説明によれば、公的に信頼される証明書を自ら発行したことは一度もない。

それが変わろうとしている。少なくともCloudflareはそうするつもりだと言う。同社はパブリック認証局になる意向を発表した。発表は現状について慎重であり、本稿もそうあるべきだろう。Cloudflareはまだ証明書を発行していない。ACMEインターフェースから更新規則、Merkle Tree Certificateへの対応まで、サービスの振る舞いに関するすべては計画の表明であり、稼働中のシステムの説明ではない。

発表に信憑性を与えているのは野心ではなく、すでに目に見える下準備である。CloudflareはChrome、Apple、Microsoft、Mozillaのルートプログラムへの収録を申請した。同社は主要なウェブのルートキープログラムのそれぞれと申請・承認の手続きを進めているとし、これらの手続きが公開の場で行われることにも触れている。原理的には、誰でも申請が通るかどうかを見守ることができる。

Cloudflareがこの問いを立てられる理由 #

CloudflareがCAを構築する根拠は、顧客としての立場から始まる。同社は世界のインターネットリクエストトラフィックの20パーセント超の前段に位置する。数百万のドメインのTLSを終端し、年間数百万件の証明書に依存している。顧客向けにはUniversal SSLを通じて証明書パックを提供し、自社のシステムと社内業務を動かすためにも多数のCAから証明書を調達している。

顧客のサービスを止めないため、Cloudflareはそれらの証明書を複数のCAを通じて手配し、CAの障害や失効の際にも顧客のサービスが動き続けるよう、主経路と予備経路を用意している。同社が長年頼ってきた提携パブリックCAのネットワークは16社に上る。

この予備の仕組みは、Cloudflareが障害をどう考えているかを示すので、もう少し詳しく見る価値がある。すべてのUniversal SSL証明書には、別の鍵で包まれ、別の認証局から発行された予備の証明書がすでに付いている。主証明書が失効したり侵害されたりしても、予備はすぐに自動で展開できる。これは、どのCA一つが問題を起こしても備えられるヘッジであり、関係の顧客側から組み立てられている。

ただし、このヘッジには上限がある。分散できるのは存在するCAの範囲に限られ、出典は、十分な能力を持つCAの供給は見かけより乏しいと論じている。

集中という問題 #

この議論を支える数字は目を引く。Let's Encryptは1日あたり1,000万件規模の証明書を発行している。5億を超えるサイトにサービスを提供し、2025年には有効な証明書が40億件を超えた。これは無料CA一つの数字であり、暗号化を一つの組織に大きく依存するウェブの姿を表している。

出典は当然の結論を、適切な留保を付けて導いている。支配的な無料認証局が悪い1週間を過ごせば、ウェブの大部分には、負荷を引き受けられる同等の無料で自動化された代替手段がないというものだ。これは仮定についての記述であり、Cloudflareもそのように示している。そうした1週間が起きたとも、起きるとも主張していない。

それでも論理はわかりやすい。無料で自動化されたCAがレジリエンスの選択肢になるのは、緊急事態の前から存在している場合に限られる。Cloudflareの売り込みは、二つ目をその規模で提供できるという点にある。私はこれが発表の中で最も強い商業的・技術的な理由だと考えるし、計画のより推測的な部分には左右されない。支配的な無料CAが一つあるだけで他にほとんど何もないウェブは、そのCAの運用品質がどうであれ、単一障害点を抱えたウェブである。

観点	従来の無料自動化CA(Let's Encrypt)	提案されているCloudflareのパブリックCA
トラストアンカー戦略	ISRG Root X1 / X2(2015年以降に確立した自社ルート)	取得するGlobalSignルート(2012年から信頼) + 新ルート
発行プロトコル	標準のACME(RFC 8555)	ARI(RFC 9773)の適用を必須とするACME
失効の考え方	CRL / OCSP + 緊急時の加入者一括置き換え	ARIエンドポイントによる協調的な更新の前倒し
ポスト量子への道筋	ハイブリッドX.509署名を評価中	従来型X.509と共存するネイティブなMerkle Tree Certificates(MTC)
規模と初期の負荷	5億超のサイトで1日約1,000万件の証明書	世界のウェブトラフィックの20%超でのCustomer Zeroによる検証

ルートは待たずに買う #

発表の中で最も実務的な判断はルートに関するものだ。Cloudflareは、広く信頼された既存のルートをGlobalSignから取得する最終合意に署名したと述べている。出典は理由を率直に示す。まったく新しいルートは何年も広く役立たない。対照的に、既存のGlobalSignルートは2012年からブラウザ、OS、端末の全体で信頼されている。

ルートの信頼が遅いのは、それが端末に組み込まれ、端末の更新が遅いからだ。新しいルートはすべてのプログラムに受け入れられても、古いスマートフォンや組み込みシステムでは検証に失敗しうる。2012年から現場にあるルートを取得すれば、少なくとも出典の捉え方では、その待ち時間を回避できる。

Cloudflareは新ルートの道を完全に捨てたわけではない。新しいルートもルートキープログラムに収録申請する予定で、同社はそれをエコシステムの向かう先、つまり信頼されるルートの年齢に上限を設け始めたプログラムを含む将来に向けて作ったものだと説明している。この最後の点は、年齢が両刃の剣であることを思い出させてくれる。信頼されたルートの年齢は端末の対応範囲にとっては資産だが、一部のプログラムは信頼されるルートの年齢を制限する方向に動いている。取得したルートと新規申請を並行させるのは、この緊張への対応に見える。ただし出典はその理由をこうした言葉で説明してはいない。

条件付きのACMEファーストのサービス #

導入は、多くのCAの発表が曖昧になるところだ。Cloudflareは具体的である。同社のパブリックCAはACMEファーストになる。つまり、既存の自動化がすでに使っているAutomated Certificate Management Environmentプロトコルを話す。既存の無料CAを指定している人なら誰でも、ディレクトリURLを変えるだけで、新しいツールも設計の見直しもなしにCloudflareのCAへ移れるという主張だ。これは計画であって検証済みの移行経路ではなく、そう読むべきだ。それでも、設定1行の変更は正しい目標である。人を既定の選択肢にとどめるのは移行コストだからだ。

落とし穴は、ほとんどのACME利用者がこれまで満たす必要のなかった要件にある。Cloudflareは、RFC 9773で標準化されたACME Renewal Information、すなわちARIに対応するクライアントにのみ発行する。加入者は、Cloudflareの更新エンドポイントを定期的に確認し、Cloudflareが公表する更新ウィンドウに従って動き、置き換える証明書を特定する自動化を維持しなければならない。

これは強い立場であり、私は正しいと思う。同時に、導入について当然の疑問も生む。ARI対応クライアントにしかサービスしないCAは、ACMEライブラリを持つ誰にでもサービスするCAより狭い。出典は現時点でそれが何件のクライアントを除外するかを述べていないので、推測はしない。出典が述べているのは、Cloudflareがなぜこの制約を望むかである。

サイトを壊さない失効 #

Cloudflareは過去16年間に見てきたことがあると述べており、その一つがこの設計を動かしている。同社は、適時の失効と加入者のサイトを動かし続けることの板挟みになった認証局を見てきた。

この緊張はどのCAにとっても現実的だ。証明書を素早く失効させれば公衆は守られるが、加入者が十分速く置き換えられなければ、その証明書に依存するすべてのサイトが停止しうる。板挟みになったCAは、失効を遅らせるか顧客を壊すかのどちらかになる。

ARIがCloudflareの答えだ。証明書を退役させる必要があるとき、Cloudflareは対象となる証明書の更新ウィンドウを前倒しできるとしている。加入者は更新エンドポイントを確認し、公表されたウィンドウに従って動くことを求められているので、CAは強制的な失効が来る前に加入者を置き換えへと誘導できる。この仕組みはCloudflareが持つつもりの能力として説明されており、CAとして実証したものではない。それでも論理は筋が通っている。確認の要件は、このレバーが機能するために存在する。

同じ考え方は、より広い設計目標にも表れている。Cloudflareは、信頼性が単に間違いを避けることだけでなく、Cloudflareの他の製品と同様に、小さく失敗し、どの問題一つの影響も限定することにかかっている認証局を作るつもりだ。間違いを避けることはCAにとって必要だが、どのCAも完璧には約束できない。間違いが封じ込められたままになるよう設計することのほうが、より誠実なエンジニアリングの姿勢である。

監査を超える透明性 #

パブリックCAは通常、監査によって評価される。出典はその限界を率直に述べる。監査はある時点のものであり、CAが合格したことを教えるだけだ。その後の任意の火曜日にCAが何をしているかは教えてくれない。

Cloudflareの対応は、証明書に署名するソフトウェアの再現可能なビルドを公開するというものだ。これは完成した成果物ではなく約束として示されている。再現可能なビルドがあれば、外部の人は署名経路で動くバイナリが公開されたソースに対応しているかを確認できる。これは監査報告にはない、継続的な性質である。それで十分かどうかは、Cloudflareが実際に何を公開するか、そして他者がそれを確認するかにかかっている。

発表の後半: Merkle Tree Certificates #

ポスト量子の部分は、発表が最も先を見ているところだ。Cloudflareはポスト量子証明書を提供する最初のCAの一つになる計画を発表し、最初のMerkle Tree Certificatesを2027年第1四半期に発行する予定だ。出典の別の箇所では、最初のMTCは2027年初めに見込まれるとしている。どちらも計画である。

出典はMTCを、公的に信頼される証明書を届けるための新しく、はるかにコンパクトな方法だと説明している。この表現は説明であり、私が依拠している箇所では出典は測定値を示していないので、どの程度コンパクトかは言えない。CloudflareはIETFでMTCの標準ベースの提案を推進してきたと述べている。また、Chromeが今年初めにMTCをポスト量子認証の推奨経路に挙げたとも報告している。これは実際に起きた出来事であり、重要だ。ブラウザベンダーが表明した選好こそが、提案をCAが計画の前提にできるものへと変えるからである。

Cloudflareは移行が急に進むとは見ていない。インターネットの大部分は今後も長年、従来型の証明書と既存のWebPKIに頼り続けると見込んでいる。その期間を通じて、MTCが発行に占める割合は着実に増えていくと見ている。これらは見込みであり、出典もそう示している。

一つのCA、一つのライフサイクル #

ここから導かれるアーキテクチャ上の選択は、私が最も説得力を感じるものだ。新しいCAは、従来型の証明書とMerkle Tree Certificatesを一つのCAの下で、一つのライフサイクルと一組の保証で扱うよう設計されている。顧客は自分に合ったペースで導入でき、強制的な一斉切り替えなしにウェブが移行を成し遂げる手助けができる。

代替案は二つの並行するCA、二組の手順、そしていずれかの時点での強制移行だ。一斉切り替えは証明書エコシステムを変える最もリスクの高い方法であり、出典が表明する狙いはそれを避けることにある。表現には留保が付いており、それは正しい。これはまだ発行していないCAの設計意図だからだ。

これはインセンティブの構図にも合う。Cloudflareは、最大有効期間の短縮、エージェント型の活動の増加、ポスト量子証明書の普及に伴い、自社が年間に依存する証明書の数は増え続けると見込んでいる。より多くの証明書がより頻繁に発行されるなら、自動化と、更新を第一級の操作として扱うCAが求められる。ARIと一つのライフサイクルを軸に作られたシステムはその見込みへの妥当な対応だ。ただし見込み自体は予測であり、測定ではない。

Customer Zero #

公衆が頼る前に、CAをどう試すのか。Cloudflareの答えは、自らが最初の顧客になることだ。同社は新しいCAとその証明書(WebPKIとMTCの両方)のCustomer Zeroになる。表明された目的は、新しいシステムとプロセスのあらゆる面がCloudflareの高い社内基準を満たすこと、そしてCAのインフラがCloudflareの規模で実際に使われることを確かめることである。

先の数字を考えれば、これは厳しい社内負荷だ。世界のリクエストトラフィックの20パーセント超の前段に位置する企業全体で、年間数百万件の証明書になる。運用の最初の数年が順調に進むかどうかは、主張からはわからない。主張が示しているのは、妥当な作業順序である。同社は自らが作るものの大口利用者として始め、複数CAによる手配、予備経路、そして背後にある16社の提携CAという実績を持っている。

欠けているものについては率直に述べておく価値がある。出典にはCloudflare自身のCAの発行量、エラー率、検証の遅延、障害の履歴は何も報告されていない。そうした履歴はまだ存在しないからだ。この発表は、申請、取得合意、設計に裏付けられた意図の表明である。実績ではない。

注目すべき点 #

これがWebPKIへの意味のある追加になるのか、単に興味深い発表で終わるのかは、三つのことで決まる。

一つ目はルートプログラムだ。CloudflareはChrome、Apple、Microsoft、Mozillaに申請しており、手続きは公開の場で行われる。それを見守るのが、計画がどこまで進んだかを知る最も直接的な方法であり、結果はどの主張からも予測できない。

二つ目はARIの要件だ。RFC 9773への対応を求めるCAは、更新の自動化を加入者全体に広げられるという賭けをしている。賭けが当たれば、証明書を退役させる必要があるときに更新ウィンドウを前倒しする能力がCloudflareに与えられる。これが、同社が見てきた失効のジレンマへの表明された答えだ。外れれば、導入は1行で移行できるという話が示唆するより遅くなる。

三つ目は2027年第1四半期だ。Cloudflareはその時期に最初のMerkle Tree Certificatesを計画している。未解決の問いは、インターネットの大部分が今後も長年従来型の証明書にとどまるという同社自身の見方を踏まえて、同社が見込む着実に増える割合が実際にどれほど速く増えるかである。同社は、移行に一斉切り替えは必要ないはずだと述べている。2027年第1四半期は、両方の証明書を扱う一つのCAがそれを実現できるかを見る最初の機会になる。

業界別の意味 #

エッジインフラ事業者から大量発行の自動化されたパブリック認証局が登場することは、いくつかの技術分野で運用リスクとPKI計画を変える。

クラウドインフラとエッジネットワーク #

エッジの規模でパブリックCAを運用すれば、第三者の検証APIやCRLへの外部依存が減る。リバースプロキシによるエッジでの終端とACME ARIによる自動更新を組み合わせることで、インフラ事業者は上流の認証局の障害から顧客を守ることができる。

企業のPKIとDevOpsチーム #

公開エンドポイントにLet's Encryptを使っている組織は、信頼できる自動化された代替手段を得る。ただし、RFC 9773(ARI)の適用が必須であるため、チームはディレクトリのエンドポイントを切り替える前に、ACMEクライアント(Certbot、Lego、Caddy、Traefik)を点検し、ARI対応が有効であることを確かめる必要がある。

ブラウザベンダーとルートのガバナンス #

ルートプログラム(Chrome、Mozilla、Apple、Microsoft)は、大量発行の自動化されたCAが増えるエコシステムに直面している。二本立てのルート戦略(2012年の既存ルートを取得しつつ新しいルートを申請する)は、ルート証明書の有効期間をますます制限するブラウザのポリシーに対応しながら、古い端末との後方互換性を保つものだ。

結論 #

Cloudflareがパブリック認証局になる動きは、現代のWebPKIが抱える本物の構造的な弱点、すなわち無料で自動化された証明書発行の極端な集中に取り組むものだ。既存のGlobalSignルート、厳格なARIによる更新の自動化、ポスト量子のMerkle Tree Certificatesへの橋渡しを組み合わせることで、この設計は単なる証明書の供給ではなく運用のレジリエンスに取り組んでいる。成否を決めるのは、ルートプログラムの承認と、2027年の展開に先立ってクライアントツールがどれだけ速くARI標準を採用するかである。

よくある質問 #

今すぐACMEクライアントをCloudflareのCAに切り替えられますか。

まだできない。Cloudflareは意向を発表し、ルート取得の合意に署名し、主要なルートプログラムに申請を提出した段階だ。一般向けの発行は、ルートプログラムの承認後に展開される予定である。

ACME Renewal Information(ARI)とは何で、なぜ重要なのですか。

ARI(RFC 9773)はACMEプロトコルの拡張で、証明書をいつ更新すべきかを認証局が加入者に知らせられるようにする。これによりCAは計画された失効に先立って早めの更新を円滑に調整でき、サイトの停止を防げる。

Merkle Tree Certificates(MTC)は標準のX.509証明書とどう違うのですか。

MTCは、従来の個別の暗号署名を、公開で検証可能なログに固定されたMerkle包含証明に置き換える。これにより証明書のサイズと送信のオーバーヘッドが大きく減り、ポスト量子のTLS認証の有力な候補となっている。

参考文献 #

Cloudflare, (2026). インターネット全体のための認証局を作る ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment(ACME)Renewal Information(ARI) ⧉. IETF.
IETF, (2025). TLSのためのMerkle Tree Certificates ⧉. IETF.
Chrome Root Program, (2026). ポスト量子認証に関するポリシーと考慮事項 ⧉. Chromium Projects.

最終確認日 2026-09-20.

最終確認日 2026-10-27.

この記事を転載

Cloudflareが自ら証明書発行へ、背景に無料CAの集中問題 — Sebastien Rousseau

Cloudflareがパブリック認証局になる意向を表明した。Chrome、Apple、Microsoft、Mozillaのルートプログラムに申請し、GlobalSignのルート取得で最終合意に署名した。

本記事のライセンスは Creative Commons Attribution 4.0 International. 転載の際は正規URLへの帰属表示が必要です。

Cloudflareが自ら証明書発行へ、背景に無料CAの集中問題 — Sebastien Rousseau

Cloudflareがパブリック認証局になる意向を表明した。Chrome、Apple、Microsoft、Mozillaのルートプログラムに申請し、GlobalSignのルート取得で最終合意に署名した。

Originally published at https://sebastienrousseau.com/ja/2026-09-20-cloudflare-mizukara-shomeisho-hakko-haikei/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER