修正 SSL 續期後 Zimbra 管理控制台 404 未找到錯誤

以下僅為範例，並非真實事件： Jordan 管理著一台虛構的 Zimbra 伺服器mail.example.com。在續訂 SSL/TLS 憑證後，Jordan 開啟一個已儲存的管理控制台書籤，卻看到「404 Not Found」頁面。憑證續約可能與此有關，但 404 錯誤本身並不能證明憑證無效。該位址可能存取了錯誤的連接埠、代理程式、主機名稱或 URL 路由。

在本例中，Jordan 建議最穩健的順序是：首先確認預期的管理控制台 URL，然後分別測試直接端點和代理端點，檢查 Zimbra 服務狀態和已部署的證書，最後僅在有證據表明需要重新部署或重啟元件時才進行操作。請務必遵循您安裝版本特定的說明：Zimbra 連接埠和憑證流程可能因版本而異，並且取決於伺服器使用的是 Zimbra Proxy、獨立的負載平衡器還是外部反向代理。

SSL憑證續期後出現404錯誤代表什麼？

瀏覽器明確傳回的 HTTP 404 回應通常表示 HTTP 伺服器回應了請求，但沒有找到符合的資源或路由。因此，主機名稱、連接埠、URL 路徑、虛擬主機和代理路由都是重要的檢查項目。這與瀏覽器憑證警告或 TLS 握手失敗不同。然而，反向代理或 Web 應用防火牆本身在主機或路由不符時也可能傳回 404 回應，因此僅憑狀態碼無法確定是哪一層造成的。

7071Zimbra 文件預設使用 TCP 連接埠直接存取管理控制台。如果配置了 Zimbra Proxy 來代理管理控制台，其預設代理連接埠為9071；此連接埠為可選，可自訂。標準 Webmail 位址（連接埠）443與直接存取管理控制台的端點並不完全相同。請對照Zimbra 管理控制台 URL 指南和Zimbra 連接埠參考文檔，檢查您的配置是否正確。

應該如何排查錯誤？

1. 確認管理員控制台的準確地址

請使用部署中配置的主機名稱和端口，不要假設您的 Webmail URL 就是管理控制台 URL。對於典型的直接連接，Zimbra 文件中給出了一個格式https://server.example.com:7071為 `<hostname>/<port>/ https://proxy.example.com:9071.../admin

瀏覽器網址列顯示虛構的 Zimbra 管理控制台直接位址 mail.example.com，連接埠為 7071 — 範例：瀏覽器指向虛構伺服器的直接管理控制台連接埠 7071。

瀏覽器網址列顯示虛構的 Zimbra 代理管理控制台主機，連接埠為 9071 — 範例：連接埠 9071 顯示為單獨的代理路由，僅在設定了管理控制台代理時使用。

在 Jordan 的假設案例中，舊書籤指向的是 443 連接埠上的公共 Webmail 主機名稱。 Jordan 會將其與文件中記錄或配置的管理端點進行比較。 Webmail 主機傳回 404 錯誤並不表示 Zimbra 管理控制臺本身已關閉。如果 7071 連接埠被有意地從公共互聯網屏蔽，則只能在授權網路或本地進行測試；切勿為了測試而將其公開。 Zimbra 的代理指南建議，當管理員使用代理端點時，應限制對 7071 連接埠的直接存取。

2. 比較直接路由和代理路由

每次測試一條路由，確保使用正確的主機名稱、協定和連接埠。如果從允許的網路直接存取 7071 連接埠有效，但透過 9071 連接埠的代理路由傳回 404 錯誤，請專注於檢查代理程式的管理控制台設定和主機名稱路由。如果直接存取也失敗，則檢查郵件伺服器及其管理控制台服務部署的憑證。如果 Zimbra 的兩個路由都有效，但公用 URL 仍傳回 404 錯誤，則檢查 Zimbra 前端的外部負載平衡器、反向代理、CDN 或 Web 應用防火牆。

請將此比較結果用作診斷工具，而非啟用新網路存取的命令。被阻止的直接連接埠可能是出於安全控制的考慮。 Zimbra 的管理控制台代理設定指南介紹了可選的 9071 監聽器，並指出郵件伺服器的管理控制台通常保留在 7071 連接埠上。

3. 檢查 Zimbra 服務和代理日誌

使用與您的安裝相對應的管理員帳戶登入 Zimbra 主機，然後檢查服務狀態。以下狀態指令為唯讀指令：

su - zimbra
zmcontrol status
zmproxyctl status

zmcontrol status報告 Zimbra 組件狀態。zmproxyctl status當安裝了 Zimbra Proxy 時非常有用；如果該命令不可用或您的拓撲中沒有 Zimbra Proxy，請跳過此步驟並檢查實際提供 URL 服務的元件。郵箱或代理程式元件停止運作可能會導致路由失敗，但不要因為一個 URL 傳回 404 就重啟整個伺服器。

使用唯讀指令 zmcontrol status 和 zmproxyctl status 的終端 — 請先檢查服務狀態；所示指令為診斷指令，不會修改伺服器。

對於代理請求，Zimbra 會識別出/opt/zimbra/log/nginx.access.log有用/opt/zimbra/log/nginx.log的代理程式日誌。請將請求時間和請求的主機/路徑與日誌中記錄的回應進行比較。如果該請求從未出現在 Zimbra 的代理程式日誌中，則 404 錯誤可能來自上游負載平衡器或其他前端服務。請參閱Zimbra 代理指南及其故障排除部分。

4. 驗證每個端點提供的憑證。

磁碟上續訂的憑證不一定與每個 Zimbra 服務目前載入的憑證相同。請在 Zimbra 主機上執行憑證管理員的部署憑證檢查，並使用您已安裝版本支援的語法：

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

終端機顯示 Zimbra 指令 zmcertmgr viewdeployedcrt，用於檢查已部署的憑證。 — 使用 Zimbra 的憑證管理員檢查為本機服務（包括代理程式和郵件信箱服務，如有）安裝的憑證。

檢查處理故障路由的服務的憑證詳細信息，包括有效期和主機名稱或主題備用名稱。如果瀏覽器透過外部 TLS 終止器存取 443 端口，也請檢查該終止器的憑證和路由配置；Zimbra 可能並非提供該公鑰憑證的元件。在多伺服器部署中，請檢查相關的代理節點和郵箱節點。 Zimbra 會報告viewdeployedcrt本機伺服器，因此檢查節點並不能證明每個節點都擁有已更新的憑證。

如果已部署正確的證書，但僅出現 HTTP 404 錯誤，請繼續排查路徑和代理路由問題，而不是重複續訂證書。如果已部署的憑證過期、無效或與私鑰或憑證鏈不匹配，請依照適用於您 Zimbra 版本的憑證部署路徑進行操作。

5. 僅當檢查顯示需要時才重新部署證書

在更改憑證之前，請確認您擁有相符的私鑰、已更新的伺服器憑證以及來自憑證提供者的完整 CA 鏈。請妥善保管私鑰。在 Jordan 的範例中，檔案名稱分別為 `<filename>` commercial.key、commercial.crt`<filename>` 和ca_chain.crt`<filename>`；請替換為您伺服器上的實際路徑。以下檔案名稱僅為範例，並非 Zimbra 自動建立的檔案。

檔案管理器顯示範例 Zimbra 憑證檔案：commercial.crt、commercial.key 和 ca_chain.crt — 憑證包元件範例：伺服器憑證、相符的私鑰和 CA 鏈。

對於商業證書，Zimbra 文件會在部署前驗證證書是否與金鑰和金鑰鏈相符。請根據您的路徑和版本所需的使用者權限調整命令：

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

Zimbra 商業證書驗證指令的終端語法預覽 — 部署前請先驗證憑證、金鑰和金鑰鏈；此圖僅顯示指令前綴，未顯示已完成的檢查。

僅當驗證輸出確認金鑰匹配且憑證鏈有效時才繼續。如果驗證失敗，請停止並修正金鑰、憑證或中間憑證鏈。切勿部署不符的憑證來嘗試修復 404 錯誤。

驗證成功後，文件中記錄的商業證書部署模式為：

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

Zimbra 商業憑證部署指令的終端語法預覽 — 僅在驗證成功後部署；顯示的命令前綴僅供參考，並非已完成的部署。

這些命令並非通用的續期指南。 Zimbra 的憑證文件包含特定版本的權限說明，多節點部署要求在處理相關流量的節點上安裝並驗證憑證。請查閱管理控制台和 CLI 憑證工具，對於基於 Let's Encrypt 的設置，請查閱最新的Zimbra Let's Encrypt 憑證說明。切勿在未與您已安裝的版本進行比對的情況下，請從舊版本複製指令。

6. 重新啟動受影響的服務，然後測試兩個端點。

Zimbra 的憑證部署說明要求重新啟動服務以載入新憑證。請選擇您的拓撲和版本支援的最窄範圍重啟。如果只需要重新載入 Zimbra 代理憑證或產生的代理程式配置，則代理服務指令為：

zmproxyctl restart

終端機顯示 Zimbra 代理程式重啟指令 zmproxyctl restart — 只有當代理程式是受影響的元件且重啟代理程式對您的部署來說是合適的時，才重新啟動代理程式。

完全zmcontrol restart重新啟動會影響該主機上的 Zimbra 服務，並可能中斷郵件存取。請在維護視窗期間，當您的版本憑證部署流程需要時使用此功能，並為每個受影響的節點做好規劃。 Zimbra 的憑證指南在其單一伺服器商業憑證流程中記錄了完全重新啟動服務的操作；其代理指南解釋了代理重新啟動會在重新啟動代理之前重新產生代理程式配置。請勿自動運行這兩種重啟路徑。

選定的服務恢復後，再次測試相同的 URL：首先測試來自授權網路的預期直接或代理管理控制台位址，然後測試公用或負載平衡 URL。確認預期的登入頁面載入正常，瀏覽器顯示主機名稱的更新證書，且相關日誌不再顯示該要求的路由或上游錯誤。在 Jordan 的虛構範例中，檢查的是已儲存的書籤現在是否指向已配置的端點，而不是是否達到了預設的測試結果。

何時應該在 Zimbra 之外進行調查？

如果 Zimbra 的直接端點和配置的代理端點都能正確回應，但公用 URL 仍傳回 404 錯誤，則故障可能出在外部前端或其虛擬主機規則上。請檢查反向代理程式的上游主機名稱和連接埠、TLS 終止設定、轉送的主機頭以及 URL 重寫規則。如果公共憑證在 Zimbra 外部終止，則僅續訂 Zimbra 的內部憑證不會更新該外部監聽器。

對於 Zimbra Proxy 提供的回應，請將時間戳記和狀態nginx.access.log與日誌中的詳細資訊進行比較nginx.log。如果回應未出現在這些日誌中，請檢查外部代理程式或負載平衡器。避免直接編輯產生的 Zimbra NGINX 檔案；Zimbra 的代理服務會在重新啟動時重新產生其配置，因此持久性變更應遵循已安裝版本支援的代理程式配置方法。