Catalyst 6500 シリーズ スイッチ SSL サービス モジュール コンフィギュレーション ノート

鍵および証明書の設定

鍵および証明書を次のいずれかの方法で設定できます。

• Simple Certificate Enrollment Protocol（SCEP）を使用している場合は、次の方法で鍵および証明書を設定します。

–鍵ペアを生成します。

–トラストポイント（信頼点）を宣言します。

–CA証明書を取得します。

–SSLサーバに代わり、CAに登録要求を送信します。

詳細は、「SCEPを使用するトラストポイントの設定」を参照してください。

• SCEPを使用していない場合は、手動の証明書登録（Trivial File Transfer Protocol[TFTP;簡易ファイル転送プロトコル]およびカット&ペースト）機能を使用して、鍵と証明書を設定します。次の手順を実行してください。

–鍵ペアを生成またはインポートします。

–トラストポイントを宣言します。

–PKCS10ファイルを作成するのに、TFTPまたはカット&ペーストによりCA証明書を取得し、トラストポイントを登録します。

–PKCS10パッケージを使用して、SSLサーバ証明書をオフラインで要求します。

–TFTPまたはカット&ペーストを使用して、SSLサーバ証明書をインポートします。

詳細については、「手動証明書登録」を参照してください。

• 外部PKIシステムを使用している場合は、次の手順を実行してください。

–PKCS12ファイルまたはPEMファイルを生成します。

–このファイルをモジュールにインポートします。

詳細については、「鍵ペアおよび証明書のインポートとエクスポート」を参照してください。

外部PKIシステムは、鍵ペアを生成し、CAまたは鍵からの証明書の登録やアーカイブ システムの認証を行うサーバまたはPKI管理システムです。Public-Key Cryptography Standards（PKCS）は、秘密鍵および証明書を含む、個人識別情報の転送構文を指定します。この情報は、暗号化ファイルに格納されます。暗号化ファイルを開くには、パス フレーズを取得する必要があります。暗号鍵は、パス フレーズから取得されます。

（注） PKCS12ファイルまたはPEMファイルをインポートする前にトラストポイントを設定する必要はありません。トラストポイントが未設定の場合は、PKCS12ファイルまたはPEMファイルから鍵および証明書をインポートすると、トラストポイントが自動作成されます。

鍵および証明書の設定の概要については、図 3-1を参照してください。

図 3-1 鍵および証明書の設定概要

SCEPを使用するトラストポイントの設定

SCEPを使用してトラストポイントを設定する手順は、次のとおりです。

• 「RSA鍵ペアの生成」

• 「トラストポイントの宣言」

• 「CA証明書の取得」

• 「証明書の要求」

RSA鍵ペアの生成

（注） Secure Shell（SSH;セキュア シェル）は、生成された最初の鍵ペアによってモジュールでイネーブルになります。SSHを使用する場合は、SSHの鍵ペアを設定します。「SSHの設定」を参照してください。

RSAは、Ron Rivest、Adi Shamir、およびLeonard Aldemanが開発した公開鍵暗号システムです。RSAアルゴリズムは、鍵ペアを生成するためにCAおよびSSLサーバで幅広く使用されています。各CAおよびSSLサーバには、独自のRSA鍵ペアがあります。SSLサーバは、証明書を登録するときに、公開鍵をCAに送信します。SSLサーバはSSLセッションを設定するときに、証明書を使用してクライアントに対してIDを証明します。

SSLサーバはセキュアなストレージ内に秘密鍵を保管し、CAには公開鍵のみを送信します。CAは秘密鍵を使用して、サーバの公開鍵およびサーバに関するその他の識別情報が格納された証明書に署名します。

各CAは秘密鍵の機密を保持し、秘密鍵を使用して、下位のCAおよびSSLサーバ用の証明書に署名します。CAには、公開鍵が格納された証明書が保管されます。

CAは1つまたは複数のレベルからなる階層を形成します。最上位レベルのCAをルートCAと呼びます。下位レベルのCAを中間CAまたは下位CAと呼びます。ルートCAには自己署名証明書が格納されます。ルートCAはすぐ下のレベルの下位CA用証明書に署名し、その下位CAはさらに1つ下のレベルのCA用証明書に署名します。以下、同様です。最下位レベルのCAは、SSLサーバ用証明書に署名します。

（注） SSLサービス モジュールは、最大8レベルのCAをサポートします（1つのルートCAと最大7つの下位CA）。「3層のCA登録の例」に、3レベル（3層）の登録例を示します。

これらの証明書は、最下位レベルのサーバ証明書および最上位レベルのルートCA自己署名証明書とともに、チェーンを形成します。各署名を作成するには、発行元CAの秘密鍵を使用して、証明書本体のハッシュ ダイジェストを暗号化します。証明書本体の末尾にシグニチャが付加されて、完全な証明書となります。

SSLセッションの設定時に、SSLサーバは証明書チェーンをクライアントに送信します。クライアントは、レベルが1つ上の証明書から公開鍵を取得して、証明書本体に付加されたシグニチャを復号化することにより、チェーン上方に向かって各証明書のシグニチャを確認します。復号結果と証明書本体のハッシュ ダイジェストが比較されます。チェーン内のいずれかのCA証明書が、クライアントの独自データベースに保存された信頼できるCA証明書の1つと一致した場合、確認は終了します。

チェーン内の最上位レベルのCA証明書に到達しても、信頼できる自己署名証明書と一致しなかった場合、クライアントはセッションを終了するか、またはユーザに対して、証明書を閲覧して信頼できるかどうかを判別するように要求します。

SSLクライアントは、サーバを認証したあと、サーバ証明書内の公開鍵を使用して機密事項を暗号化し、サーバに送信します。SSLサーバは秘密鍵を使用して、機密事項を復号化します。クライアントおよびサーバは両方で、交換された機密事項および2つの乱数を使用することにより、SSLセッション全体でデータの暗号化、復号化、および整合性チェックを行うために必要な鍵情報を生成します。

（注） SSLサービス モジュールは、汎用鍵のみをサポートします。

汎用鍵を生成すると、RSA鍵ペアが1対のみ生成されます。名前付きの鍵ペアを使用すると、複数のRSA鍵ペアを所有することができ、Cisco IOSソフトウェアはID証明書ごとに異なる鍵ペアを管理できます。鍵ペアに名前を指定することを推奨します。

（注） 生成された鍵ペアは、システム メモリ（RAM）に保存されます。停電が起こるか、またはモジュールをリセットすると、これらの鍵ペアは失われます。実行コンフィギュレーションを保存し、モジュールのNVRAM内にあるプライベート コンフィギュレーション ファイルに鍵ペアを保存するには、copy system:running-config nvram:startup-configコマンドを入力する必要があります。

RSA鍵ペアを生成する手順は、次のとおりです。

（注） RSA鍵を生成するとき、鍵の係数長をビット単位で入力するように要求されます。SSLサービス モジュールは、512、768、1,024、1,536、および2,048ビットの係数長をサポートします。512または768も指定できますが、1,024以上の係数長を推奨します。係数が長いほど生成や使用に時間がかかりますが、セキュリティが強化されます。

次に、汎用のRSA鍵を生成する例を示します。

（注） 鍵ペアを生成したあとに、自己署名証明書を生成してSSLサービスをテストすることができます。テスト用の自己署名証明書を生成するには、「自己署名証明書の生成」を参照してください。

トラストポイントの宣言

証明書ごとに、モジュールで使用されるトラストポイントを1つ宣言する必要があります。

モジュールが使用するトラストポイントを宣言し、トラストポイントの特性を指定するには、グローバル コンフィギュレーション モードから始めて次の作業を行います。

次に、トラストポイントPROXY1を宣言して、接続を確認する例を示します。

CA証明書の取得

トラストポイントごとに、CAの公開鍵が格納された証明書を取得する必要があります。複数のトラストポイントで同じCAを使用することができます。

（注） CAに問い合わせて、証明書の正しいフィンガープリントを取得し、コンソールに表示されるフィンガープリントを検証します。

CAの公開鍵が格納された証明書を取得するには、グローバル コンフィギュレーション モードで次の作業を行います。

次に、CA証明書を取得する例を示します。

証明書の要求

トラストポイントごとに、CAから署名付き証明書を取得する必要があります。

CAから署名付き証明書を要求するには、グローバル コンフィギュレーション モードで次の作業を行います。

（注） crypto ca enrollコマンドを入力してから、証明書を受け取るまでの間にモジュールまたはスイッチを再起動した場合は、このコマンドを再入力して、CA管理者に通知する必要があります。

次に、証明書を要求する例を示します。

トラストポイントを設定したあとに、証明書およびトラストポイントの情報を確認する場合は、「証明書およびトラストポイントの確認」を参照してください。

3層のCA登録の例

SSLサービス モジュールは、最大8レベルのCAをサポートします（1つのルートCAと最大7つの下位CA）。

次に、3レベルのCAを設定する例を示します。

鍵の生成

トラストポイントの定義

3つのCAの認証（1つのルートCAと2つの下位CA）

3番めのレベルのCAによる登録

手動証明書登録

手動証明書登録（TFTPおよびカット&ペースト）機能を使用すると、証明書要求を生成し、ルータの証明書と同様にCA証明書も受け入れることができます。これらの手順は、TFTPサーバまたは手動のカット&ペースト操作で行われます。TFTPまたは手動のカット&ペースト登録を使用しなければならない状況は、次のとおりです。

• ご使用のCAが、SCEPをサポートしていない場合（要求および証明書の送受信に通常使用される方法）

• ルータとCA間のネットワーク接続が不可能な場合（Cisco IOSソフトウェアを実行しているルータが証明書を入手する方法）

次のURLに従って、手動証明書登録（TFTPおよびカット&ペースト）機能を設定してください。

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftmancrt.htm

（注） CRLサーバが到達不能であるかまたはCRLダウンロード パスが存在しないために、CRLをダウンロードできない場合、証明書をインポートできない可能性があります。インポート プロセスにリンクしているすべてのトラストポイントで、CRLをダウンロードできることを確認する必要があります。CRLパスが存在しないか、またはCRLサーバが到達不能な場合は、インポート プロセスにリンクするすべてのトラストポイントで crl optionalコマンドを入力する必要があります。show crypto ca certificates コマンドを入力して、すべての証明書に関する情報を表示し、この表示から関連するトラストポイントのリストを取得します。これらすべてのトラストポイントに、crl optionalコマンドを入力します。

たとえば3層のCA階層（ルートCA、下位CA1、および下位CA2）で、下位CA1の証明書をインポートする場合、ルートCAに関連するすべてのトラストポイントに crl optionalコマンドを入力します。同様に、下位CA2証明書をインポートする場合は、ルートCAおよび下位CA1に関連するすべてのトラストポイントにcrl optionalコマンドを入力します。

証明書を正常にインポートしてから、トラストポイントで元のCRLオプションを回復させることができます。

例1：TFTPを使用する証明書登録の設定（1層のCA）

1. トラストポイントを設定します。

2. トラストポイント用の証明書を要求します。

3. CAの公開鍵が格納された証明書を取得します。

4. サーバ証明書をインポートします。

例2：カット&ペーストを使用する証明書登録の設定（1層のCA）

1. RSA鍵ペアを生成します。

2. トラストポイントを設定します。

3. トラストポイント用の証明書を要求します。

4. CA証明書をインポートします。

5. サーバ証明書をインポートします（サーバ証明書は、手順4でインポートする証明書のCAによって発行されます）。

例3：TFTPを使用する証明書登録の設定（3層のCA）

1. RSA鍵ペアを生成します。

2. トラストポイントを設定します。

3. Certificate Signing Request（CSR）を生成して、TFTPサーバに送信します。

4. CSRを使用して、3層のCAからSSL証明書をオフラインで取得します。

5. 3つのCAを認証します（1つのルートCAと2つの下位CA）

6. サーバ証明書をインポートします。

例4：カット&ペーストを使用する証明書登録の設定（3層のCA）

1. RSA鍵ペアを生成します。

2. トラストポイントを設定します。

3. トラストポイント用の証明書を要求します。

4. 3番めのレベルのCAにより署名された手順3の証明書要求を取得します。

5. すべてのCAを定義し、インポートします（1つのルートCAと2つの下位CA）。

a. ルートCAおよび下位CA1の2つのトラストポイントを定義します。

（注） 下位CA2証明書をインポートするには、tp-proxy1を使用します。

b. ルートCA証明書をインポートします。

c. 下位CA1証明書をインポートします。

d. 下位CA2証明書をインポートします。

e. サーバ証明書をインポートします。

鍵ペアおよび証明書のインポートとエクスポート

PKCS12ファイル フォーマットまたはPrivacy-Enhanced Mail（PEM）ファイル フォーマットのいずれかを使用して、鍵ペアと証明書をインポート/エクスポートすることができます。

鍵ペアと証明書をインポート/エクスポートするには、次のいずれかの章を参照してください。

• 「PKCS12ファイルのインポートとエクスポート」

• 「PEMファイルのインポートとエクスポート」

（注） モジュールのSSLソフトウェアには、テスト用PKCS12ファイル（test/testssl.p12）が組み込まれています。このファイルをNVRAMにインストールして、テストや概念の検証に使用することができます。PKCS12ファイルをインストールしたあとに、このファイルをトラストポイントにインポートして、テスト用に設定されたプロキシ サービスに割り当てることができます。テスト用PKCS12ファイルのインストールについては、「組み込みテスト証明書のインポート」を参照してください。

（注） CRLサーバが到達不能であるかまたはCRLダウンロード パスが存在しないために、CRLをダウンロードできない場合、証明書をインポートできない可能性があります。インポート プロセスにリンクしているすべてのトラストポイントで、CRLをダウンロードできることを確認する必要があります。CRLパスが存在しないか、またはCRLサーバが到達不能な場合は、インポート プロセスにリンクするすべてのトラストポイントに crl optionalコマンドを入力する必要があります。show crypto ca certificates コマンドを入力して、すべての証明書に関する情報を表示し、この表示から関連するトラストポイントのリストを取得します。これらすべてのトラストポイントにcrl optionalコマンドを入力します。

たとえば3層のCA階層（ルートCA、下位CA1、および下位CA2）で、下位CA1の証明書をインポートする場合、ルートCAに関連するすべてのトラストポイントに crl optionalコマンドを入力します。同様に、下位CA2証明書をインポートする場合は、ルートCAおよび下位CA1に関連するすべてのトラストポイントにcrl optionalコマンドを入力します。

証明書を正常にインポートしてから、トラストポイントで元のCRLオプションを回復させることができます。

PKCS12ファイルのインポートとエクスポート

外部PKIシステムを使用してPKCS12ファイルを生成し、生成されたファイルをモジュールにインポートすることができます。

（注） PKCS12ファイルを作成する場合は、サーバ証明書からルート証明書までの証明書チェーン全体、および公開鍵と秘密鍵をファイルに含める必要があります。また、モジュールからPKCS12ファイルを生成して、それをエクスポートすることもできます。

（注） インポートされた鍵ペアは、エクスポートできません。

（注） SSHを使用している場合は、PKCS12ファイルをインポートまたはエクスポートするときに、SCP（セキュアなファイル転送）を使用することを推奨します。SCPはホストを認証して、転送セッションを暗号化します。

PKCS12ファイルをインポートまたはエクスポートする手順は、次のとおりです。

コマンド	目的
ssl-proxy(config)# crypto ca { import | export } trustpoint_label pkcs12 { scp: | ftp: | nvram: | rcp: | tftp: } [ pkcs12_filename7 ] pass_phrase8	PKCS12ファイルをインポートまたはエクスポートします。 （注） PKCS12ファイルをインポートする前にトラストポイントを設定する必要はありません。トラストポイントが未設定の場合は、PKCS12ファイルから鍵および証明書をインポートすると、トラストポイントが自動作成されます。

次に、SCPを使用してPKCS12ファイルをインポートする例を示します。

次に、SCPを使用してPKCS12ファイルをエクスポートする例を示します。

次に、FTP（ファイル転送プロトコル）を使用してPKCS12ファイルをインポートする例を示します。

次に、FTPを使用してPKCS12ファイルをエクスポートする例を示します。

PKCS12ファイルをインポートしたあとに、証明書およびトラストポイントの情報を確認する場合は、「証明書およびトラストポイントの確認」を参照してください。

PEMファイルのインポートとエクスポート

（注） crypto ca import pemコマンドを使用すると、秘密鍵（.prv）、サーバ証明書（.crt）、および発行者のCA証明書（.ca）のみをインポートします。証明書チェーンに複数のCAレベルがある場合は、このコマンドが認証用に発行される前に、ルートCA証明書および下位CA証明書をインポートする必要があります。ルートCA証明書および下位CA証明書をインポートするには、カット&ペーストまたはTFTPを使用します。

（注） インポートされた鍵ペアは、エクスポートできません。

（注） SSHを使用している場合は、PEMファイルをインポートまたはエクスポートするときに、SCP（セキュアなファイル転送）を使用することを推奨します。SCPはホストを認証して、転送セッションを暗号化します。

PEMファイルをインポートまたはエクスポートするには、次の手順のいずれかを実行します。

コマンド	目的
ssl-proxy(config)# crypto ca import trustpoint_label pem [ exportable ] { terminal | url { scp: | ftp: | nvram: | rcp: | tftp: } | usage-keys } pass_phrase9 , 10	PEMファイルをインポートします。 （注） PEMファイルをインポートする前にトラストポイントを設定する必要はありません。トラストポイントが未設定の場合は、PEMファイルから鍵および証明書をインポートすると、トラストポイントが自動作成されます。
ssl-proxy(config)# crypto ca export trustpoint_label pem { terminal | url { scp: | ftp: | nvram: | rcp: | tftp: } [ des | 3des ] pass_phrase1 , 2	PEMファイルをエクスポートします。 （注） 鍵、サーバ証明書、およびサーバ証明書の発行者CAのみがエクスポートされます。上位レベルのCAはすべて、TFTPのカット&ペーストを使用してエクスポートされる必要があります。

次に、TFTPを使用してPEMファイルをインポートする例を示します。

（注） TP5.ca、TP5.prv、およびTP5.crtファイルは、サーバ上に格納されている必要があります。

次に、TFTPを使用してPEMファイルをエクスポートする例を示します。

PEMファイルをインポートしたあとに、証明書およびトラストポイントの情報を確認する場合は、「証明書およびトラストポイントの確認」を参照してください。

3レベルのCA用PEMファイルのインポート例

ここでは、オフライン登録のカット&ペースト オプションを使用して、ルートCA証明書（Tier 1）および中間CA証明書（Tier 2）を取得します。中間CA証明書（Tier 3）、秘密鍵、およびルータ証明書は、PEMファイルをインポートすることで取得されます。

1. カット&ペーストを使用して、ルートCA-Tier 1証明書を取得します。

2. カット&ペーストを使用して、下位CA1証明書を取得します。

3. 下位CA2証明書、RSA鍵ペア、およびルータ証明書をインポートします。ルータ証明書には、下位CA2による署名が必要です。

4. 証明書情報を表示します（任意）。

証明書およびトラストポイントの確認

証明書およびトラストポイント（信頼点）に関する情報を確認するには、EXECモードで次の作業を行います。

鍵および証明書の共有

SSLサービス モジュールを使用すると、複数の証明書で同じ鍵ペアを共有できます。ただし、1つの鍵ペアが損なわれた場合に、すべての証明書を取り消して置き換える必要があるため、この方法は推奨しません。

各プロキシ サービスの追加や削除は随時行われるため、各証明書の有効期限もそれぞれ異なります。一部のCAは、証明書を書き換えるときに鍵ペアを更新するように要求します。複数の証明書で1つの鍵ペアを共有している場合は、これらの複数の証明書を同時に書き換える必要があります。一般に、証明書ごとに鍵ペアが異なる場合は、証明書の管理が容易です。

SSLモジュールには、複数のプロキシ サービス間、および複数のSSLサービス モジュール間で証明書を共有する場合の制限がありません。複数のプロキシ サービスに、同じトラストポイントを割り当てることができます。

ビジネス上の観点から、CAに制限が設けられる場合があります（たとえば、同じ証明書を使用できるサーバ ファーム内のサーバ数が制限されます）。証明書の共有に関して、契約またはライセンス上の合意がある場合もあります。ビジネス契約については、CAまたは法律関係者にお問い合わせください。

実際には、一部のWebブラウザは、サーバ証明書の件名と、URLに含まれるホスト名またはIPアドレスを比較します。件名がホスト名またはIPアドレスと一致しない場合は、証明書を確認して受け入れるようにユーザに要求するダイアログ ボックスが表示されます。この手順を省略するには、ホスト名またはIPアドレスに基づく証明書の共有を制限します。

設定の保存

設定を変更した場合は、必ず作業内容を保存してください。

設定をNVRAMに保存する手順は、次のとおりです。

コマンド

目的

ssl-proxy# copy [ /erase ] system:running-config nvram:startup-config

設定、鍵ペア、および証明書をNVRAMに保存します。鍵ペアがプライベート コンフィギュレーション ファイルに保存され、各証明書がNVRAM内にバイナリ ファイルとして保存されます。モジュールは、起動時に、証明書を取得するかまたは自動登録するようにCAに問い合わせる必要がなくなります。 （注） セキュリティ上の理由から、/eraseオプションを入力してパブリックおよびプライベート コンフィギュレーション ファイルを消去してから、NVRAMを更新することを推奨します。/eraseオプションを入力しないと、古いプライベート コンフィギュレーション ファイルの鍵ペアがNVRAMに残ることがあります。 注意 /eraseオプションを入力すると、実行中の設定がNVRAMに保存される前に、NVRAM内の現在のバッファおよびバックアップのバッファが削除されます。バッファは削除されたあとにもかかわらず、実行中の設定が保存される前に停電が起こるか、または再起動をすると、両方の設定が失われることになります。

（注） NVRAMに保存されているファイル数が多い場合は、この作業に最長で2分かかることがあります。

NVRAMへの設定の自動バックアップ機能では、最後に保存された設定を自動的にバックアップします。現在の書き込み過程でエラーが発生した場合は、前回の設定が自動的に回復されます。

コンフィギュレーションのサイズが大きすぎる場合

サイズが大きすぎるコンフィギュレーション（257以上のプロキシ サービス、および357以上の証明書）を保存すると、NVRAM内の内容が破壊されることがあります。

NVRAMに保存する前に、必ず実行コンフィギュレーションにコピーしてください。実行コンフィギュレーション ファイルをリモート サーバに保管すると、各証明書がファイル内に16進ダンプとして保存されます。実行コンフィギュレーション ファイルを実行コンフィギュレーションにコピーしてから、NVRAMに保存すると、証明書が再度保存されますが、今度はバイナリ ファイルとして保存されます。ただし、実行コンフィギュレーション ファイルをリモート サーバからスタートアップ コンフィギュレーションに直接コピーした場合は、16進ダンプとして保存された証明書も保存されて、同じ証明書のコピーが2つ（16進ダンプ形式とバイナリ ファイル形式）存在することになります。証明書は2つも必要ではありませんし、またリモート ファイルのサイズが大きい場合はNVRAMの内容の一部が上書きされて、内容が破壊される危険性があります。

保存済みコンフィギュレーションの確認

保存済みコンフィギュレーションを確認する手順は、次のとおりです。

（注） プロキシ サービスおよび証明書の数が上限（それぞれ256、356）まで設定されている場合は、出力を表示するまで最長で7分かかります。

保存済みコンフィギュレーションの削除

保存済みコンフィギュレーションを削除する手順は、次のとおりです。

（注） NVRAMに保存されているファイル数が多い場合は、この作業に最長で2分かかることがあります。

鍵および証明書のバックアップ

鍵および証明書をNVRAMに保存するプロセスを中断する事象（停電など）が発生した場合は、保存中の鍵および証明書が失われることがあります。公開鍵および証明書はCAから取得できますが、秘密鍵は回復できません。

セキュアなサーバが使用可能な場合は、各トラストポイントをPKCS12ファイルにエクスポートして、鍵ペアおよび対応する証明書チェーンをバックアップすることができます。その後PKCS12ファイルをインポートして、鍵および証明書を回復できます。

セキュリティに関する注意事項

鍵および証明書をバックアップする場合は、次の注意事項に従ってください。

• PKCS12ごとに、容易に推測できないパス フレーズを選択して、厳重に保護する必要があります。PKCS12ファイルをクリア テキスト形式で保存しないでください。

• バックアップ サーバはセキュアでなければなりません。権限を持つユーザにのみ、バックアップ サーバへのアクセスを許可します。

• PKCS12ファイル（そこにパス フレーズを入力します）のインポートまたはエクスポート時には、モジュール コンソールに直接接続するか、SSHセッションを使用します。

• ファイル転送にはSCPを使用します。

鍵および証明書のモニタおよびメンテナンス

ここに記載された次の作業は任意です。

• 「モジュールからのRSA鍵の削除」

• 「鍵および証明書の表示」

• 「コンフィギュレーションからの証明書の削除」

モジュールからのRSA鍵の削除

場合によっては、モジュールのRSA鍵を削除しなければならないことがあります。たとえば、RSA鍵が何らかの理由で損なわれて使用できない場合は、鍵を削除する必要があります。

モジュールからRSA鍵をすべて削除するには、グローバル コンフィギュレーション モードで次の作業を行います。

コマンド	目的
ssl-proxy(config)# crypto key zeroize rsa [ key-label ]	すべてのRSA鍵ペア、または指定された鍵ペアを削除します。 注意 鍵を削除すると、その鍵に関連付けられたすべての証明書も削除されます。

モジュールのRSA鍵を削除したあとに、次に示す2つの作業を行います。

• モジュールの証明書をCAで無効にするように、CA管理者に要求します。 crypto ca enroll コマンドを使用して、最初に証明書を取得したときにモジュールに作成したチャレンジ パスワードを指定する必要があります。

• コンフィギュレーションからトラストポイントを手動で削除します（コンフィギュレーションからの証明書の削除を参照）。

鍵および証明書の表示

鍵および証明書を表示するには、EXECモードで次のコマンドを入力します。

コマンド	目的
ssl-proxy# show crypto key mypubkey rsa	モジュールのRSA公開鍵を表示します。
ssl-proxy# show crypto ca certificates [ trustpoint_label ]	証明書、CA証明書、およびあらゆるRA証明書の情報を表示します。
ssl-proxy# show running-config [ brief ]	公開鍵および証明書チェーンを表示します。 brief オプションを指定すると、各証明書の16進ダンプが表示されません。
ssl-proxy# show ssl-proxy service proxy-name	指定されたプロキシ サービスに使用される鍵ペアおよび証明書チェーンのシリアル番号を表示します。 （注） proxy-name値は大文字/小文字の区別があります。

コンフィギュレーションからの証明書の削除

モジュールには、独自の証明書およびCAの証明書が保存されます。モジュールに保存された証明書は削除できます。

モジュールのコンフィギュレーションから証明書を削除するには、グローバル コンフィギュレーション モードで次の作業を行います。

プロキシ サービスへの証明書の割り当て

certificate rsa general-purpose trustpoint trustpoint_label サブコマンドを入力すると（ ssl-proxy service proxy_service コマンドの下に入力）、指定されたプロキシ サービスに証明書が割り当てられます。プロキシ サービスごとに、 certificate rsa general-purpose trustpoint サブコマンドを何度でも入力できます。

トラストポイントラベルを変更した場合は、移行期間の間、プロキシ サービスが一時的に停止します。接続を閉じるか削除しない限り、既存の接続は古い証明書を使用し続けます。新しい接続では新しいトラストポイントの証明書が使用され、サービスが再び使用可能になります。

ただし、新しいトラストポイントに証明書がない場合は、サービスの動作ステータスはダウンのままです。新しい接続は、新しい証明書が使用可能になるまで確立されません。 no certificate rsa
general-purpose trustpoint サブコマンドを入力して証明書を削除した場合でも、接続を閉じるかまたは削除しない限り、既存の接続はこの証明書を使用し続けます。不用になった証明書も、すべての接続を閉じるかまたは削除しない限り、プロキシ サービスから削除されません。

次に、プロキシ サービスにトラストポイントを割り当てる例を示します。

次に、プロキシ サービスのトラストポイントを変更する例を示します。

（注） 接続を閉じない限り、既存の接続は古い証明書を使用し続けます。サービスの動作ステータスはアップからダウンに変わり、再度アップになります。新しい接続は、新しい証明書を使用します。

証明書の更新

証明書を更新する場合、一部のCAでは新しい鍵ペアを生成する必要がありますが、その他のCAでは期限切れ証明書の鍵ペアを使用することができます。SSLサービス モジュールは、この両方の場合に対応しています。

通常、SSLサーバ証明書の期限は1～2年です。証明書を適宜に書き換えることにより、サービスが突然停止する事態を避けることができます。

次の例では、プロキシ サービスs2はトラストポイントt2に割り当てられています。

次の例では、トラストポイントt2の鍵ペアを更新して、古い証明書をCisco IOSデータベースから削除します。プロキシ サービスs2に対する証明書の書き換えが自動的に開始します。

次の例では、トラストポイントt2が再登録されるまで、既存および新規の接続は古い証明書を使用します。トラストポイントt2を再登録したあと、新しい接続は新しい証明書を使用します。既存の接続は接続が終了するまで、古い証明書を使用し続けます。

次の例では、既存の接続をすべて閉じたあとに、不用になった証明書を削除します。

証明書の自動更新および自動登録

自動登録を設定する場合、モジュールは、設定のパラメータを使用しているCAからの証明書を自動的に要求します。

指定された比率の有効時間が過ぎた証明書を、自動的に更新するように設定することができます。たとえば、証明書が300日間有効で、 renewal_percent を80と指定する場合、証明書の有効時間の開始から240日過ぎると、証明書は自動的に更新されます。

（注） 自動登録および自動更新の前に、CA証明書をデータベースに格納する必要があります。自動登録を設定する前に、トラストポイントを認証します。また、トラストポイントのSCEP登録URLも設定します。

自動登録および自動更新をイネーブルにして、タイマー情報を表示する手順は、次のとおりです。

	コマンド	目的
ステップ 1	ssl-proxy(config)# crypto ca trustpoint trustpoint-label	トラストポイントを宣言します。
ステップ 2	ssl-proxy(ca-trustpoint)# auto-enroll {renewal_ percent | regenerate }	指定されたトラストポイントの自動更新および自動登録をイネーブルにします。 （注） renewal_percent の有効値は0（1分以内の登録）～100です。 （注） 名前付きの鍵がすでに存在している場合でも、regenerateキーワードを使用すると、証明書の新しい鍵が生成されます。
ステップ 3	ssl-proxy# show crypto ca timers	各タイマーの期限切れまでの残り時間を表示します。

次に、自動登録および自動更新をイネーブルにする例を示します。

鍵および証明書の履歴のイネーブル化

ssl-proxy pki history コマンドを入力すると、SSLプロキシ サービスの鍵および証明書の履歴がイネーブルになります。この履歴には、プロキシ サービスの鍵ペアおよび証明書チェーンの追加レコードまたは削除レコードがそれぞれ作成されます。

show ssl-proxy certificate-history コマンドを入力すると、各レコードが表示されます。各レコードにはサービス名、鍵ペアの名前、生成またはインポートの時刻、トラストポイントの名前、証明書の件名と発行者名、シリアル番号、および日付が記録されます。

メモリには最大512のレコードを格納できます。レコードごとに、Syslogメッセージが生成されます。レコード数が上限である512を超えた場合は、古いレコードから順に削除されます。

鍵および証明書の履歴をイネーブルにして、レコードを表示する手順は、次のとおりです。

次に、鍵および証明書の履歴をイネーブルにして、指定されたプロキシ サービスのレコードを表示する例を示します。

ピア証明書のキャッシュ

認証済みのサーバ/クライアント（ピア）証明書をキャッシュするように、SSLモジュールを設定することができます。認証済みのピア証明書をキャッシュすることにより、SSLモジュールは同じ証明書を再び認証する必要がなくなるため、時間の節約になります。SSLモジュールは、指定されたタイムアウト インターバル内に同じピア証明書を受信して、確認オプション（signature-onlyまたはall）が一致する場合に、キャッシュされた証明書情報を使用します。

（注） verifying allを指定すると、指定されたタイムアウト インターバル内にCRL検索またはACLフィルタリングの結果が変更される場合があります。これは、SSLモジュールが否定される必要のある証明書を不正に受け取る原因となります。たとえば、SSLモジュールがピア証明書をキャッシュし、その後指定されたタイムアウト内に、この証明書が表示されている更新済みのCRLをダウンロードする場合があります。

SSLモジュールが多量の証明書を何度も受信して、リスクが容認できる環境では、認証済みのピア証明書をキャッシュすることにより、オーバーヘッドを減らすことができます。

たとえば、サイトツーサイトVirtual Private Network（VPN;仮想私設網）環境で、2つのSSLモジュールがフル ハンドシェイクの間に相互の証明書を認証すると、キャッシュが適用されます。signature-onlyの確認および認証済みのピア証明書のキャッシュを組み合わせると、最高のパフォーマンスを得ることができます。

指定されたタイム インターバル内に期限切れになるピア証明書は、キャッシュされません。SSLモジュールは、signature-onlyおよびverify-allオプションに、別々のキャッシュ エントリを使用します。確認オプションの一致は、キャッシュ ヒットの基準の1つです。

同じピア証明書を、異なるプロキシ サーバで異なる時間に受け取ることができ、各プロキシ サーバにはそれぞれ固有のCAプールがあるため、ピア証明書の発行者が現在のプロキシ サービスのCAプールではなく、前回のプロキシ サービスのCAプールにある場合があります。これはキャッシュ ミスとみなされ、ピア証明書は確認されます。

認証済みのピア証明書をキャッシュする手順は、次のとおりです。

証明書期限切れ警告の設定

証明書の期限が切れた場合、または指定された時間内に切れる場合に、警告メッセージをロギングするようにSSLモジュールを設定することができます。証明書期限切れ警告をイネーブルにすると、SSLモジュールは30分ごとに次の期限切れ情報を確認します。

• すべてのプロキシ サービス

• プロキシ サービスに関連付けられたCA証明書

• 信頼できるCAプールに割り当てられた、すべてのCAトラストポイント

タイム インターバルは、1～720時間の範囲で指定できます。

（注） SSLモジュールでは、証明書にロギングされていた情報を保管します。0を指定すると警告はディセーブルになり、以前ロギングされたすべての警告メッセージの内部メモリが削除されます。タイム インターバルを1～720時間の範囲で指定すると、ロギング プロセスが再開されます。ログ メッセージは、ロギング開始後すぐには表示されない場合があります。最初のログ メッセージが表示されるまで、最大30分かかる場合があります。

証明書が指定されたインターバル内で期限切れになる場合、またはすでに期限切れになった場合は、SSLモジュールは証明書の警告メッセージを1つロギングします。

さらに、CISCO-SSL-PROXY-MIB証明書期限切れトラップをイネーブルにして、プロキシ サービスの証明書期限切れ警告がロギングされるたびに、トラップを発行することができます。SNMP（簡易ネットワーク管理プロトコル）トラップの設定の詳細については、「SNMPトラップの設定」を参照してください。

証明書期限切れ警告をイネーブルにして、警告のインターバルを設定する手順は、次のとおりです。

コマンド	目的
ssl-proxy(config)# ssl-proxy pki certificate check-expiring interval interval	証明書期限切れ警告をイネーブルにして、警告のインターバルを設定します。 interval のデフォルト値は0（ディセーブル）です。有効範囲は1～720時間です。 （注） 0 を入力すると、警告はディセーブルになり、以前ロギングされたすべての警告メッセージの内部メモリが削除されます。SNMPトラップは送信されません。

次に、証明書期限切れ警告をイネーブルにして、警告のインターバルを設定する例を示します。

次に、以前ロギングされたすべての警告メッセージの内部メモリを削除して、ロギング プロセスを再開する例を示します。

次に、まもなく期限切れになるか、またはすでに期限切れになった、プロキシ サービスの証明書に関するSyslogメッセージ例を示します。

次に、まもなく期限切れになるか、またはすでに期限切れになった1つまたは複数のプロキシ サービスに関連付けられたCA証明書に関するSyslogメッセージ例を示します。

次に、期限切れになるまたはすでに期限切れになった、信頼できるCAプールに割り当てられたCA証明書に関するSyslogメッセージ例を示します。

SSLサーバ プロキシ サービス

SSLサーバ プロキシ サービスを設定する手順は、次のとおりです。

	コマンド	目的
ステップ 1	ssl-proxy(config)# ssl-proxy service service_name	SSLプロキシ サービスの名前を定義します。 （注） service_name値は大文字/小文字の区別があります。
ステップ 2	ssl-proxy(config-ssl-proxy)# virtual ipaddr ip_addr [ mask_addr ] 11 protocol tcp port port [ secondary 12 ,13, 14]	SSLサービス モジュールがプロキシとして機能する仮想サーバのIPアドレス、トランスポート プロトコル（TCP）、およびポート番号を定義します。 （注） 直接接続されているネットワーク上に仮想IPアドレスがない場合、secondaryキーワードが必要です。
ステップ 3	ssl-proxy(config-ssl-proxy)# server ipaddr ip_addr protocol tcp port port	プロキシのターゲット サーバのIPアドレス、ポート番号、およびトランスポート プロトコルを定義します。 （注） ターゲット サーバのIPアドレスには、SLBデバイスの仮想IPアドレス、またはWebサーバの実IPアドレスを指定できます。
ステップ 4	ssl-proxy(config-ssl-proxy)# virtual policy tcp tcp_policy_name 15	（任意）プロキシ サーバのクライアント側にTCPポリシーを適用します。TCPポリシーのパラメータについては、「TCPポリシーの設定」を参照してください。
ステップ 5	ssl-proxy(config-ssl-proxy)# virtual policy ssl ssl_policy_name 5	（任意）プロキシ サーバのクライアント側にSSLポリシーを適用します。SSLポリシーのパラメータについては、「SSLポリシーの設定」を参照してください。
ステップ 6	ssl-proxy(config-ssl-proxy)# server policy tcp tcp_policy_name	（任意）プロキシ サーバのサーバ側にTCPポリシーを適用します。「TCPポリシーの設定」を参照してください。
ステップ 7	ssl-proxy(config-ssl-proxy)# policy http-header http_header_policy_name	（任意）プロキシ サーバにHTTPヘッダー ポリシーを適用します。「HTTPヘッダー挿入」を参照してください。
ステップ 8	ssl-proxy(config-ssl-proxy)# policy url-rewrite url_rewrite_policy_name	（任意）URL書き換えポリシーを適用します。「URL書き換えの設定」を参照してください。
ステップ 9	ssl-proxy(config-ssl-proxy)# trusted-ca ca_pool_name	（任意）信頼されるCAプールをプロキシ サービスに関連付けます。CAプールの詳細については、「サーバ証明書認証」を参照してください。
ステップ 10	ssl-proxy(config-ssl-proxy)# authenticate verify { signature-only16 | all17 }	（任意）サーバ証明書認証をイネーブルにして、確認形式を指定します。サーバ証明書認証については、「サーバ証明書認証」を参照してください。
ステップ 11	ssl-proxy(config-ssl-proxy)# nat {server | client natpool_name }	（任意）SSLサービス モジュールによって開かれたサーバ側の接続に、サーバNAT18またはクライアントNATを使用するように指定します。「NATの設定」を参照してください。
ステップ 12	ssl-proxy(config-ssl-proxy)# certificate rsa general-purpose trustpoint trustpoint_label	トラストポイントの設定をプロキシ サーバに適用します 19 。 （注） トラストポイントはCAサーバ、鍵パラメータと鍵生成方法、およびプロキシ サーバの証明書登録方法を定義します。トラストポイントの設定手順については、「トラストポイントの宣言」を参照してください。
ステップ 13	ssl-proxy(config-ssl-proxy)# inservice	プロキシ サーバを管理上のアップに設定します。

次に、SSLプロキシ サービスを設定する例を示します。

管理および設定する仮想IPアドレスおよびサーバIPアドレスが数多くある場合、ワイルドカードのプロキシ サービスを設定することができます。

次に、ワイルドカードのSSLプロキシ サービスを設定し、これにより proxy1 が仮想IPアドレス10.0.0.1～10.25.255.254を受け入れる例を示します。

SSLバージョン2.0フォワーディング

SSLモジュールは、SSLバージョン2.0（SSLv2）接続を終了することができません。ただし、 server コマンドで sslv2 キーワードを入力して、SSLモジュールがSSLv2接続を他のサーバに転送するように設定することができます。SSLv2サーバのIPアドレスを設定すると、SSLモジュールはこのサーバにすべてのSSLv2接続を透過的に転送します。SSLv2フォワーディングが必要な場合、SSLバージョン3.0（SSLv3）またはTransport Layer Security（TLS）バージョン1.0のオフロード接続に使用されるサーバのIPアドレスに加えて、SSLv2サーバのIPアドレスも設定する必要があります。

SSLv2フォワーディングを設定するには、次のコマンドを入力します。

コマンド	目的
ssl-proxy(config-ssl-proxy)# server ipaddr ip_addr protocol tcp port port sslv2 20	プロキシのターゲット サーバのIPアドレス、ポート番号、およびトランスポート プロトコルを定義します。 （注） ターゲット サーバのIPアドレスには、SLBデバイスの仮想IPアドレス、またはWebサーバの実IPアドレスを指定できます。

次に、SSLプロキシ サービスにSSLv2接続を転送するよう設定する例を示します。

SSLクライアント プロキシ サービス

SSLクライアント サービスの設定では、プロキシ サービスがクリア テキスト トラフィックを受け入れ、このトラフィックをSSLトラフィックに暗号化し、バックエンドのSSLサーバに転送するように指定します。

SSLサーバ プロキシの証明書を設定する必要はありますが、SSLクライアント プロキシの証明書の設定は必要ありません。SSLクライアント プロキシの証明書を設定すると、サーバがハンドシェイク プロトコルのクライアント認証フェーズの間に送信するCertificateRequestメッセージに応じて、この証明書が送信されます。

（注） SSLポリシーは、SSLクライアント プロキシ サービスではserverサブコマンドで設定され、SSL
サーバ プロキシ サービスではvirtual サブコマンドで設定されます。

SSLクライアント プロキシ サービスを設定する手順は、次のとおりです。

	コマンド	目的
ステップ 1	ssl-proxy(config)# ssl-proxy service proxy_name client	SSLプロキシ サービスの名前を定義します。 client キーワードには、SSLクライアント プロキシ サービスを設定します。 （注） proxy-name値は大文字/小文字の区別があります。
ステップ 2	ssl-proxy(config-ssl-proxy)# virtual ipaddr ip_addr [ mask_addr ] 21 protocol tcp port port [ secondary 22 ,23, 24]	SSLサービス モジュールがプロキシとして機能する仮想サーバのIPアドレス、トランスポート プロトコル（TCP）、およびポート番号を定義します。 （注） 直接接続されているネットワーク上に仮想IPアドレスがない場合、secondaryキーワードが必要です。
ステップ 3	ssl-proxy(config-ssl-proxy)# server ipaddr ip_addr protocol tcp port port	プロキシのターゲット サーバのIPアドレス、ポート番号、およびトランスポート プロトコルを定義します。 （注） ターゲット サーバのIPアドレスには、SLBデバイスの仮想IPアドレス、またはWebサーバの実IPアドレスを指定できます。
ステップ 4	ssl-proxy(config-ssl-proxy)# virtual policy tcp tcp_policy_name25	（任意）プロキシ サーバのクライアント側にTCPポリシーを適用します。TCPポリシーのパラメータについては、「TCPポリシーの設定」を参照してください。
ステップ 5	ssl-proxy(config-ssl-proxy)# server policy ssl ssl_policy_name5	（任意）プロキシ サーバのサーバ側にTCPポリシーを適用します。SSLポリシーのパラメータについては、「SSLポリシーの設定」を参照してください。
ステップ 6	ssl-proxy(config-ssl-proxy)# server policy tcp tcp_policy_name	（任意）プロキシ サーバのサーバ側にTCPポリシーを適用します。「TCPポリシーの設定」を参照してください。
ステップ 7	ssl-proxy(config-ssl-proxy)# policy http-header http_header_policy_name	（任意）プロキシ サーバにHTTPヘッダー ポリシーを適用します。「HTTPヘッダー挿入」を参照してください。
ステップ 8	ssl-proxy(config-ssl-proxy)# policy url-rewrite url_rewrite_policy_name	（任意）URL書き換えポリシーを適用します。「URL書き換えの設定」を参照してください。
ステップ 9	ssl-proxy(config-ssl-proxy)# trusted-ca ca_pool_name	信頼されるCAプールをプロキシ サービスに関連付けます。CAプールの詳細については、「クライアント証明書認証の設定」を参照してください。
ステップ 10	ssl-proxy(config-ssl-proxy)# authenticate verify { signature-only26 | all27 }	クライアント証明書認証をイネーブルにして、確認形式を指定します。クライアント証明書認証については、「クライアント証明書認証の設定」を参照してください。
ステップ 11	ssl-proxy(config-ssl-proxy)# nat {server | client natpool_name }	（任意）SSLサービス モジュールによって開かれたサーバ側の接続に、サーバNAT28またはクライアントNATを使用するように指定します。「NATの設定」を参照してください。
ステップ 12	ssl-proxy(config-ssl-proxy)# certificate rsa general-purpose trustpoint trustpoint_label	（任意）トラストポイントの設定をクライアント プロキシに適用します。 （注） トラストポイントはCAサーバ、鍵パラメータと鍵生成方法、およびプロキシ サーバの証明書登録方法を定義します。トラストポイントの設定手順については、「トラストポイントの宣言」を参照してください。
ステップ 13	ssl-proxy(config-ssl-proxy)# inservice	プロキシ サーバを管理上のアップに設定します。

次に、SSLクライアント プロキシ サービスを設定する例を示します。

クライアント証明書認証の設定

SSLモジュールをSSLサーバとして設定する場合、SSLクライアントを認証するように、SSLモジュールを設定することができます。この場合、SSLモジュールはSSLクライアントからの証明書を認証するよう要求します。

SSLクライアントを認証するには、SSLモジュールで次の点を確認する必要があります。

• あるレベルの証明書が、次のレベルで発行者により適切に署名されている。

• 証明書チェーン内の最低1つの発行者の証明書が、SSLプロキシ サービスにより信頼されている。

• 証明書チェーン内に、CRLに表示されていたり、ACLに拒否されている証明書がない。

SSLクライアント証明書を確認するために、SSLモジュールは信頼されるCAのリスト（CAプール）により設定されます。信頼されるCAプールは、データベース内の信頼されるCAのサブセットです。SSLモジュールは、CAプールで設定されたCAが発行する証明書のみを信頼します。

SSLモジュールをSSLサーバとして設定し、クライアントの証明書を認証する必要がある場合、

（注） プロキシ サービスを操作上のアップにするには、CAプール内に証明書付きのトラストポイントが、最低1つは存在する必要があります。CAプール内に証明書付きのトラストポイントがない場合、プロキシ サービスは自動的にダウンされます。

（注） CAプール内にこの階層の特定レベルのCAが含まれない場合は、認証されない可能性があります。このタイプのエラーを回避して、認証でsignature-onlyの確認を行う際の効率を改善するには、すべてのレベルの下位CAおよびルートCAを合わせて、CAプールに追加します。

（注） CAのトラストポイントが削除される場合、これに対応するトラストポイントを信頼されるCAプールから削除する必要があります。

クライアント認証を設定する手順は、次のとおりです。

	コマンド	目的
ステップ 1	ssl-proxy(config)# ssl-proxy pool ca_pool_name	CAプールを作成します。 （注） 最大8つのプールを作成できます。
ステップ 2	ssl-proxy(config-ssl-proxy)# ca trustpoint ca_trustpoint_label29	信頼されるCAをプールに追加します。 （注） 各プールには、最大16のCAを追加することができます。
ステップ 3	ssl-proxy(config-ssl-proxy)# exit	configモードに戻ります。
ステップ 4	ssl-proxy(config)# ssl-proxy service proxy_name	SSLサーバ プロキシ サービスの名前を定義します。
ステップ 5	ssl-proxy(config-ssl-proxy)# trusted-ca ca_pool_name	信頼されるCAプールをプロキシ サービスに関連付けます。
ステップ 6	ssl-proxy(config-ssl-proxy)# authenticate verify { signature-only30 | all31 }	クライアント証明書認証をイネーブルにして、確認形式を指定します。 （注） signature-onlyキーワードを使用すると、CRLの検索またはACLとの適合は行われず、シグニチャのみが確認されます。デフォルトはallです。
ステップ 7	ssl-proxy(config-ssl-proxy)# exit	コンフィギュレーション モードを終了します。

次に、シグニチャのみ（signature-only）を確認して、クライアント証明書認証を設定する例を示します。

次に、すべて（all）を確認して、クライアント証明書認証を設定する例を示します。

サーバ証明書認証

SSLモジュールをSSLクライアントとして設定する場合（バックエンドの暗号化に対してなど）、SSLモジュールはSSLサーバを常に認証します。

SSLサーバを認証するには、SSLモジュールで次の点を確認する必要があります。

• あるレベルの証明書が、次のレベルで発行者により適切に署名されている。

• 証明書チェーン内の最低1つの発行者の証明書が、SSLプロキシ サービスにより信頼されている。

• 証明書チェーン内に、CRLに表示されていたり、ACLに拒否されている証明書がない。

デフォルトでは、SSLモジュールは、CRLに表示されず、ACLに拒否されない証明書付きの任意のCAトラストポイントにより発行されたすべての証明書を受け入れます。

任意で、信頼されるCAプールを作成し、これをプロキシ サービスに関連付けることができます。この場合、SSLモジュールはプール内のCAにより発行された証明書のみを受け入れます。

また、 authenticate verify signature-only コマンドを入力して、シグニチャのみの確認を選択することもできます。シグニチャを確認すると、CRLおよびACLのチェックは省略されます。signature-onlyオプションを指定するには、信頼されるCAプールを設定する必要があります。

サーバ証明書認証を設定する手順は、次のとおりです。

	コマンド	目的
ステップ 1	ssl-proxy(config)# ssl-proxy pool ca_pool_name	CAプールを作成します。 （注） 最大8つのプールを作成できます。
ステップ 2	ssl-proxy(config-ssl-proxy)# ca trustpoint ca_trustpoint_label32	信頼されるCAをプールに追加します。 （注） 各プールには、最大16のCAを追加することができます。
ステップ 3	ssl-proxy(config-ssl-proxy)# exit	configモードに戻ります。
ステップ 4	ssl-proxy(config)# ssl-proxy service proxy_name client	SSLクライアント プロキシ サービスの名前を定義します。 （注） clientキーワードを入力して、SSLクライアント プロキシ サービスを設定します。
ステップ 5	ssl-proxy(config-ssl-proxy)# trusted-ca ca_pool_name	（任意）CAプールをプロキシ サービスに関連付けます。 （注） ステップ 6でsignature-onlyを指定する場合は、CAプールを設定する必要があります。
ステップ 6	ssl-proxy(config-ssl-proxy)# authenticate verify { signature-only33 | all34 }	（任意）サーバ証明書認証をイネーブルにして、確認形式を指定します。 （注） signature-onlyキーワードを使用すると、CRLの検索またはACLとの適合は行われず、署名のみが確認されます。signature-onlyを指定するには、CAプールを設定する必要があります。デフォルトはallです。
ステップ 7	ssl-proxy(config-ssl-proxy)# exit	コンフィギュレーション モードを終了します。

次に、シグニチャのみ（signature-only）を確認して、サーバ証明書認証を設定する例を示します。

次に、すべて（all）を確認して、サーバ証明書認証を設定する例を示します。

次に、すべて（all）を確認して、サーバ証明書認証を設定する例を示します。ここで、SSLモジュールはクライアントとして設定され、要求される場合はSSLサーバにその証明書を送信します。

CRL

CRLは、信頼できなくなった証明書を認識するタイムスタンプ付きのリストです。各失効証明書は、CRLで証明書のシリアル番号により認識されます。加入しているピア デバイスが証明書を使用する場合、このデバイスは証明書のシグニチャおよび有効期限に加えて、証明書のシリアル番号がこのCRLに表示されていないことを確認します。

（注） CRLのダウンロードおよび使用は、時間のかかるCPU多用型の処理です。

ここでは、CRLのダウンロードおよび設定の手順について説明します。

• 「CRLのダウンロード」

• 「CRLオプションの設定」

• 「CRLの更新」

• 「X.500 CDP情報の入力」

• 「CRLの手動入力」

• 「CRL情報の表示」

• 「CRLの削除」

CRLのダウンロード

有効とされている証明書に、CRL Distribution Point（CDP）拡張子フィールドが含まれる場合、このモジュールはCDPをダウンロード パスとして使用します。SSLモジュールは、次の3タイプのCDPをサポートします。

• HTTP URL

http://hostname/file.crlなど

• X.500 Distinguished Name（DN）

CN=CRL,O=cisco,C=usなど

• LDAP URL

ldap://hostname/CN=CRL,O=cisco,C=usなど

証明書にCDPがない場合、SSLモジュールがこの証明書に関連付けられたトラストポイントを検索します。SSLモジュールが1つまたは複数の関連するトラストポイントを認識した場合、そのトラストポイントの1つを使用して、SCEPの登録URLによりダウンロード パスおよびプロトコルを判別します。SCEPの登録URLがない場合は、認証されません。

（注） CRL要求にSCEPを使用する際は、トラストポイントに鍵ペアを関連付ける必要があります。このために、既存の鍵ペアを任意で割り当てることができます。鍵ペアは、CRLダウンロード要求に署名するために使用されます。

SSLモジュールは、ルートCA証明書上でCRL検索を実行しません。理由は、次のとおりです。

• ルートCA証明書の多くには、CDP拡張子が含まれません。CAがCRL要求に関するSCEPをサポートしない場合、CRLはダウンロードされません。

• CRLは、ルートCAにより署名されます。ルートCAが取り消された場合、CRLは無効になる可能性があります。取り消されたルートCAに関連付けられたすべてのトラストポイントは、取り消しが明らかになるとただちにデータベースから削除される必要があります。

ダウンロード パスが不明の場合、またはダウンロード処理ができない場合、ピア証明書チェーンは拒否されます。

モジュールはCRLをダウンロードしたあとで、証明書のシリアル番号がCRLに表示されているかを確認します。有効とされている証明書のシリアル番号がCRLに表示されている場合、ピア証明書チェーンは拒否されます。

（注） CA証明書の中に信頼できるものがある場合でも、ピア証明書チェーン内の1つまたは複数の証明書はCRL検索を実行しない場合があります（たとえば、CA証明書がインポートされてから取り消された場合、またはこのCAの証明書用にダウンロードされたCRLが期限切れになり、更新済みのCRLをダウンロードできない場合など）。

CRLオプションの設定

（注） ルートCAまたは下位CA証明書に関連付けられたトラストポイントが、複数存在する場合があります。証明書認証の間に、これらのトラストポイントのいずれかを選択して、CRL設定を判別することができます。一貫した認証結果を取得するには、これらのトラストポイントのすべてが同じCRL設定である必要があります。

デフォルトでは、証明書を認証するのにトラストポイントが選択された場合は常に、SSLモジュールがCRL検索を実行します。CRLがデータベースに存在しないか、または期限切れの場合は、SSLモジュールがCRLをダウンロードし、あとで使用するためにデータベースに保管しておきます。CRLをダウンロードできない場合、SSLモジュールは有効とされている証明書を拒否します。

CRL検索には、次の2つのオプションを設定することができます。

• ベストエフォート型

SSLモジュールがデータベース内のCRLを検出し、これが期限切れでない場合、SSLモジュールはCRL検索を実行します。SSLモジュールがCRLを検出できない場合、CRLのダウンロードを試みます。ただし、SSLモジュールがCRLをダウンロードできなければ、証明書を受け入れます。

• オプション型

SSLモジュールがデータベース内のCRLを検出し、これが期限切れでない場合、SSLモジュールはCRL検索を実行します。SSLモジュールがCRLを検出しなければ、証明書を受け入れます。SSLモジュールは、CRLのダウンロードを試みません。

CRLオプションを設定する手順は、次のとおりです。

CRLの更新

CRLは期限切れになるまでは、後続の証明書で再利用することができます。

指定されたCRLのNextUpdate時刻になると、CRLは削除されます。CRLの残り時間を表示するには、 show crypto ca timers コマンドを入力します。

CRLの期限は切れていないが、CRLの内容が期限切れの可能性がある場合、ただちに最新のCRLをダウンロードして、旧CRLと置き換えることができます。

ただちに最新のCRLをダウンロードするよう要求するには、次のコマンドを入力します。

（注） 新しいCRLをダウンロードすると、既存のバージョンはすべて上書きされます。

次に、トラストポイント［tp-root:］に関連付けられたCRLをダウンロードする例を示します。

X.500 CDP情報の入力

CDPがX.500 DN形式の場合、ホスト名およびポートを入力することができます。クエリには、次の形式の情報が使用されます。 ldap:// hostname :[ port ]

たとえば、有効とされている証明書には次の情報があります。

• X.500 DNは、 CN=CRL,O=Cisco,C=US で設定されます。

• 関連付けられたトラストポイントは、 crl query ldap://10.1.1.1 で設定されます。

次に、これら2つを組み合わせて完全なURLを形成します（下記を参照）。

ldap://10.1.1.1/CN=CRL,O=Cisco,C=US

（注） トラストポイントは、有効とされている証明書の発行者のCA証明書と関連付けられる必要があります。データベース内にこのようなトラストポイントがない場合は、完全なURLを形成できず、CRLダウンロードが実行されません。

X.500 URLを使用してCRLをクエリするには、次のコマンドを入力します。

CRLの手動入力

CAサーバが、オンラインで（HTTP、LDAP、またはSCEP）CRLを発行しない場合、オフラインでCRLの16進ダンプを取得し、これを手動で入力することができます。

CRLを手動で入力する手順は、次のとおりです。

次に、CRLを手動で入力する例を示します。

CRL情報の表示

CRLの情報を表示するには、次のコマンドを入力します。

次に、データベース内の各CRLの有効日時を表示する例を示します。

CRLの削除

（注） CRLは、トラストポイント単位ではなく、グローバルに削除されます。

CRLを削除するには、トラストポイントの任意の証明書チェーンに対して no crl コマンドを入力します。