Cisco ESAでのTLS証明書の確認とトラブルシューティング

はじめに

このドキュメントでは、Cisco Eメールセキュリティアプライアンス(ESA)でTLS証明書を作成、設定、およびトラブルシューティングする方法について説明します。

前提条件

要　件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

バックグラウンド情報

ESAのTLS実装は、暗号化を介した電子メールのポイントツーポイント送信にプライバシーを提供します。この実装により、管理者は認証局(CA)サービスから証明書と秘密キーをインポートしたり、自己署名証明書を使用したりできます。

Cisco AsyncOS for Email Securityは、シンプルメール転送プロトコル(SMTP)（セキュアSMTP over TLS）へのSTARTTLS拡張をサポートしています。

注：このドキュメントでは、ESAの集中管理機能を使用して、証明書をクラスタレベルでインストールする方法について説明します。証明書はマシンレベルで適用できますが、マシンをクラスタから削除してから再度追加すると、マシンレベルの証明書は失われます。

機能の概要と要件

管理者は、次のいずれかの理由でアプライアンス上の証明書を使用できます。

• TLSを使用する他のMTAとのSMTP通信（着信と発信の両方の通信）を暗号化します。
• アプライアンスでHTTPSサービスを有効にして、HTTPS経由でGUIにアクセスできるようにします。
• Lightweight Directory Access Protocol(LDAP)のクライアント証明書として使用するために、LDAPサーバでクライアント証明書が必要な場合。
• アプライアンスとCisco Advanced Malware Protection(AMP)Threat Gridアプライアンスの間でセキュアな通信を可能にする。

ESAには、TLS接続の確立に使用できるデモンストレーション証明書が事前設定されています。

注意：セキュアTLS接続を確立するにはデモ証明書で十分ですが、検証可能な接続は提供できないことに注意してください。X.509またはプライバシー強化メール(PEM)証明書をCAから取得することをお勧めします。

証明書の設定と割り当て

続行する前に、『ユーザガイド』に記載されている証明書の作成および割り当ての手順を完了してください。必要な手順については、次のリンクを参照してください。

• 署名付き証明書の展開
• 証明書の割り当て

確認

HTTPSのTLSの確認

1. GUIにアクセスします。HTTPS URLを使用してESAデバイスに移動します(例：https://esa.example.com)。

2.証明書の詳細を開く：ブラウザのアドレスバーのURLの左側にあるサイト情報アイコン（通常は南京錠）をクリックします。

3. ブラウザに基づいて検証します。

     a. Google Chrome:南京錠アイコン> 接続は保護されています> 証明書は有効ですをクリックします。

     b. Microsoft Edge:フライアウトの右上の南京錠アイコン> 接続はセキュリティで保護されています> 証明書アイコンをクリックします。

     c. Mozilla Firefox:南京錠のアイコンをクリックし> 接続のセキュリティをクリックし> 詳細情報をクリックし> 証明書を表示します。

4. 有効性の確認：証明書ビューアで「有効期間」または「ステータス」を確認します。証明書にasValidと表示されている場合、接続は安全であり、証明書はブラウザで正しく認識されます。

電子メールの配信または受信のTLSの確認

GUIのメッセージトラッキングがこの情報を提供しますが、一括レビューや迅速なトラブルシューティングを行うには、コマンドラインインターフェイス(CLI)を使用する方が効率的な場合が多くあります。

CLIを使用してTLSステータスを確認するには、次の手順に従います。

1. CLIにログインします。管理資格情報を使用して、SSH経由でアプライアンスにアクセスします。
2. Grepコマンドを実行します。greputilityを使用して、TLS関連のアクティビティのメールログをフィルタリングします。
3. 接続IDの分析：接続タイプに基づいて出力を確認します。
   • ICID（着信接続ID）:これらのエントリを確認して、リスナーで受信される接続のTLSを確認します。
   • DCID（配信接続ID）:これらのエントリを確認して、ネクストホップMTAに配信される接続のTLSを確認します。

注:「TLS success」や「TLS failed」などの特定の文字列を検索して、結果を絞り込むことができます。

メール受信時のTLS成功例

(Machine esa.example.com)> grep "ICID.*TLS failed" mail_logs
Sat Feb 14 19:20:28 2026 Info: ICID 111396123 TLS failed: [Errno 0] Error
Sat Feb 14 19:20:28 2026 Info: ICID 111396456 TLS failed: ('SSL routines:tls_early_post_process_client_hello:no shared cipher')

メール受信時のTLS障害例

(Machine esa.example.com)> grep "ICID.*TLS success" mail_logs
Sat Feb 14 19:14:38 2026 Info: ICID 111395123 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384
Sat Feb 14 19:14:41 2026 Info: ICID 111395456 TLS success protocol TLSv1.3 cipher TLS_AES_256_GCM_SHA384

メール配信時のTLS成功例

(Machine esa.example.com)> grep "DCID.*TLS success" mail_logs

Sat Feb 14 19:12:56 2026 Info: DCID 21966123 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384 the.cpq.host
Sat Feb 14 19:13:00 2026 Info: DCID 21966456 TLS success protocol TLSv1.3 cipher TLS_AES_256_GCM_SHA384

メール配信時のTLS障害の例

(Machine esa.example.com)> grep "DCID.*TLS failed" mail_logs

Sat Feb 14 19:58:43 2026 Info: DCID 21967123 TLS failed: TLS required, STARTTLS unavailable, destination is TLS disabled
Sat Feb 14 20:58:44 2026 Info: DCID 21967456 TLS failed: TLS required, STARTTLS unavailable, destination is TLS disabled

LDAPのTLSの確認

ldap_debugログには特定のTLS文字列は表示されませんが、LDAP応答と使用中のポートを調べることによって、TLSが成功したか失敗したかを確認できます。LDAPS接続の場合、通常はActive Directoryのポート3269またはOpenLDAPのポート636を意味します。

LDAPのTLSの例

(Machine esa.example.com) (SERVICE)> tail ldap_debug

Wed Feb 25 03:24:23 2026 Debug: LDAP: (group) Query (proxyAddresses=smtp:user@example.com) to server LDAP (ldaps-esa.example.com:3269)
Wed Feb 25 03:24:23 2026 Debug: LDAP: (group) Query (proxyAddresses=smtp:user@example.com) lookup success, (ldaps-esa.example.com:3269) returned 0 results timestamp=1771989863.189580

注:LDAPトラフィックとTLSアクティビティの詳細な分析については、関連するホストとポートでネットワークパケットをキャプチャすることをお勧めします。

トラブルシュート

このセクションでは、ESAの基本的なTLSの問題をトラブルシューティングする方法について説明します。

中間証明書の確認

特に、新しい証明書を作成する代わりに現在の証明書が更新される場合は、重複する中間証明書を探します。中間証明書は変更されたり、不適切にチェーン化されたりすることがあり、証明書は複数の中間証明書をアップロードできます。これにより、証明書チェーンと検証の問題が発生する可能性があります。

必要なTLS接続失敗の通知を有効にする

TLS接続を必要とするドメインにメッセージが配信されるときにTLSネゴシエーションが失敗した場合にアラートを送信するように、ESAを設定できます。アラートメッセージには、失敗したTLSネゴシエーションの宛先ドメインの名前が含まれています。システムアラートタイプの警告重大度レベルのアラートを受信するように設定されているすべての受信者にアラートメッセージが送信されます。

注：これはグローバルな設定なので、ドメイン単位では設定できません。

TLS接続アラートを有効にするには、次の手順を実行します。

1. Mail Policies > Destination Controlsの順に移動します。
2. [Edit Global Settings] をクリックします。
3. Send an alert when a required TLS connection failsチェックボックスにチェックマークを付けます。

ヒント：この設定は、CLIコマンドdestconfig > setupで設定することもできます。

また、ESAは、ドメインにTLSが必要だがアプライアンスmail_logsで使用できなかったインスタンスのログも記録します。これは、次のいずれかの条件が満たされた場合に発生します。

• リモートMTAはESMTPをサポートしていません（たとえば、ESAからのEHLOコマンドを認識していません）。
• リモートMTAはESMTPをサポートしますが、STARTTLSコマンドがEHLO応答でアドバタイズされた内線番号のリストに含まれていません。
• リモートMTAはSTARTTLS拡張をアドバタイズしましたが、ESAがSTARTTLSコマンドを送信したときにエラーで応答しました。

サードパーティ製ツールを使用したトラブルシューティング

• テストを開始する前に、アプライアンスが受信メールを受信するリスナーで証明書が適用されていることを確認してください。

CheckTLS.comやSSL-Tools.netなどのサードパーティツールを使用して、受信時に証明書のチェーンが正しいことを確認できます。証明書の検証方法については、各ツールのドキュメントを参照してください。

注：自己署名証明書が使用されている場合は、エラーが発生することが予想されます。

解決策

CA署名付き証明書が使用中でTLS検証が失敗する場合は、次の項目が一致していることを確認します。

• 証明書の共通名
• Hostname(GUI > Network > Interfaceで)
• MXレコードホスト名：これはTestReceiverテーブルのMX Server列です。

関連情報

• Cisco E メール セキュリティ アプライアンス：エンドユーザ ガイド