SSL更新後にZimbra管理コンソールで発生する404 Not Foundエラーを修正する

実例ではなく、説明のための例です。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​​を返すことがあるため、ステータスだけではどのレイヤーが原因かを特定することはできません。

Zimbra では、デフォルトでは TCP ポートで直接管理コンソールが使用されると規定されています7071。Zimbra Proxy が管理コンソールをプロキシするように設定されている場合、そのデフォルトのプロキシ ポートは です9071。これはオプションであり、カスタマイズ可能です。ポート の標準ウェブメール アドレスは、直接管理コンソールと同じエンドポイントとは必ずしも一致しません。Zimbra管理コンソールの URL に関するガイダンスとZimbra のポート参照を、ご自身の設定と照らし合わせて443確認してください。

エラーのトラブルシューティングはどのように行えばよいでしょうか？

1. 管理コンソールの正確なアドレスを確認してください。

ウェブメールの URL が管理コンソールの URL と同じであると想定するのではなく、デプロイメント用に構成されたホスト名とポートを使用してください。一般的な直接接続の場合、Zimbra は の形式の URL をドキュメントに記載していますhttps://server.example.com:7071。コンソールで Zimbra プロキシを有効にしている管理者は、代わりにプロキシのホスト名とポート（通常は ）を使用する場合がありますhttps://proxy.example.com:9071。想定されるパスを追加しないでください/admin。インストールまたは管理者向けドキュメントで指定されているアドレスを使用してください。

ジョーダンの仮説的なケースでは、古いブックマークはポート443のパブリックWebメールホスト名を指しています。ジョーダンはそれを、文書化または設定されている管理エンドポイントと比較します。Webメールホストで404エラーが発生したとしても、Zimbraの管理コンソール自体がダウンしているとは限りません。ポート7071が意図的にパブリックインターネットからブロックされている場合は、承認されたネットワークまたはローカルからのみテストしてください。テストのためだけに公開しないでください。Zimbraのプロキシに関するガイダンスでは、管理者がプロキシエンドポイントを使用する場合、7071への直接アクセスを制限することを推奨しています。

2. 直接経路とプロキシ経路を比較する

正しいホスト名、スキーム、ポートを使用して、一度に 1 つのルートをテストします。許可されたネットワークから 7071 への直接アクセスが機能するが、9071 のプロキシ ルートが 404 を返す場合は、プロキシの管理コンソール構成とホスト名ルーティングに注目してください。直接ルートも失敗する場合は、メールボックス サーバーと、その管理コンソール サービスに展開されている証明書を確認してください。Zimbra のルートが両方とも機能するが、パブリック URL が依然として 404 を返す場合は、Zimbra の前にある外部ロード バランサー、リバース プロキシ、CDN、または Web アプリケーション ファイアウォールを調査してください。

この比較は診断ツールとして使用し、新しいネットワークアクセスを有効にするためのコマンドとして使用しないでください。直接ポートがブロックされている場合は、意図的なセキュリティ制御である可能性があります。Zimbraの管理コンソールプロキシ設定ガイドでは、オプションの9071リスナーについて説明しており、メールボックスサーバーの管理コンソールは通常7071番ポートを使用していることを明記しています。

3. Zimbraサービスとプロキシログを確認する

インストール環境に適した管理者アカウントを使用してZimbraホストにログインし、サービスの状態を確認してください。以下のステータスコマンドは読み取り専用です。

su - zimbra
zmcontrol status
zmproxyctl status

zmcontrol statusZimbraコンポーネントの状態を報告します。Zimbrazmproxyctl statusプロキシがインストールされている場合に便利です。コマンドが利用できない場合、またはトポロジにZimbraプロキシがない場合は、スキップして、URLを処理している実際のコンポーネントを確認してください。停止したメールボックスまたはプロキシコンポーネントがルートの失敗の原因となる可能性がありますが、1つのURLが404を返すという理由だけでサーバー全体を再起動しないでください。

プロキシ経由のリクエストの場合、Zimbra は/opt/zimbra/log/nginx.access.logと を/opt/zimbra/log/nginx.log有用なプロキシログとして識別します。リクエスト時刻とリクエストされたホスト/パスを、そこに記録されたレスポンスと比較してください。リクエストが Zimbra のプロキシログに表示されない場合は、404 エラーは上流のロードバランサーまたは別のフロントエンドサービスから発生している可能性があります。Zimbra プロキシガイドのトラブルシューティングセクションを参照してください。

4. 各エンドポイントが提示する証明書を確認する

ディスク上で更新された証明書は、必ずしも現在すべての Zimbra サービスに読み込まれている証明書と同じとは限りません。Zimbra ホストから、インストールされているリリースでサポートされている構文を使用して、証明書マネージャの deployed-certificate check を実行してください。

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

障害が発生したルートを処理するサービスの証明書の詳細（有効期限、ホスト名またはサブジェクト代替名など）を確認してください。ブラウザが外部TLSターミネータ経由でポート443にアクセスする場合は、その証明書とルーティング構成も確認してください。Zimbraがその公開証明書を提示しているコンポーネントではない可能性があります。マルチサーバー構成の場合は、関連するプロキシノードとメールボックスノードを確認してください。Zimbraはviewdeployedcrtローカルサーバーを報告するため、1つのノードをチェックしただけでは、すべてのノードに更新された証明書が備わっているとは限りません。

正しい証明書がデプロイされており、唯一の症状がHTTP 404エラーである場合は、証明書を繰り返し更新するのではなく、パスとプロキシルーティングの調査を続けてください。デプロイされた証明書が期限切れ、無効、または秘密鍵や証明書チェーンと一致しない場合は、ご使​​用のZimbraのバージョンに応じた証明書のデプロイ手順に従ってください。

5. 証明書の再デプロイは、チェックの結果、必要であることが示された場合にのみ行う。

証明書を変更する前に、プロバイダーから提供された、一致する秘密鍵、更新されたサーバー証明書、および完全な CA チェーンが揃っていることを確認してください。秘密鍵は保護してください。ジョーダンの架空の例では、ファイル名はcommercial.key、、、commercial.crtおよびとca_chain.crtなっています。実際のパスは、サーバー上に置き換えてください。以下のファイル名は例であり、Zimbra が自動的に作成するファイルではありません。

商用証明書の場合、Zimbraのドキュメントでは、デプロイ前に証明書が鍵とチェーンと一致していることを確認するよう指示されています。コマンドを、ご使用のリリースに必要なパスとユーザー権限に合わせて調整してください。

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

検証結果で鍵が一致し、証明書チェーンが有効であることが確認された場合にのみ、処理を進めてください。検証に失敗した場合は、処理を停止し、鍵、証明書、または中間チェーンを修正してください。404エラーが解消されるかどうかを確認するために、不一致の証明書をデプロイしないでください。

検証が成功した場合、文書化された商用証明書の展開パターンは次のとおりです。

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

これらのコマンドは、普遍的な更新手順ではありません。Zimbraの証明書に関するドキュメントには、リリース固有の権限に関する注記があり、マルチノード展開では、関連するトラフィックを処理するノードに証明書をインストールして検証する必要があります。管理コンソールとCLI証明書ツール、およびLet's Encryptベースの設定の場合は、最新のZimbra Let's Encrypt証明書手順を確認してください。古いリリースからコマンドをコピーする場合は、インストール済みのビルドと照合して確認してください。

6. 影響を受けているサービスを再起動し、両方のエンドポイントをテストします。

Zimbraの証明書展開に関する注意事項では、新しい証明書を読み込むためにサービスを再起動する必要があるとされています。トポロジとリリースでサポートされている最も限定的な再起動方法を選択してください。Zimbraプロキシ証明書または生成されたプロキシ構成のみを再読み込みする必要がある場合は、プロキシサービスコマンドは次のとおりです。

zmproxyctl restart

フルzmcontrol restart再起動は、そのホスト上の Zimbra サービスに影響を与え、メール アクセスを中断する可能性があります。お使いのバージョンの証明書展開手順で必要な場合に、メンテナンス ウィンドウで実行し、影響を受けるすべてのノードについて計画を立ててください。Zimbra の証明書ガイドには、シングル サーバー商用証明書フローにおけるフル サービス再起動について記載されています。プロキシ ガイドでは、プロキシ再起動はプロキシを再度起動する前にプロキシ構成を再生成すると説明されています。両方の再起動パスを自動的に実行しないでください。

選択したサービスが復旧したら、同じ URL を再度テストします。まず、認証済みネットワークから、意図した直接またはプロキシの管理コンソール アドレスにアクセスし、次に、パブリック URL またはロードバランシングされた URL にアクセスします。期待どおりのログイン ページが読み込まれ、ブラウザーがホスト名の更新された証明書を表示し、関連するログにそのリクエストのルート エラーやアップストリーム エラーが表示されていないことを確認します。ジョーダンの架空の例では、保存されたブックマークが構成済みのエンドポイントをターゲットにしているかどうかをチェックしており、架空のテスト結果が得られたかどうかをチェックしているわけではありません。

Zimbra以外の調査を行うべきタイミングはいつですか？

Zimbraの直接エンドポイントと設定済みのプロキシエンドポイントの両方が正しく応答しているにもかかわらず、公開URLが404エラーを返す場合は、外部フロントエンドまたはその仮想ホストルールに問題がある可能性があります。リバースプロキシのアップストリームホスト名とポート、TLS終端設定、転送ホストヘッダー、およびURL書き換えルールを確認してください。公開証明書がZimbraの外部で終端されている場合、Zimbraの内部証明書のみを更新しても、その外部リスナーは更新されません。

Zimbra Proxy から返された応答については、タイムスタンプとステータスをnginx.access.logの詳細と比較してくださいnginx.log。これらのログに応答がない場合は、外部プロキシまたはロードバランサーを調べてください。生成された Zimbra NGINX ファイルを直接編集することは避けてください。Zimbra のプロキシ サービスは再起動時に構成を再生成するため、永続的な変更はインストールされているバージョンでサポートされているプロキシ構成方法に従って行う必要があります。

修理が完了したことをどのように確認するのですか？

• ブックマークは、設定されたホスト名、スキーム、ポート、およびルートを使用します。
• 意図した管理コンソールエンドポイントは、認証されたネットワークから応答します。意図的にブロックされた直接ポートは、引き続きブロックされます。
• Zimbraの関連サービスは正常に稼働しており、デプロイされた証明書はホスト名と現在の有効期間と一致しています。
• プロキシまたは外部フロントエンドは、404エラーではなく、期待される管理コンソールページを返します。
• ログには、リクエストが想定されたコンポーネントに到達したこと、および他のノードが古い証明書を提示していないことが示されています。

このガイドの作成にあたって参照したZimbraの公式ドキュメントでは、7071がデフォルトの直接管理コンソールポート、9071がオプションのプロキシ管理コンソールポートとして指定されています。404エラーは様々なレイヤーで発生する可能性があるため、これらのデフォルト値は診断の手がかりとして利用し、ご使用のZimbraのバージョンとトポロジーにおける実際の値を確認してください。

公式資料

• Zimbra管理コンソール
• Zimbraポート
• 管理コンソールプロキシを有効にする
• Zimbraプロキシガイド
• 管理コンソールとCLI証明書ツール
• Let's Encrypt SSL証明書のインストール