如何在 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 產生的 CSR 建立新證書	產生 CSR`zmcertmgr`並保留產生的 CSR。`commercial.key`	最簡單的金鑰匹配方式，但私鑰仍然與此 Zimbra 安裝綁定。
由現有私鑰頒發的憑證	部署前請確認該金鑰是 Zimbra 將使用的金鑰。	對遷移很有用，但創建鍵不匹配更容易。
單節點 Zimbra	驗證並本地部署，然後重啟	簡單明了，只有一個維護視窗。
多節點 Zimbra	按節點規劃憑證放置和部署，或使用 Zimbra 支援的多伺服器選項	需要加強協調；不要假設單節點流程可以涵蓋所有角色。

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

終端範例展示如何建立 Zimbra 商業憑證簽署要求以及產生的 commercial.csr 和 commercial.key 檔案。 — 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。

終端機範例展示了 Zimbra 系統中中間憑證和根憑證合併到 ca_chain.crt 檔案中的情況。 — CA 鏈階段將頒發中間憑證和根憑證合併到 Zimbra 與伺服器憑證一起驗證的連結檔中。

步驟 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結合了金鑰檢查和憑證鏈檢查。

終端機範例顯示 zmcertmgr verifycrt 指令正在檢查 Zimbra 商業私鑰、伺服器憑證和 CA 鏈。 — 在部署任何憑證之前，驗證階段應該確認金鑰與憑證的匹配情況以及 CA 鏈。

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

憑證與私鑰不符： 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 的通信，尤其是在多節點部署中。

終端範例展示了 Zimbra 商業憑證的部署、Zimbra 重新啟動以及 viewdeployedcrt 的輸出。 — 伺服器端的最後一個階段部署已驗證的證書，重新啟動 Zimbra，並檢查報告的證書`viewdeployedcrt`。

步驟 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無法驗證為新金鑰對所頒發的憑證。