Certimate 實測：開源 SSL 憑證工具把部署自動化到 162 個目標

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

如果你的 TLS 憑證只裝在自己管的 Nginx 或 Caddy 上，這篇可以跳過：Caddy 會自己簽自己續，acme.sh 一行 cron 也搞定。但只要你的網站掛在 CDN、負載平衡器或 WAF 後面，憑證每九十天到期一次，你就要登入一個又一個雲端後台，把新的 PEM 手動貼進去。Certimate 想自動化的是後面這段。

我在 macOS 上把官方 v0.4.34 完整跑起來操作過一輪。要先說明的是，手上沒有可填入 DNS API 的受控網域，申請成功率與續期排程的穩定度，要等真的接上網域才驗證得了；面板本身的功能與設計，是親自操作過的。

從下載到登入面板，中間沒有任何安裝步驟

到 GitHub Releases 抓下來的壓縮檔約 33MB，解開只有四個檔案：執行檔、LICENSE、README、CHANGELOG，執行檔本身約 122MB。對照官方 checksums.txt 的 SHA256 一致後，終端機執行 ./certimate serve，瀏覽器打開 127.0.0.1:8090，面板就在了。沒有資料庫要裝、沒有 Node 或 Python 環境要配，資料落在工作目錄的 pb_data 資料夾。底層是內嵌的 PocketBase，一個把 SQLite 打包進單一執行檔的後端。偏好 Docker 的話，官方映像檔一行 docker run 掛載 pb_data 就能跑，Docker Hub 顯示累積約 27.7 萬次拉取。

第一次登入用的是文件上寫明的預設帳號 [email protected] 與預設密碼。輸入後直接進入 Dashboard，中途沒有出現強制改密碼的畫面，帳號設定頁只有一段建議你定期換密碼的文案。這個細節後面會再回來談，因為它決定了這套東西能不能直接對外開。

介面本身乾淨：左側是 Dashboard、Workflows、Certificates、Credentials、Presets、Settings 六個入口。所有操作圍繞「工作流」這個概念組成，申請、部署、通知都被拉成畫布上的節點。首頁是四張統計卡（全部憑證、即將到期、已過期、工作流數）加上最近的執行紀錄表，旁邊放了三個捷徑：建新工作流、改帳號密碼、設定憑證機構。對一個要長期掛著的維運面板來說，到期可見性放在第一屏是合理的設計。語言選項只有英文與簡體中文，沒有繁體中文，從原始碼的語言檔目錄看也只有這兩套資源，短期內不會有第三種。

Pin

162 個部署目標，才是它真正在賣的東西

README 說支援「160+ 部署目標」，我把工作流裡的部署節點打開逐項數過：162 項，行銷數字與實際清單對得上。清單依服務類型分成 CDN、儲存、負載平衡、防火牆等十一個分頁。

真正值得注意的是結構。162 項裡，「裝到自己伺服器」的選項只有 Local host、Remote host (SSH)、Remote host (FTP)、Webhook、Kubernetes Secret 這少數幾項，其餘一百五十多項全部是特定廠商的特定服務。阿里雲一家就佔 17 種，從 OSS、CDN、DCDN、ESA、三種負載平衡器到 WAF、Anti-DDoS、函式運算都有對應。騰訊雲也是 17 種，華為雲與火山引擎各 10 種上下。這個深度分布說明了它的主要使用者樣貌：網站在中國雲端生態裡跑、憑證要裝進十幾種託管服務的人。

Pin

台灣的使用者看同一份清單會得到不太一樣的結論。Cloudflare、AWS、GCP、Azure、Hetzner、Vercel、Netlify、Bunny 都在，但每家多半只有一兩種部署方式，與阿里雲的 17 種相比明顯是點綴。如果你的目標是「把憑證自動推到 Cloudflare」，它能做；如果你期望它對國際雲的服務覆蓋與中國雲同樣深，目前不是。

實際操作的流程是兩段式。你先到 Credentials 頁把各家雲的 API 金鑰建成一筆筆「憑證」，新增時的類型對話框列出 130 多個服務，每選一家就出現對應的存取欄位；之後在工作流的部署節點裡，就能直接引用這筆憑證。部署節點還會誠實標示：沒有先建對應憑證的服務會整組變成不可選，介面直接把未建憑證的服務列為停用。這個設計把「金鑰保管」與「部署排程」拆開，金鑰集中存放，工作流各自引用，觀念上是乾淨的。

這也是它與腳本工具真正分工的地方。acme.sh 其實有 deploy hook，certbot 也有部署外掛，兩者都涵蓋一部分雲端服務；差別在 hook 清單要自己維護、出了錯要看 log，而這裡的 162 項是圖形介面裡勾一勾就排進工作流。付費面板與 CDN 廠的自動託管也解同一個問題，差別是這套開源、自架、金鑰不出自己的機器。

申請側：能力與你熟悉的 ACME 工具同級

憑證申請該有的選項都在。驗證方式支援 DNS-01 與 HTTP-01。網域支援單一、多網域與萬用字元，連 IP 位址憑證都能申請，走 HTTP-01 驗證，這是 Let’s Encrypt 這一年多才正式開放的能力。金鑰可選 RSA2048 或 ECC。憑證機構預設 Let’s Encrypt，也可換 ZeroSSL、Google Trust Services、SSL.com、Actalis。簽下來的憑證可以匯出成 PEM、PFX、JKS 三種格式，Windows 伺服器與 Java 應用程式環境都吃得到。

DNS 供應商的數量官方寫「70+」，我在新增憑證的對話框裡數到的 DNS 類項目正好是 70 個。國際常用的 Cloudflare、GoDaddy、Namecheap、Gandi、Hetzner、Porkbun、OVHcloud 都在，也有 Duck DNS 這類免費動態 DNS，以及給進階玩家的 RFC 2136 動態更新與自架 acme-dns。對台灣讀者來說，只要網域放在國際註冊商或 Cloudflare，幾乎都接得上。

有一個預設值值得注意。申請節點的說明文字寫著預設採用 shortlived 的 ACME 設定檔，白話說就是簽出來的憑證效期比傳統九十天短、續期間隔也跟著縮短。這是 Let’s Encrypt 這兩年推動的方向：短效期憑證被偷走的利用價值低，安全性換來的是續期機制必須更可靠。不喜歡這個預設，同一頁表單就能改回長效期，或直接指定效期天數，前提是你選的憑證機構支援。

工作流編輯器把申請節點做成多步精靈：先選要申請網域還是 IP，再填聯絡信箱、選驗證方式與 DNS 供應商。接著一頁攤開金鑰演算法、憑證機構、效期、鏈偏好，連 DNS 傳播等待秒數、CNAME 跟隨、ARI 都有開關。不想從空白畫布開始，內建範本一鍵生成的就是標準編排：申請節點接部署節點，掛一條失敗通知分支，尾端收在 End。整個編排是 try-catch-finally 結構，申請失敗可以走通知或重試分支，這是 v0.4 重構後的樣子，舊版的失敗分支節點無法自動轉換，升級的人要手動把多個結果分支合併成一個。通知對象涵蓋 email、Discord、Slack、Telegram、釘釘、飛書、企業微信，這份名單來自官方文件。

Pin

到期監控目前藏在工作流的排程裡：你可以讓工作流定時檢查效期、低於門檻就重簽重部署，觸發方式支援手動與排程兩種。官方遷移文件提到未來計畫把憑證監控獨立成專門模組，現階段的作法是把它當成工作流的一種觸發條件，申請、部署、通知全部接在同一條流程裡，跑過的每一步紀錄都留在 History runs 頁，失敗了回頭查得到是哪個節點出的錯。

把金鑰交給面板之前，先算清這筆帳

這套工具的本質，是你把 Cloudflare、AWS、阿里雲這些帳號的 API 金鑰，一次交給一個自己管的網頁面板，讓它代你簽發、推送、續期。金鑰存在本機 SQLite，不經過第三方伺服器，這點與雲端 SaaS 面板不同；但風險集中度是一樣的：面板一旦被任何人登入，等於同時拿到你全部雲端服務的控制權。

對外開放之前，有幾件事必須先處理。最急的是那組預設密碼：首次登入不會強制你換，8090 埠又只有明文 HTTP，穩妥的做法是改成僅監聽 localhost，對外一律走反向代理加 TLS。資源預期也要重新校準：README 寫「約 20MB 記憶體」，我在 macOS 上量到的待機 RSS 是 92MB，差了四倍多，對伺服器來說仍然輕，但別按 20MB 做容量規劃。權限模型的限制更根本：GitHub 上有人要求開放多使用者帳號與操作紀錄，方便團隊分工與稽核，維護者的回覆是這個需求現階段不會支援，issue 直接以 not planned 關閉。也就是說，面板設計上就是單一管理員全權，想拿來當團隊共用工具的人要先想清楚。備份紀律則是雙面刃：pb_data 資料夾裡是金鑰、帳號與工作流設定，一次打包備份就能搬機，但這個資料夾外流就等於全部金鑰外流，權限要收緊。

下載前先認明專案位址

網路上流傳的教學與分享文，不少把 GitHub 連結指向 usual2970/certimate 這個位址。實際查看會發現那是個空殼：整個儲存庫只有一次提交、17 顆星、沒有原始碼、沒有授權檔，建立在 2025 年 6 月 22 日，三十六分鐘後就停止推送，當天發了一個 v0.3.19 的 release 之後再無動靜。

真正活著的專案在 certimate-go/certimate：9,345 顆星、909 個 fork、MIT 授權、Go 語言，2024 年 8 月建立，截至 2026 年 10 月初仍有程式碼推送與修 bug 的提交。從 2024 年 9 月的 v0.1.0 到 2026 年 9 月底的 v0.4.34，累積 106 個版本，平均下來約一週就出一版。維護回應也算得上勤：十月初有人回報介面裡「了解更多」的文件連結失效，當天就有人提交修復連結的 PR，隔天合併、issue 同步關閉，前後不到一天半。兩個位址的關係從授權檔看得出來：LICENSE 上同時寫著 2024 Yoan.Liu（原作者個人）與 2025 certimate-go（組織），舊位址是專案搬進組織前的歷史痕跡。無論如何，binary 請從 certimate-go 的 Releases 頁下載，各平台共八種執行檔外加 checksums.txt，下載後先對雜湊再執行。

已經在跑 v0.3 的使用者要注意 v0.4 是破壞性升級。全域通知設定被整併進憑證管理、失敗分支改成 try-catch 結構、萬用字元網域的比對行為被統一，而且官方文件明說升級完成後無法降回舊版，動手前先備份 pb_data。

誰該裝它，誰留在腳本就好

適合自架這套的樣貌很明確：手上有兩三個以上的站、憑證要裝進 CDN 或負載平衡器而不是本機檔案、到期續期不想再靠人登入後台貼字、或者團隊裡有只會圖形介面的同事。作者自己在官方部落格也是這樣定位的：網站部署在 CDN 與物件儲存後面時，Caddy 與 acme.sh 這類工具照顧不到「把憑證裝進廠商後台」這段，這是開發它的動機。

反過來，單一站、自己管伺服器、命令列用得順的人，繼續用 acme.sh 或直接讓 Caddy 處理就好。多一個面板就多一個要顧的服務，何況自架監控類面板本身就是另一門學問，UptimeFlare 那類狀態頁工具的使用者應該很有感。若你在 Cloudflare 生態裡，工程量其實更小：Cloudflare Email Routing 這類服務開起來就是幾個點選的事，憑證面 Cloudflare 的免費方案也能把大部分場景吃掉。自架這類面板的意義，在於跨多家雲、跨多個站的集中管理。另一種不適合的情境是家裡的小服務：只掛一兩個自簽給內網用的憑證，多數人連對外都不需要，用 frp 打通內網之後再考慮憑證也不遲，為此常駐一個管理面板，成本與收益不成比例。

想先看看再說的人，成本是一分鐘：下載、解壓、serve，用 localhost 開起來把玩，全程不對外曝露、不填任何真金鑰，看完再決定要不要認真導入。這大概是它最友善的一面，試用與正式採用之間那道門，比多數自架工具都矮。