- はじめに
- Cisco ISE でのネットワーク配置
- Cisco SNS-3400 シリーズ アプライアンス
- Cisco SNS-3400 シリーズ アプライアンスのインストールおよび設定
- VMware 仮想マシンでのリリース 1.2 ソフトウェアのインストール
- Cisco ISE 3300 シリーズ、Cisco NAC、および Cisco Secure ACS のアプライアンスへのリリース 1.2 ソフトウェアのインストール
- 管理者アカウントの管理
- インストール後のタスクの実行
- ラックへの Cisco SNS-3400 シリーズ アプライアンスの設置
- Cisco SNS-3400 シリーズ サーバの仕様
- Cisco SNS-3400 シリーズ アプライアンスのポート リファレンス
- Cisco ISE ライセンス
- Cisco ISE での証明書の管理
- Index
Cisco Identity Services Engine ハードウェア インストレーション ガイド リリース 1.2
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月29日
章のタイトル： Cisco ISE での証明書の管理
- Cisco ISE 証明書を使用した HTTPS 通信
- Cisco ISE 証明書を使用する EAP 通信
- Cisco ISE によるセキュアなアクセスの提供を可能にする証明書
- Cisco ISE での PKI の有効化
- ローカル証明書
- 証明書署名要求
- 証明書ストア
Cisco ISE での証明書の管理
証明書は、ネットワークに対するセキュアなアクセスを提供するために使用されます。また、証明書はエンドポイントに対して Cisco ISE を識別するため、そして、そのエンドポイントと Cisco ISE ノード間の通信のを保護するために使用されます。証明書は、すべての HTTPS 通信および拡張認証プロトコル（EAP）の通信に使用されます。
Cisco ISE 証明書を使用した HTTPS 通信
リリース 1.1.0 以降では、次のすべての Cisco ISE Web ポータルは HTTPS（TLS 暗号化された HTTP 通信）プロトコルを使用して、保護されています。
図 E-1 に、管理ポータルと通信する際の TLS 暗号化プロセスを示します。
図 E-1 HTTPS（TLS 暗号化された HTTP 通信）
Cisco ISE 証明書を使用する EAP 通信
証明書はほとんどすべての EAP 方式で使用されます。一般に使用されるのは、次の EAP 方式です。
PEAP や FAST など、トンネル型の EAP 方式の場合は、クレデンシャルの交換を保護するために、Transport Layer Security（TLS）が使用されます。HTTPS Web サイトへの要求と同様に、クライアントがサーバとの接続を確立します。サーバがクライアントへ証明書を提示します。クライアントが証明書を信頼する場合は、TLS トンネルが形成されます。クライアントのクレデンシャルはトンネルが確立されるまでサーバに送信されないため、安全な交換が保障されます。セキュアなアクセスの導入では、クライアントはサプリカントであり、サーバは ISE ポリシー サービス ノードです。図 E-2 に PEAP を使用する例を示します。
Cisco ISE によるセキュアなアクセスの提供を可能にする証明書
Cisco Identity Services Engine（ISE）は、公開キー インフラストラクチャ（PKI）に依存して、エンドポイントおよび管理者の両方とのセキュアな通信、そしてマルチノード導入環境内の複数の Cisco ISE ノード間のセキュアな通信を実現しています。PKI は X.509 デジタル証明書に依存して、メッセージの暗号化と復号化のための公開キーの転送、およびユーザとデバイスを表す他の証明書の信頼性の検証を行います。Cisco ISE には、次の 2 つの X.509 証明書のカテゴリを管理する、管理ポータルが用意されています。
•
ローカル証明書：これらはクライアント アプリケーションに対して Cisco ISE ノードを識別するサーバ証明書です。各 Cisco ISE ノードには独自のローカル証明書があり、それぞれの証明書は対応する秘密キーとともにノードに格納されています。
• 証明書ストア証明書：この証明書は、ユーザおよびデバイスから受信した公開キーの信頼を確立するために使用される認証局（CA）証明書です。証明書ストアには、Simple Certificate Enrollment Protocol（SCEP）から配信された証明書も含まれます。これにより、モバイル デバイスのエンタープライズ ネットワークへの登録が可能になります。証明書ストア内の証明書はプライマリ管理ノードで管理され、Cisco ISE の導入環境内の他のすべてのノードに自動的に複製されます。
分散導入環境では、証明書をプライマリ管理ノードの証明書信頼リスト（CTL）のみにインポートする必要があります。この証明書はセカンダリ ノードに複製されます。
一般に、Cisco ISE での証明書認証が、証明書による認証機能のわずかな違いの影響を受けないようにするために、ネットワークに導入されているすべての Cisco ISE ノードには小文字のホスト名を使用してください。
Cisco ISE での PKI の有効化
次のようにして、Cisco ISE で PKI を有効にする必要があります。
ステップ 1 ブラウザおよび REST クライアントが Cisco ISE Web ポータルへのアクセスするのに使用する、TLS 対応の認証プロトコル（たとえば、EAP-TLS プロトコル）および HTTPS を対象として、各導入ノードでローカル証明書を確立します。
デフォルトでは、Cisco ISE ノードには両方の目的に使用される自己署名証明書があらかじめインストールされています。一般的な企業環境では、この証明書は、信頼された CA によって署名された 1 つおよび 2 つののサーバ証明書に置き換えられます。
ステップ 2 証明書ストアに、ユーザとの信頼を確立するために必要な CA 証明書と、Cisco ISE に提示されるデバイス証明書を配置します。
ユーザまたはデバイスの証明書の信頼性を検証するために、ルート CA 証明書と 1 つ以上の中間 CA 証明書で構成される証明書チェーンが必要な場合は、証明書ストアにそのチェーン全体をインポートする必要があります。
• 証明書署名要求を生成し、CA 署名付きの証明書をインポートする方法の詳細については、「ローカル証明書」を参照してください。
• これらの証明書チェーンをインポートする方法の詳細については、「証明書ストア」を参照してください。
Cisco ISE ノードはノード間の通信に HTTPS を使用するため、管理者は、Cisco ISE 導入環境内の各ノードに属する HTTPS ローカル証明書を検証するために必要な信頼証明書を、証明書ストアに配置する必要があります。デフォルトの自己署名証明書を HTTPS に使用する場合は、各 Cisco ISE ノードからこの証明書をエクスポートし、証明書ストアにインポートする必要があります。自己署名証明書を CA 署名証明書で置き換える場合に必要なのは、適切なルート CA 証明書および中間 CA 証明書を証明書ストアに配置することだけです。この手順を完了するまでは、ノードを Cisco ISE 導入環境に登録できないことに注意してください。
導入した Cisco ISE が FIPS モードで動作するようにする場合、すべてのローカル証明書および証明書ストアの証明書が FIPS 準拠であることを確認する必要があります。つまり、各証明書のキー サイズが 2048 バイト以上であり、SHA-1 または SHA-256 暗号化を使用する必要があります。
（注） スタンドアロンの Cisco ISE またはプライマリ管理ノードからバックアップを取得した後に導入環境内の 1 つ以上のノードの証明書設定を変更する場合は、データを復元するために、もう一度バックアップを取得する必要があります。そうしないで古いバックアップを使用してデータを復元すると、ノード間の通信が失敗する可能性があります。
• 「証明書ストア」
ローカル証明書
Cisco ISE ローカル証明書は、クライアント アプリケーションに対して Cisco ISE ノードを識別するサーバ証明書です。ローカル証明書は、
• Cisco ISE Web ポータルにブラウザおよび REST クライアントで使用されます。これらの接続には HTTPS プロトコルを使用する必要があります。
• PEAP および EAP-FAST を使用する外部 TLS トンネルを形成するために使用される。これらの証明書は、EAP-TLS、PEAP、および EAP-FAST を使用した相互認証に使用できます。
Cisco ISE 導入環境内の各ノードに HTTPS および EAP-TLS 用の有効なローカル証明書をインストールする必要があります。デフォルトでは、自己署名証明書はインストール時に Cisco ISE ノードに作成されます。また、この証明書は、HTTPS、および EAP-TLS を使用するために設計されています（キーの長さは 1024 で、1 年間有効です）。セキュリティを強化するために、自己署名証明書を CA 署名証明書で置き換えることが推奨されます。
ワイルドカード証明書
ワイルドカード証明書はワイルドカード表記（ドメイン名の前にアスタリスクとピリオドの形式）を使用し、組織の複数のホスト間で証明書を共有できるようにします。たとえば、証明書サブジェクトの CN 値は aaa.ise.local などの汎用ホスト名であり、SAN フィールドには、同じ汎用ホスト名と DNS.1=aaa.ise.local および DNS.2=*.ise.local などのワイルドカード表記が含まれます。
*.ise.local を使用してワイルドカードの証明書を設定している場合は、同じ証明書を使用して、次のような、DNS 名が「.ise.local」で終了する他の任意のホストを保護することができます。
図 E-3 に、Web サイトを保護するために使用されるワイルドカードの証明書の例を示します。
ワイルドカード証明書は通常の証明書と同じ方法で通信を保護し、要求は同じ検証方式を使用して処理されます。
• 「HTTPS および EAP 通信用のワイルドカード証明書」
HTTPS および EAP 通信用のワイルドカード証明書
SSL/TLS トンネリングを使用する HTTPS（Web ベースのサービス）および EAP プロトコルに対して、Cisco ISE でワイルドカード サーバ証明書を使用できます。ワイルドカードの証明書を使用することにより、各 Cisco ISE ノード用の固有の証明書を生成する必要がなくなります。また、証明書の警告を防ぐために、SAN フィールドに複数の FQDN 値のを入力する必要もありません。SAN フィールドでアスタリスク（*）を使用すると、導入環境内の複数のノードで単一の証明書を共有できるようになり、証明書名の不一致による警告を防止することができます。ただし、ワイルドカード証明書は、各 Cisco ISE ノードに固有のサーバ証明書を割り当てる場合より、安全性が低いと見なされます。
（注） ワイルドカード証明書を使用する場合は、セキュリティを強化するためにドメイン領域を分割することを推奨します。たとえば、*.example.com の代わりに *.amer.example.com を使用して領域を分割することができます。ドメインを分割しないと、重大なセキュリティ問題が発生する可能性があります。
ワイルドカード証明書では、ドメイン名の前にアスタリスク（*）およびピリオドが使用されます。たとえば、証明書のサブジェクト名の CN 値は aaa.ise.local などの汎用ホスト名になり、SAN フィールドには *.ise.local のようなワイルドカード文字が入力されます。Cisco ISE は、ワイルドカード証明書（表示される ID の一番左の文字がワイルドカード文字（*））をサポートします。たとえば、*.example.com または *.ind.example.com です。表示される ID にワイルドカード文字とともに追加の文字が含まれた証明書はサポートされません。たとえば、abc*.example.com、a*b.example.com、または *abc.example.com です。
Cisco ISE リリース 1.2 におけるワイルドカード証明書のサポート
Cisco ISE リリース 1.2 は、ワイルドカード証明書をサポートしています。リリース 1.2 よりも前の Cisco ISE では、HTTPS に対して有効になったすべての証明書を検証し、CN フィールドがホストの完全修飾（FQDN）が正確に一致することが確認されます。フィールドが一致しない場合、その証明書は HTTPS 通信に使用できませんでした。
1.2 より前のリリースでは、Cisco ISE はその CN 値 を使用して、URL リダイレクト A-V ペア文字列内の変数を置き換えます。この CN 値は、すべての Centralized Web Authentication（CWA）、オンボーディング、ポスチャのリダイレクトなどに使用されます。
URL リダイレクトの完全修飾ドメイン名
Cisco ISE が承認プロファイル リダイレクトを構築（中央集中型 Web認証、デバイス登録 Web 認証、ネイティブ サプリカントのプロビジョニング、モバイル デバイス管理、およびクライアントのプロビジョニングとポスチャ サービスに対して）する場合、結果の cisco-av-pair ペアには、次のような文字列が含まれます。
url-redirect=https://ip:port/guestportal/gateway?sessionId=SessionIdValue&action=cwa
この要求を処理するときに、Cisco ISE は文字列の一部のキーワードを実際の値で置き換えます。たとえば、SessionIdValue は、要求の実際のセッション ID に置き換えられます。eth0 インターフェイスの場合、Cisco ISE は URL 内の IP を Cisco ISE ノードの FQDN で置き換えます。eth0 以外のインターフェイスの場合、Cisco ISE は URL 内の IP アドレスを使用します。インターフェイス eth1 から eth3 にはホストのエイリアス（名前）を割り当てることができます。このエイリアスは Cisco ISE が URL リダイレクト時に IP アドレスの代わりに置き換えることができます。これを行うには、次のように、Cisco ISE CLI から設定モードで ip host コマンドを使用できます。
ISE /admin(config)# ip host IP_address host-alias FQDN-string
ここで、 IP_address はネットワーク インターフェイス（eth1、eth2、または eth3）の IP アドレスです。
host-alias はネットワーク インターフェイスに割り当てる名前です。
FQDN-string は、ネットワーク インターフェイスの完全修飾ドメイン名です。
このコマンドを使用して、ネットワーク インターフェイスに host-alias または FQDN-string あるいはその両方を割り当てることができます。
eth0 以外のインターフェイスにホストのエイリアスを割り当てたら、 application start ise コマンドを使用して Cisco ISE でアプリケーション サービスを再起動する必要があります。
このホスト エイリアスのネットワーク インターフェイスとの関連付けを削除するには、次のようにこのコマンドの no 形式を使用します。
ISE/admin(config)# no ip-host IP_address host-alias FQDN-string
ホストのエイリアスの定義を表示するには、 show running-config コマンドを使用します。
FQDN 文字列を指定している場合は、その FQDN で URL 内の IP アドレスが置き換えられます。ホストのエイリアスのみを指定した場合は、そのホスト エイリアスと設定された IP ドメイン名を結合して完全な FQDN が結合され、URL 内の IP アドレスがその FQDN で置き換えられます。ネットワーク インターフェイスをホストのエイリアスにマッピングしない場合は、URL 内のネットワーク インターフェイスの IP アドレスが使用されます。
クライアントのプロビジョニング、ネイティブ サプリカント、またはゲスト フローに対して eth0 以外のインターフェイスを使用する場合は、eth0 以外のインターフェイスの IP アドレスまたはホスト エイリアスがポリシー サービス ノードの証明書の SAN フィールドに適切に設定されていることを確認する必要があります。
ワイルドカード証明書を使用する利点
• コスト削減。サードパーティの認証局によって署名された証明書には高額な費用がかかります（特にサーバ数が多い場合）。ワイルドカード証明書は、Cisco ISE 導入環境内の複数ノードで使用できます。
• 運用の効率化。ワイルドカード証明書は、すべてのポリシー サービス ノード（PSN）EAP および Web サービスが同じ証明書を共有することを可能にします。証明書を 1 回作成して、すべての PSN に適用することにより、コストを大幅に削減できるだけでなく、証明書の管理も簡素化されます。
• 認証エラーの低減。ワイルドカード証明書は、クライアントがプロファイル内に信頼された証明書を保存しており、そのクライアントが iOS のキーチェーン（署名ルートが信頼されている）に従っていない Apple iOS デバイスで発生する問題に対処します。iOS クライアントが最初に PSN と通信する際、このクライアントはその PSN の証明書を（信頼された認証局が署名している場合でも）明示的に信頼しません。ワイルドカード証明書を使用すると、この証明書がすべての PSN で同一になるため、ユーザは証明書の受け入れを 1 回行えばよく、その後の異なる PSN に対する認証はエラーやプロンプトが表示されることなく進行します。
• 簡素化されたサプリカントの設定。たとえば、PEAP-MSCHAPv2 およびサーバ証明書の信頼が有効化された Microsoft Windows サプリカントで、各サーバ証明書を信頼するように指定することが必要とされており、そのように指定されていない場合、そのクライアントが別の PSN を使用して接続を行うと、各 PSN 証明書を信用するように、ユーザにプロンプトが出される可能性があります。ワイルドカード証明書を使用すると、各 PSN の個別の証明書ではなく、単一のサーバ証明書を信頼するだけで済みます。
• ワイルドカード証明書を使用すると、プロンプトの提示が減り、よりシームレスな接続が実現されることにより、ユーザ エクスペリエンスが改善されます。
ワイルドカード証明書を使用することの欠点
次に、ワイルドカード証明書に関連するセキュリティ上の考慮事項の一部を説明します。
ワイルドカード証明書は ISE ノードごとの固有のサーバ証明書より安全性が低いと見なされています。ただし、コスト、およびその他の運用関連の要因がセキュリティ リスクに勝っています。
ASA などのセキュリティ デバイスも、ワイルドカード証明書をサポートしています。
ワイルドカード証明書を導入する場合には注意が必要です。たとえば、*.company.local を使用して証明書を作成したとします。該当の秘密キーを攻撃者が回復できた場合、攻撃者は company.local ドメイン内のすべてのサーバをスプーフィングすることができます。したがって、このタイプの危険を回避するために、ドメイン領域を分割することがベスト プラクティスと見なされています。
この想定される問題に対処し、利用範囲を制限するために、ワイルドカード証明書を使用して組織の特定のサブドメインを保護することもできます。ワイルドカードを指定する一般名のサブドメイン領域に、アスタリスク（*）を追加します。
たとえば、*.ise.company.local に対してワイルドカード証明書を設定すると、その証明書は次のような、DNS 名が「.ise.company.local」で終わるすべてのホストを保護するために使用できます。
ワイルドカード証明書の互換性
ワイルドカード証明書は、通常図 E-3 の例にあるような、一般名（CN）としてリストされているワイルドカードを使用して作成されます。Cisco ISE リリース 1.2 は、このタイプの作成をサポートします。ただし、すべてのエンドポイント サプリカントが証明書サブジェクトのワイルドカード文字をサポートするわけではありません。
テスト済みのすべての Microsoft ネイティブ サプリカント（Windows Mobile を含む）の一部は、証明書のサブジェクトのワイルドカード文字をサポートしていません。
Cisco AnyConnect Network Access Manager（NAM）など、[Subject（サブジェクト）] フィールドでのワイルドカード文字の使用をサポートできる他のサプリカントを使用することができます。
また、DigiCert の Wildcard Plus など、証明書のサブジェクト代替名に特定のサブドメインを含めることで、互換性のないデバイスを使用するように設計された、特別なワイルドカード証明書を使用することもできます。
Microsoft サプリカントの制限はワイルドカード証明書の使用にとって妨げになるように見えますが、Microsoft のネイティブ サプリカントを含む、セキュアなアクセスについてテスト済みのすべてのデバイスを使用できるようにする代替の方法があります。
このためには、サブジェクトにワイルドカードを使用する代わりに、[Subject Alterative Name (SAN)（サブジェクト代替名（SAN））] フィールドでワイルドカード文字を使用します。SAN フィールドはドメイン名（DNS 名）を検査するように設計された拡張を保持します。詳細については、RFC 6125 および 2128 を参照してください。
ワイルドカード証明書の Microsoft サポートの詳細については、次を参照してください。 http://technet.microsoft.com/en-US/cc730460
ワイルドカードの証明書の作成
この項では、ワイルドカード証明書を作成する方法について説明します。この手順は、ほとんどの SSL 証明書のプロバイダーに適用されます。
ただし SSL 証明書プロバイダーが証明書の SAN フィールドにおけるワイルドカード値をサポートしていない場合は、証明書の SAN に各 ISE ノードのおよびインターフェイスの FQDN を設定します（ip host コマンドを使用して指定されたエイリアスごと）。この証明書は複数ドメイン証明書と呼ばれます。デバイス ポータルおよびスポンサー ポータルで使用されるような特定のサービス エイリアスの FQDN も、証明書の SAN に含める必要があります。ISE 管理ポータル、スポンサー ポータル、およびデバイス ポータルに対するローカル Web 認証ネットワーク認証など、一部のサービスではロード バランサを使用できます。このような場合は、証明書の SAN フィールドに、ロード バランス対象のサービスの仮想 IP アドレスに割り当てられた FQDN を含める必要があります。
（注） HTTPS および EAP 認証に別々の証明書を使用することもできます。HTTPS に対して指定された証明書はノード間の通信およびすべての Web ポータル サービス（中央集中型 Web 認証、DRW、ポスチャの検出と評価、モバイル デバイス管理、ネイティブ サプリカントのプロビジョニング、スポンサー、および自分のデバイスのポータルなど）を保護するために使用されます。EAP に指定された証明書は、PEAP、EAP-TLS、EAP-FAST など、EAP プロトコルを使用するすべてのクライアント認証を保護するために使用されます。
たとえば 2 つの PSN ノードがある ISE の導入環境（eth0、eth1、および eth2 インターフェイスが有効になった psn1 および psn2）を使用しており、ワイルドカードを使用せずに複数ドメインの証明書を作成する場合、値は次のようになります。
CN=aaa.company.local（導入環境内の ISE ノードの FQDN）
SAN=DNS.1=aaa.company.local、DNS.2=psn1.company.local、DNS.3=psn2.company.local、DNS.4=psn1-e1.company.local、DNS.5=psn2-e1.company.local、DNS.6=psn1-e2.company.local、DNS.7=psn2-e2.company.local。
ヒント 追加のポリシー サービス ノードを今後導入することを計画している場合は、SAN フィールドに追加の DNS 名のエントリを追加して、新しいノードの導入時に同じ証明書を再利用できるようにします。
証明書の SAN フィールドに IP アドレスを指定する必要がある場合は（たとえば、URL リダイレクションのための固定 IP アドレスを使用する DMZ）証明書の SAN フィールドの DNS 名および IP アドレスとして、該当のポリシー サービス ノードの IP アドレスを指定していることを確認します。たとえば、CN=psn.ise.local および SAN=DNS.1=psn.ise.local、DNS.2=*.ise.local、DNS.3= 10.1.1.20、IP.1=10.1.1.20 のようになります。
Microsoft のネイティブ サプリカントの場合は、証明書の SAN フィールドでワイルドカードを使用します。
ステップ 1 サブジェクトの CN フィールドに汎用のホスト名を入力します。たとえば、CN=aaa.ise.local のようになります。
ステップ 2 証明書の SAN フィールドに同じ汎用のホスト名とワイルドカード表記を入力します。たとえば、DNS Name=aaa.ise.local、DNS Name=*.ise.local のようになります。図 E-3を参照してください。
この方法は、Comodo.com や SSL.com など、大部分のテスト済みのパブリック認証局で成功します。これらの パブリック CA を使用する場合は、「Unified Communications Certificates（UCC）」を要求する必要があります。
Cisco ISE へのワイルドカード証明書のインストール
eth0 以外のインターフェイスを有効にしている場合は、CLI で ip host コマンドを使用して、必ずそのインターフェイスにホストのエイリアスをマッピングします。詳細については、「 URL リダイレクトの完全修飾ドメイン名」を参照してください。
ワイルドカード証明書をインストールするには、次のタスクを実行する必要があります。
ステップ 1 ワイルドカード証明書の証明書署名要求を作成します。「ワイルドカード証明書に対する証明書署名要求の作成」を参照してください。
ステップ 2 証明書署名要求をエクスポートします。「証明書署名要求のエクスポート」を参照してください。
ステップ 3 証明書署名要求を認証局へ送信します。「認証局への CSR の送信」を参照してください。
ステップ 4 証明書ストアにルート証明書をインポートします。「証明書ストアへのルート証明書のインポート」を参照してください。
ステップ 5 証明書署名要求を新しいパブリック証明書にバインドします。「新しいパブリック証明書と CSR のバインド」を参照してください。
ステップ 6 CA 署名付き証明書と秘密キーをエクスポートします。「CA 署名付き証明書と秘密キーのエクスポート」を参照してください。
ステップ 7 すべてのポリシー サービス ノードに CA 署名付き証明書と秘密キーをインポートします。「ポリシーのサービス ノードへの CA 署名付き証明書のインポート」を参照してください。
ワイルドカード証明書に対する証明書署名要求の作成
ステップ 1 [Administration（管理）] > [Certificates（証明書）] > [Local Certificates（ローカル証明書）] を選択します。
ステップ 2 [Add（追加）] > [Generate Certificate Signing Request（証明書署名要求の作成）] をクリックします。
ステップ 3 証明書のサブジェクトに、ポリシーのサービス ノードのいずれかの汎用 FQDN を入力します。たとえば、CN=psn.ise.local です。
ステップ 4 SAN に 2 つの値を入力します。値の 1 つは、証明書のサブジェクトに入力した CN と同じである必要があります。もう 1 つの値はワイルドカード表記です。たとえば、DNS name=psn.ise.local、DNS name=*.ise.local のようになります。
ステップ 5 [Allow Wildcard Certificates（ワイルドカード証明書の許可）] チェックボックスをオンにします。
証明書署名要求のエクスポート
ステップ 1 [Administration（管理）] > [Certificates（証明書）] > [Certificate Signing Requests（証明書署名要求）] を選択します。
ステップ 2 作成した CSR の横にあるチェックボックスをオンにします。たとえば、psn.ise.local です。
ステップ 3 [Export（エクスポート）] をクリックします。
認証局への CSR の送信
ステップ 1 CSR をメモ帳などのテキスト エディタで開きます。
ステップ 2 「-----BEGIN CERTIFICATE REQUEST-----」から「-----END CERTIFICATE REQUEST-----」までのテキストをコピーします。
ステップ 3 選択した CA の証明書要求に、この CSR の内容を貼ってください。図 E-5を参照してください。
図 E-5 証明書署名要求フォームの CSR のコンテンツ：Active Directory CA
CA によっては、署名付き証明書が電子メールで送信される場合があります。署名付き証明書は、zip ファイルの形式で、Cisco ISE の信頼された証明書ストアに追加する必要がある、新規発行の証明書と CA のパブリック署名証明書が含まれています。図 E-6を参照してください。
証明書ストアへのルート証明書のインポート
Cisco ISE の CSR に新規の署名付き証明書をバインドする前に、署名ルート証明書が Cisco ISE 証明書ストアにあることを確認します。
ステップ 1 [Administration（管理）] > [Certificates（証明書）] > [Certificate Store（証明書ストア）] を選択します。
ステップ 2 [Import（インポート）] をクリックします。
ステップ 3 CA によって返されたルート証明書を選択します。
新しいパブリック証明書と CSR のバインド
ステップ 1 [Administration（管理）] > [Certificates（証明書）] > [Local Certificates（ローカル証明書）] を選択します。
ステップ 2 [Add（追加）] > [Bind CA signed Certificate（CA 署名付き証明書のバインド）] をクリックします。
ステップ 4 [Allow Wildcard Certificates（ワイルドカード証明書の許可）] チェックボックスをオンにします。
CA 署名付き証明書と秘密キーのエクスポート
ステップ 1 [Administration（管理）] > [Certificates（証明書）] > [Local Certificates（ローカル証明書）] を選択します。
ステップ 2 エクスポートする CA 署名付き証明書の横にあるチェックボックスをオンにし、[Export（エクスポート）] をクリックします。
ポリシーのサービス ノードへの CA 署名付き証明書のインポート
ステップ 1 [Administration（管理）] > [Certificates（証明書）] > [Certificate Store（証明書ストア）] を選択します。
ステップ 2 エクスポートした CA 署名付き証明書を選択します。
Cisco ISE での CA 署名付き証明書のインストール
CA 署名付き証明書をインストールするための手順は次のとおりです。
ステップ 1 CA 署名付き証明書を必要とするノードの Cisco ISE 管理インターフェイスで、証明書署名要求（CSR）を生成します。
ステップ 3 CSR ファイルを認証局に提供し、その CA に、CSR に指定された属性を使用して証明書を作成し、署名するよう要求します。CA が、証明書をファイルで返します。
ステップ 4 同じノードの Cisco ISE 管理インターフェイスで、ノードに CSR とともに保持されている秘密キーに CA 署名付き証明書を バインドします。HTTPS または EAP-TLS 用に使用する証明書を指定します。
（注） HTTPS に CA 署名付き証明書を使用する場合、CSR に対して指定されるサブジェクトの一般名の値が Cisco ISE ノードの完全修飾ドメイン名（FQDN）に一致するか、証明書の SAN/CN フィールドで指定されているワイルドカード ドメイン名に一致する必要があります。
Cisco ISE は、サブジェクト名の一致を次のようにして確認します。
1. 証明書のサブジェクト代替名（SAN）の拡張が確認されます。SAN に 1 つ以上の DNS 名が含まれている場合は、それらの DNS 名の 1 つが Cisco ISE ノードの FQDN に一致している必要があります。ワイルドカード証明書が使用されている場合、ワイルドカード ドメイン名は Cisco ISE ノードの FQDN ドメインに一致している必要があります。
2. SAN に DNS 名が存在しない場合、または SAN 全体が欠落している場合は、証明書の Subject フィールドの一般名（CN）または証明書の Subject フィールドのワイルドカード ドメインが、ノードの FQDN に一致している必要があります。
（注） Cisco ISE にインポートされる X.509 証明書は、Privacy Enhanced Mail（PEM）または Distinguished Encoding Rules（DER）形式である必要があります。 証明書チェーン（ローカル証明書、およびその証明書に署名する一連の信頼された証明書）が含まれたファイルはインポートすることができますが、特定の制限の対象となります。詳細については、「証明書チェーンのインポート」を参照してください。
X.509 証明書が有効なのは、指定された特定の日付までのみです。ローカル証明書が期限切れになった場合、その証明書に依存する Cisco ISE 機能が影響を受けます。Cisco ISE は、有効期限が 90 日以内になると、ローカル証明書の有効期限の保留について通知します。この通知は、いくつかの方法で表示されます。
• 配色された有効期限の状態アイコンが、[Local Certificates（ローカル証明書）] ページに表示されます。
• 期限切れメッセージが Cisco ISE システム診断レポートに表示されます。
• 有効期限のアラームは、有効期限の 90 日前、60 日前に生成され、有効期限前の最後の 30 日間には毎日生成されます。
失効した証明書が自己署名証明書の場合は、この証明書を編集して有効期限を延長できます。CA 署名付き証明書の場合は、CA から新しい証明書を取得するのに十分な期間を取ってください。
Cisco ISE 管理インターフェイスから次のタスクを実行して、ローカル証明書を管理できます。
• Cisco ISE ノードに保存されたローカル証明書のリストを表示する。リストには、有効期限の状態とともに、各証明書プロトコルの割り当て（HTTPS、EAP-TLS）が表示されます。
• ローカル証明書と、オプションで秘密キーをエクスポートする
ローカル証明書の表示
[Local Certificate（ローカル証明書）] ページに、Cisco ISE に追加されたすべてのローカル証明書が一覧表示されます。
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Local Certificates（ローカル証明書）] を選択します。
[Local Certificate（ローカル証明書）] ページが表示されます。このページには、ローカル証明書に関する次の情報が表示されています。
• [Friendly Name（わかりやすい名前）]：証明書の名前。
• [Protocol（プロトコル）]：証明書を使用するプロトコル。
• [Issued To（発行先）]：証明書のサブジェクトの一般名。
• [Issued By（発行者）]：証明書の発行者の一般名。
• [Valid From（有効期限の開始）]：証明書の作成日付（[Not Before（作成日付後）] 証明書属性）。
• [Expiration Date（有効期限）]：証明書の有効期限（[Not After（有効期限前）] 証明書属性）。
• [Expiration Status（有効期限のステータス）]：証明書の有効期限がいつ切れるかを示します。ここには、アイコンが関連付けられた 5 つのカテゴリがあります。
1. [Expiring in more than 90 days（有効期限が 90 日以上先）]（緑のアイコン）
2. [Expiring in 90 days or less（有効期限が 90 日以内）]（青のアイコン）
3. [Expiring in 60 days or less（有効期限が 60 日以内）]（青のアイコン）
4. [Expiring in 30 days or less（有効期限が 30 日以内）]（青のアイコン）
ローカル証明書の追加
次のいずれかの方法で、ローカル証明書を Cisco ISE に追加できます。
• 「証明書署名要求の生成」および「CA 署名付き証明書のバインディング」
ワイルドカード証明書のインポートを計画している場合は、必ず次の項をお読みください。
• 「Cisco ISE へのワイルドカード証明書のインストール」
（注） Firefox および Internet Explorer 8 ブラウザを使用している場合、あるノードにある HTTPS ローカル証明書を変更すると、そのノードに接続された既存のブラウザ セッションでは新しい証明書への自動的な切り替えは行われません。新しい証明書を表示するには、ブラウザを再起動する必要があります。
ローカル証明書のインポート
ローカル証明書をインポートすることにより、新しいローカル証明書を追加できます。
クライアント ブラウザを実行しているシステムに、ローカル証明書と秘密キー ファイルがあることを確認します。
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
インポートするローカル証明書に基本制約拡張が含まれていて CA フラグが true に設定されている場合は、キー使用拡張が存在することと、keyEncipherment ビットと keyAgreement ビットの一方または両方が設定されていることを確認してください。
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Local Certificates（ローカル証明書）] を選択します。
ローカル証明書をセカンダリ ノードにインポートするには、[Administration（管理）] > [System（システム）] > [Server Certificate（サーバ証明書）] を選択します。
ステップ 2 [Add（追加）] > [Import Local Server Certificate（ローカル サーバ証明書のインポート）] を選択します。
ステップ 3 [Browse（参照）] をクリックして、クライアント ブラウザを実行しているシステムから証明書ファイルと秘密キーを選択します。
秘密キーが暗号化されている場合は、パスワードを入力して復号化します。
ステップ 4 証明書のフレンドリ名を入力します。名前を入力しない場合は、 <common name> # <issuer> # <nnnnn> の形式で自動的に名前が作成されます。ここで、 <nnnnn> は固有の 5 桁の数値です。
ステップ 5 Cisco ISE に証明書の拡張の検証を許可する場合は、[Enable Validation of Certificate Extensions（証明書の拡張の検証を許可）] チェックボックスをオンにします。
[Enable Validation of Certificate Extensions（証明書の拡張の検証を許可）] チェックボックスがオンになっており、インポートする証明書に CA フラグ が true に設定された基本制約拡張が含まれている場合は、キー使用拡張が存在しており、keyEncipherment ビットまたは keyAgreement ビット、あるいはその両方が設定されていることを確認します。
ステップ 6 ワイルドカード証明書（サブジェクトまたはサブジェクト代替名の DNS 名、またはその両方にアスタリスク（*）が含まれている証明書）をインポートする場合は、[Allow Wildcard Certificates（ワイルドカード証明書の許可）] チェックボックスをオンにします。
ステップ 7 [Protocol group（プロトコル グループ）] ボックスで、次のようにします。
• Cisco ISE ノードを識別する EAP プロトコルでこの証明書を使用するには、[EAP] チェックボックスをオンにします。
• この証明書を Web サーバの認証に使用するには、[HTTPS] チェックボックスをオンにします。
[Management Interface（管理インタフェース）] チェックボックスをオンにする場合は、証明書サブジェクトの一般名の値がノード完全修飾ドメイン名（FQDN）またはワイルドカード表記（ワイルドカード証明書が使用されている場合）に一致していることを確認してください。そうしない場合、インポート プロセスは失敗します。
ステップ 8 既存の証明書を複製した証明書で置き換えるには、[Replace Certificate（証明書を置き換える）] チェックボックスをオンにします。証明書のサブジェクトまたは発行者、およびシリアル番号が既存の証明書と同じ場合、その証明書は複製と見なされます。このオプションでは証明書の内容が更新されますが、証明書の既存のプロトコルの選択は保持されます。
（注） Cisco ISE を FIPS モードで動作するように設定する場合、証明書の RSA キー サイズは 2048 ビット以上であり、SHA-1 または SHA-256 ハッシュ アルゴリズムを使用する必要があります。
ステップ 9 ローカル証明書をインポートするには、[Submit（送信）] をクリックします。
プライマリ Cisco ISE ノードにローカル証明書をインポートし、管理インターフェイス オプションが導入環境内のノードで有効になっている場合は、ノードのアプリケーション サーバが自動的に再起動されます。それ以外の場合は、プライマリ Cisco ISE ノードに接続されているセカンダリ ノードを再起動します。
CLI からセカンダリ ノードを再起動するには、指定された順序で次のコマンドを入力してください。
これらのコマンドの詳細については、『 Cisco Identity Services Engine CLI Reference Guide, Release 1.2（Cisco Identity Services Engine CLI リファレンス ガイド リリース 1.2） 』を参照してください。
自己署名証明書の生成
自己署名証明書を生成することにより、新しいローカル証明書を追加できます。自己署名証明書は、内部テストと評価のニーズに対してのみ使用することを推奨します。実稼働環境に Cisco ISE を導入することを計画している場合、可能な場合は CA 署名付き証明書を使用して、実稼働ネットワーク全体でより均一な受け入れが行われるようにします。
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
[Administration（管理）] > [System（システム）] > [Certificates（証明書）]
> [Local Certificates（ローカル証明書）]
を選択します。
セカンダリ ノードから自己署名証明書を生成するには、[Administration（管理）] > [System（システム）] > [Server Certificate（サーバ証明書）] を選択します。
ステップ 2 [Add（追加）] > [Generate Self Signed Certificate（自己署名証明書の生成）] を選択します。
ステップ 3 [Generate Self Signed Certificate（自己署名証明書の生成）] ページで、次の情報を入力してください。
• 証明書サブジェクト ：証明書に関連付けられているエンティティを識別する識別名（DN）。DN には一般名（CN）値が含まれている必要があります。
• サブジェクト代替名 ：証明書に関連付けられた DNS 名または IP アドレス。
• 必要な キーの長さ ：有効な値は 512、1024、2048、および 4096 です。Cisco ISE を FIPS 準拠のポリシー管理エンジンとして導入する場合は、2048 ビット以上のキーの長さを指定する必要があります。
• 署名するダイジェスト ：SHA-1 または SHA-256 を使用して証明書を暗号化および復号化できます。
• 証明書の 期限切れ TTL ： 有効期限の期間を日、週、月、または年単位で指定できます。
• 証明書の フレンドリ名 を指定する場合は、フレンドリ名を秘密キー パスワードの下のフィールドに入力します。名前を入力しない場合は、 <common name> # <issuer> # <nnnnn> の形式で自動的に名前が作成されます。ここで、 <nnnnn> は固有の 5 桁の数値です。
ステップ 4 自己署名したワイルドカード証明書（サブジェクトまたはサブジェクト代替名の DNS 名、またはその両方にアスタリスク（*）が含まれている証明書）を作成する場合は、[Allow Wildcard Certificates（ワイルドカード証明書の許可）] チェックボックスをオンにします。たとえば、SAN に割り当てられている DNS 名が *.amer.cisco.com の場合です。
ステップ 5 [Protocol group（プロトコル グループ）] ボックスで、次のようにします。
• SSL/TLS トンネルを使用する EAP プロトコルでこの証明書を使用するには、[EAP] チェックボックスをオンにします。
• この証明書を Cisco ISE ポータルの認証に使用するには、[HTTPS] チェックボックスをオンにします。
[Management Interface（管理インターフェイス）] チェックボックスをオンにする場合は、証明書のサブジェクトの一般名値がノードの完全修飾ドメイン名 （FQDN）に一致していることを確認します。そうでない場合、自己署名証明書は生成されません。
[HTTPS] チェックボックスがオンになっている場合は、導入環境内のプライマリ管理ノードが再起動されます。
ステップ 6 [Override Policy（上書きポリシー）] 領域で、既存の証明書を複製された証明書で置き換えるには、[Replace Certificate（証明書を置き換える）] チェックボックスをオンにします。証明書のサブジェクトまたは発行者、およびシリアル番号が既存の証明書と同じ場合、その証明書は複製と見なされます。このオプションでは証明書の内容が更新されますが、証明書の既存のプロトコルの選択は保持されます。
ステップ 7 証明書を生成するには、[Submit（送信）] をクリックします。
（注） 自己署名証明書を使用しており、Cisco ISE ノードのホスト名を変更する必要がある場合は、Cisco ISE ノードの [Admin（管理）] ポータルにログインし、古いホスト名が使用された自己署名証明書を削除し、新しい自己署名証明書を生成します。そうしないと、Cisco ISE は古いホスト名が使用された自己署名証明書を引き続き使用します。
証明書署名要求の生成
証明書署名要求を生成し、CA 署名付き証明書をバインドすることにより、新しいローカル証明書を追加できます。
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
[Administration（管理）] > [System（システム）] > [Certificates（証明書）]
> [Local Certificates（ローカル証明書）]
を選択します。
セカンダリ ノードから CSR を生成するには、[Administration（管理）] > [System（システム）] > [Server Certificate（サーバ証明書）] を選択します。
ステップ 2 [Add（追加）] > [Generate Certificate Signing Request（証明書署名要求の作成）] を選択します。
ステップ 3 証明書サブジェクトおよび必要なキーの長さを入力します。証明書サブジェクトは、証明書に関連付けられているエンティティを識別する識別名（DN）です。DN には一般名の値が含まれている必要があります。識別名の要素は次のとおりです。
たとえば、ある CSR の証明書サブジェクトの値は次のような値になる可能性があります。「CN=Host-ISE.cisco.com、OU=Cisco、O=security、C=US、ST=NC、L=RTP、e= test@test.com」または「CN=aaa.amer.cisco.com、SAN 内の DNS 名=*.amer.cisco.com、OU=Cisco、O=security、C=US、ST=NC、L=RTP、e=abc@xyz.com」。
（注） [Certificate Subject（証明書件名）] フィールドに入力するときは、文字列を引用符でカプセル化しないでください。
この CSR から生成された証明書を HTTPS 通信に使用する場合は、証明書サブジェクトの一般名の値がノードの FQDN であることを確認してください。そうでない場合は、生成された証明書をバインドするときに [Management Interface（管理インターフェイス）] を選択できません。
ステップ 4 サブジェクト代替名 ：証明書に関連付けられた DNS 名または IP アドレス。
ステップ 5 SHA-1 または SHA-256 を使用して証明書を暗号化および復号化することを選択します。
（注） Cisco ISE を FIPS モードで動作するように設定する場合、証明書の RSA キー サイズは 2048 ビット以上であり、SHA-1 または SHA-256 ハッシュ アルゴリズムを使用する必要があります。
ステップ 6 証明書サブジェクトにCN または SAN とともにワイルドカードの FQDN を含める場合は、[Allow Wildcard Certificates（ワイルドカード証明書の許可）] チェックボックスオンにします。
ステップ 7 [Submit（送信）] をクリックして CSR を生成します。
CSR とその秘密キーが生成され、Cisco ISE に保存されます。この CSR は、[Certificate Signing Requests（証明書署名要求）] ページで表示できます。この CSR をエクスポートし、CA に送信して署名を取得できます。
CA 署名付き証明書のバインディング
証明書署名要求が認証局によって署名され、返されたら、CA 署名付き証明書とその秘密キーとをバインドして、Cisco ISE へのローカル証明書の追加プロセスを完了します。
• 次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Local Certificates（ローカル証明書）] を選択します。
CA 署名付き証明書をセカンダリ ノードにバインドするには、[Administration（管理）] > [System（システム）] > [Server Certificate（サーバ証明書）] を選択します。
ステップ 2 [Add（追加）] > [Bind CA Certificate（CA 証明書のバインド）] を選択します。
ステップ 3 [Browse（参照）] をクリックして CA 署名付き証明書を選択します（該当する CA 署名付き証明書を選択します）。
ステップ 4 証明書の フレンドリ名 を指定します。名前を入力しない場合は、 <common name> # <issuer> # <nnnnn> の形式で自動的に名前が作成されます。ここで、 <nnnnn> は固有の 5 桁の数値です。
ステップ 5 Cisco ISE に証明書の拡張の検証を許可する場合は、[Enable Validation of Certificate Extensions（証明書の拡張の検証を許可）] チェックボックスをオンにします。
（注） [Enable Validation of Certificate Extensions（証明書の拡張の検証を許可）] オプションが有効になっており、インポートする証明書に CA フラグ が true に設定された基本制約拡張が含まれている場合は、キー使用拡張が存在しており、keyEncipherment ビットまたは keyAgreement ビット、あるいはその両方が設定されていることを確認します。
ステップ 6 サブジェクトのいずれかの CN またはサブジェクト代替名の DNS にワイルドカード文字であるアスタリスク（*）が含まれている証明書をバインドするには、[Allow Wildcard Certificates（ワイルドカード証明書の許可）] チェックボックスをオンにします。
ステップ 7 [Protocol group（プロトコル グループ）] ボックスで、次のようにします。
• SSL/TLS トンネルを使用する EAP プロトコルでこの証明書を使用するには、[EAP] チェックボックスをオンにします。
• この証明書を Cisco ISE Web ポータルの認証に使用するには、[HTTPS] チェックボックスをオンにします。
[Management Interface（管理インタフェース）] チェックボックスをオンにする場合は、証明書サブジェクトの一般名の値がノード完全修飾ドメイン名（FQDN）またはワイルドカード表記（ワイルドカード証明書が使用されている場合）に一致していることを確認してください。そうではない場合、バインド操作は失敗します。
[HTTPS] チェックボックスがオンになっている場合は、導入環境内のプライマリ管理ノードが再起動されます。
ステップ 8 既存の証明書を複製した証明書で置き換えるには、[Replace Certificate（証明書を置き換える）] チェックボックスをオンにします。証明書のサブジェクトまたは発行者、およびシリアル番号が既存の証明書と同じ場合、その証明書は複製と見なされます。このオプションでは証明書の内容が更新されますが、証明書の既存のプロトコルの選択は保持されます。
ステップ 9 [Submit（送信）] をクリックして、CA 署名付き証明書をバインドします。
ローカル証明書の編集
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Local Certificates（ローカル証明書）] を選択します。
ローカル証明書をセカンダリ ノードで編集するには、[Administration（管理）] > [System（システム）] > [Server Certificate（サーバ証明書）] を選択します。
ステップ 2 編集する証明書の横にあるチェックボックスをオンにして、[Edit（編集）] をクリックします。
ステップ 4 オプションで、この証明書を識別するためのフレンドリ名と説明を入力します。
ステップ 5 [Protocol group（プロトコル グループ）] ボックスで、次のようにします。
• SSL/TLS トンネルを使用する EAP プロトコルでこの証明書を使用するには、[EAP] チェックボックスをオンにします。
• この証明書を Cisco ISE Web ポータルの認証に使用するには、[HTTPS] チェックボックスをオンにします。
[HTTPS] チェックボックスがオンになっている場合は、導入環境内のプライマリ管理ノードが再起動されます。
（注） [Management Interface（管理インタフェース）] チェックボックスをオンにする場合は、証明書サブジェクトの一般名の値がノード完全修飾ドメイン名（FQDN）またはワイルドカード表記（ワイルドカード証明書が使用されている場合）に一致していることを確認してください。一般名の値がブランクの場合、編集操作は失敗します。
たとえば、現在 local_certificate_1 が EAP に対して指定されており、local_certificate_2 の編集時に [EAP] チェックボックスをオンにした場合、local_certificate_2 への変更を保存すると、local_certificate_1 の EAP への関連付けが解除されます。
ステップ 6 自己署名証明書を編集しており、有効期限を延長する必要がある場合は、[Renew Self Signed Certificate（自己署名証明書の更新）] チェックボックスをオンにします。
ステップ 7 日、週、月、年単位で、証明書の有効期限の TTL（存続可能時間）を入力します。
ステップ 8 [Save（保存）] をクリックして変更を保存します。
ローカル証明書のエクスポート
選択したローカル証明書とその証明書に関連付けられている秘密キーをエクスポートできます。証明書とその秘密キーをバックアップ用にエクスポートする場合は、それらを必要に応じて後で再インポートできます。
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Local Certificates（ローカル証明書）] を選択します。
ローカル証明書をセカンダリ ノードからエクスポートするには、[Administration（管理）] > [System（システム）] > [Server Certificate（サーバ証明書）] を選択します。
ステップ 2 エクスポートする証明書の横にあるチェックボックスをオンにし、[Edit（編集）] をクリックします。
ステップ 3 証明書のみをエクスポートするか、証明書と証明書に関連付けられている秘密キーをエクスポートするかを選択します。
ヒント 値が公開される可能性があるため、証明書に関連付けられている秘密キーのエクスポートは推奨しません。秘密キーをエクスポートする必要がある場合は、秘密キーの暗号化パスワードを指定します。このパスワードは、証明書を別の Cisco ISE サーバにインポートするときに指定して、秘密キーを復号化する必要があります。
ステップ 4 エクスポートする証明書コンポーネントを選択します。
ステップ 5 秘密キーをエクスポートすることを選択した場合は、パスワードを入力します。パスワードは、8 文字以上にする必要があります。
ステップ 6 [OK] をクリックして、クライアント ブラウザを実行しているファイル システムに証明書を保存します。
証明書のみをエクスポートする場合、証明書は Privacy Enhanced Mail 形式で保存されます。証明書と秘密キーの両方をエクスポートする場合、証明書は Privacy Enhanced Mail 形式の証明書と暗号化された秘密キー ファイルを含む .zip ファイルとしてエクスポートされます。
証明書署名要求
自分が作成した証明書署名要求（CSR）のリストは、[Certificate Signing Requests（証明書署名要求）] ページで使用できます。CA から署名を取得するには、クライアント ブラウザを実行しているローカル ファイル システムに CSR をエクスポートする必要があります。次に、CA に証明書を送信します。証明書は CA によって署名され、返されます。
（注） Cisco ISE 導入環境の分散セットアップに複数のノードがある場合は、導入環境内の各ノードから CSR を個別にエクスポートする必要があります。
証明書署名要求のエクスポート
[Exporting Certificate Signing Requests（証明書署名要求のエクスポート）] ページを使用して、証明書署名要求をエクスポートすることができます。
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Certificate Signing Requests（証明書署名要求）] を選択します。
セカンダリ ノードから CSR をエクスポートするには、[Administration（管理）] > [System（システム）] > [Certificate Signing Requests（証明書署名要求）] を選択します。
ステップ 2 エクスポートする証明書の横にあるチェックボックスをオンにし、[Edit（エクスポート）] をクリックします。
ステップ 3 [OK] をクリックして、クライアント ブラウザを実行しているファイル システムにファイルを保存します。
証明書ストア
Cisco ISE 証明書ストアには、信頼に使用される、Simple Certificate Enrollment Protocol（SCEP）用の X.509 証明書が含まれています。証明書ストア内の証明書はプライマリ管理ノードで管理され、Cisco ISE の導入環境内の他のすべてのノードに複製されます。
Cisco ISE はワイルドカード証明書をサポートしています。
Cisco ISE は、次の目的で証明書ストアの証明書を使用します。
• 証明書ベースの管理認証を使用して管理ポータルにアクセスする Cisco ISE 管理者、およびエンドポイントによる認証に使用されるクライアント証明書の検証。
• 導入環境内の Cisco ISE ノード間のセキュアな通信を可能にする。証明書ストアには、導入環境内の各ノードのローカル HTTPS サーバ証明書との信頼を確立するために必要な CA 証明書のチェーンが含まれている必要があります。
– 自己署名証明書をサーバ証明書に使用する場合は、各ノードの自己署名証明書をプライマリ管理ノードの証明書ストアに配置する必要があります。
– CA 署名付き証明書をサーバ証明書に使用する場合は、CA ルート証明書だけでなく、信頼チェーン内のすべての中間証明書もプライマリ管理ノードの証明書ストアに配置する必要があります。
• 安全な LDAP 認証を有効にする。SSL を経由してアクセスされる LDAP ID ソースを定義するときに、証明書ストアから証明書を選択する必要があります。
• デバイス ポータルを使用してネットワークでの登録を準備するモバイル デバイスへの配布のため。Cisco ISE は、モバイル デバイス登録をサポートするために、ポリシー サービス ノード（PSN）での SCEP を実装しています。登録するデバイスは、SCEP プロトコルを使用して、PSN にクライアント証明書を要求します。PSN には仲介として動作する登録局（RA）が含まれています。RA は登録からの要求を受信し、検証して、その要求を CA（実際にクライアント証明書を発行する）に転送します。CA は RA に証明書を返し、RA が証明書をデバイスに返します。
Cisco ISE によって使用される各 SCEP CA は、SCEP RA プロファイルによって定義されます。SCEP RA のプロファイルが作成されると、次の 2 つの証明書が証明書ストアに自動的に追加されます。
b. CA によって署名された RA 証明書（証明書要求のエージェントの証明書）。
SCEP プロトコルでは、これらの 2 つの証明書が RA によって登録デバイスに提供されている必要があります。証明書ストアにこの 2 つの証明書を配置すると、これらのノードの RA が使用するために、証明書がすべての PSN ノードに複製されます。
（注） Cisco ISE にインポートされる X.509 証明書は、Privacy Enhanced Mail（PEM）または Distinguished Encoding Rules（DER）形式である必要があります。 証明書チェーン（つまり、ローカル証明書、およびその証明書に署名する一連の信頼された証明書）が含まれたファイルはインポートすることができますが、特定の制限の対象となります。
• 「Simple Certificate Enrollment Protocol プロファイル」
X.509 証明書の有効期限
X.509 証明書が有効なのは、指定された特定の日付までのみです。証明書ストアの証明書が期限切れになると、その証明書に依存する Cisco ISE 機能が影響を受けます。Cisco ISE は、有効期限が 90 日以内になると、証明書の有効期間の残りについて通知します。この通知は、いくつかの方法で表示されます。
• 配色された有効期限の状態アイコンが、[Certificate Store（証明書ストア）] ページに表示されます。
• 期限切れメッセージが Cisco ISE システム診断レポートに表示されます。
• 有効期限のアラームは、有効期限の 90 日前、60 日前に生成され、有効期限前の最後の 30 日間には毎日生成されます。
証明書ストアには、製造証明書とルート証明書の 2 つのシスコ CA 証明書があります。ルート証明書は製造証明書に署名します。これらの証明書は、デフォルトでは無効になっています。導入環境でエンドポイントとして Cisco IP Phone を使用している場合は、これら 2 つの証明書を有効にして、この電話用にシスコが署名した証明書の認証ができるようにします。
証明書の名前の制約
CTL の CA 証明書には名前の制約の拡張が含まれている場合があります。この拡張は、証明書チェーンの後続のすべての証明書のサブジェクト名とサブジェクト代替名フィールドの値の名前空間を定義します。Cisco ISE は、ルート証明書で指定された制約を検査しません。
ディレクトリ名の制限は、サブジェクト/SAN のディレクトリ名のプレフィクスです。次に例を示します。
CA 証明書の名前の制約：Permitted: O=Cisco
クライアント証明書のサブジェクト：O=Cisco,CN=Salomon
CA 証明書の名前の制約：Permitted: O=Cisco
クライアント証明書のサブジェクト：CN=Salomon,O=Cisco
• URI（URI の制約は、http://、https://、ftp:// または ldap:// のような URI プレフィクスで開始する必要があります）。
CA 証明書にサポートされていない制約が含まれており、検証中の証明書に該当のフィールドが含まれていない場合は、Cisco ISE がサポートされない制約を検証できないため、その証明書は拒否されます。
受け入れ可能なクライアント証明書のサブジェクトは、次のように上記の定義に一致します。
証明書ストアの証明書の表示
[Certificate Store（証明書ストア）] ページに、Cisco ISE に追加されたすべての CA 証明書が一覧表示されます。CA 証明書を表示するには、スーパー管理者またはシステム管理者である必要があります。
すべての証明書を表示するには、[Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Certificate Store（証明書ストア）] を選択します。[Certificate Store（証明書ストア）] ページが表示され、すべての CA 証明書の一覧が一覧表示されています。
証明書ストア内の証明書の変更
証明書のステータスが有効になっている必要があります。これにより、Cisco ISE が信頼の確立にこの証明書を使用できるようになります。証明書が証明書ストアにインポートされると、この証明書は自動的に有効になります。
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Certificate Store（証明書ストア）] を選択します。
ステップ 2 有効または無効にする証明書の横にあるチェックボックスをオンにし、[Change Status（ステータスの変更）] をクリックします。
証明書ストアへの証明の追加
[Certificate Store（証明書ストア）] ページを使用して、Cisco ISE に CA 証明書を追加することができます。
• 次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
• ブラウザを実行しているコンピュータのファイル システムに、証明書ストアの証明書が存在することを確認します。証明書は PEM または DER 形式である必要があります。
[Administration（管理）]
> [System（システム）] > [Certificates（証明書）] > [Certificate Store（証明書ストア）]
を選択します。
ステップ 2 [Import（インポート）] をクリックします。
クライアント証明書ベースの認証が有効の場合は、導入環境内の各ノードのアプリケーション サーバが再起動されます（最初にプライマリ管理ノードのアプリケーション サーバが再起動され、続いて追加のノードのアプリケーション サーバが 1 つずつ再起動されます）。
証明書ストアの証明書の編集
証明書を証明書ストアに追加したら、編集の設定を使用して、その証明書をさらに編集できます。
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [Certificate Store（証明書ストア）] を選択します。
ステップ 2 編集する証明書の横にあるチェックボックスをオンにして、[Edit（編集）] をクリックします。
ステップ 3 必要に応じて編集可能なフィールドを変更します。
ステップ 4 [Save（保存）] をクリックして、証明書ストアに対して行った変更を保存します。
証明書ストアからの証明書のエクスポート
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
[Administration（管理）]
> [System（システム）] > [Certificates（証明書）] > [Certificate Store（証明書ストア）] を選択します。
ステップ 2 エクスポートする証明書の横にあるチェックボックスをオンにし、[Edit（エクスポート）] をクリックします。一度に 1 つの証明書のみをエクスポートできます。
ステップ 3 クライアント ブラウザを実行しているファイル システムに Privacy Enhanced Mail ファイルを保存します。
証明書チェーンのインポート
証明書ストアから受信した証明書チェーンを含む単一のファイルから、複数の証明書をインポートすることができます。ファイル内のすべての証明書は Privacy-Enhanced Mail (PEM) の形式であり、証明書は次の順序に並べられている必要があります。
• ファイル内の最後の証明書は、CA によって発行されたクライアントまたはサーバ証明書である必要があります。
• 前にあるすべての証明書は、ルート CA 証明書と、発行された証明書の署名のチェーンにあるすべて中間 CA 証明書である必要があります。
証明書チェーンのインポートは、次の 2 つのステップで構成される手順です。
ステップ 1 証明書ストアへの証明の追加に記載された操作によって、証明書ストアに証明書チェーン ファイルをインポートします。この操作により、証明書ストアにある最後の 1 つを除き、すべての証明書がファイルからインポートされます。このステップは、プライマリ管理ノードでのみ実行できます。
ステップ 2 CA 署名付き証明書のバインディングに記載された操作によって、証明書チェーン ファイルをインポートします。この操作により、最後の証明書がローカル証明書としてインポートされます。
Cisco ISE のノード間通信のための CA 証明書のインストール
分散導入環境では、セカンダリ ノードを登録する前に、セカンダリ ノードの HTTPS 証明書を検証するために使用する適切な CA 証明書をプライマリ ノードの CTL に入力する必要があります。プライマリ ノードの CTL に入力する手順は、シナリオに応じて異なります。
• セカンダリ ノードで HTTPS 通信に CA 署名付き証明書が使用されている場合は、セカンダリ ノードの CA 署名付き証明書をプライマリ ノードの CTL にインポートできます。
• セカンダリ ノードで HTTPS 通信に自己署名証明書が使用されている場合は、セカンダリ ノードの自己署名証明書をプライマリ ノードの CTL にインポートできます。
（注） セカンダリ ノードをプライマリ ノードに登録した後に、登録されているセカンダリ ノードの HTTPS 証明書を変更する場合は、セカンダリ ノードの HTTPS 証明書の検証に使用できる適切な CA 証明書を取得する必要があります。
セカンダリ ノードからプライマリ ノードの CTL への CA 署名付き証明書のインポート
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
ステップ 1 セカンダリ ノードとして登録するノードの管理ポータルにログインし、HTTPS 通信に使用される CA 署名付き証明書を、クライアント ブラウザを実行しているファイル システムにエクスポートします。
ステップ 2 [Export（エクスポート）] ダイアログボックスで、[Export Certificate Only（証明書のみをエクスポート）] オプション ボタンををクリックします。
ステップ 3 プライマリ ノードの管理ポータルにログインして、プライマリ ノードの CTL にセカンダリ ノードの CA 署名付き証明書をインポートします。
セカンダリ ノードからプライマリ ノードの CTL への自己署名証明書のインポート
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
ステップ 1 セカンダリ ノードとして登録するノードの管理ポータルにログインし、HTTPS 通信に使用される自己署名証明書を、クライアント ブラウザを実行しているファイル システムにエクスポートします。
ステップ 2 [Export（エクスポート）] ダイアログボックスで、[Export Certificate Only（証明書のみをエクスポート）] オプション ボタンををクリックします。
ステップ 3 プライマリ ノードの管理ポータルにログインして、プライマリ ノードの CTL にセカンダリ ノードの自己署名証明書をインポートします。
Simple Certificate Enrollment Protocol プロファイル
ユーザがネットワークで登録できるさまざまなモバイル デバイスの証明書のプロビジョニング機能を有効にするために、1 つ以上の Simple Certificate Enrollment Protocol（SCEP）認証局（CA）プロファイルを設定して、Cisco ISE に複数の CA の場所を指定できます。複数のプロファイルを使用できる利点は、ハイ アベイラビリティが実現できるようになり、指定した CA の場所の間でロード バランシングを実行できることです。特定の SCEP CA への要求に 3 回連続して応答がなかった場合、Cisco ISE は特定のサーバが使用不能であると宣言し、次に負荷が小さく応答時間が短い既知の CA に自動的に移動して、サーバがオンラインに復帰するまで、定期的なポーリングを開始します。
Microsoft SCEP サーバを Cisco ISE と相互運用するように設定する方法については、次を参照してください。
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/howto_60_byod_certificates.pdf .
• 「Simple Certificate Enrollment Protocol（SCEP）プロファイルの追加」
Simple Certificate Enrollment Protocol（SCEP）プロファイルの追加
ステップ 1 [Administration（管理）] > [System（システム）] > [Certificates（証明書）] > [SCEP CA Profile（SCEP CA プロファイル）] を選択します。
ステップ 2 他の SCEP CS プロファイル名と区別するために、プロファイルの名前を指定します。
ステップ 3 オプションで、プロファイルの説明を入力します。
ステップ 4 ユーザがモバイル デバイスからネットワークにアクセスしたときに Cisco ISE が SCEP CA 要求を転送できる、該当のSCEP CA サーバの URL を指定します。
[Submit（送信）] ボタンをクリックしてセッションを終了する前に、オプションで横にある [Test Connectivity（接続のテスト）] ボタンを使用して、指定した URL のサーバに Cisco ISE が到達できることを確認できます。（いずれにしても、Cisco ISE ではプロファイルを保存する前に URL がテストされます）。
ユーザのデバイスが検証済みの証明書を受信すると、 表 E-1 に示すように、証明書はそのデバイスに置かれます。
OCSP サービス
Online Certificate Status Protocol（OCSP）は、x.509 デジタル証明書のステータスのチェックに使用されるプロトコルです。このプロトコルは証明書失効リスト（CRL）に代わるものであり、CRL の処理が必要となる問題に対処します。
Cisco ISE には HTTP を介して OCSP サーバと通信し、認証で証明書のステータスを検証する機能があります。OCSP の設定は、Cisco ISE で設定される任意の認証局（CA）の証明書から参照できる、再利用可能な設定オブジェクトで設定されます。「証明書ストアの証明書の編集」を参照してください。
CRL 検証または OCSP 検証、あるいはその両方を CA ごとに設定できます。両方を選択すると、Cisco ISE は最初に OCSP を介した検証を実行します。プライマリ OCSP サーバとセカンダリ OCSP サーバの両方で通信の問題が検出された場合、または特定の証明書に対して不明のステータスが返された場合、Cisco ISE は CRL チェックの実行に切り替えます。
OCSP 証明書のステータスの値
OCSP サービスは、指定された証明書要求に対して次の値を返します。
• [Good（良い）]：ステータスの問い合わせに対する肯定的な応答を示します。証明書が失効していないこと、および状態が次の時間間隔（存続可能時間）値までは良好であることを示します。
• [Unknown（不明）]：証明書のステータスが不明です。これは、OCSP が特定の証明書 CA を処理するように設定されていない場合に発生することがあります。
OCSP ハイ アベイラビリティ
Cisco ISE では CA ごとに最大 2 つの OCSP サーバを設定でき、それらのサーバはプライマリおよびセカンダリ OCSP サーバと呼ばれます。各 OCSP サーバ設定には、次のパラメータが含まれます。
• [Nonce（ナンス）]：要求で送信される乱数。このオプションにより、リプレイ アタックで古い通信を再利用できないことが保証されます。
• [Validate Response（応答の検証）]：Cisco ISE は OCSP サーバから受信した応答署名を検証します。
Cisco ISE がプライマリ OCSP サーバと通信しているときに、タイムアウト（5 秒）が発生した場合、Cisco ISE はセカンダリ OCSP サーバに切り替えます。
Cisco ISE はプライマリ サーバの再使用を試行する前に、設定可能な期間セカンダリ OCSP サーバを使用します。
OCSP エラー
3 つの一般的な OCSP 障害のシナリオは次のとおりです。
1. 失敗した OCSP キャッシュまたは OCSP クライアント側（Cisco ISE）の障害
a. 最初のプライマリ OCSP 応答側が応答せず、セカンダリ OCSP 応答側が Cisco ISE OCSP 要求に応答する。
b. Cisco ISE OCSP 要求からエラーまたは応答が受信されない。
OCSP レスポンダが、Cisco ISE OCSP 要求への応答を提供しないか、失敗の OCSP 応答のステータスを返している可能性があります。OCSP 応答のステータス値は次のようになります。
OCSP 要求に対する多数の日時チェック、署名の有効性チェックなどがあります。詳細については、「 RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol - OCSP（RFC 2560 X.509 インターネット パブリック キー インフラストラクチャのオンライン証明書ステータスのプロトコル：OCSP） 」を参照してください。これにはエラー ステータスを含む、可能性があるすべてのステータスが説明されています。
OCSP サービスの追加
[Add OCSP（OCSP の追加）] ページを使用して、Cisco ISE に新しい OCSP サービスを追加することができます。
[Administration（管理）]
> [System（システム）] > [Certificates（証明書）] > [OCSP Services（OCSP サービス）]
を選択します。
ステップ 4 ハイ アベイラビリティを有効にする場合は、[Enable Secondary Server（セカンダリ サーバの有効化）] チェックボックスをオンにします。
ステップ 5 ハイ アベイラビリティの次のいずれかのオプションを選択します。
• [Always Access Primary Server First（常にプライマリ サーバに最初にアクセスする）]：このオプションは、セカンダリ サーバへの移動を試行する前にプライマリ サーバをチェックする場合に使用します。プライマリが以前にチェックされ、応答しないことが確認されている場合にも、Cisco ISE はセカンダリ サーバに移動する前にこのプライマリ サーバへの要求の送信を試行します。
• [Fallback to Primary Server After Interval（時間を置いてプライマリ サーバにフォールバックする）]：このオプションは、Cisco ISE がセカンダリ サーバに移動してから、再度プライマリ サーバにフォールバックする場合に使用します。この場合、その他の要求はすべてスキップされ、テキスト ボックスで設定した期間セカンダリ サーバが使用されます。許可される時間の範囲は 1 ～ 999 分です。
ステップ 6 プライマリおよびセカンダリの OCSP サーバの URL または IP アドレスを指定します。
• [Nonce（ナンス）]：ナンスが OCSP 要求の一部として送信されるように設定できます。ナンスには、OCSP 要求の擬似乱数が含まれます。応答で受信される数値が要求に含まれる数値と同じであることが検証されます。このオプションにより、リプレイ アタックで古い通信を再利用できないことが保証されます。
• [Validate Response Signature（応答の署名の検証）]：OCSP レスポンダは次のいずれかの署名を使用して応答に署名します。
Cisco ISE が応答の署名を検証するためには、OCSP レスポンダが応答を証明書とともに送信する必要があります。そうでない場合、応答の検証は失敗し、証明書のステータスを信頼にすることはできません。RFC に従い、OCSP は異なる証明書を使用して応答に署名できます。このことは、OCSP が検証のために、Cisco ISE の応答に署名した証明書を送信する限り当てはまります。OCSP が Cisco ISE で設定されているものとは異なる証明書を使用して応答に署名した場合、応答の検証は失敗します。
ステップ 8 キャッシュ エントリの存続可能期間を分単位で入力します。
OCSP サーバからの各応答には nextUpdate 値が含まれています。この値は、証明書のステータスがサーバで次にいつ更新されるかを示します。OCSP 応答がキャッシュされるとき、2 つの値（1 つは設定から、もう 1 つは応答から）が比較され、この 2 つの最小値の期間だけ応答がキャッシュされます。nextUpdate 値が 0 の場合、応答はまったくキャッシュされません。
Cisco ISE は設定された期間 OCSP 応答をキャッシュします。キャッシュは複製されず、永続的でもないため、Cisco ISE が再起動するとキャッシュはクリアされます。
次の理由により、OCSP キャッシュは OCSP 応答を保持するために使用されます。
• 既知の証明書に関する OCSP サーバからのネットワーク トラフィックと負荷を低減するため
• 既知の証明書のステータスをキャッシュすることによって Cisco ISE のパフォーマンスを向上させるため
ステップ 9 OCSP サービスに接続されているすべての認証局のエントリをクリアするには、[Clear Cache（キャッシュを消去）] をクリックします。
導入環境内で、キャッシュのクリアはすべてのノードと相互作用して、処理を実行します。このメカニズムにより、導入環境内のすべてのノードが更新されます。
OCSP 統計情報カウンタ
OCSP カウンタは、OCSP サーバのデータと健全性のロギングおよびモニタリングに使用されます。ロギングは 5 分ごとに実行されます。syslog メッセージが Cisco ISE モニタリング ノードに送信され、ローカル ストア（前の 5 分間のデータが格納されている）に保存されます。メッセージが送信された後、カウンタは次の間隔について再計算されます。つまり、5 分後に、新しい 5 分間の間隔が再度開始されます。
表 E-2 に OCSP syslog メッセージとその説明を示します。
|
|
|
|---|---|
OCSP のモニタリング
OCSP サービス データを OCSP モニタリング レポートの形式で表示することができます。Cisco ISE レポート作成の詳細については、『 Cisco Identity Services Engine User Guide, Release 1.2（Cisco Identity Services Engine ユーザ ガイド リリース 1.2） 』を参照してください。
インライン ポスチャ ノードの証明書の設定
サポートされる任意のアプライアンス プラットフォームでインライン ポスチャ ノード リリース 1.2 の ISO イメージをインストールし、セットアップ プログラムを実行したら、インライン ポスチャ ノードを導入環境に追加する前に、それらのノードの証明書を設定する必要があります。インライン ポスチャ ノードの証明書の設定は CLI からのみ行います。
• インライン ポスチャ ノードは、プライマリ管理ノードを認証したのと同じ認証局（CA）から認証する必要があります。
• インライン ポスチャ ノードのアクティブ/スタンバイ ペアを導入する場合は、アクティブおよびスタンバイの両方のインライン ポスチャ ノードで証明書を設定します。
ステップ 1 CLI を使用してインライン ポスチャ ノードにログインします。
pep certificate server generatecsr
ステップ 3 証明書署名要求（CSR）とともに既存の秘密キー ファイルを使用するには n を入力し、新規の秘密キーファイルを使用するには y を入力します。
ステップ 5 証明書に署名するダイジェストのタイプを入力します。
ステップ 8 一般名を入力します。一般名はホスト名と同じです。完全修飾ドメイン名（FQDN）を入力します。たとえば、ホスト名が IPN1 、DNS ドメイン名が cisco.com である場合は、一般名として IPN1.cisco.com を入力します。
ステップ 10 END CERTIFICATE REQUEST タグの後に、空白行を含むテキスト ブロック全体をコピーします（復帰改行を含みます）。
ステップ 11 プライマリ管理ノードの証明書に署名した CA にこの CSR を送信します。
Microsoft の CA を使用している場合は、署名要求の送信時に証明書のテンプレートとして [Web Server（Web サーバ）] を選択します。
（注） リリース 1.2 でサポートされるのはサーバ認証のみです。証明書に署名するために他の CA を使用する場合は、キーの拡張用途でサーバ認証のみが指定されていることを確認します。
ステップ 12 DER または Base64 形式の署名付き証明書をダウンロードし、FTP サーバにコピーします。
ステップ 13 インライン ポスチャ ノードの CLI から次のコマンドを入力します。
copy ftp:// a.b.c.d/ipn1.cer disk:
ここで、 a.b.c.d は FTP サーバの IP アドレスであり、 ipn1.cer はインライン ポスチャ ノードに追加する CA 署名付き証明書です。
ステップ 14 FTP サーバのユーザ名とパスワードを入力します。
ステップ 15 インライン ポスチャ ノードの CLI から次のコマンドを入力します。
ステップ 16 再起動するアプリケーションに対して y を入力します。
ステップ 17 最後の CSR に証明書をバインドするために y を入力します。
インライン ポスチャ アプリケーションが再起動します。これで、プライマリ管理ノードにインライン ポスチャのノードを登録できるようになりました。詳細については、『 Cisco Identity Services Engine User Guide, Release 1.2（Cisco Identity Services Engine ユーザ ガイド リリース 1.2） 』を参照してください。
フィードバック