修復 Zimbra 憑證過期問題：安全地續訂自簽名憑證

Zimbra 伺服器可能看起來運作正常，直到使用者突然收到瀏覽器警告（例如「憑證已過期」）、郵件用戶端拒絕 SSL/TLS 連接，或管理員發現憑證已過期。最快捷安全的解決方法並非立即更換所有憑證元件。首先確定哪些組件已過期，然後續訂所需的最小組件。

Zimbra 技術中心目前針對單一伺服器自簽章部署的流程用於zmcertmgr建立和部署憑證。值得注意的是，Zimbra 指出，對於普通的自簽名憑證續訂，建立新的憑證授權單位 (CA) 是可選的；您無需在每次伺服器憑證過期時都更換 CA。本指南使用的官方參考資料已於 2026 年 10 月 6 日核實：重新產生自簽名 SSL 憑證 — 單一伺服器和管理控制台以及 CLI 憑證工具。

為什麼過期的 Zimbra 憑證會導致實際服務問題

Zimbra 在 Web 介面、代理、LDAP 和郵件協定等服務中使用 TLS 憑證。一旦憑證過期，即使底層 Zimbra 進程仍在運行，客戶端也可能拒絕連線。因此，瀏覽器警告只是其中一種症狀。根據您的網路拓撲和用戶端策略，您可能還會遇到安全 IMAP/POP/SMTP 連線失敗、代理錯誤或 LDAP/TLS 問題。

有兩種不同的過期情況需要區分：

• 只有伺服器憑證過期了。這種情況比較簡單。如果現有的 Zimbra CA 仍然有效，請保留它，產生新的伺服器證書，部署新證書，然後重新啟動服務。
• Zimbra CA 本身已過期。請重新建立並部署 CA，然後建立並部署由該 CA 簽署的新伺服器憑證。在多伺服器部署中，跨節點的 CA 一致性至關重要，因此請勿將多節點環境視為單一伺服器環境。

在進行任何變更之前，請先建立適合您環境的最新備份或快照。憑證重新產生通常很簡單，但如果伺服器有較舊的自訂設定、手動安裝的憑證或混合拓撲結構，備份可以為您提供一個復原點。

第一步：確認已部署的憑證確實已過期

切換到 Zimbra 帳戶並檢查目前部署到本機服務的憑證：

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

檢查證書的有效期限和證書主題。如果證書仍在有效期內，請先調查主機名稱不符、不受信任的自簽名 CA、代理伺服器仍在提供舊證書，或者伺服器/用戶端時間不正確等問題，而不是不必要地重新產生證書。

您也可以檢查遠端用戶端在 HTTPS 上實際收到的憑證。請將「主機名稱」替換mail.example.com為使用者連線的主機名稱：

openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

當證書看起來正確但瀏覽器仍然看到舊證書時，這種遠端檢查非常有用viewdeployedcrt，因為它測試的是透過網路提供的證書，而不僅僅是磁碟上的檔案。

步驟 2：檢查服務狀態並確定 CA 是否也需要續約

在變更憑證之前，請確認目前的 Zimbra 服務狀態，以便建立一個基準：

zmcontrol status

如果只有伺服器憑證過期，而 Zimbra CA 仍然有效，則跳過 CA 重建步驟，直接跳到下一節中的伺服器憑證命令。這樣可以最大程度地減少信任鏈的改變。 Zimbra 的單一伺服器文件明確指出，建立新的 CA 是可選的，並非每次續訂自簽章憑證時都必須這樣做。

如果證書已過期，或者您有充分的理由需要更換證書，請建立新的證書：

/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca

步驟 3：產生並部署新的自簽名伺服器憑證

對於簡單的單一伺服器續期，Zimbra 文件中記錄了以下步驟。此範例建立了一個有效期為 365 天的證書：

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt self

如果用戶端透過多個 DNS 名稱連接，則應使用所需的「使用者備用名稱」產生證書，而不是假設預設主機名稱就足夠了。 Zimbra 的憑證工具支援此功能-subjectAltNames。例如：

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365 -subjectAltNames "mail.example.com,webmail.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self

請使用能夠真正解析到此 Zimbra 服務且您的使用者或整合實際使用的名稱。即使憑證未過期，如果要求的主機名稱不在憑證的主題/SAN 值範圍內，驗證仍然會失敗。

請勿使用此自簽名程序意外覆蓋商業/公共信任憑證。如果您的伺服器需要使用商業證書，請立即停止操作，並按照 Zimbra 的商業證書部署流程進行操作。

步驟 4：驗證部署，重新啟動 Zimbra，並從客戶端進行測試

確認 Zimbra 已部署新憑證：

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

然後重新啟動 Zimbra，以便服務載入新憑證：

zmcontrol restart

重啟完成後，運行：

zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

你想要的結果很簡單：預期的服務正在運行，並且已部署的憑證現在有未來的過期日期。最後，針對使用者實際存取的主機名稱重複執行遠端 OpenSSL 測試。這可以驗證重啟後網路上提供的服務內容。

如果瀏覽器仍然顯示舊的或過期的證書

不要立即重新產生憑證。依序完成剩餘的憑證層級：

• 確認 DNS 和主機名稱。確保您測試的主機名稱與新憑證所涵蓋的主機名稱一致，並且能夠連接到預期的 Zimbra 伺服器。
• 檢查代理路徑。 Zimbra的憑證故障排除文件指出，在某些情況下，代理伺服器可能會繼續提供舊憑證。請檢查遠端提供的證書，而不僅僅是本機證書文件。請參閱Zimbra 證書錯誤。
• 檢查客戶端信任度。即使續期的自簽名憑證在有效期內，瀏覽器或郵件用戶端可能仍然不信任它。憑證過期和信任度是兩個不同的問題。
• 檢查系統時間。伺服器或用戶端上嚴重不準確的時鐘可能會導致原本有效的憑證顯示為尚未生效或已過期。
• 檢查 CA。如果葉憑證是新的，但已核發憑證的 Zimbra CA 已過期，請更換 CA 並使用新的 CA 重新產生伺服器憑證。

多伺服器 Zimbra 需要不同程度的維護。

對於多節點安裝，請使用多伺服器流程，而不是在每台主機上盲目重複單一伺服器命令。 Zimbra 文件中介紹如何建立/部署 CA，然後使用 `git regenerate self-signed SSL certificate — Multi-Server` 將自簽名憑證部署到各個節點deploycrt self -allserver；文件也警告說，` git regenerate self-signed SSL Certificate — Multi- viewdeployedcrtServer` 僅報告本地伺服器。官方參考文件是《重新產生自簽名 SSL 憑證 — 多伺服器》。

LDAP 主伺服器和副本伺服器之間的 CA 憑證不符會導致 TLS 和複製問題。如果您採用多伺服器拓撲結構，請在每個受影響的節點上驗證 CA 憑證鏈，並遵循文件中規定的部署順序。

自檢：如何判斷修復是否完成

在關閉事件之前，請核實以下所有資訊：

• zmcontrol status顯示預期的 Zimbra 服務正在運作。
• zmcertmgr viewdeployedcrt顯示一份有效期限在未來的證書。
• 遠端openssl s_client檢查傳回的公共/內部主機名稱使用者實際使用的憑證新日期相同。
• 憑證主題或SAN涵蓋該主機名稱。
• Webmail 和您的環境所使用的郵件協定可以建立 TLS 連線。
• 如果您有意更換了 Zimbra CA，則已依要求更新了綁定或信任舊 CA 的用戶端或內部系統。

對於例行的單伺服器證書過期，通常情況下，影響最小的方案是保留一個仍然有效的 Zimbra CA，創建一個新的自簽名伺服器證書，部署該證書，重啟服務，然後從伺服器外部驗證該證書。僅當 CA 過期或有其他明確的理由需要輪換時才更換它。這種方法既能解決目前的服務中斷問題，又能避免不必要的信任鏈變更。