如何在 Zimbra 伺服器上安裝商業 SSL 憑證

即使憑證授權單位 (CA) 聲稱憑證已正確頒發，Zimbra 上的商業 SSL 憑證仍可能出現多種令人沮喪的故障。最常見的問題通常並非憑證本身：私鑰與傳回的憑證不符、缺少中間 CA、憑證的「使用者備用名稱」(SAN) 中缺少主機名，或者管理員在驗證憑證鏈之前部署了檔案。

處理這項工作最安全的方法是將其視為一系列檢查，而不是單一「安裝憑證」命令。 Zimbra 官方文件中的憑證工具zmcertmgr可以建立憑證簽署請求 (CSR)、驗證私鑰和 CA 鏈、將憑證部署到 Zimbra 服務，並顯示目前已啟動的憑證。 Zimbra 技術中心在其《管理控制台和 CLI 憑證工具指南》中記錄了這些指令。

成功的 Zimbra SSL 安裝應該是什麼樣子

在進行任何更改之前，請先定義您想要的結果。正確的部署應滿足以下所有條件：

• 憑證的 SAN 清單包含客戶端實際使用的每個公用主機名，例如mail.example.com。
• 頒發的憑證與儲存的商業憑證的私鑰相符。
• Zimbra 可以驗證從伺服器憑證到中間 CA 憑證再到根 CA 的完整憑證鏈。
• zmcertmgr deploycrt comm完成時沒有出現密鑰不匹配或鏈驗證錯誤。
• Zimbra 服務正常重開機。
• zmcertmgr viewdeployedcrt顯示預期證書。
• 瀏覽器或 TLS 用戶端連線到公用主機名稱時會看到新憑證和無信任警告。

如果其中任何一項檢查失敗，請先修復該特定層，然後再繼續。重複重新部署相同的檔案很少能解決密鑰、SAN 或鏈問題。

開始之前：選擇正確的證書工作流程

Zimbra 目前的技術中心頁面指出，在 Zimbra 8.7 及更高版本中，該服務zmcertmgr以使用者身分運作zimbra。頁面還說明，商業私鑰必須commercial.key在配置中指定名稱/opt/zimbra/ssl/zimbra/commercial，並且伺服器憑證和 CA 鏈檔案應在部署前暫存在臨時目錄中。

第一步：備份現有憑證材料

不要一開始就刪除現有的 SSL 目錄。請先建立一個備份，以便在新部署失敗時可以還原。以下是一個保守的範例（以 root 使用者身分）：

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

在變更憑證之前，請記錄目前已部署的憑證：

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

這樣可以為您提供更改後的基準進行比較。如果您的環境中有多個 Zimbra 節點，請擷取每個相關伺服器上的目前憑證狀態，而不是假設它們完全相同。

步驟 2：產生包含實際所需主機名稱的 CSR

對於新的商業證書，請使用生產主機名稱和任何其他SAN建立CSR。 Zimbra文件中記錄了以下語法：

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

如果使用者也透過其他名稱（例如 `example.com`）連接，webmail.example.com請在要求憑證時將其包含在 SAN 清單中。現代 TLS 用戶端會根據 SAN 驗證主機名，因此即使僅憑通用名稱看起來正確的證書，如果缺少主機名，瀏覽器仍可能發出警告。

在將 CSR 發送給證書頒發機構之前，請先仔細檢查 CSR：

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

檢查點：如果請求的 DNS 名稱錯誤，請在此處停止。如果先頒發了證書，之後才發現缺少 SAN，通常需要 CA 重新頒發證書。

步驟 3：收集伺服器憑證和完整的 CA 鏈

驗證完成後，您的商業 CA 通常會傳回伺服器憑證以及一個或多個中間憑證。 Zimbra 官方的單節點商業憑證流程要求伺服器憑證採用 PEM 格式，並指示管理員將中間憑證和根 CA 憑證合併到一個憑證連結檔中。

典型的舞台佈置佈置如下：

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

然後按照 Zimbra 文件中記錄的順序建立鏈條：

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

請使用憑證授權單位提供的與您的憑證產品完全相符的文件。不要因為憑證授權單位名稱相似就從其他無關教學複製中間憑證。憑證授權單位的層級結構會隨時間變化，使用錯誤的中間憑證是導致憑證失效的常見原因unable to get local issuer certificate。

步驟 4：部署前驗證私鑰、伺服器憑證和憑證鏈

這是最重要的安全關卡。請在目前 Zimbra 版本上以 Zimbra 使用者身分執行文件中記錄的驗證指令：

su - zimbra
/opt/zimbra/bin/zmcertmgr verifycrt comm \
/opt/zimbra/ssl/zimbra/commercial/commercial.key \
/tmp/commercial.crt \
/tmp/ca_chain.crt

驗證成功後，報表會顯示憑證和私鑰匹配，並且憑證有效。 Zimbra 的憑證工具文件解釋說，該驗證verifycrt結合了金鑰檢查和憑證鏈檢查。

如果驗證失敗，請根據錯誤選擇相應的修復方案。

• 憑證與私鑰不符： CA 憑證並非由與目前帳戶關聯的 CSR 頒發commercial.key。請恢復正確的金鑰或使用新的 CSR 重新頒發憑證。
• 無法驗證憑證鏈：中間/根憑證包不完整、順序錯誤、已過期，或不是此伺服器憑證的正確憑證鏈。請從頒發憑證的 CA 取得正確的憑證鏈。
• 憑證已過期：請勿部署。請申請有效證書，並檢查證書鏈中的中間證書或根證書是否已過期。 Zimbra 在其過期根 CA 故障排除指南中記錄了此故障模式。
• 主機名稱缺失：驗證結果可能與瀏覽器執行的主機名稱檢查不完全一致。請檢查已核發的 SAN，如果公有名稱不存在，請重新核發。

步驟 5：部署商業證書

只有在驗證成功後才能部署：

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

Zimbra 的部署流程記錄了將商業憑證複製到其 SSL 區域、附加 CA 鏈、更新憑證設定以及為 MTA、LDAP、代理程式和郵件元件元件等服務安裝憑證資料（如適用於伺服器）。

除非您所用 Zimbra 版本的特定文件明確要求，否則請勿手動覆寫隨機的 Java 金鑰庫或服務憑證檔案。這樣做的目的zmcertmgr是為了保持特定服務的憑證資料的一致性。

步驟 6：重啟 Zimbra 服務

部署完成後，重新啟動 Zimbra：

su - zimbra
zmcontrol restart

然後檢查服務狀態：

zmcontrol status

如果服務沒有恢復正常Running，請在宣布證書變更完成之前進行調查。憑證問題可能會影響 LDAP、代理程式、郵箱或其他依賴 TLS 的通信，尤其是在多節點部署中。

步驟 7：驗證 Zimbra 和客戶端的結果

請先使用 Zimbra 隨附的憑證檢視：

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

您也可以檢查已部署的服務憑證是否即將過期：

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

最後，測試使用者實際開啟的公共主機名稱。以下是一個從另一台機器進行 OpenSSL 檢查的有效方法：

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

尋找預期的葉子憑證、正確的主機名稱、完整的憑證鏈以及成功的驗證結果。然後在目前瀏覽器中開啟相同的 HTTPS URL。瀏覽器測試很重要，因為它測試的是使用者實際存取的主機名，而不僅僅是磁碟上的憑證檔案。

當標準程序不足以應對時

如果符合以下任何條件，請變更方法，而不是強制執行單節點步驟：

• 多節點 Zimbra：憑證部署可能需要覆寫不同主機上的代理程式、郵件信箱、LDAP 和 MTA 角色。 Zimbra 的憑證工具支援多伺服器選項，但請在使用前驗證是否適用於您的拓撲結構。
• 反向代理程式或外部負載平衡器終止 TLS 連線：可能還需要在該裝置上安裝公鑰憑證。如果上游 TLS 連線終止，僅憑正確的 Zimbra 憑證無法改變用戶端看到的內容。
• 您正在匯入現有金鑰：請確保將其放置在 Zimbra 期望商業私鑰的位置，並在驗證之前確保權限符合版本要求。
• 您的 CA 僅提供中間憑證套件：請遵循 CA 目前的憑證鏈說明，而不是自行建立根憑證。 Zimbra 需要一個可以驗證的憑證鏈；具體文件取決於頒發機構。
• 憑證續期時使用了相同的主機名，但金鑰不同：請在驗證前更新符合的私鑰。先前的憑證commercial.key無法驗證為新金鑰對所頒發的憑證。

最終自檢

只有當以下所有條件都滿足時，安裝才算完成：verifycrt透過、deploycrt成功、Zimbra 服務返回運作狀態、viewdeployedcrt顯示新證書，並且到真實主機名稱的外部 TLS 連線收到相同的有效證書，而沒有信任或主機名稱警告。

有關指令語法和特定版本行為，請主要參考Zimbra官方憑證工具文件mail.example.com。此處的範例使用佔位符；請將名稱、憑證檔案和組織詳細資​​訊取代為您環境中頒發的實際值。