Cloudflare想自行簽發憑證，其計畫立足於免費CA集中問題

TL;DR. Cloudflare宣布有意成為公開憑證機構。它已向Chrome、Apple、Microsoft與Mozilla的根憑證計畫提出申請，並簽署向GlobalSign收購根憑證的最終協議。

核心要點

憑證的使用者變成憑證的簽發者. 多數基礎設施公司只站在憑證關係的一邊。它們申請憑證、安裝憑證，CA出事時就抱怨。Cloudflare一直穩穩站在使用的那一方。依它自己的說法，它從未親自簽發過任何一張公開受信任的憑證。.
為什麼Cloudflare有立場提出這個問題. Cloudflare建立CA的理由，始於它身為客戶的位置。它位於全球網際網路請求流量20%以上的前端。它為數百萬個網域終結TLS，每年仰賴數百萬張憑證。它透過Universal SSL為客戶提供憑證套件，同時也向許多不同的CA取得憑證，用來運作自己的系統與內部業務。.
集中問題. 支撐這個論點的數字相當驚人。Let's Encrypt每天簽發約一千萬張憑證。它服務超過5億個網站，並在2025年突破40億張有效憑證。這只是一家免費CA的數字，描繪出一個加密高度仰賴單一組織的網路。.
買下根憑證，而不是等待. 公告中最務實的決定與根憑證有關。Cloudflare表示，它已簽署最終協議，向GlobalSign收購一個成熟且廣受信任的根憑證。來源直接說明理由：全新的根憑證多年內都難以廣泛派上用場。相較之下，既有的GlobalSign根憑證自2012年起就在各瀏覽器、作業系統與裝置上受到信任。.

多年來，Cloudflare一直仰賴16家合作的公開CA，自己從未簽發過任何一張公開受信任的憑證。如今它打算成為CA，而值得注意的是它的設計：在同一個CA之下同時處理傳統憑證與Merkle Tree Certificates，並從一開始就內建故障隔離。

憑證的使用者變成憑證的簽發者 #

多數基礎設施公司只站在憑證關係的一邊。它們申請憑證、安裝憑證，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每天簽發約一千萬張憑證。它服務超過5億個網站，並在2025年突破40億張有效憑證。這只是一家免費CA的數字，描繪出一個加密高度仰賴單一組織的網路。

來源得出顯而易見的結論，並加上恰當的保留：如果居主導地位的免費憑證機構遇上糟糕的一週，網路的大部分將沒有可相提並論的免費自動化替代方案來承接負載。這是對一種假設情境的陳述，Cloudflare也是這樣呈現的。它並未宣稱這樣的一週已經發生，或即將到來。

即便如此，其中的邏輯不難理解。免費的自動化CA唯有在緊急情況發生前就已存在，才算得上是一種韌性選項。Cloudflare的訴求是，它能以相應的規模提供第二家這樣的CA。我認為這是公告中最有力的商業與技術理由，而且不依賴計畫中任何較具推測性的部分。一個只有一家主導的免費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億以上網站，每天約1000萬張憑證	在全球20%以上網路流量上進行Customer Zero驗證

買下根憑證，而不是等待 #

公告中最務實的決定與根憑證有關。Cloudflare表示，它已簽署最終協議，向GlobalSign收購一個成熟且廣受信任的根憑證。來源直接說明理由：全新的根憑證多年內都難以廣泛派上用場。相較之下，既有的GlobalSign根憑證自2012年起就在各瀏覽器、作業系統與裝置上受到信任。

根憑證的信任建立得慢，是因為根憑證安裝在裝置裡，而裝置更新得很慢。一個新根憑證即使被所有計畫接受，仍可能在較舊的手機或嵌入式系統上驗證失敗。收購一個自2012年起就已部署的根憑證，至少依來源的說法，可以避開這段等待。

Cloudflare並沒有完全放棄新根憑證這條路。它也將提交一個新根憑證申請加入根金鑰計畫，並表示這是為生態系統的發展方向而打造，包括一些開始限制受信任根憑證年齡上限的計畫。最後這個細節提醒我們，年齡是一把雙面刃。受信任根憑證的年齡對裝置涵蓋範圍而言是一項資產，而一些計畫正朝著限制受信任根憑證年齡的方向前進。同時運作收購來的根憑證與新提交的根憑證，看來是對這種張力的回應，不過來源並沒有用這些話說明其中的理由。

附帶條件的ACME優先服務 #

導入環節是許多CA公告變得含糊的地方。Cloudflare說得很具體。它的公開CA將以ACME為優先，也就是使用既有自動化工具早已採用的Automated Certificate Management Environment協定。它的說法是，任何已經指向既有免費CA的人，只要更改一個目錄URL，就能轉移到Cloudflare的CA，不需要新工具，也不必重新設計架構。這是計畫，而不是經過驗證的轉移路徑，應該這樣看待。但一行設定的變更是正確的目標，因為讓人們停留在預設選項上的，正是轉移成本。

問題在於一項多數ACME使用者過去不必滿足的要求。Cloudflare只會對支援ACME Renewal Information（即ARI，已在RFC 9773中標準化）的用戶端簽發憑證。訂閱者必須維護自動化程式，定期輪詢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之一，並計畫在2027年第一季簽發首批Merkle Tree Certificates。來源的另一段則說首批MTC預計在2027年初推出。兩者都是計畫。

來源將MTC描述為一種交付公開受信任憑證的新方式，而且精簡得多。這個措辭是一種描述，而在我所依據的段落中，來源沒有提供量測資料，所以我無法說明它究竟精簡多少。Cloudflare表示，它一直在IETF推動以標準為基礎的MTC提案。它也提到，Chrome今年稍早已將MTC列為後量子認證的首選路徑。這是已經發生的事，而且很重要，因為瀏覽器廠商公開表態的偏好，正是把一項提案變成CA可以據以規劃的東西的關鍵。

Cloudflare並不認為轉換會是突然的。它預期在未來許多年裡，網際網路的大部分仍將仰賴傳統憑證與現有的WebPKI。在這段期間，它預期MTC在簽發量中的占比會穩定成長。這些都是預期，來源也是這樣標示的。

一個CA，一個生命週期 #

由此而來的架構選擇，是我認為最有說服力的部分。新的CA設計成在同一個CA之下處理傳統憑證與Merkle Tree Certificates，採用同一個生命週期與同一套保證。如此一來，客戶就能依適合自己的步調導入，並在不需硬性切換的情況下，協助網路完成轉換。

另一種做法是兩個平行的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就能在憑證必須汰換時提前更新時段，這正是它針對所見撤銷困境提出的答案。如果押錯了，導入速度會比一行設定即可轉移的說法所暗示的更慢。

第三是2027年第一季。那是Cloudflare計畫推出首批Merkle Tree Certificates的時間。懸而未決的問題是，考量到它自己認為網際網路的大部分在未來許多年仍會停留在傳統憑證上，它所預期穩定成長的占比，實際上會成長得多快。這家公司表示，這次轉換不應需要硬性切換。2027年第一季將是第一個機會，看看一家同時處理兩種憑證的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/zh-hant/2026-09-20-cloudflare-xiang-zixing-qianfa-pingzheng-jihua-tw/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER