Zimbraの「TLSを開始できません：SSLハンドシェイクに失敗しました」エラーを修正する方法

このメッセージは、Unable to start TLS: SSL handshake failedクライアントとサーバーが暗号化接続を開始するためのネゴシエーションを完了できなかったことを意味します。Zimbraでは、このメッセージはさまざまな場所から発生する可能性があります。よくあるバリエーションとして、zmcontrol statusLDAPマスターへの接続で証明書の検証に失敗したというメッセージが表示されることがあります。メールクライアントやSMTPリレーも、パブリックメールポートでのハンドシェイクの問題を報告する場合があります。

解決策は、どの接続が失敗したかによって異なります。まず、ログの該当行からサービス名とホスト名を特定してください。次に、証明書、その発行チェーン、システムクロック、およびTLSエンドポイントを確認します。最初の対応としてTLSを無効にすることは避けてください。症状を隠蔽するだけでなく、メールサーバーと内部の通信を弱めたり、切断したりする可能性があります。

変更を加える前に知っておくべきこと

TLSは、ネットワーク接続を暗号化するプロトコルです。TLSハンドシェイクとは、2つのシステムが暗号化パラメータについて合意し、サーバー証明書を検証する最初のやり取りのことです。STARTTLSは、最初は通常のプロトコル接続として開始し、両側から要求があった場合にTLSに切り替わります。LDAPとSMTPはどちらもSTARTTLSを使用できるため、このエラーだけでは障害が発生しているサービスを特定することはできません。

修復コマンドを実行する前に、Zimbraのバージョン、インストールがシングルノードかマルチノードか、エラーが発生した正確なコマンドまたはクライアント、およびその前後のログ行全体を記録してください。証明書の展開やサービスの再起動は、メンテナンス期間中にスケジュールしてください。証明書ファイルと構成を編集する前に、バックアップを作成してください。

• 管理者コマンドは、お使いのZimbraのリリースで必要とされるアカウントと権限で実行してください。
• チケットや公開フォーラムに、秘密鍵、パスワード、または編集されていないメールログを貼り付けないでください。
• どのエンドポイントで障害が発生したかを特定し、その証明書を確認するまでは、LDAPのセキュリティフラグやプロトコル設定を変更しないでください。

ステップ1：TLS接続の失敗箇所を特定する

まず、問題を再現し、メッセージ全文を確認してください。Zimbraがサービスステータスを確認した際にメッセージが表示され、などの文言が含まれている場合はwhen connecting to ldap master、内部LDAP TLSを調査してください。メールクライアントのみがSMTP送信で失敗する場合は、公開SMTPエンドポイントとクライアントのホスト名、ポート、暗号化モードを調査してください。

su - zimbra
zmcontrol status

同じタイムスタンプの最近の Zimbra ログエントリを確認してください。多くのインストール環境では、メインログは にあります/var/log/zimbra.log。サーバーで設定されているログの場所を使用してください。

grep -Ei 'Unable to start TLS|SSL handshake|certificate|ldap|STARTTLS' /var/log/zimbra.log | tail -n 80

プロセス名、リモートホスト、ポート、および証明書の検証失敗、証明書の有効期限切れ、不明な発行者、プロトコルアラートなど、OpenSSLに関するより詳細な情報を確認してください。これらの情報によって、証明書の信頼性の問題とネットワークまたはプロトコルの不一致を区別できます。

内部LDAPエラーが発生した場合は、このサーバーが使用するように設定されているLDAPホストを確認してください。ローカル構成キーを個別に照会し、ホスト名をDNSおよびサーバー証明書と比較してください。

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required

キーの可用性と出力は、Zimbra のバージョンとノードの役割によって異なる場合があります。これらは診断用の読み取り値です。出力に表示されているからといって値を変更しないでください。Zimbra のドキュメントでは、LDAP STARTTLS 設定の役割について説明し、内部 TLS を有効にしておくことを推奨しています。Zimbra TLS および STARTTLS のローカル構成値を参照してください。

ステップ2：システムクロック、DNS、および接続可能性を確認する

証明書の検証はサーバーの時計に依存します。時計が大幅に遅れていたり進んでいたりすると、有効な証明書でも無効または期限切れと表示されることがあります。Zimbraホスト、および接続に関与するすべてのLDAPマスターまたはレプリカの時刻を確認してください。

date -u
getent hosts ldap.example.com

設定ファイルまたはログに記載されている LDAP ホスト名に置き換えてくださいldap.example.com。ホスト名が想定されるサーバー アドレスに解決され、設定された LDAP ポートがホスト ファイアウォールとネットワーク経由で到達可能であることを確認してください。マルチノード構成の場合は、ワークステーションからだけでなく、障害が発生した Zimbra ノードから実際の LDAP ノードへの接続テストを行ってください。

クライアント側のSMTP STARTTLS接続の場合、ZimbraのSMTPトラブルシューティングガイドでは、OpenSSLを使用してポート25をテストする方法が示されています。ポート587も、STARTTLSを使用したメッセージ送信によく使用されます。メールクライアントで設定されているホスト名とポートを使用してください。

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -showcerts

ポート25のSMTPの場合は、587を に置き換えてください25。ポート465は暗黙のTLSを使用するため、そのポートをテストするときは を追加しないでください-starttls smtp。TCP接続が成功したとしても、それだけで証明書が信頼されていることやクライアントが正しいセキュリティモードを使用していることが証明されるわけではありません。ZimbraのSMTPおよびOpenSSLトラブルシューティングガイドを参照してください。

ステップ3：Zimbraが実際にデプロイした証明書を検査する

証明書は、サーバーの署名付き身分証明書です。証明書は、クライアントが使用するホスト名に対して有効であり、有効期限内であり、接続コンポーネントが信頼する認証局に紐づいている必要があります。ブラウザ上では正しく見える証明書でも、LDAP、Postfix、またはプロキシノードに別の証明書が展開されている場合があります。

Zimbra管理者として、Zimbraがデプロイ済みと報告する証明書を確認します。

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

リストされている各証明書のサブジェクトまたはサブジェクト代替名（SAN）、発行者、有効期限、およびサービスを確認してください。SANには、LDAPまたはメール接続に実際に使用されるホスト名が含まれている必要があります。また、マルチサーバー展開のすべてのノードに、期待される証明書と証明書チェーンが設定されていることを確認してください。Zimbraでは、展開された証明書の表示はサーバーローカルで行われるため、関連する各ノードでチェックを実行してください。

ソース証明書ファイルをお持ちの場合は、デプロイ前に日付とファイル名を確認してください。

openssl x509 -in /tmp/commercial.crt -noout -dates -subject -issuer -ext subjectAltName

例示されているパスを、評価対象の証明書ファイルのパスに置き換えてください。SANの欠落、リーフ証明書または中間証明書の有効期限切れ、ホスト名の誤り、あるいは別のサーバー用に発行された証明書などが原因で、検証が失敗する場合があります。

ステップ4：秘密鍵と証明書チェーンを確認する

証明書チェーンとは、クライアントがサーバー証明書を信頼できる認証局まで遡って追跡できるようにする、発行者証明書の集合です。チェーンファイルに中間証明書が欠落している場合、または誤ったチェーンが含まれている場合、末端証明書が最新であっても、クライアントはサーバーを拒否する可能性があります。証明書と秘密鍵も一致している必要があります。

商用証明書の場合、Zimbraの証明書ツールには検証手順が用意されています。インストール環境と認証局に合わせてファイルパスを調整してください。

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

証明書と秘密鍵が一致し、証明書チェーンが有効であることが検証で確認された場合にのみ、先に進んでください。検証に失敗した証明書はデプロイしないでください。認証局から提供された中間チェーンと、ご使用の Zimbra バージョンで想定されているチェーン形式を使用してください。推測でチェーンを構築したり、無関係なルート証明書を追加したりしないでください。

Zimbraの証明書ガイドには、CAチェーンを含む検証と展開の手順が記載されています。Zimbra証明書のインストールとCLIツールをご覧ください。また、証明書チェーンのトラブルシューティングページでは、発行者チェーンの検証エラーについても説明しています。Zimbra証明書チェーンのガイダンスをご覧ください。

ステップ5：証明書を修正して安全に展開する

検証の結果、証明書の有効期限切れ、キーの誤り、中間証明書の欠落、ホスト名の不一致が判明した場合は、デプロイ前に正しいファイルを取得または生成してください。Zimbraのリリースと証明書の種類に応じた手順に従ってください。商用証明書の場合、ドキュメントに記載されているコマンドは一般的に次の形式になります。

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

インストールされているリリースのドキュメントに記載されているコマンド構文と権限を正確に使用してください。ZimbraのCLIは、MTA、LDAP、プロキシなどのコンポーネントの証明書をインストールできるため、展開によって複数のサービスに影響が出る可能性があります。マルチノード環境では、LDAPマスターを含むすべての関連サーバーに証明書が正しく展開されていることを確認してください。

検証済みのデプロイ後、リリース手順で必要な場合は、計画されたメンテナンス期間中にZimbraサービスを再起動し、サービスの状態とデプロイされた証明書を確認します。

su - zimbra
zmcontrol restart
zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

再起動すると、サービスが停止して復旧する間、メールとウェブへのアクセスが中断されます。負荷の高い本番サーバーで安易に実行しないでください。Zimbra 証明書ガイドには、zmcontrol restartデプロイ後に使用して、で結果を確認する方法が記載されていますviewdeployedcrt。

ステップ6：TLSを無効にせずにLDAP信頼構成を確認する

証明書自体は検証できるものの、ZimbraのLDAPクライアントがそれを拒否する場合は、LDAP信頼マテリアルと障害が発生しているノードを調べてください。ZimbraのアーカイブされたMTAトラブルシューティングノートには、無効なCAチェーン、期限切れのCA証明書、予期しないファイルなどが、/opt/zimbra/conf/caLDAP STARTTLSの失敗の可能性のある原因として挙げられています。これは診断の手がかりとして扱い、ファイルを削除する理由にはしないでください。ディレクトリを既知の正常なバックアップまたはバージョン固有のガイダンスと比較し、変更を加える前にその内容を保存してください。

単純なLDAP STARTTLSプローブの場合、OpenLDAPクライアントはStartTLSを要求し、アカウント認証情報を提供することなくルートDSEにクエリを実行できます。

ldapsearch -x -ZZ -H ldap://ldap.example.com:389 -b "" -s base namingContexts

デプロイメントでは、実際の LDAP ホストとポートを使用してください。OpenLDAP ツールでは、-ZZStartTLS を要求し、確立に失敗するとエラーとして処理します。このプローブが信頼または証明書のメッセージで失敗した場合は、LDAP エンドポイントから返された証明書を、デプロイ済みの証明書およびクライアントが利用できる CA 信頼と比較してください。あるノードではテストが成功するのに、別のノードでは失敗する場合は、DNS、CA ファイル、またはローカル構成の違いを調査してください。

ステップ7：証明書のチェックが完了した後にのみ、プロトコルの互換性を検討する。

クライアントとサーバーがTLSプロトコルバージョンまたは暗号スイートについて合意できない場合にも、ハンドシェイクが失敗する可能性があります。これは、古いクライアント、カスタムのセキュリティ強化、またはバージョン固有のデフォルト設定で発生する可能性があります。最新のOpenSSLクライアントを使用してエンドポイントをテストし、ZimbraのTLS設定で正確な製品バージョンを確認してください。アーカイブされたページから古いプロトコルコマンドを新しいインストールにコピーすることは避けてください。暗号とプロトコルの設定はリリース間で変更される可能性があります。

SSLv3を有効にしたり、検証を弱めたり、LDAP STARTTLSをグローバルに無効にしたりしてエラーを「修正」しないでください。Zimbraフォーラムのスレッドには、LDAP STARTTLSを無効にするという過去の回避策が記載されていますが、別の回答者が、セキュリティ機能を無効にすることは適切な証明書の修復方法ではないと正しく警告しています。Zimbraのローカル構成に関する注記では、プロセス間TLSとLDAP STARTTLSを有効にしたままにしておくことを推奨しています。このような変更は、Zimbraサポートから指示があった場合にのみ、厳密に管理された一時的な診断手段として使用し、安全な設定を直ちに復元してください。

修理を確認する方法

• zmcontrol statusLDAP TLS エラーが発生しなかった場合、そのエラーなしで処理が完了します。
• 影響を受けるLDAPまたはSMTPエンドポイントは、期待どおりの有効期限内の証明書と完全な発行者チェーンを提示します。
• 同一ホストおよび同一ネットワークパスからのテストは、意図したTLSモードで成功しました。
• Zimbraのログには、テスト時に証明書の検証エラーやハンドシェイクエラーが表示されなくなりました。
• SMTPの場合は、双方向でテストメッセージを送信し、関連するキューまたはログで配信を確認してください。

問題が解決しない場合は、エラーメッセージ全文、Zimbraのリリース情報、影響を受けるサービスとホスト名、証明書の日付とSAN、検証出力、および関連するログ行を収集してください。共有する前に、秘密鍵、認証情報、ユーザーアドレス、および機密性の高いホストの詳細を削除してください。正確なメッセージは症状を示すものであり、完全な診断ではありません。適切な修復方法は、サービス名とOpenSSLのエラー理由に基づいて判断してください。

ドキュメントに関する注記： Zimbraの公開証明書およびTLSページには複数のリリースに関する情報が含まれており、一部のトラブルシューティングページは明示的にアーカイブされています。ここに記載されているコマンドは、ドキュメントに記載されているCLIパターンを反映していますが、証明書のパス、権限、および再起動要件については、インストールされているZimbraバージョンのドキュメントを参照してください。2026年10月6日レビュー済み。