カスタムポートでのKopano SSLハンドシェイクエラーを修正する

成功した修復とはどのようなものかを定義する

Kopano SSLハンドシェイクエラーとは、クライアントとサーバーがTLS接続について合意できなかった、または接続を完了できなかったことを意味します。カスタムポートは、設定の一部では正しくても、別の部分では間違っている可能性があります。証明書やプロトコル設定を変更する前に、どのサービスがそのポートを所有しているか、またそのポートでTLSが想定されているかどうかを確認してください。

正常に動作する構成では、指定されたポートがTLS接続を受け入れ、クライアントが使用するホスト名に対して有効な証明書を提示し、次のプロトコルステップの完了を許可します。ブラウザは証明書の警告なしにWebAppのサインインページに到達できるはずです。Kopano Coreクライアントは、一致するTLSポートと、設定されている場合はその信頼できるクライアント証明書を使用して接続する必要があります。TLSプローブが成功しただけでは、WebAppログイン、Kopano認証、またはメール配信が正常に機能していることは証明されません。

まず、2つの共通ポート設定を分離します。

Kopano Core で検証済み: Kopano の Core 管理者マニュアル 8.0 では、によって制御されるネイティブ TLS リスナーについて説明していますserver_listen_tls。この例ではポート 237 を使用し、ポートは変更可能であると述べ、証明書と CA ファイルを に設定します/etc/kopano/server.cfg。マニュアルでは、クライアントが一致するポートとクライアント証明書を使用してサーバー ソケットを使用する様子も示しています。Kopano Core: SSL 接続と証明書、およびKopano Core の特別な構成をhttps://参照してください。

また、WebAppへのアクセスについては、通常、ユーザーはApache、Nginx、またはKopano Webによって提供されるブラウザのURLを開きます。TLSは、リクエストをKopanoサービスに転送する間、そのフロントエンドサーバーで終了することができます。Kopanoのマニュアルでは、ポート236でCoreリスナーへのHTTPプロキシについて説明されており、Kopano WebガイドではTLS証明書の設定/etc/kopano/kwebd.cfgについて説明されています。このフロントエンドHTTPSポートは、Core TLSポートと自動的に同じではありません。Coreリバースプロキシの例とKopano Webインストールガイドを確認してください。

対処方法：クライアントURL、カスタムポート、そこでリッスンする予定のプロセス、TLSがプロキシで終了するのかKopano Coreで終了するのかをメモしてください。両方のリスナーを同時に変更しないでください。

1. カスタムポートで何がリッスンしているかを確認する

Kopanoホスト上で、8443以下の行を障害が発生しているポート番号に置き換えてください。

sudo ss -ltnp | grep ':8443'

一致する行には、リスニングソケットが表示されます。行がない場合、サービスはそのポートにバインドされていないか、別のアドレスにバインドされています。ポートがローカルリバースプロキシに属している場合は、プロキシの仮想ホストを調べます。Kopano Core のネイティブ TLS ポートであるべき場合は、server_listen_tlsで調べます/etc/kopano/server.cfg。のみでリスニングしているプロセスは、127.0.0.1リモート接続を直接受け入れることはできません。これは、プロキシが前面にある場合、意図的な動作である可能性があります。

ホストファイアウォール、クラウドファイアウォール、ロードバランサー、NATルールも確認してください。パブリックポートは、意図した内部リスナーに到達できる必要があります。タイムアウトや接続拒否は、到達可能性またはリスナーの設定の問題を示しており、それ自体が証明書の不正を示すものではありません。

2. 正確なホスト名とポートでTLSをプローブする

クライアントマシンから、OpenSSLを使用してパブリックエンドポイントをテストします。証明書に記載されているDNS名を使用し、無関係なIPアドレスは使用しないでください。

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

提示された証明書、ネゴシエートされたプロトコルと暗号、および検証エラーを確認します。この-servernameオプションはTLS SNIホスト名を送信します。これは、サーバーが複数のTLSサイトをホストしている場合に重要です。OpenSSLのs_clientマニュアルには、これらのオプションに関する説明があります。Ctrl+Cを押して対話型プローブを終了します。

証明書が存在しない場合、エンドポイントがプレーンなHTTP通信を行っているか、ポートを所有しているサービスが間違っているか、プロキシが誤ったアップストリームに転送している可能性があります。証明書は存在するものの、その名前、発行者、または有効期限が間違っている場合は、TLSエンドポイントの証明書の選択またはチェーンを修正してください。ホスト名の不一致は、Kopano Coreリスナーポートを変更しても解決しません。

ブラウザ向けエンドポイントの場合は、以下に従ってください。

curl -v https://mail.example.com:8443/webapp/

詳細な出力は、TLS 検証とリダイレクト、404 エラー、502 エラーなどの HTTP レスポンスを区別するのに役立ちます。ハンドシェイクが完了した後に 404 エラーが発生した場合は、TLS ネゴシエーションの失敗ではなく、パスまたはルーティングの問題です。curl -vk証明書検証をバイパスすると結果が変わるかどうかは、一度限りの診断としてのみ確認できます。ブラウザ、クライアント、プロキシで証明書チェックを無効にしないでください。

重要な制限事項： Kopano CoreのネイティブTLSはクライアント証明書を使用できます。TLSs_clientリスナーが正しく動作している場合でも、クライアント証明書を使用しない基本的なテストは拒否される可能性があります。サーバーがクライアント認証を要求する場合は、承認済みのクライアント証明書とキーを使用してテストを繰り返すか、設定済みのKopanoサービスクライアントを使用してテストしてください。コマンドの記録やサポートチケットに秘密鍵を記載しないでください。

3. プロトコルをリスナーに合わせる

カスタムポート設定でよくある間違いは、HTTPSクライアントを通常のHTTPリスナーに接続するように設定したり、HTTPトラフィックをHTTPを期待するアップストリームに転送したりすることです。スキームとポートは同じエンドポイントを記述する必要があります。

• https://mail.example.com:8443/webapp/これは、ブラウザがポート8443でTLS接続を期待していることを意味します。
• Kopano Core のドキュメントに記載されている例では、プロキシ経由の HTTP を に送信します127.0.0.1:236。デプロイメントでこのパターンを使用する場合、パブリック ブラウザー接続では HTTPS が使用される場合でも、プロキシ アップストリームは を使用する必要がありますhttp://。
• Kopano Core TLS のネイティブ機能の場合、マニュアルの例でserver_listen_tls = *:237は、 と で始まるクライアント URLを使用していますhttps://。237 をカスタム ポートに変更する場合は、依存するすべてのクライアントまたはプロキシを同じ値に更新してください。

ポート番号やスキームに関して矛盾する設定行がないか確認してください。マルチサーバー構成の場合は、公開されているサーバーまたはプロキシのURLも確認してください。クライアントは最初の接続を完了した後、Kopanoが古いホスト名やポート番号にリダイレクトした際に接続に失敗する可能性があります。

4. リスナーと証明書の構成を修復する

これがKopano CoreのネイティブTLSリスナーである場合は、重複するディレクティブを追加するのではなく、既存の設定を編集してください。以下はカスタムポートの簡略化された例です。証明書のパスとCAは、ご使用のインストール環境に合わせて変更してください。

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

Kopanoのマニュアルには、リスナー、CA、サーバーキー、キーパスの設定方法が記載されており、kopano-serverこのネイティブリスナーの変更後には再起動が必要です。インストールされているバージョンが上記のオプションをサポートしていることを確認してください。パッケージのレイアウトや指示は異なる場合があります。キーディレクトリを保護し、Kopanoサービスアカウントが必要なファイルを読み取れることを確認してください。

証明書がクライアントが実際に使用するホスト名に対応していること、有効期限内であること、および必要な中間証明書がすべて含まれていることを確認してください。Kopano のマニュアルには、コンポーネントが証明書の共通名とサブジェクト代替名をチェックすると記載されています。マルチサーバー TLS 設定では、サーバーはクライアント証明書に署名した認証局 (CA) を信頼する必要があり、承認済みクライアント証明書を設定する必要があります。公開ブラウザ サービスへのショートカットとして、証明書を自己署名証明書に置き換えないでください。

TLSがApache、Nginx、またはKopano Webで終端する場合は、代わりにそのフロントエンドで証明書とカスタムlistenポートを設定してください。次に、バックエンドの実際のリスナーに応じてアップストリームのスキームとポートを設定します。パブリック側がHTTPSを使用しているという理由だけでアップストリームTLSを有効にしないでください。まず、バックエンドのポートもTLSを提供していることを確認してください。

5. 正しいサービスを検証して再読み込みする

ウェブサーバーをリロードする前に、sudo nginx -tNginxやsudo apachectl configtestApacheなどの設定チェックを実行してください。テストでエラーが報告された場合は、リロードする前に修正してください。ディストリビューションにインストールされているサービス名を使用してください。例：

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

Kopano Core の設定を変更した場合にのみ再起動してください。フロントエンドのみのポートまたは証明書の変更の場合は、フロントエンド サービスを検証してリロードしてください。変更後すぐにジャーナルまたはエラー ログを確認し、クライアント ネットワークから OpenSSL プローブを再度実行してください。ハンドシェイクで期待どおりの証明書が表示されるはずです。TLS の成功だけではアプリケーションのルーティングや認証が検証されたとは限らないため、実際の WebApp URL または Kopano クライアント接続をテストしてください。

変更を加える前に結果を確認してください

• リスニングソケットがありません。設定されているリスナー、サービスの状態、およびバインドアドレスを確認してください。
• 接続が拒否されたかタイムアウトしました。ファイアウォール、NAT、ロードバランサー、およびターゲットポートに到達可能かどうかを確認してください。
• 証明書が間違っています。そのポートに応答するエンドポイントに設定されている証明書（SNI選択と証明書チェーンを含む）を確認してください。
• TLSはローカルでは機能しますが、リモートでは機能しません。パブリックプロキシまたはロードバランサーのパスをローカルリスナーと比較し、転送されたホストとポートの値を確認してください。
• ハンドシェイクは成功したが、Webアプリケーションが失敗した場合： HTTPステータス、プロキシパス、PHP/Webアプリケーションのログ、およびKopano Coreの接続状況を確認してください。アプリケーション層で処理を続行してください。
• Coreクライアントのみが失敗します。server_socketカスタムポート、信頼済みCA、およびクライアント証明書の設定を確認してください。Core TLSパスでは、相互証明書認証が必要になる場合があります。

確実な修正方法は、ハンドシェイクに失敗したエンドポイントのみを変更することです。この手順で使用できるKopano Core管理者マニュアルはバージョン8.0.0であり、その例はインストールされているパッケージとローカルのマニュアルページと照らし合わせて確認してください。デプロイメントで別のKopanoリリース、コンテナ、またはマネージドリバースプロキシを使用している場合は、サンプルディレクティブを適用する前に、そのコンポーネントの現在の構成を確認してください。