卡關的不是工具，是驗證方式

ACME 協定要求你證明「這個網域確實由你控制」，才會簽發憑證。證明的方式就是 challenge，目前主要有三種，分別要求你在不同的地方放上指定內容：網站的特定路徑、DNS 的 TXT 記錄，或 TLS 交握過程。

多數教學會直接給一行 Certbot 指令，預設用 HTTP-01。在單機、直接對外的架構上這確實能跑。但只要架構複雜一點——前面加了 CDN、後面有多台伺服器、或需要萬用字元憑證——HTTP-01 就會開始出問題，而錯誤訊息通常不會直接告訴你「你該換一種驗證方式」。

驗證方式 運作原理 限制
HTTP-01 在網站特定路徑放檔案供 CA 讀取 需開放 80 埠；CDN 或多節點易失敗；不支援萬用字元
DNS-01 在網域下建立指定的 TXT 記錄 唯一支援萬用字元；需 DNS API 權限與傳播等待
TLS-ALPN-01 TLS 交握時回傳特製憑證 需直接掌控 443 埠；CDN 前置時不適用；不支援萬用字元
DNS-PERSIST-01 一次建立常設授權記錄，之後免重複更新 IETF 草案階段，生產可用性請以官方公告為準
三種 ACME 驗證方式的運作原理與硬性限制。第四列是尚未進入生產的新方式。

下表把三種驗證方式的原理與限制列清楚。第三欄才是選擇的依據。

HTTP-01 會失敗的三種情境

HTTP-01 要求 CA 能從公開網路讀到你伺服器上的特定檔案。以下三種架構會讓這個前提不成立：

  1. 服務在 CDN 後面 CA 連過來時會先碰到 CDN 節點，而驗證檔案放在源站。除非 CDN 設定了對 `/.well-known/acme-challenge/` 路徑的回源穿透，否則 CA 讀到的是 CDN 的快取或 404。這是台灣與港澳團隊最常遇到的狀況，因為跨境服務幾乎都會掛 CDN。
  2. 後端有多台伺服器 負載平衡器會把 CA 的請求隨機分到某一台，但驗證檔案只寫在發起申請的那台上。命中率是 1/N，而且每次重試都可能落到不同機器。這種失敗特別惱人，因為它是間歇性的——有時候會過，有時候不會。
  3. 80 埠不對外開放 基於資安政策關閉 80 埠、或服務本來就只在內網提供的環境，HTTP-01 完全無法運作。這也包含只想對特定來源開放的 API 網域。

DNS-01 的代價

DNS-01 解決了上面所有問題——它不需要 CA 連到你的伺服器，只要能查到 DNS 記錄就好。所以無論你在 CDN 後面、有幾台機器、開不開 80 埠，都不影響。這也是為什麼多節點架構幾乎都會走 DNS-01。

但它有自己的成本。每次簽發都要在 DNS 新增一筆 TXT 記錄，代表自動化流程必須持有 **DNS 服務商的 API 憑證**。這些憑證要散布到會執行續簽的每一台機器或 CI 環境，而 DNS 權限是高風險的——拿到它等同於能改你的網域指向。

值得注意的是，Let's Encrypt 在 2026 年 2 月提出了 **DNS-PERSIST-01**，改用一筆綁定特定 ACME 帳戶的**常設授權記錄**，簽發時不必再反覆更新 DNS。這正好針對上述兩個痛點。不過它目前仍是 IETF 草案，官方公告的生產上線時程為 2026 年第二季，實際是否已可用請以 Let's Encrypt 官方資訊為準——同時要注意，授權變成常設之後，保護 ACME 帳戶金鑰的重要性也隨之提高。

萬用字元憑證的硬限制

如果你需要 `*.example.com` 這種萬用字元憑證，選擇題直接結束：**只有 DNS-01 可以**。HTTP-01 與 TLS-ALPN-01 都無法簽發萬用字元憑證，這不是設定問題，是協定層面的限制。

這件事值得提早知道，因為它會反過來決定你的 DNS 供應商選擇。如果你的網域註冊商或 DNS 服務不提供 API，就無法自動化 DNS-01，也就拿不到自動續簽的萬用字元憑證——只能每次手動加 TXT 記錄。在效期已縮短到 200 天、未來將降至 47 天的情況下，手動處理不是可行的長期方案。

三個實作決策

實務上，選擇可以收斂成三個問題：

一、你的架構前面有沒有 CDN 或負載平衡？

有的話直接排除 HTTP-01 與 TLS-ALPN-01，走 DNS-01。硬要用 HTTP-01 也不是不行（設定 CDN 對驗證路徑穿透回源），但那等於多維護一條特例規則，而且 CDN 設定變動時容易被無意間破壞。

二、你需不需要萬用字元憑證？

需要就只能 DNS-01，沒有其他選項。如果子網域數量固定且不多，也可以考慮用 SAN 憑證列舉所有網域來避開萬用字元——但每新增一個子網域就要重新簽發，這個取捨要依實際變動頻率決定。

三、你的 DNS 供應商有沒有 API？

這是走 DNS-01 的前提。挑選註冊商或 DNS 服務時，API 支援應該是必要條件而非加分項。同時要規劃憑證的存放方式——不要把 DNS API 金鑰直接寫在每台伺服器的設定檔裡，那會讓憑證自動化本身變成資安弱點。

開始前該確認的三件事

在動手設定自動化之前，先把這三項確認清楚：

  1. 列出所有需要憑證的網域與子網域 這決定你需不需要萬用字元，也就決定了驗證方式。事後才發現要加萬用字元，等於整套流程重做。
  2. 確認 DNS 供應商的 API 能力與權限粒度 除了有沒有 API，也要看能不能發行「只能改特定網域 TXT 記錄」的受限權杖。全權限金鑰散布在多台機器上，風險太高。
  3. 確認驗證與部署是分開的兩件事 拿到憑證只是第一步。憑證還要送到每一個終止 TLS 的位置並生效，這部分 ACME 工具通常不管。動手前先想清楚部署那一段誰負責。

小結

憑證自動化的難點從來不是安裝 Certbot，而是在你的實際架構下選對驗證方式。判斷邏輯其實很短：**前面有 CDN 或需要萬用字元，就是 DNS-01**；而走 DNS-01 就必須先確保 DNS 供應商有 API，並妥善管理那把金鑰。

如果你不想自己處理 DNS API 金鑰的散布與多節點部署，我們的 SSL 憑證自動化平台把驗證與推播整合在同一個流程裡——DNS 驗證由平台完成，簽發後直接推送到各 CDN 節點，省掉自行維護憑證散布的環節。

參考資料