ESAでのTLS用の証明書セットアップガイドの作成

はじめに

このドキュメントでは、TLSで使用する証明書を作成し、着信/発信TLSをアクティブ化し、Cisco ESAの問題をトラブルシューティングする方法について説明します。

前提条件

要件

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

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

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

背景説明

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

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

ヒント:TLSの詳細については、RFC 3207を参照してください。

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

機能の概要と要件

管理者は、次のいずれかの理由で、アプライアンス上に自己署名証明書を作成する必要があります。

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

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

注意：セキュアTLS接続を確立するにはデモ証明書で十分ですが、検証可能な接続は提供できないことに注意してください。

CAからX.509またはプライバシー強化メール(PEM)証明書を取得することをお勧めします。これは、Apache証明書とも呼ばれます。自己署名証明書は、前述のデモンストレーション証明書に似ており、検証可能な接続を提供できないため、自己署名証明書よりもCAからの証明書が望ましいと言えます。

注:PEM証明書の形式は、RFC 1421 ～ RFC 1424でさらに定義されています。PEMは、公開キー、秘密キー、およびルート証明書を含めるために、公開証明書(ApacheインストールおよびCA証明書ファイル/etc/ssl/certsなど)または証明書チェーン全体を含むことができるコンテナ形式です。PEMという名前は、電子メールをセキュリティ保護するための方法として失敗したものです。しかし、この名前で使用されているコンテナフォーマットは引き続きアクティブであり、X.509 ASN.1キーの64進数への変換です。

個人証明書の持ち込み

独自の証明書をインポートするオプションはESAで使用できますが、要件は証明書がPKCS#12形式であることです。この形式には秘密キーが含まれます。管理者は、この形式で使用できる証明書を持っていないことがよくあります。このため、ESAで証明書を生成し、CAによって適切に署名することをお勧めします。

現在の証明書の更新

既存の証明書が期限切れになった場合は、このドキュメントの「自己署名証明書の展開」セクションをスキップして、既存の証明書に再署名します。

ヒント：詳細については、シスコのドキュメント『Renew a Certificate on an Email Security Appliance』を参照してください。

自己署名証明書の導入

このセクションでは、自己署名証明書と証明書署名要求(CSR)の生成、署名用のCAへの自己署名証明書の提供、署名付き証明書のESAへのアップロード、ESAサービスで使用する証明書の指定、アプライアンス設定と証明書のバックアップを行う方法について説明します。

自己署名証明書とCSRの生成

CLIを使用して自己署名証明書を作成するには、certconfigコマンドを入力します。

GUIから自己署名証明書を作成するには、次の手順を実行します。

1. アプライアンスのGUIから、Network > Certificates > Add Certificateの順に選択します。
   
   
2. Create Self-Signed Certificateドロップダウンメニューをクリックします。
   
   証明書を作成する際には、共通名がリスニングインターフェイスのホスト名と一致するか、または配信インターフェイスのホスト名と一致することを確認します。
   
   • listeningインターフェイスは、Network > Listenersで設定されたリスナーにリンクされたインターフェイスです。
   • CLIでdeliveryconfigコマンドを使用して明示的に設定されていない限り、deliveryインターフェイスは自動的に選択されます。
3. 検証可能なインバウンド接続の場合は、次の3つの項目が一致していることを検証します。
   
   
   • MXレコード(ドメインネームシステム(DNS)ホスト名)
     
     
   • 共通名
     
     
   • インターフェイスホスト名

注：システムホスト名は、検証可能であることに関してTLS接続に影響を与えません。システムホスト名は、アプライアンスGUIの右上隅、またはCLIのsethostnameコマンド出力に表示されます。

注意:CSRをエクスポートする前に、変更を送信し、確定することを忘れないでください。これらの手順が完了していない場合、新しい証明書はアプライアンス設定にコミットされず、CAからの署名付き証明書はすでに存在する証明書に署名できないか、またはそれに適用できません。

CAへの自己署名証明書の提供

自己署名証明書を署名のためにCAに送信するには、次の手順を実行します。

1. PEM形式でCSRをローカルコンピュータに保存します。Network > Certificates > Certificate Name > Download Certificate Signing Request。
   
   
2. 生成された証明書を署名用の認識されたCAに送信します。
   
   
3. X.509/PEM/Apache形式の証明書と中間証明書を要求します。

その後、CAはPEM形式で証明書を生成します。

注:CAプロバイダーのリストについては、Certificate authority Wikipediaの記事を参照してください。

署名付き証明書のESAへのアップロード

CAが秘密キーによって署名された信頼できる公開証明書を返した後、署名付き証明書をESAにアップロードします。

証明書は、パブリックまたはプライベートリスナー、IPインターフェイスHTTPSサービス、LDAPインターフェイス、または宛先ドメインへのすべてのアウトバウンドTLS接続で使用できます。

署名付き証明書をESAにアップロードするには、次の手順を実行します。

1. アプライアンスにアップロードする前に、受信した信頼できるパブリック証明書がPEM形式、またはPEMに変換可能な形式を使用していることを確認します。

   ヒント：フォーマットを変換するには、無料のソフトウェアプログラムであるOpenSSLツールキットを使用できます。

2. 署名付き証明書をアップロードします。
   
   
   1. Network > Certificatesの順に移動します。
      
      
   2. 署名のためにCAに送信された証明書の名前をクリックします。
      
      
   3. ローカルマシンまたはネットワークボリューム上のファイルへのパスを入力します。

注：新しい証明書をアップロードすると、現在の証明書が上書きされます。自己署名証明書に関連する中間証明書もアップロードできます。

注意：署名付き証明書をアップロードした後は、必ず送信し、変更をコミットしてください。

ESAサービスで使用する証明書の指定

これで、証明書が作成され、署名され、ESAにアップロードされたため、証明書の使用を必要とするサービスに使用できます。

インバウンド TLS

インバウンドTLSサービスに証明書を使用するには、次の手順を実行します。

1. Network > Listenersの順に移動します。
   
   
2. リスナー名をクリックします。
   
   
3. Certificateドロップダウンメニューから証明書名を選択します。
   
   
4. [Submit] をクリックします。
   
   
5. 必要に応じて、追加のリスナーに対してステップ1 ～ 4を繰り返します。
   
   
6. 変更を保存します。

アウトバウンド TLS

発信TLSサービスに証明書を使用するには、次の手順を実行します。

1. Mail Policies > Destination Controlsの順に移動します。
   
   
2. Global SettingsセクションでEdit Global Settings...をクリックします。
   
   
3. Certificateドロップダウンメニューから証明書名を選択します。
   
   
4. [Submit] をクリックします。
   
   
5. 変更を保存します。

HTTPS

HTTPSサービスに証明書を使用するには、次の手順を実行します。

1. Network > IP Interfacesの順に移動します。
   
   
2. インターフェイス名をクリックします。
   
   
3. HTTPS Certificateドロップダウンメニューから証明書名を選択します。
   
   
4. [Submit] をクリックします。
   
   
5. 必要に応じて、追加のインターフェイスに対してステップ1 ～ 4を繰り返します。
   
   
6. 変更を保存します。

LDAPS

LDAPに証明書を使用するには、次の手順を実行します。

1. System Administration > LDAPの順に移動します。
   
   
2. LDAP Global SettingsセクションでEdit Settings...をクリックします。
   
   
3. Certificateドロップダウンメニューから証明書名を選択します。
   
   
4. [Submit] をクリックします。
   
   
5. 変更を保存します。

URL フィルタリング

URLフィルタリングに証明書を使用するには、次の手順を実行します。

1. CLIにwebsecurityconfigコマンドを入力します。
   
   
2. コマンドプロンプトを実行します。次のプロンプトが表示されたら、必ずYを選択してください。
   
   

   Do you want to set client certificate for Cisco Web Security Services Authentication?

3. 証明書に関連付けられている番号を選択します。
   
   
4. commitコマンドを入力して、設定変更を確定します。

アプライアンスの設定と証明書のバックアップ

この時点でアプライアンス設定が保存されていることを確認します。アプライアンスの設定には、前述のプロセスで適用された完成した証明書作業が含まれます。

アプライアンス設定ファイルを保存するには、次の手順を実行します。

1. System Administration > Configuration File > Download file to local computerの順に移動して、表示または保存します。
   
   
2. 証明書をエクスポートします。
   
   
   1. Network > Certificatesの順に移動します。
      
      
   2. Export Certificateをクリックします。
      
      
   3. エクスポートする証明書を選択します。
      
      
   4. 証明書のファイル名を入力します。
      
      
   5. 証明書ファイルのパスワードを入力します。
      
      
   6. [Export] をクリックします。
      
      
   7. ファイルをローカルマシンまたはネットワークマシンに保存します。
      
      
   8. この時点で追加の証明書をエクスポートするか、CancelをクリックしてNetwork > Certificatesの場所に戻ることができます。

注：このプロセスでは、証明書をPKCS#12形式で保存します。これにより、ファイルが作成され、パスワードで保護された状態で保存されます。

インバウンドTLSの有効化

すべてのインバウンドセッションのTLSをアクティブにするには、Web GUIに接続し、設定されたインバウンドリスナーに対してMail Policies > Mail Flow Policiesの順に選択してから、次の手順を実行します。

1. ポリシーを変更する必要があるリスナーを選択します。
   
   
2. ポリシーを編集するには、ポリシーの名前のリンクをクリックします。
   
   
3. Security Featuresセクションで、次のEncryption and Authenticationオプションのいずれかを選択して、そのリスナーとメールフローポリシーに必要なTLSのレベルを設定します。
   
   
   • Off：このオプションを選択すると、TLSは使用されません。
     
     
   • Preferred：このオプションを選択すると、TLSはリモートMTAからESAにネゴシエートできます。ただし、(220応答の受信前に)リモートMTAがネゴシエートしない場合、SMTPトランザクションはクリア(暗号化されていない)で続行します。証明書が信頼できる認証局から発行されたかどうかを確認する試みは行われません。220応答の受信後にエラーが発生した場合、SMTPトランザクションはクリアテキストにフォールバックしません。
     
     
   • Required：このオプションを選択すると、リモートMTAからESAにTLSをネゴシエートできます。ドメインの証明書を確認する試みは行われません。ネゴシエーションに失敗すると、電子メールはその接続を介して送信されません。ネゴシエーションが成功すると、暗号化されたセッションを介してメールが配信されます。
4. [Submit] をクリックします。
   
   
5. [Commit Changes] ボタンをクリックします。必要に応じて、この時点でオプションのコメントを追加できます。
   
   
6. Commit Changesをクリックして、変更を保存します。

リスナーのメールフローポリシーが、選択したTLS設定で更新されます。

選択したドメインセットから着信する着信セッションのTLSをアクティブにするには、次の手順を実行します。

1. Web GUIに接続し、Mail Policies > HAT Overviewの順に選択します。
   
   
2. 送信者のIP/FQDNを適切な送信者グループに追加します。
   
   
3. 前の手順で変更した送信者グループに関連付けられているメールフローポリシーのTLS設定を編集します。
   
   
4. [Submit] をクリックします。
   
   
5. [Commit Changes] ボタンをクリックします。必要に応じて、この時点でオプションのコメントを追加できます。
   
   
6. Commit Changesをクリックして、変更を保存します。

送信者グループのメールフローポリシーが、選択したTLS設定で更新されます。

ヒント:ESAがTLS検証を処理する方法の詳細については、この記事を参照してください。ESAでの証明書検証のアルゴリズムは何ですか。

アウトバウンドTLSのアクティブ化

発信セッションのTLSをアクティブにするには、Web GUIに接続し、Mail Policies > Destination Controlsの順に選択してから、次の手順を実行します。

1. Add Destination...をクリックします。
   
   
2. 宛先ドメインを追加します。
   
   
3. TLS Supportセクションで、ドロップダウンメニューをクリックし、次のいずれかのオプションを選択して、設定するTLSのタイプを有効にします。
   
   
   • None：このオプションを選択すると、インターフェイスからドメインのMTAへのアウトバウンド接続に対してTLSがネゴシエートされません。
     
     
   • Preferred：このオプションを選択すると、EメールゲートウェイインターフェイスからドメインのMTAへのTLSがネゴシエートされます。ただし、（220応答を受信する前に）TLSネゴシエーションが失敗した場合、SMTPトランザクションはクリアテキストにフォールバックしません。証明書が信頼できる認証局によって発行された場合、検証は行われません。エラーが発生し、220応答の受信後にTLSネゴシエーションが失敗した場合、SMTPトランザクションは「暗号化されていない」状態で続行できます。
     
     
   • Required：このオプションを選択すると、ESAインターフェイスからドメインのMTAへのTLSがネゴシエートされます。ドメインの証明書を確認する試みは行われません。ネゴシエーションに失敗すると、電子メールはその接続を介して送信されません。ネゴシエーションが成功すると、暗号化されたセッションを介してメールが配信されます。
     
     
   • Preferred-Verify：このオプションを選択すると、ESAからドメインのMTAにTLSがネゴシエートされ、アプライアンスはドメイン証明書の確認を試みます。この場合、次の3つの結果が考えられます。
     
     
     • TLSがネゴシエートされ、証明書が検証されます。暗号化されたセッションによってメールが配信される。
       
       
     • TLSはネゴシエートされますが、証明書は検証されません。暗号化されたセッションによってメールが配信される。
       
       
     • TLS接続は確立されず、証明書は検証されません。電子メール メッセージがプレーン テキストで配信される。
   • Required-Verify：このオプションを選択すると、ESAからドメインのMTAへのTLSがネゴシエートされ、ドメイン証明書の検証が必要になります。この場合、次の3つの結果が考えられます。
     
     
     • TLS接続がネゴシエートされ、証明書が検証されます。暗号化されたセッションによって電子メール メッセージが配信される。
       
       
     • TLS接続がネゴシエートされますが、信頼できるCAによって証明書が検証されません。メールは配信されない。
       
       
     • TLS接続はネゴシエートされませんが、メールは配信されません。
4. 宛先ドメインの宛先コントロールに必要な変更を加えます。
   
   
5. [Submit] をクリックします。
   
   
6. [Commit Changes] ボタンをクリックします。必要に応じて、この時点でオプションのコメントを追加できます。
   
   
7. Commit Changesをクリックして、変更を保存します。

ESA証明書の誤設定の症状

TLSは自己署名証明書で動作しますが、送信者がTLS検証を必要とする場合は、CA署名付き証明書をインストールする必要があります。

CA署名付き証明書がESAにインストールされている場合でも、TLS検証が失敗することがあります。

このような場合は、「確認」セクションの手順で証明書を確認することを推奨します。

確認

Webブラウザを使用したTLSの確認

CA署名付き証明書を確認するには、証明書をESA GUI HTTPSサービスに適用します。

次に、WebブラウザでESAのGUIに移動します。https://youresaに移動したときに警告が表示される場合は、中間証明書がないなど、証明書が不適切にチェーンされている可能性があります。

サードパーティツールを使用したTLSの確認

テストを行う前に、アプライアンスが受信メールを受信するリスナーにテスト対象の証明書が適用されていることを確認します。

CheckTLS.comやSSL-Tools.netなどのサードパーティツールを使用して、証明書のチェーンが正しいことを確認できます。

TLS-Verifyが成功した場合のCheckTLS.comの出力例

TLS-Verify障害に対するCheckTLS.comの出力例

証明書ホスト名が確認されない(mailC.example.com != gvsvipa006.example.com)

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

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

CA署名付き証明書がインストールされており、エラーが表示される場合は、次のセクションに進み、問題のトラブルシューティング方法を確認してください。

トラブルシュート

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

中間証明書

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

必要なTLS接続障害の通知を有効にする

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

注：これはグローバル設定であるため、ドメイン単位で設定することはできません。

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

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

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

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

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

メールログで成功したTLS通信セッションを見つける

TLS接続は、フィルタアクション、ウイルス対策とスパム対策の判定、配信試行など、メッセージに関連するその他の重要なアクションとともにメールログに記録されます。TLS接続が成功すると、メールログにTLS successエントリが記録されます。同様に、TLS接続に失敗すると、TLS failedエントリが生成されます。メッセージに関連付けられた TLS エントリがログ ファイルにない場合、そのメッセージは TLS 接続経由で配信されていません。

ヒント：メールログを理解するには、シスコのドキュメント『ESAメッセージ破棄の判別』を参照してください。

リモートホスト（受信）からの正常なTLS接続の例を次に示します。

Tue Apr 17 00:57:53 2018 Info: New SMTP ICID 590125205 interface Data 1 (192.168.1.1) address 10.0.0.1 reverse dns host mail.example.com verified yes
Tue Apr 17 00:57:53 2018 Info: ICID 590125205 ACCEPT SG SUSPECTLIST match sbrs[-1.4:2.0] SBRS -1.1
Tue Apr 17 00:57:54 2018 Info: ICID 590125205 TLS success protocol TLSv1 cipher DHE-RSA-AES256-SHA
Tue Apr 17 00:57:55 2018 Info: Start MID 179701980 ICID 590125205

リモートホスト（受信）からの失敗したTLS接続の例を次に示します。

Mon Apr 16 18:59:13 2018 Info: New SMTP ICID 590052584 interface Data 1 (192.168.1.1) address 10.0.0.1 reverse dns host mail.example.com verified yes
Mon Apr 16 18:59:13 2018 Info: ICID 590052584 ACCEPT SG UNKNOWNLIST match sbrs[2.1:10.0] SBRS 2.7
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 TLS failed: (336109761, 'error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher')
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 lost
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 close

リモートホスト（配信）への正常なTLS接続の例を次に示します。

Tue Apr 17 00:58:02 2018 Info: New SMTP DCID 41014367 interface 192.168.1.1 address 10.0.0.1 port 25
Tue Apr 17 00:58:02 2018 Info: DCID 41014367 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384 
Tue Apr 17 00:58:03 2018 Info: Delivery start DCID 41014367 MID 179701982 to RID [0]

リモートホスト（配信）へのTLS接続が失敗した例を次に示します。

Mon Apr 16 00:01:34 2018 Info: New SMTP DCID 40986669 interface 192.168.1.1 address 10.0.0.1 port 25
Mon Apr 16 00:01:35 2018 Info: Connection Error: DCID 40986669 domain: domain IP:10.0.0.1 port: 25 details: 454-'TLS not available due to
 temporary reason' interface: 192.168.1.1 reason: unexpected SMTP response
Mon Apr 16 00:01:35 2018 Info: DCID 40986669 TLS failed: STARTTLS unexpected response

関連情報

• Cisco E メール セキュリティ アプライアンス：エンドユーザ ガイド
• Ciscoコンテンツセキュリティ管理アプライアンス – エンドユーザガイド
• テクニカル サポートとドキュメント - Cisco Systems