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

はじめに

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

前提条件

要件

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

使用するコンポーネント

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

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

背景説明

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

Cisco AsyncOS for Email Securityは、Simple Mail Transfer Protocol(SMTP)へのSTARTTLS拡張(Secure SMTP over TLS)をサポートします。

ヒント: 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によって適切に署名することをお勧めします。

現在の証明書の更新

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

ヒント：詳細については、Ciscoのドキュメント「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ドロップダウンメニューをクリックします。
   
   証明書を作成する際には、共通名(CN)がリスニングインターフェイスのホスト名に一致しているか、または配信インターフェイスのホスト名に一致していることを確認します。
   
   • 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プロバイダーのリストについては、認証局の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 to view or saveの順に移動します。
   
   
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 Successに対するCheckTLS.comの出力例

TLS検証エラーに対する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チェックボックスにチェックマークを付けます。

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

また、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