SSL 自動續期失敗怎麼查：DNS 驗證與權限排查

文章目錄

• 1. 確認續期工作有沒有執行
• 檢查排程服務狀態
• 查閱歷史執行紀錄
• 確認是否使用容器或多主機架構
• 2. 辨識驗證方式與失敗階段
• HTTP-01 與 DNS-01 的差異
• 讀懂錯誤訊息的階段定位
• 3. 檢查 DNS 及憑證工具權限
• DNS API 權限範圍檢查
• 檔案系統與憑證目錄權限
• 反向代理與 Web Server 設定檔權限
• 4. 用測試模式核對設定
• 使用 dry-run 模式驗證流程
• 核對設定檔與憑證清單
• 5. 建立到期前告警和負責人
• 設定告警觸發的時間窗口
• 明確指定負責人與備援機制
• 告警欄位建議表

SSL 自動續期失敗怎麼查，第一步永遠是確認排程本身有沒有被執行，而不是急著重新申請憑證。多數案例的根源其實是 cron job 或排程工具靜默失敗，並非憑證系統本身故障。接下來的判斷流程會依序排除排程、驗證方式、權限與設定這幾層可能性，最後補上長期該有的到期前告警機制。這套排查順序的重點在於：先確認「有沒有跑」，再確認「跑到哪裡斷」，最後才是「怎麼讓它不再斷」。

本文重點摘要

• SSL 自動續期失敗最常見的原因不是憑證工具壞掉，而是排程根本沒執行成功。
• 辨識驗證方式卡在 HTTP-01 還是 DNS-01 階段，能把排查範圍縮小八成以上。
• DNS 權限與憑證工具的檔案寫入權限，是續期失敗排查中最容易被忽略的兩個環節。
• 用 certbot 的 --dry-run 測試模式核對設定，可以避免反覆觸發正式簽發撞上 Let's Encrypt 的速率限制。
• 沒有到期前告警機制，等於把網站安全交給運氣，這在企業網站維運上是不可接受的風險。

確認續期工作有沒有執行

網站顯示憑證過期警告時，多數人第一反應是「憑證系統壞了」，但實務上更常見的情況是續期排程根本沒被觸發。這個階段的檢查重點，是把「有沒有跑」跟「跑了但失敗」這兩種狀況先切開來看，否則容易白做工。

檢查排程服務狀態

多數 Linux 主機透過 cron 或 systemd timer 執行 certbot renew，若系統更新後 cron 服務未重啟、或 timer 單元被意外停用，續期指令就不會被呼叫。可透過 systemctl list-timers 查看 certbot 相關 timer 的下次執行時間，若顯示異常久遠或無排程紀錄，代表問題出在排程層而非憑證驗證本身。

查閱歷史執行紀錄

certbot 預設會在 /var/log/letsencrypt/ 留下執行紀錄，依照官方文件（Certbot 官方文件）說明，renew 指令只會處理 30 天內到期的憑證，這代表就算排程有跑，若還沒進入續期窗口，也不會留下任何動作紀錄，這點容易被誤判為「排程失敗」。

先分清楚是「排程沒跑」還是「跑了但沒處理到」，這兩種狀況的修法完全不同，混在一起查只會浪費時間。

確認是否使用容器或多主機架構

若網站部署在容器環境或多台伺服器之間有負載平衡，排程可能只在其中一台主機上設定，導致其他節點的憑證資訊不同步。這種架構下的續期失敗，根源往往不是 certbot 本身，而是部署架構沒有對齊。此類情境建議在架構設計階段就釐清憑證集中管理的方式，避免日後逐台排查。

辨識驗證方式與失敗階段

SSL 自動續期失敗的訊息往往很長，但關鍵只在於辨識是哪一種驗證方式（challenge type）卡住，以及卡在哪個具體階段。這一步做對，後續的權限或設定排查才不會白費力氣。

HTTP-01 與 DNS-01 的差異

HTTP-01 驗證要求憑證工具在網站根目錄下放置一個驗證檔案，讓 Let's Encrypt 伺服器透過 HTTP 連線確認網域擁有權；DNS-01 驗證則是要求在 DNS 設定中新增一筆 TXT 記錄。兩者失敗的徵兆不同：HTTP-01 失敗通常會出現連線逾時或 404 錯誤，DNS-01 失敗則多半是 TXT 記錄查詢不到或 DNS 傳播延遲。

讀懂錯誤訊息的階段定位

certbot 的錯誤輸出通常會標明是在哪個階段失敗，例如 Challenge failed for domain 代表驗證本身沒過，而 Error creating new order 則可能是 ACME 帳戶或網路連線層級的問題。先看清楚錯誤訊息的位置，再決定要往 DNS、權限還是設定檔哪個方向查，能省下大量試錯時間。

看不懂錯誤訊息的階段定位，排查就只是瞎猜。

檢查 DNS 及憑證工具權限

假設一家中小企業的網站交給外部廠商代管 DNS，內部團隊只有憑證工具的操作權限，卻沒有 DNS 後台的存取權，這種分工模式在續期失敗時特別容易卡關：工具端顯示驗證失敗，但真正能解決問題的 DNS 設定卻不在同一組人手上。這種情境在導入 DNS-01 驗證的企業中並不少見。

DNS API 權限範圍檢查

若使用 DNS-01 驗證並透過 API 自動新增 TXT 記錄，該 API 金鑰的權限範圍必須涵蓋「新增與刪除 DNS 記錄」，許多 DNS 服務商預設的 API 金鑰僅有「讀取」權限，導致驗證階段能查詢但無法寫入，這類錯誤訊息通常會明確指出權限不足，而非單純的連線逾時。

檔案系統與憑證目錄權限

certbot 預設將憑證與金鑰存放在 /etc/letsencrypt/ 目錄下，若該目錄的擁有者或權限設定在系統維護過程中被意外變更（例如誤用 chmod 或 chown），續期程序可能因無法寫入新憑證而失敗。這類問題的徵兆是驗證階段本身成功，但最後儲存憑證時報錯，排查時容易被誤判為驗證失敗。

反向代理與 Web Server 設定檔權限

使用 Nginx 或 Apache 作為反向代理時，certbot 若需要重新載入設定檔套用新憑證，執行帳號必須具備重啟或 reload 服務的權限。根據 Nginx 官方文件的設定說明，reload 動作通常需要特定的系統權限層級，若排程以非特權帳號執行，這一步常常被忽略而導致憑證簽發成功卻未實際套用。

驗證成功不代表部署成功，權限問題常常卡在「簽發完之後」而不是「簽發過程中」。

用測試模式核對設定

反覆觸發正式簽發來測試設定，是許多團隊排查時踩過的坑：Let's Encrypt 對同一網域的簽發次數設有速率限制，一旦短時間內多次嘗試失敗的正式請求，就會被暫時鎖住，必須等待限額重置才能再試。這個階段的做法，就是改用官方提供的測試模式，把試錯成本降到最低。

使用 dry-run 模式驗證流程

certbot 提供 --dry-run 參數，依官方文件（Certbot 官方文件）說明，此模式會完整執行驗證流程但不實際簽發憑證，也不計入正式簽發的速率限制。排查設定是否正確時，應優先透過這個方式反覆測試，確認無誤後再讓排程自然觸發正式續期。

核對設定檔與憑證清單

執行 certbot certificates 可以列出目前所有管理中的憑證、到期日與對應的驗證方式設定檔，這是核對「系統認為自己該怎麼續期」與「實際環境能不能配合」兩者是否一致的關鍵步驟。若設定檔中記錄的驗證方式與目前 DNS 或主機架構已不相符（例如網站搬過家但設定檔沒更新），測試模式會立刻反映出來。

以一個典型情境為例，假設某企業網站從原本的單機架構升級為多台伺服器搭配 CDN，但憑證設定檔仍沿用舊有的 HTTP-01 驗證方式，測試模式執行後會明確顯示驗證路徑無法到達，這時候該調整的是驗證方式本身，而不是反覆嘗試正式簽發。

建立到期前告警和負責人

排查完當下的失敗原因只能解決這一次的問題，沒有建立到期前的告警機制，下一次續期失敗時，往往是等到網站訪客看到瀏覽器警告才被發現，這時候商譽損失已經造成。這個階段要處理的是「如何在問題變成事故之前就被看見」。

設定告警觸發的時間窗口

建議在憑證到期前 30 天、14 天、3 天各設一道告警門檻，分別對應「還有時間從容排查」「需要立即處理」「緊急狀態」三種嚴重程度。多數監控工具都能透過 SSL 檢測模組設定到期日告警，重點是告警不能只發到單一信箱，應同步到團隊共用的通知管道。

明確指定負責人與備援機制

告警若沒有明確指定負責人，常見的結果是「以為別人會處理」。建議在告警設定中明列主要負責人與備援聯絡人，並將處理流程記錄成可查核的文件，避免因人員異動導致告警訊息石沉大海。

沒有負責人的告警，跟沒有告警沒有兩樣。

告警欄位建議表

一份完整的告警設定，至少應包含以下欄位：網域名稱、憑證到期日、驗證方式（HTTP-01 或 DNS-01）、負責人聯絡方式、備援負責人、告警觸發天數門檻、最後一次成功續期時間。這些欄位看似基本，但在實際稽核時，正是最容易發現漏洞的地方。

對台中與台灣中小企業而言，許多網站是由內部單一人員兼任維運工作，一旦該人員離職或請假，告警機制若沒有明確交接，等於整個防護網出現破口。這也是為什麼在網站資安防護的規劃上，告警與負責人機制需要被當成制度來設計，而不是臨時補上的待辦事項。企業若評估自行維運吃力，也可以考慮尋求專業的系統維護與顧問服務，將告警監控與續期排查制度化。

需要協助盤點網站憑證與告警機制嗎？

歡迎與欣創數位科技聯繫，針對網站資安防護與系統維護需求進行專業諮詢與報價評估。