ZimbraプロキシサーバーでHTTPSリダイレクトを有効にする方法

Zimbraのプロキシ属性を使用してzimbraReverseProxyMailMode、WebリクエストをHTTPからHTTPSにリダイレクトします。すべてのZimbraプロキシノードでこの属性を有効にしredirect、プロキシサービスを再起動して、HTTPレスポンスにLocation: https://...ヘッダーが含まれていることを確認してください。この操作を行う前に、公開されているHTTPSホスト名が既にプロキシまたはロードバランサーに解決され、有効な証明書が提示されていることを確認してください。

この設定は、Zimbraプロキシ経由でのWebアクセス用です。この設定自体では、メールストアのHTTPS構成、証明書のインストール、すべてのメールアプリケーションがリダイレクトに従うことの保証は行われません。HTTPリクエストを完全に拒否する必要がある場合は、リダイレクトではなくHTTPS専用プロキシモードを検討してください。

mail.example.comが2つのZimbraプロキシノードを指し、それらがメールボックスサーバーに接続する様子を示す図。
トポロジーの例:パブリックメールのホスト名は、リクエストがメールボックスサーバーに渡される前にプロキシ層に到達します。

デプロイメントに適した動作を選択してください

プロキシメールモードHTTPはどうなるのかいつ使うべきか
redirectプロキシはHTTP 302レスポンスを返し、クライアントをHTTPSに誘導します。ユーザーがHTTP URLを入力し、それを安全なWebアドレスに送信する必要がある場合に便利です。
httpsプロキシはWebクライアントにHTTPS経由で接続を提供しますが、HTTPからHTTPSへのリダイレクトフローは提供しません。クライアントがHTTP経由でセッションを開始すべきでない場合は、こちらを推奨します。
bothまたはmixedこれらは、HTTP/HTTPSの動作が異なる、別々のプロキシモードです。デプロイメントで文書化された動作が具体的に必要な場合にのみ使用してください。HTTPリダイレクトが強制されると想定しないでください。

Zimbraのセキュリティガイドラインでは、ActiveSyncクライアントを含む一部のクライアントはHTTPリダイレクトを尊重せず、最初の暗号化されていないリクエストで認証情報を送信する可能性があると警告しています。そのため、リダイレクトはブラウザの利便性を高めるのに役立ちますが、すべてのクライアントがHTTPを回避する必要があるHTTPS専用アクセスに代わるものではありません。リダイレクトモードを選択する場合は、ネットワークエッジのHTTPリスナーを適切に保護し、HTTPS URLをユーザーに通知してください。

ブラウザウィンドウに、鍵アイコンが表示されたhttps://mail.example.comのZimbra Web Clientサインインページが表示されています。
プロキシの動作を変更する前に、公開されているウェブメールのホスト名がHTTPS経由で開き、信頼できる鍵マークが表示されていることを確認してください。

プロキシを変更する前に

  • 適用範囲を確認してください。この手順は、Zimbra Proxy が処理する Web トラフィックを変更します。導入環境では、プロキシ サービスが既に有効化され、正常に動作している必要があります。
  • 公開エンドポイントを確認してください。ユーザーがアクセスするホスト名(例:)は、mail.example.com公開プロキシまたはロードバランサーに解決される必要があります。HTTPSは、想定されるホスト名とポートで既に正常に動作している必要があります。
  • 証明書を確認してください。ユーザーをリダイレクトする前に、公開ホスト名の証明書チェーンをインストールして検証してください。証明書が破損しているか、一致していない状態でHTTPSにリダイレクトしても、エラーが次のリクエストに持ち越されるだけです。
  • すべてのプロキシノードを特定してください。ロードバランシング環境では、各プロキシサーバーのZimbraサーバー名をメモしておいてください。あるプロキシに適用された変更は、他のプロキシに自動的に反映されません。
  • 必要に応じてメンテナンス期間を計画してください。プロキシサービスを再起動すると、そのノードを経由する接続が一時的に中断される場合があります。冗長構成の場合は、変更をノードごとに適用し、サービスの状態を監視してください。

以下の管理コマンドには、Zimbraアカウントを使用してください。proxy1.example.comプロキシノードのZimbraサーバー名を正確に置き換え、mail.example.com公開ウェブメールのホスト名に置き換えてください。サンプル名をそのまま本番システムに貼り付けないでください。

HTTPからHTTPSへのリダイレクトを有効にする

1. 現在のプロキシモードを記録する

コマンドラインツールが利用可能なZimbraホストで、プロキシの現在の設定を照会します。

zmprov gs proxy1.example.com zimbraReverseProxyMailMode

変更後の出力を記録しておけば、変更後と比較したり、必要に応じて以前のモードに戻したりできます。このgsコマンドはサーバー属性を読み取りms、以下で使用するコマンドはそれらを変更します。

proxy1.example.com に対して zimbraReverseProxyMailMode を照会し、現在の値として https を表示するターミナルウィンドウの例。
このサンプルコマンドは、1つのプロキシノードの現在のメールモードを読み取ります。お使いのサーバーでは異なる値が表示される場合があります。

2. プロキシモードをリダイレクトに設定します

プロキシサーバーオブジェクトに属性を設定します。

zmprov ms proxy1.example.com zimbraReverseProxyMailMode redirect

Zimbra Proxyの設定ドキュメントでは、redirectHTTPリクエストをHTTPSにリダイレクトするモードとして、この設定が示されています。パブリックWebトラフィックを受け入れる各プロキシノードに同じコマンドを適用してください。ロードバランサーがHTTPリクエストを複数のプロキシに送信できる場合、対象となるすべてのプロキシで一貫した動作が求められます。

この設定を と混同しないでくださいzimbraMailMode。Zimbra では、メールボックス サーバー接続用に属性を個別に指定しています。メールストア モードを変更しても、プロキシ上でブラウザ向けの HTTP リダイレクトが有効になるわけではありません。

zimbraReverseProxyMailMode を設定して proxy1.example.com にリダイレクトするターミナルコマンドの例。
プロキシのメールモードを に設定しますredirect。マルチノード展開の場合は、各プロキシサーバー名に対してこの手順を繰り返します。

3. 各プロキシに変更を適用する

設定を変更したノードでプロキシサービスを再起動してください。

zmproxyctl restart

次に、サービスの状態を確認します。

zmproxyctl status

冗長構成の場合は、プロキシノードごとに再起動を実行してください。環境によっては、構成キャッシュの更新やサービスオーケストレーションの手順が定められている場合がありますので、その場合は、インストールされている Zimbra のバージョンの運用ガイドに従ってください。生成された Nginx ファイルを直接編集することは避けてください。Zimbra はサーバー設定からプロキシ構成を管理しており、手動で編集すると上書きされる可能性があります。

これらの例では、Zimbra Daffodil v10 管理者ガイドと Zimbra が公開しているプロキシ/セキュリティ関連のドキュメントを使用しています。古い ZCS リリースでは、パッケージやサポートされる手順が異なる場合があるため、変更を適用する前に、ご使用の環境にインストールされているリリースの正確なバージョンについて管理者ガイドをご確認ください。

Zimbraの設定キャッシュの更新とそれに続くzmproxyctlの再起動を示す、ターミナルでの一連の動作例。
設定データを更新し、プロキシを再起動する操作手順の例を以下に示します。お使いのインストール済みリリースでサポートされている手順に従ってください。

リダイレクトとHTTPS応答を確認する

4. HTTPレスポンスヘッダーを確認する

公開エンドポイントにアクセスできるシステムから、リダイレクトを経由せずにHTTP URLをリクエストする。

curl -sS -D - -o /dev/null http://mail.example.com/

リダイレクトモードでは、302 レスポンスと、Location値が で始まるヘッダーを探してくださいhttps://mail.example.com/。正確なヘッダーとステータス処理は、Zimbra のリリース、パス、およびプロキシの前にあるロードバランサーや Web ゲートウェイによって異なる場合があります。次の画面は、想定されるヘッダーパターンを示す例であり、実際のサーバーからキャプチャしたテストではありません。

HTTPリクエストのターミナル出力例。302 Foundと、https://mail.example.com/を指すLocationヘッダーが表示されます。
想定されるリダイレクトパターン:HTTPは302レスポンスを返し、ブラウザをHTTPSホスト名に誘導します。実際のレスポンスヘッダーと日付は異なる場合があります。

5. HTTPSと証明書を確認する

セキュアなURLに別途リクエストを送信してください。

curl -sS -D - -o /dev/null https://mail.example.com/

ホスト名に対してTLS証明書が検証され、応答が期待どおりのWebメールページまたはアプリケーションのリダイレクトであることを確認してください。curl -k証明書の検証を回避するために使用しないでください。これは、ユーザーが目にする証明書の問題を隠蔽します。ログインページは、製品のバージョンと認証フローによっては、リダイレクトまたは200以外のステータスを返す場合があります。そのため、ブラウザのチェックと併せて応答を判断してください。

mail.example.com に対する HTTPS リクエストのターミナル出力例。HTTP レスポンスが成功し、証明書が検証されたことを示しています。
この例では、ホスト名と一致する証明書を使用してHTTPS経由でサービスに到達する方法を示しています。エンドポイントで実際の証明書チェーンを確認してください。

6. ブラウザでテストする

新しいブラウザセッションで開いてくださいhttp://mail.example.com。認証情報を入力する前に、アドレスがHTTPS URLに変わるはずです。次に、HTTPS URLを直接開き、証明書の警告が表示されずにサインインページが読み込まれることを確認してください。パブリックDNS、ファイアウォールルール、またはロードバランサーによって結果が異なる可能性がある場合は、内部ネットワークの外部から同じ手順を繰り返してください。

アドレスバーにHTTPが表示されている間は、実際のパスワードを入力してテストしないでください。リダイレクトが失敗した場合は、まずプロキシ、エッジ、または証明書の設定を見直して修正してください。

Zimbra Web Clientのサインインページがブラウザに表示され、アドレスバーにはhttps://mail.example.comと鍵のアイコンが表示されています。
最終的なブラウザチェック:リダイレクト後、サインインページがHTTPSホスト名で表示されること。

トラブルシューティングのクイックリファレンス

症状チェックすべき事項
HTTPは同じURLにとどまりますzimbraReverseProxyMailModeリクエストを処理したプロキシに対してクエリを実行し、ロードバランスされたすべてのノードが意図した値を持ち、再起動されていることを確認します。
Locationヘッダーでホスト名またはポート番号が間違っています公開リンクの生成に使用される公開URL、リバースプロキシまたはロードバランサーのルール、およびZimbra公開サービスのホスト名/プロトコル/ポート設定を確認してください。
ブラウザが証明書の警告を報告します証明書がTLS終端点にインストールされ、公開ホスト名をカバーし、必要なチェーン証明書が含まれていることを確認してください。
ユーザーはリダイレクトループを目にするフロントエンドのロードバランサーがTLSを終端しつつHTTPをZimbraに転送しているかどうかを確認し、プロキシが外部リクエストプロトコルを正しく識別できることを確認してください。ネットワークエッジにおけるTLSと転送の設定を調整してください。
メールクライアントは依然としてHTTPを送信しますクライアントが302レスポンスに従うと想定しないでください。HTTP経由で認証情報を送信する必要のないクライアントには、HTTPSのみのアクセスを優先し、各クライアントにHTTPSサーバーのURLを設定してください。

導入チェックリスト

  • 公開されているHTTPS URLは、目的のプロキシまたはロードバランサーに解決されます。
  • TLS証明書は公開ホスト名に対して有効であり、クライアントから信頼されています。
  • zimbraReverseProxyMailModeredirect該当するすべてのプロキシノードで設定されます。
  • プロキシサービスは、インストールされているZimbraのリリース版の手順に従って再起動されました。
  • HTTPリクエストはHTTPSLocationヘッダーを返し、直接HTTPSリクエストを行うことで証明書の妥当性が検証されます。
  • ユーザーとメールクライアントはHTTPS用に設定されていますが、リダイレクトモードは、すべてのクライアントが最初の要求を保護することを保証するものではありません。

公式資料

コメントを残す

クライアントブラウザでのJitsi MeetにおけるCPU使用率の高さを修正する

クライアントブラウザでのJitsi MeetにおけるCPU使用率の高さを修正する

Jitsi MeetブラウザのCPUスパイクを診断し、ビデオタイル、カメラエフェクト、ブラウザグラフィック、ホスト設定をチェックすることで、クライアントの負荷を軽減します。

PrometheusとGrafanaを使用してJitsi Videobridgeのメトリクスを監視する方法

PrometheusとGrafanaを使用してJitsi Videobridgeのメトリクスを監視する方法

Jitsi Videobridgeに内蔵されたPrometheusエンドポイントを使用して、Jitsi Videobridgeの状態、会議の負荷、トラフィックを追跡し、Grafanaでデータを探索およびグラフ化できます。

Jitsi Meet Docker のカスタムドメイン名の設定方法

Jitsi Meet Docker のカスタムドメイン名の設定方法

Jitsi Meet Docker 用のカスタムドメインを、DNS、PUBLIC_URL、HTTPS、Let's Encrypt、ファイアウォールポート、NAT 設定、エンドツーエンド検証とともに構成します。

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

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

SSL更新後に発生するZimbra管理コンソールの404エラーを修正するには、正しいURLとポート、プロキシルーティング、サービスステータス、デプロイ済みの証明書、およびログを確認してください。

Nextcloudの「PHP OPcacheが正しく設定されていません」という警告を修正する

Nextcloudの「PHP OPcacheが正しく設定されていません」という警告を修正する

アクティブなPHP SAPI、サイズ制限、コメント、および再検証設定を確認することで、NextcloudのPHP OPcache構成警告を診断および修正する方法を学びましょう。

MySQLバージョンアップグレード後のKopanoデータベース移行エラーを修正する

MySQLバージョンアップグレード後のKopanoデータベース移行エラーを修正する

MySQLまたはMariaDBのアップグレード後にKopanoデータベースの移行が失敗した場合は、バックアップ、サーバーバージョン、SQLモード、文字セット、スキーマ状態、およびログを確認してトラブルシューティングを行います。

NextcloudでLDAPとActive Directory認証を設定する方法

NextcloudでLDAPとActive Directory認証を設定する方法

セキュアなトランスポート、ユーザーおよびグループフィルタ、ログイン属性、そしてテスト済みの展開機能を使用して、NextcloudをLDAPまたはActive Directoryに接続します。

GoogleサービスなしでElement Android通知を修正する方法:UnifiedPushガイド

GoogleサービスなしでElement Android通知を修正する方法:UnifiedPushガイド

UnifiedPush、Androidの権限設定、バッテリー設定、および信頼性の高い検証テストを設定することで、Googleサービスを削除した端末におけるElement Android通知の問題を修正します。

Nextcloudの「データベースに一部のインデックスが欠落しています」という警告を修正する

Nextcloudの「データベースに一部のインデックスが欠落しています」という警告を修正する

Nextcloudのデータベースインデックス不足警告を、公式のoccコマンドでクリアします。まずバックアップを作成し、変更内容をプレビューしてから修復を実行し、結果を確認してください。

Element WebでKeycloakを使用してシングルサインオン(SSO)を設定する方法

Element WebでKeycloakを使用してシングルサインオン(SSO)を設定する方法

Element Web 用の Keycloak SSO を設定するには、OIDC を Synapse に接続し、正確なコールバック URL を設定し、ユーザー クレームをマッピングし、ログアウトをテストします。