この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
証明書は、個人、サーバ、会社、またはその他のエンティティを識別し、そのエンティティを公開キーに関連付ける電子文書です。自己署名証明書は、独自の作成者によって署名されます。証明書は、自己署名したり、外部の認証局(CA)がデジタルで署名したりできます。CA 署名付きデジタル証明書は、業界標準であり、よりセキュアです。
証明書は、ネットワークに対するセキュアなアクセスを提供するために使用されます。Cisco ISE は、ノード間通信、および syslog サーバ、フィード サーバ、すべてのエンドユーザ ポータル(ゲスト、スポンサーおよびパーソナル デバイス ポータル)などの外部サーバとの通信に証明書を使用します。証明書は、エンドポイントに対して Cisco ISE ノードを識別し、そのエンドポイントと 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)から配信された証明書も含まれます。これにより、モバイル デバイスを企業ネットワークに登録できるようになります。信頼できる証明書ストア内の証明書はプライマリ管理ノード(PAN)で管理され、Cisco ISE 展開内の他のすべてのノードに自動的に複製されます。
分散展開では、証明書を PAN の証明書信頼リスト(CTL)のみにインポートする必要があります。この証明書はセカンダリ ノードに複製されます。
一般に、Cisco ISE での証明書認証が、証明書による認証機能のわずかな違いの影響を受けないようにするために、ネットワークに展開されているすべての Cisco ISE ノードには小文字のホスト名を使用してください。
Cisco ISE に証明書を追加またはインポートする場合、証明書の使用目的を指定する必要があります。
管理者:ノード間通信および管理者ポータルの認証
EAP:TLS ベースの EAP 認証
RADIUS DTLS: RADIUS DTLS サーバ認証用
ポータル:すべての Cisco ISE エンドユーザ ポータルとの通信
xGrid:pxGrid コントローラとの通信
管理者ポータル(管理者)、pxGrid コントローラ(xGrid)との通信および TLS ベースの EAP 認証(EAP)に、各ノードから異なる証明書を関連付けることができます。ただし、これらの各目的に各ノードから関連付けることができる証明書は 1 つのみです。
Web ポータル要求を処理できる展開に複数のポリシー サービス ノード(PSN)がある場合、Cisco ISE には一意の ID が必要です。この ID で、ポータルの通信に使用する必要がある証明書を識別します。ポータルでの使用に指定された証明書を追加またはインポートする場合、証明書グループ タグを定義して、それを展開内の各ノードの対応する証明書に関連付ける必要があります。この証明書グループ タグを対応するエンドユーザ ポータル(ゲスト、スポンサー、およびパーソナル デバイス ポータル)に関連付ける必要があります。この証明書グループ タグは一意の ID で、Cisco ISE が各ポータルと通信する際に使用する必要がある証明書を識別する場合に役立ちます。ポータルごとに各ノードから 1 つの証明書を指定できます。
展開内で Cisco ISE ノードをセットアップすると、2 つのノードが相互に通信します。システムは各 ISE ノードの FQDN を調べ、FQDN が一致することを確認します(たとえば ise1.cisco.com と ise2.cisco.com、またはワイルドカード証明書を使用している場合は *.cisco.com)。また、外部マシンから ISE サーバに証明書が提示される場合、認証のために提示される外部証明書が、ISE サーバの証明書と照合されます。2 つの証明書が一致すると、認証は成功します。
では、 ノード間(2 ノードの場合)、または と pxGrid の間で照合が実行されます。
Cisco ISE は、サブジェクト名の一致を次のようにして確認します。
Cisco ISE により証明書のサブジェクト代替名(SAN)の拡張が確認されます。SAN に 1 つ以上の DNS 名が含まれている場合は、それらの DNS 名の 1 つが Cisco ISE ノードの FQDN に一致している必要があります。ワイルドカード証明書が使用されている場合、ワイルドカード ドメイン名は Cisco ISE ノードの FQDN ドメインに一致している必要があります。
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 日以内になると、システム証明書の有効期間の残りについて通知します。この通知は、いくつかの方法で表示されます。
配色された有効期限の状態アイコンが、[システム証明書(System Certificates)] ページに表示されます。
有効期限のアラームは、有効期限の 90 日前、60 日前に生成され、有効期限前の最後の 30 日間には毎日生成されます。
失効した証明書が自己署名証明書の場合は、この証明書を編集して有効期限を延長できます。CA 署名付き証明書の場合は、CA から新しい証明書を取得するのに十分な期間を確保する必要があります。
公開キー インフラストラクチャ(PKI)は、セキュアな通信を可能にし、デジタル署名を使用してユーザの ID を確認する暗号化技術です。
ワイルドカード証明書はワイルドカード表記(ドメイン名の前にアスタリスクとピリオドの形式)を使用し、組織の複数のホスト間で証明書を共有できるようにします。たとえば、証明書サブジェクトの CN 値は aaa.ise.local などの汎用ホスト名であり、SAN フィールドには、同じ汎用ホスト名と DNS.1=aaa.ise.local および DNS.2=*.ise.local などのワイルドカード表記が含まれます。
のように *.ise.local を使用してワイルドカード証明書を設定すると、その同じ証明書を使用して、次のような、DNS 名が「.ise.local」で終了する他のすべてのホストを保護することができます。
ワイルドカード証明書は通常の証明書と同じ方法で通信を保護し、要求は同じ検証方式を使用して処理されます。
次の図に、Web サイトの保護に使用されるワイルドカード証明書の例を示します。
以前のリリースの Cisco ISE では、CN 値を使用して、url-redirect A-V pair 文字列の変数を置き換えていました。この CN 値は、すべての Centralized Web Authentication(CWA)、オンボーディング、ポスチャ リダイレクションなどに使用されました。
Cisco ISE は CN として ISE ノードのホスト名を使用します。
SSL/TLS トンネリングを使用する Admin(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 です。
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 の ISE /admin(config)# プロンプトからコンフィギュレーション モードで ip host コマンドを使用できます。
ip host IP_address host-alias FQDN-string
ここで、IP_address はネットワーク インターフェイス(eth1 または eth2 または eth3)の IP アドレスで、host-alias はネットワーク インターフェイスに割り当てる名前です。FQDN-string は、ネットワーク インターフェイスの完全修飾ドメイン名です。このコマンドを使用して、ネットワーク インターフェイスに host-alias または FQDN-string あるいはその両方を割り当てることができます。
ip host コマンドの使用例:ip host a.b.c.d sales sales.amerxyz.cometh0 以外のインターフェイスにホストのエイリアスを割り当てたら、application start ise コマンドを使用して Cisco ISE でアプリケーション サービスを再起動する必要があります。
このホスト エイリアスのネットワーク インターフェイスとの関連付けを削除するには、次のようにこのコマンドの no 形式を使用します。
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」で終わるすべてのホストを保護するために使用できます。
ワイルドカード証明書は通常、証明書サブジェクトの一般名(CN)としてリストされているワイルドカードを使用して作成されます。Cisco ISE は、このタイプの作成をサポートします。ただし、すべてのエンドポイント サプリカントが証明書サブジェクトのワイルドカード文字をサポートするわけではありません。
テスト済みのすべての Microsoft ネイティブ サプリカント(Windows Mobile を含む)の一部は、証明書のサブジェクトのワイルドカード文字をサポートしていません。
Cisco AnyConnect Network Access Manager(NAM)など、[サブジェクト(Subject)] フィールドでのワイルドカード文字の使用をサポートできる他のサプリカントを使用することができます。
また、DigiCert の Wildcard Plus など、証明書のサブジェクト代替名に特定のサブドメインを含めることで、互換性のないデバイスを使用するように設計された、特別なワイルドカード証明書を使用することもできます。
Microsoft サプリカントの制限はワイルドカード証明書の使用にとって妨げになるように見えますが、Microsoft のネイティブ サプリカントを含む、セキュアなアクセスについてテスト済みのすべてのデバイスを使用できるようにする代替の方法があります。
このためには、サブジェクトにワイルドカードを使用する代わりに、[Subject Alterative Name (SAN)] フィールドでワイルドカード文字を使用します。SAN フィールドはドメイン名(DNS 名)を検査するように設計された拡張を保持します。詳細については、RFC 6125 および 2128 を参照してください。
管理者ポータルから、すべてのエンドポイント、システム、および信頼できる証明書の証明書階層または信頼書トラスト チェーンを表示できます。証明書階層には、証明書、すべての中間認証局(CA)の証明書、およびルート証明書が含まれています。たとえば、管理者ポータル からシステム証明書を表示すると、デフォルトでは該当するシステム証明書の詳細が表示されます。証明書階層は、証明書の上部に表示されます。詳細を表示するには、その階層で証明書をクリックします。自己署名証明書には階層または信頼チェーンがありません。
証明書のリスト ページで、[ステータス(Status)] 列に次のアイコンのいずれかが表示されます。
Cisco ISE システム証明書は、展開内のその他のノードおよびクライアント アプリケーションに対して Cisco ISE ノードを識別するサーバ証明書です。システム証明書の用途は次のとおりです。
Cisco ISE 展開でノード間通信に使用されます。この証明書の場合、[使用方法(Usage)] フィールドで [管理(Admin)] オプションを選択します。
Cisco ISE Web ポータルに接続するブラウザおよび REST クライアントで使用されます。この証明書の場合、[使用方法(Usage)] フィールドで [ポータル(Portal)] オプションを選択します。
PEAP および EAP-FAST を使用する外部 TLS トンネルを形成するために使用されます。EAP-TLS、PEAP、および EAP-FAST の相互認証の場合、[使用方法(Usage)] フィールドで [EAP] オプションを選択します。
RADIUS DTLS サーバ認証に使用されます。
SAML ID プロバイダー(IdP)との通信に使用されます。この証明書の [使用方法(Usage)] フィールドで [SAML] オプションを選択します。[SAML] オプションを選択すると、その他のサービスにこの証明書を使用することはできません。
pxGrid コントローラとの通信に使用されます。この証明書の場合、[使用方法(Usage)] フィールドで [pxGrid] オプションを選択します。
Cisco ISE 展開で、各ノードで有効なシステム証明書をインストールする必要があります。デフォルトでは、インストール時に Cisco ISE ノードに 2 つの自己署名証明書と、内部 Cisco ISE CA により署名された 1 つの証明書が作成されます。
[EAP]、[管理(Admin)]、[ポータル(Portal)]、および [RADIUS DTLS] のための自己署名サーバ証明書(キー サイズは 2048 で 1 年間有効です)。
SAML IdP との安全な通信に使用できる自己署名 SAML サーバ証明書(キー サイズは 2048 で 1 年間有効です)。
pxGrid クライアントとの安全な通信に使用できる内部 Cisco ISE CA 署名付きサーバ証明書(キー サイズは 4096 で 1 年間有効です)。
展開をセットアップし、セカンダリ ノードを登録すると、pxGrid コントローラ用の証明書が自動的にプライマリ ノードの CA 署名付き証明書に置き換わります。したがってすべての pxGrid 証明書が同一 PKI トラスト階層の一部となります。
(注) | ワイルドカード システム証明書をエクスポートして、(ノード間通信用に)他のノードにインポートする場合は、必ず証明書と秘密キーをエクスポートして、暗号化パスワードを指定してください。インポート時は、証明書、秘密キー、および暗号化パスワードが必要です。 |
シスコでは、セキュリティ向上のために自己署名証明書を CA 署名付き証明書と置き換えることを推奨します。CA 署名付き証明書を取得するには、以下を行う必要があります。
証明書署名要求(CSR)を作成します。
認証局(CA)に送信します。
署名付き証明書を取得します。
関連するルートおよび中間 CA 証明書を信頼できる証明書ストアにインポートします。
CSR に署名付き証明書をバインドします。
How To: Implement ISE Server-Side Certificates Certificate Renewal on Cisco Identity Services Engine Configuration Guide |
[システム証明書(System Certificate)] ページに、Cisco ISE に追加されたすべてのシステム証明書が一覧表示されます。
ステップ 1 | を選択します。
[システム証明書(System Certificate)] ページが表示されます。このページには、システム証明書に関する次の情報が表示されています。
|
ステップ 2 | 証明書を選択し、[表示(View)] を選択して証明書の詳細を表示します。 |
インポートするシステム証明書が外部 CA によって署名されている場合は、関連するルート CA および中間 CA 証明書を信頼できる証明書ストアにインポートします([管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [信頼できる証明書(Trusted Certificates)])。
Cisco ISE では、SHA-256 より大きいハッシュ アルゴリズムで署名された証明書はサポートされていません。したがって、SHA-256 より大きいハッシュ アルゴリズムで署名されたサーバ証明書はインポートしないでください。
インポートするシステム証明書に、CA フラグが true に設定された基本制約拡張が含まれている場合は、キー使用拡張が存在すること、および keyEncipherment ビットと keyAgreement ビットのいずれかまたは両方が設定されていることを確認します。
自己署名証明書を生成することにより、新しいローカル証明書を追加できます。自己署名証明書は、内部テストと評価のニーズに対してのみ使用することを推奨します。実稼働環境に Cisco ISE を展開することを計画している場合は、可能な限り CA 署名付き証明書を使用して、実稼働ネットワーク全体でより均一な受け入れが行われるようにします。
(注) | 自己署名証明書を使用しており、Cisco ISE ノードのホスト名を変更する必要がある場合は、Cisco ISE ノードの管理者用ポータルにログインし、古いホスト名が使用された自己署名証明書を削除し、新しい自己署名証明書を生成します。そうしないと、Cisco ISE は古いホスト名が使用された自己署名証明書を引き続き使用します。 |
ステップ 1 | を選択します。 |
ステップ 2 | [自己署名証明書の生成(Generate Self Signed Certificate)] をクリックし、[自己署名証明書の生成(Generate Self Signed Certificate)] ページに詳細を入力します。 |
ステップ 3 | 自己署名したワイルドカード証明書(サブジェクトの任意の一般名またはサブジェクト代替名の DNS 名、またはその両方にアスタリスク(*)が含まれている証明書)を生成する場合は、[ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。たとえば、SAN に割り当てられている DNS 名が *.amer.cisco.com の場合です。 |
ステップ 4 | この証明書を使用するサービスに基づいて [使用方法(Usage)] 領域のチェックボックスをオンにします。 |
ステップ 5 | 証明書を生成するには、[送信(Submit)] をクリックします。
CLI からセカンダリ ノードを再起動するには、指定された順序で次のコマンドを入力します。 |
このページを使用して、システム証明書を編集し、自己署名証明書を更新できます。ワイルドカード証明書を編集すると、変更が展開内のすべてのノードに複製されます。ワイルドカード証明書を削除した場合、そのワイルドカード証明書は展開内のすべてのノードから削除されます。
ステップ 1 | を選択します。 |
ステップ 2 | 編集する証明書の横にあるチェックボックスをオンにして、[編集(Edit)] をクリックします。 |
ステップ 3 | 自己署名証明書を更新するには、[更新期間(Renewal Period)] チェックボックスをオンにして、有効期限 TTL(存続可能時間)を日、週、月、または年単位で入力します。 |
ステップ 4 | [Save(保存)] をクリックして変更内容を保存します。
[管理者(Admin)] チェックボックスがオンになっている場合、Cisco ISE ノードのアプリケーション サーバが再起動されます。また、その Cisco ISE ノードが展開の PAN である場合は、展開内のその他すべてのノードでもアプリケーション サーバが再起動されます。プライマリ管理ノード(PAN)の再起動が完了すると、システムによって一度に 1 つのノードが再起動されます。 |
今後使用しないシステム証明書を削除できます。
システム証明書ストアから複数の証明書を一度に削除できますが、管理および EAP 認証に使用できる証明書を少なくとも 1 つ所有する必要があります。また、管理、EAP 認証、ポータル、または pxGrid コントローラに使用される証明書は削除できません。ただし、サービスがディセーブルの場合は、pxGrid 証明書を削除できます。
ワイルドカード証明書を削除することを選択した場合、証明書は展開内のすべてのノードから削除されます。
選択したシステム証明書とその証明書に関連付けられている秘密キーをエクスポートできます。証明書とその秘密キーをバックアップ用にエクスポートする場合は、それらを必要に応じて後で再インポートできます。
ステップ 1 | を選択します。 | ||
ステップ 2 | エクスポートする証明書の横にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。 | ||
ステップ 3 | 証明書のみをエクスポートするか、証明書と証明書に関連付けられている秘密キーをエクスポートするかを選択します。
| ||
ステップ 4 | 秘密キーをエクスポートする場合は、パスワードを入力します。パスワードは、8 文字以上にする必要があります。 | ||
ステップ 5 | [エクスポート(Export)] をクリックして、クライアント ブラウザを実行しているファイル システムに証明書を保存します。
証明書のみをエクスポートする場合、証明書は Privacy Enhanced Mail 形式で保存されます。証明書と秘密キーの両方をエクスポートする場合、証明書は Privacy Enhanced Mail 形式の証明書と暗号化された秘密キー ファイルを含む .zip ファイルとしてエクスポートされます。 |
信頼できる証明書ストアには、信頼に使用される、Simple Certificate Enrollment Protocol(SCEP)用の X.509 証明書が含まれています。
信頼できる証明書ストア内の証明書は PAN で管理され、Cisco ISE 展開内の他のすべてのノードに複製されます。Cisco ISE はワイルドカード証明書をサポートしています。
Cisco ISE は、次の目的で信頼できる証明書を使用します。
エンドポイントによる認証と、証明書ベースの管理者認証を使用してISE-PIC管理者ポータルにアクセスする Cisco ISE 管理者による認証に使用するクライアント証明書を確認するため。
展開内の Cisco ISE ノード間のセキュアな通信を可能にするため。信頼できる証明書ストアには、展開内の各ノードのシステム証明書との信頼を確立するために必要な CA 証明書のチェーンが含まれている必要があります。
セキュア LDAP 認証を有効にするには、SSL を経由してアクセスされる LDAP ID ソースを定義するときに、証明書ストアから証明書を選択する必要があります。
パーソナル デバイス ポータルを使用してネットワークへの登録を準備しているパーソナル デバイスに配信するため。Cisco ISE は、パーソナル デバイス登録をサポートするために、ポリシー サービス ノード(PSN)での SCEP を実装しています。登録するデバイスは、SCEP プロトコルを使用して PSN からクライアント証明書を要求します。PSN には中継の役割を果たす登録局(RA)があります。RA は、登録するデバイスからの要求を受信して検証し、その後クライアント証明書を発行する外部 CA または内部 Cisco ISE CA にその要求を転送します。CA は RA に証明書を返し、RA が証明書をデバイスに返します。
Cisco ISE によって使用される各 SCEP CA は、SCEP RA プロファイルによって定義されます。SCEP RA のプロファイルが作成されると、次の 2 つの証明書が信頼できる証明書ストアに自動的に追加されます。
SCEP プロトコルでは、これらの 2 つの証明書が RA によって登録デバイスに提供されている必要があります。信頼できる証明書ストアにこの 2 つの証明書を配置すると、これらのノードの RA が使用するために、証明書がすべての PSN ノードに複製されます。
(注) | Cisco ISE にインポートされる X.509 証明書は、Privacy Enhanced Mail(PEM)または Distinguished Encoding Rules(DER)形式である必要があります。証明書チェーン(システム証明書、およびその証明書に署名する一連の信頼された証明書)が含まれたファイルはインポートすることができますが、特定の制限の対象となります。 |
信頼できる証明書ストアは、次の信頼できる証明書で事前設定されています。製造業者証明書、ルート証明書、その他の信頼できる証明書。ルート証明書(Cisco Root CA)は、製造業者(Cisco CA Manufacturing)証明書に署名します。これらの証明書は、デフォルトでは無効になっています。展開でエンドポイントとして Cisco IP Phone を使用している場合は、これら 2 つの証明書を有効にして、この電話用にシスコが署名した証明書の認証ができるようにします。
CTL の信頼できる証明書には名前の制約の拡張が含まれている場合があります。この拡張は、証明書チェーンの後続のすべての証明書のサブジェクト名とサブジェクト代替名フィールドの値の名前空間を定義します。Cisco ISE は、ルート証明書で指定された制約を検査しません。
信頼できる証明書にサポートされていない制約が含まれており、検証中の証明書に該当のフィールドが含まれていない場合は、Cisco ISE がサポートされない制約を検証できないため、その証明書は拒否されます。
X509v3 Name Constraints: critical Permitted: othername:<unsupported> email:.abcde.at email:.abcde.be email:.abcde.bg email:.abcde.by DNS:.dir DirName: DC = dir, DC = emea DirName: C = AT, ST = EMEA, L = AT, O = ABCDE Group, OU = Domestic DirName: C = BG, ST = EMEA, L = BG, O = ABCDE Group, OU = Domestic DirName: C = BE, ST = EMEA, L = BN, O = ABCDE Group, OU = Domestic DirName: C = CH, ST = EMEA, L = CH, O = ABCDE Group, OU = Service Z100 URI:.dir IP:172.23.0.171/255.255.255.255 Excluded: DNS:.dir URI:.dir
受け入れ可能なクライアント証明書のサブジェクトは、次のように上記の定義に一致します。
Subject: DC=dir, DC=emea, OU=+DE, OU=OU-Administration, OU=Users, OU=X1, CN=cwinwell
[信頼できる証明書(Trusted Certificates)] ページに、Cisco ISE に追加されたすべての信頼できる証明書が一覧表示されます。信頼できる証明書を表示するには、スーパー管理者またはシステム管理者である必要があります。
すべての証明書を表示するには、 を選択します。[信頼できる証明書(Trusted Certificates)] ページが表示され、すべての信頼できる証明書が一覧表示されます。
証明書のステータスが有効になっている必要があります。これにより、Cisco ISE が信頼の確立にこの証明書を使用できるようになります。証明書が信頼できる証明書ストアにインポートされると、この証明書は自動的に有効になります。
[証明書ストア(Certificate Store)] ページを使用して、Cisco ISE に CA 証明書を追加することができます。
ステップ 1 | を選択します。 |
ステップ 2 | [インポート(Import)] をクリックします。 |
ステップ 3 | 必要に応じてフィールドの値を設定します。
EAP 認証用に証明書チェーンにサブ CA 証明書を使用する場合は、ルート CA までに証明書チェーンにすべての証明書をインポートする際に [クライアント認証および syslog 用に信頼する(Trust for client authentication and Syslog)] チェックボックスを必ずオンにしてください。 パスワード ベースの認証から証明書ベースの認証に認証タイプを変更すると、Cisco ISE は展開内の各ノードでアプリケーション サーバを再起動します。PAN のアプリケーション サーバから開始され、その後に各追加ノードが 1 つずつ続きます。 |
今後使用しない信頼できる証明書を削除できます。ただし、ISE 内部 CA(認証局)の証明書は削除しないでください。ISE 内部 CA 証明書を削除できるのは、展開全体の ISE ルート証明書チェーンを置き換える場合のみです。
ステップ 1 | 。 |
ステップ 2 | 削除する証明書の隣にあるチェックボックスをオンにし、[削除(Delete)] をクリックします。
警告メッセージが表示されます。ISE 内部 CA 証明書を削除することを選択した場合は、次のとおりにクリックします。
|
ステップ 3 | [はい(Yes)] をクリックして、証明書を削除します。 |
ルート CA 証明書および中間 CA 証明書をインポートするとき、信頼できる CA 証明書を使用する対象のサービスを指定できます。
ステップ 1 | 。 |
ステップ 2 | [インポート(Import)] をクリックします。 |
ステップ 3 | [参照(Browse)] をクリックして、ルート CA 証明書を選択します。 |
ステップ 4 | わかりやすい名前を入力します。 わかりやすい名前を入力しない場合、Cisco ISE により、このフィールドには、common-name#issuer#nnnnn の形式でわかりやすい名前が自動的に入力されます。ここで、nnnnn は一意の番号です。再度証明書を編集して、わかりやすい名前を変更できます。 |
ステップ 5 | CA によって返されたルート証明書を選択します。 |
ステップ 6 | この信頼できる証明書を使用するサービスの横にあるチェックボックスをオンにします。 |
ステップ 7 | 説明を入力します。 |
ステップ 8 | [送信(Submit)] をクリックします。 |
信頼できる証明書ストアに中間 CA 証明書をインポートします(該当する場合)。
証明書ストアから受信した証明書チェーンを含む単一のファイルから、複数の証明書をインポートすることができます。ファイル内のすべての証明書は Privacy-Enhanced Mail(PEM)の形式であり、証明書は次の順序に並べられている必要があります。
認証局(CA)が署名付き証明書を発行するためには、証明書署名要求(CSR)を作成して CA に送信する必要があります。
自分が作成した証明書署名要求(CSR)のリストは、[証明書署名要求(Certificate Signing Requests)] ページで使用できます。認証局(CA)から署名を取得するには、CSR をエクスポートし、その証明書を CA に送信する必要があります。証明書は CA によって署名され、返されます。
管理者ポータルから証明書を一元的に管理できます。展開内のすべてのノードの CSR を作成およびエクスポートできます。その後、CSR を CA に送信し、CA から CA 署名付き証明書を取得し、CA によって返されたルートおよび中間 CA 証明書を信頼できる証明書ストアにインポートし、CSR に CA 署名付き証明書をバインドする必要があります。
証明書署名要求(CSR)を生成して、展開内のノードの CA 署名付き証明書を取得できます。展開の選択ノードまたは展開のすべてのノード用の CSR を生成できます。
ステップ 1 | を選択します。 |
ステップ 2 | CSR を生成するための値を入力します。各フィールドの詳細については、証明書署名要求の設定を参照してください。 |
ステップ 3 | [Generate(生成)] をクリックして CSR を生成します。
CSR が生成されます。 |
ステップ 4 | [Export(エクスポート)] をクリックして、メモ帳で CSR を開きます。 |
ステップ 5 | 「-----BEGIN CERTIFICATE REQUEST-----」から「-----END CERTIFICATE REQUEST-----」までのすべてのテキストをコピーします。 |
ステップ 6 | 選択した CA の証明書要求に、この CSR の内容を貼ってください。 |
ステップ 7 | 署名済みの証明書をダウンロードする。
CA によっては、署名付き証明書が電子メールで送信される場合があります。署名付き証明書は、zip ファイルの形式で、Cisco ISE の信頼された証明書ストアに追加する必要がある、新規発行の証明書と CA のパブリック署名証明書が含まれています。デジタル署名された CA 証明書、ルート CA 証明書、および他の中間 CA 証明書(該当する場合)がクライアント ブラウザを実行するローカル システムにダウンロードされます。 |
CA からデジタル署名付き証明書を受け取った後、それを証明書署名要求(CSR)にバインドする必要があります。管理者ポータルから展開内のすべてのノードに対してバインド操作を実行できます。
ステップ 1 | を選択します。 |
ステップ 2 | [バインド(Bind)] をクリックします。 |
ステップ 3 | [参照(Browse)] をクリックし、CA 署名付き証明書を選択します。 |
ステップ 4 | 証明書の [フレンドリ名(Friendly Name)] を指定します。 |
ステップ 5 | サブジェクトの CN またはサブジェクト代替名の DNS 名にワイルドカード文字のアスタリスク(*)を含む証明書をバインドするには、[ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。 |
ステップ 6 | Cisco ISE に証明書の拡張の検証を許可する場合は、[証明書の拡張の検証を有効にする(Enable Validation of Certificate Extensions)] チェックボックスをオンにします。
[証明書の拡張の検証を有効にする(Enable Validation of Certificate Extensions)] オプションが有効になっており、インポートする証明書に CA フラグが true に設定された基本制約拡張が含まれている場合は、キー使用拡張が存在すること、および keyEncipherment ビットと keyAgreement ビットのいずれかまたは両方が設定されていることを確認します。 |
ステップ 7 | この証明書が使用領域で使用されるサービスを確認します。 この情報は、CSR の生成時に [使用方法(Usage)] オプションを有効にした場合は自動入力されます。証明書のバインディング時に使用方法を指定しない場合は、[使用方法(Usage)] オプションをオフにします。後で証明書を編集し、使用方法を指定できます。 |
ステップ 8 | [送信(Submit)] をクリックし、CA 署名付き証明書をバインドします。
Cisco ISE ノード間通信にこの証明書を使用するように選択した場合、Cisco ISE ノードでアプリケーション サーバが再起動されます。 他のノードで CA 署名付き証明書に CSR をバインドするために、このプロセスを繰り返します。 |
展開をセットアップする場合、セカンダリ ノードを登録する前に、セカンダリ ノードの管理者証明書の検証に使用される適切な CA 証明書を PAN の証明書信頼リスト(CTL)に配置する必要があります。PAN の CTL に入力する手順は、シナリオに応じて異なります。
セカンダリ ノードが管理者ポータルとの通信に CA 署名付き証明書を使用する場合は、セカンダリ ノードの CA 署名付き証明書、関連する中間証明書(ある場合)、および(セカンダリ ノードの証明書に署名した CA の)ルート CA 証明書を PAN の CTL にインポートする必要があります。
セカンダリ ノードが管理者ポータルとの通信に自己署名証明書を使用する場合は、PAN の CTL にセカンダリ ノードの自己署名証明書をインポートできます。
(注) |
|
外部 CA から発行された証明書に基本制約が定義されており、CA フラグが true に設定されていることを確認します。ノード間通信の CA 署名付き証明書をインストールするには、次の手順を実行します。
ステップ 1 | 証明書署名要求の作成と認証局への CSR の送信 |
ステップ 2 | 信頼できる証明書ストアへのルート証明書のインポート |
ステップ 3 | CSR への CA 署名付き証明書のバインド |
Web ポータル要求を処理できる展開に複数のポリシー サービス ノード(PSN)がある場合、Cisco ISE には一意の ID が必要です。この ID で、ポータルの通信に使用する必要がある証明書を識別します。ポータルでの使用に指定された証明書を追加またはインポートする場合、証明書グループ タグを定義して、それを展開内の各ノードの対応する証明書に関連付ける必要があります。この証明書グループ タグを対応するエンドユーザ ポータル(ゲスト、スポンサー、およびパーソナル デバイス ポータル)に関連付ける必要があります。この証明書グループ タグは一意の ID で、Cisco ISE が各ポータルと通信する際に使用する必要がある証明書を識別する場合に役立ちます。ポータルごとに各ノードから 1 つの証明書を指定できます。
(注) | Cisco ISE は TCP ポート 8443(またはポータルが使用するように設定したポート)でポータル証明書を提示します。 |
ステップ 1 | 証明書署名要求の作成と認証局への CSR の送信。
すでに定義済みの証明書グループ タグを選択するか、ポータル用に新しく作成する必要があります。たとえば、mydevicesportal などです。 |
ステップ 2 | 信頼できる証明書ストアへのルート証明書のインポート。 |
ステップ 3 | CSR への CA 署名付き証明書のバインド。 |
デフォルトでは、すべての Cisco ISE ポータルは自己署名証明書を使用します。ポータルに CA 署名付き証明書を使用する場合は、デフォルトのポータル証明書グループ タグを CA 署名付き証明書に割り当てることができます。既存の CA 署名付き証明書を使用するか、または CSR を生成して、ポータルに使用する新しい CA 署名付き証明書を取得できます。1 つの証明書から別の証明書にポータル グループ タグを再割り当てすることができます。
(注) | 既存の証明書を編集する場合、証明書に関連付けられているポータル タグ(ゲスト)がいずれかのポータルですでに使用されている場合は、デフォルトのポータル証明書グループ タグまたは他のポータル グループ タグをこの証明書に再割り当てすることはできません。「ゲスト」ポータル タグを使用しているポータルのリストが表示されます。 |
次に、CA 署名付き証明書にデフォルトのポータル証明書グループ タグを再割り当てする手順について説明します。
ステップ 1 |
を選択します。 このタグを使用するポータルのリストを表示するには、デフォルトのポータル証明書グループ タグの横にある i アイコンにマウス ポインタを合わせます。このタグが割り当てられているポータル証明書がある展開内の ISE ノードを表示することもできます。 |
ステップ 2 | ポータルに使用する CA 署名付き証明書の横にあるチェックボックスをオンにして、[編集(Edit)] をクリックします。
いずれのポータルでも使用されていない CA 署名付き証明書を選択してください。 |
ステップ 3 | [使用方法(Usage)] 領域で、[ポータル(Portal)] チェックボックスをオンにして、デフォルトのポータル証明書グループ タグを選択します。 |
ステップ 4 | [保存(Save)] をクリックします。
警告メッセージが表示されます。 |
ステップ 5 | [はい(Yes)] をクリックして、CA 署名付き証明書にデフォルトのポータル証明書グループ タグを再割り当てします。 |
展開内のすべてのポータルに「デフォルト ポータル証明書グループ」タグを使用する場合は、新しい ISE ノードを登録する前に、関連する CA 署名付き証明書をインポートし、サービスとして「ポータル」を選択し、この証明書に「デフォルト ポータル証明書グループ」タグを関連付けます。
展開に新しいノードを追加すると、デフォルトの自己署名証明書が「デフォルト ポータル証明書グループ」タグに関連付けられ、このタグを使用するようにポータルが設定されます。
新しいノードの登録後、証明書グループ タグの関連付けは変更できません。したがって、展開にノードを登録する前に、次を実行してください。
ステップ 1 | 自己署名証明書を作成し、サービスとして「ポータル」を選択し、別の証明書グループ タグ(たとえば、tempportaltag)を割り当てます。 | ||||||||
ステップ 2 | 新しく作成した証明書グループ タグ(tempportaltag)を使用するようにポータル設定を変更します。 | ||||||||
ステップ 3 | デフォルト自己署名証明書を編集し、ポータル ロールを削除します。
このオプションは、デフォルト ポータル証明書グループ タグとデフォルト自己署名証明書との関連付けを削除します。 | ||||||||
ステップ 4 | 次のいずれかを実行します。
| ||||||||
ステップ 5 | 展開に ISE ノードを登録します。 展開内のポータル構成は「デフォルト ポータル証明書グループ」タグに設定され、ポータルは新しいノードの「デフォルト ポータル証明書グループ」タグに関連付けられた CA 署名付き証明書を使用するように設定されます。 |
デフォルトでは、Cisco ISE は証明書が期限切れになったデバイスからの要求を拒否します。ただし、このデフォルト動作を変更し、このような要求を処理し、ユーザに証明書の更新を求めるように ISE を設定できます。
ユーザが証明書を更新することを許可する場合は、要求をさらに処理する前に証明書が更新されたかどうかを判断する許可ポリシー ルールを設定することを推奨します。証明書が期限切れになったデバイスからの要求を処理することで、潜在的なセキュリティ脅威が発生する可能性があります。組織のセキュリティが侵害されていないことを保証するには、適切な許可プロファイルおよびルールを設定する必要があります。
あるデバイスは有効期限の前後に証明書を更新できます。ただし、Windows デバイスでは、期限切れになる前にだけ証明書を更新できます。Apple iOS、Mac OSX、および Android デバイスでは、有効期限の前または後に証明書を更新できます。
Cisco ISE 証明書ディクショナリには、ユーザに証明書更新を許可するポリシー条件で使用される次の属性が含まれます。
許可ポリシーで CertRenewalRequired の単純条件(デフォルトで使用可能)を使用すると、Cisco ISE が要求を処理する前に証明書(有効期限切れまたはまもなく有効期限が切れる)を更新できます。
ユーザ証明書が期限切れになる前に失効している場合、Cisco ISE は、CA がパブリッシュした CRL をチェックして認証要求を拒否します。失効した証明書の期限が切れている場合は、CA が CRL でこの証明書をパブリッシュしない可能性があります。このシナリオでは、失効した証明書が Cisco ISE によって更新される可能性があります。このことを避けるために、証明書を更新する前に、要求が中央 Web 認証(CWA)にリダイレクトされ、完全認証が実行されるようにします。CWA のユーザをリダイレクトするには、許可プロファイルを作成する必要があります。
ユーザが証明書を更新できるように Cisco ISE を設定するには、この手順で示すタスクを実行する必要があります。
WLC で制限されたアクセス ACL を設定して、CWA 要求をリダイレクトします。
ステップ 1 | 許可されるプロトコルの設定の更新 |
ステップ 2 | CWA リダイレクションの許可ポリシー プロファイルの作成 |
ステップ 3 | 証明書を更新する許可ポリシー ルールの作成 |
ステップ 4 | ゲスト ポータルでの BYOD 設定の有効化 |
ステップ 1 | を選択します。 |
ステップ 2 | PEAP および EAP-FAST プロトコルの EAP-TLS プロトコルおよび EAP-TLS 内部方式の下の [許可ポリシーの証明書更新を可能にするために失効した証明書の認証を許可(Allow Authentication of expired certificates to allow certificate renewal in Authorization Policy)] チェックボックスをオンにします。
EAP-TLS プロトコルを使用する要求が NSP フローを通過します。 PEAP および EAP-FAST プロトコルについては、要求を処理するように Cisco ISE 向け Cisco AnyConnect を手動で設定する必要があります。 |
ステップ 3 | [送信(Submit)] をクリックします。 |
WLC で制限されたアクセス ACL が設定されていることを確認します。
ステップ 1 | を選択します。 |
ステップ 2 | [追加(Add)] をクリックします。 |
ステップ 3 | 許可プロファイルの名前を入力します。たとえば、CertRenewal_CWA です。 |
ステップ 4 | [共通タスク(Common Tasks)] 領域の [Web リダイレクション(CWA、DRW、MDM、NSP、CPP)(Web Redirection (CWA, DRW, MDM, NSP, CPP))] チェックボックスをオンにします。 |
ステップ 5 | ドロップダウン リストの [中央集中 Web 認証(Centralized Web Auth)] および制限されたアクセス ACL を選択します。 |
ステップ 6 | [証明書更新メッセージの表示(Display Certificates Renewal Message)] チェックボックスをオンにします。
url-redirect 属性値が変更され、この値に証明書が有効である日数が含まれます。 |
ステップ 7 | [送信(Submit)] をクリックします。 |
(注) | Cisco ISE 1.2 で無線デバイスの次のデバイス登録 WebAuth(DRW)ポリシーを設定している場合:
ISE 1.3 以上のバージョンにアップグレードした後は、DRW-Allow ポリシー条件を次のように更新する必要があります。 |
中央 Web 認証リダイレクションの許可プロファイルが作成されていることを確認します。
でポリシー セットを有効にします。
証明書が期限切れになったデバイスを持つ企業ネットワークにアクセスした場合は、[更新(Renew)] をクリックして、デバイスを再設定します。
ユーザがパーソナル デバイス証明書を更新できるようにするには、選択したゲスト ポータルで BYOD 設定を有効にする必要があります。
ステップ 1 | を選択します。
|
ステップ 2 | [BYOD 設定(BYOD Settings)] から [従業員にネットワークでのパーソナルデバイスの使用を許可する(Allow employees to use personal devices on the network)] チェックボックスをオンにします。 |
ステップ 3 | [保存(Save)] をクリックします。 |
ISE を使用して Apple iOS デバイスのエンドポイント証明書を更新する場合、「プロファイル済みでインストールできませんでした(Profiled Failed to Install)」エラー メッセージが表示される場合があります。このエラー メッセージは、同じポリシー サービス ノード(PSN)または別の PSN で、期限切れ間近または期限切れのネットワーク プロファイルが更新のプロセス時に使用されるものとは異なる管理者 HTTPS 証明書によって署名されている場合に表示されます。
回避策としては、展開内のすべての PSN で管理者 HTTPS 用にマルチドメイン SSL 証明書(通称 Unified Communications Certificates(UCC))またはワイルドカード証明書を使用します。
証明書は、自己署名したり、外部の認証局(CA)がデジタルで署名したりできます。Cisco ISE 内部認証局(ISE CA)は、従業員が企業ネットワークでパーソナル デバイスを使用できるように、一元的なコンソールからエンドポイントのデジタル証明書を発行し、管理します。 CA 署名付きデジタル証明書は、業界標準であり、よりセキュアです。プライマリ PAN は、ルート CA です。ポリシー サービス ノード(PSN)は、プライマリ PAN の下位 CA です(SCEP RA)。 ISE CA には次の機能があります。
インストール後に、Cisco ISE ノードはルート CA 証明書およびノード CA 証明書でプロビジョニングされ、エンドポイントの証明書が管理されます。
展開をセットアップすると、プライマリ管理ノード(PAN)として指定したノードがルート CA になります。PAN には、ルート CA 証明書と、ルート CA によって署名されたノード CA 証明書があります。
PAN にセカンダリ管理ノードを登録すると、ノード CA 証明書が生成され、プライマリ管理ノードでルート CA によって署名されます。
PAN に登録したポリシー サービス ノード(PSN)には、エンドポイント CA と、PAN のノード CA によって署名された OCSP 証明書がプロビジョニングされます。ポリシー サービス ノード(PSN)は、PAN の下位 CA です。ISE CA を使用すると、PSN のエンドポイント CA によってネットワークにアクセスするエンドポイントに証明書が発行されます。
Cisco ISE CA チェーンを再生成すると、ルート CA、ノード CA、およびエンドポイント CA 証明書を含むすべての証明書が再生成されます。PAN または PSN のドメイン名またはホスト名を変更すると、ISE CA チェーンを再生する必要があります。以前のリリースから 2.0 以降にアップグレードするときには、2 つのルート階層から 1 つのルート階層に移行するように ISE CA チェーンを再生成することをお勧めします。
Cisco ISE CA サービスが、楕円曲線暗号化(ECC)アルゴリズムに基づく証明書をサポートするようになりました。ECC は、他のシステムと同レベルのセキュリティをはるかに小さいキー サイズで実現し、他の暗号化アルゴリズムよりも強化されたセキュリティと優れたパフォーマンスを実現します。
暗号化とデジタル署名に必要なキー サイズが、他のシステムよりもはるかに小さくなっています。次の表に、同等のセキュリティ強度を実現するための ECC および RSA のキー サイズを示します。
ECC のキー サイズ(ビット単位) | RSA のキー サイズ(ビット単位) |
---|---|
160 | 1024 |
224 | 2048 |
256 | 3072 |
384 | 7680 |
521 | 15360 |
キー サイズが小さいため、このシステムでは暗号化のために必要な時間が短く、パフォーマンスが向上します。
Cisco ISE では、次の ECC 曲線タイプがサポートされています。曲線タイプまたはキー サイズが大きくなると、セキュリティが強化されます。
Cisco ISE CA サービスは、BYOD フローを介して接続するデバイスの ECC 証明書をサポートします。また、証明書プロビジョニング ポータルから ECC 証明書を生成することもできます。
(注) | 次の表に、ECC をサポートしているオペレーティング システムおよびバージョンと、サポートされている曲線タイプを示します。デバイスがサポートされているオペレーティング システムを実行していない場合、またはサポートされているバージョンでない場合には、代わりに RSA ベースの証明書を使用することもできます。
Windows 7 と Apple iOS は、EAP-TLS 認証用の ECC をネイティブでサポートしていません。Cisco ISE のこのリリースでは、Mac OS X デバイスでの ECC 証明書の使用はサポートされていません。 |
Enrollment over Secure Transport(EST)プロトコルを備えた BYOD フローが適切に機能しない場合は、次のことを確認します。
証明書サービス エンドポイント サブ CA 証明書チェーンが完全であること。証明書チェーンが完全かどうかを確認するには:
CA および EST サービスが起動し、実行されていることを確認します。サービスが有効になっていない場合には、[管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [認証局(Certificate Authority)] > [内部 CA の設定(Internal CA Settings)] に移動して CA サービスを有効にします。
2.0 以前の ISE バージョンから Cisco ISE 2.1 にアップグレードしている場合は、アップグレード後に ISE ルート CA 証明書チェーンを置き換えます。手順は次のとおりです。
[管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [証明書の管理(Certificate Management)] > [証明書署名要求(Certificate Signing Requests)] の順に選択します。
[証明書署名要求(CSR)の生成(Generate Certificate Signing Requests (CSR))] をクリックします。
[証明書の使用先(Certificate(s) will be used for)] ドロップダウン リストから ISE ルート CA を選択します。
[ISE ルート CA 証明書チェーンの置き換え(Replace ISE Root CA Certificate Chain)] をクリックします。
(注) | Cisco ISE のこのリリースでは、EST クライアントが Cisco ISE に存在する EST サーバに対して直接認証を行うことはサポートされていません。 Android または Windows エンドポイントでのオンボーディング時に、要求が ECC ベースの証明書用である場合には、EST フローが ISE で内部的にトリガーされます。 |
[認証局(CA)証明書(Certificate Authority (CA) Certificates)] ページには、内部 Cisco ISE CA に関連するすべての証明書が表示されます。以前のリリースでは、これらの CA 証明書は信頼できる証明書ストアにありましたが、現在は [CA 証明書(CA Certificates)] ページに移動しています。これらの証明書は、このページにノード方式で表示されます。ノードを展開して、その特定のノードの ISE CA 証明書をすべて表示することができます。プライマリおよびセカンダリ管理ノードには、ルート CA、ノード CA、下位 CA、OCSP レスポンダ証明書があります。展開内の他のノードには、エンドポイント下位 CA および OCSP 証明書があります。
Cisco ISE CA サービスを有効にすると、すべてのノードでこれらの証明書が自動的に生成され、インストールされます。また、ISE ルート CA チェーン全体を置き換えると、すべてのノードでこれらの証明書が自動的に再生成され、インストールされます。手動による介入は必要ありません。
Cisco ISE CA 証明書は Certificate Services <エンドポイント サブ CA/ノード CA/ルート CA/OCSP レスポンダ>-<ノードのホスト名>#証明書番号という命名規則に従います。
[CA 証明書(CA Certificates)] ページで Cisco ISE CA 証明書を編集、インポート、エクスポート、削除、表示できます。
ステップ 1 | の順に選択します。 |
ステップ 2 | 編集する証明書の横にあるチェックボックスをオンにして、[編集(Edit)] をクリックします。 |
ステップ 3 | 必要に応じて編集可能なフィールドを変更します。フィールドの説明については、証明書設定の編集を参照してください。 |
ステップ 4 | [保存(Save)] をクリックして、証明書ストアに対して行った変更を保存します。 |
Cisco ISE ルート CA およびノード CA 証明書をエクスポートするには、次の手順を実行します。
エンドポイントが別の展開の Cisco ISE CA によって発行された証明書を使用してネットワークへの認証を試みる場合、Cisco ISE ルート CA、ノード CA、エンドポイント サブ CA 証明書をその展開から Cisco ISE の信頼できる証明書ストアにインポートする必要があります。
ステップ 1 | エンドポイントが認証されている展開の管理者用ポータルにログインします。 |
ステップ 2 | 。 |
ステップ 3 | [インポート(Import)] をクリックします。 |
ステップ 4 | 必要に応じてフィールドの値を設定します。詳細については、信頼できる証明書のインポート設定を参照してください。
クライアント証明書ベースの認証が有効である場合は、Cisco ISE により展開内の各ノードのアプリケーション サーバが再起動されます(最初に PAN のアプリケーション サーバが再起動され、続いて追加のノードのアプリケーション サーバが 1 つずつ再起動されます)。 |
証明書テンプレートには、そのテンプレートに基づいて認証局(CA)によって発行されたすべての証明書に共通のプロパティが含まれています。証明書テンプレートは、件名、サブジェクト代替名(SAN)、キー タイプ、キー サイズ、使用する必要がある SCEP RA プロファイル、証明書の有効期間、証明書がクライアントまたはサーバの認証またはその両方に使用される必要があるかどうかを指定した拡張キーの使用状況(EKU)を定義します。内部 Cisco ISE CA(ISE CA)は、証明書テンプレートを使用し、そのテンプレートに基づいて証明書を発行します。
Cisco ISE には、次の ISE CA のデフォルトの証明書テンプレートが付属しています。必要に応じて、追加の証明書テンプレートを作成できます。デフォルトの証明書テンプレートは次のとおりです。
Cisco ISE の内部 CA には、エンドポイント証明書を作成するために使用された証明書テンプレートを表す拡張子が含まれています。内部 CA によって発行されたすべてのエンドポイント証明書には、証明書テンプレート名の拡張子が含まれています。この拡張子は、そのエンドポイント証明書を作成するために使用された証明書テンプレートを表します。拡張子の ID は 1.3.6.1.4.1.9.21.2.5 です。CERTIFICATE: テンプレート名属性を許可ポリシーの条件に使用して、評価の結果に基づいて適切なアクセス権限を割り当てることができます。
許可ポリシー ルールで証明書テンプレート名の拡張子を使用できます。
Cisco ISE CA は、証明書プロビジョニング ポータルから証明書を生成するための pxGrid コントローラの証明書テンプレートを提供します。
pxGrid クライアントの証明書署名要求(CSR)を生成し、CSR の内容をクリップボードにコピーします。
ステップ 1 | ネットワーク アクセス ユーザ アカウントを作成します([管理(Administration)] > [ID の管理(Identity Management)] > [ID(Identities)] > [ユーザ(Users)] > [追加(Add)])。
ユーザが割り当てられているユーザ グループをメモします。 |
ステップ 2 | 証明書プロビジョニング ポータルの設定を編集します([管理(Administration)] > [デバイス ポータル管理(Device Portal Management)] > [証明書プロビジョニング(Certificate Provisioning)])。
|
ステップ 3 | 証明書プロビジョニング ポータルを起動します。[ポータル テスト URL(Portal test URL)] リンクをクリックします。 |
ステップ 4 | pxGrid クライアントの信頼できる証明書ストアに Cisco ISE CA チェーンをインポートします。 |
ユーザがネットワークで登録できるさまざまなモバイル デバイスの証明書のプロビジョニング機能を有効にするために、1 つ以上の Simple Certificate Enrollment Protocol(SCEP)認証局(CA)プロファイル(Cisco ISE 外部 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
管理者ポータルには、内部 ISE CA によってエンドポイントに対して発行されたすべての証明書のリストが示されます([管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [エンドポイント証明書(Endpoint Certificates)])。[発行された証明書(Issued Certificates)] ページでは、証明書ステータスを一目で確認できます。証明書が失効している場合は、[ステータス(Status)] 列の上にマウス カーソルを移動すると、失効の理由を確認できます。[証明書テンプレート(Certificate Template)] 列の上にマウス カーソルを移動すると、キー タイプ、キー サイズ、曲線タイプ、サブジェクト、サブジェクト代替名(SAN)、証明書の有効性などの詳細情報を表示できます。エンドポイント証明書クリックして、証明書を表示できます。
ISE CA によって発行されたすべての証明書(BYOD フローを介して自動的にプロビジョニングされた証明書と証明書プロビジョニング ポータルから取得された証明書)は、[エンドポイント証明書(Endpoint Certificates)] ページにリストされます。このページからこれらの証明書を管理できます。
たとえば user7 に発行された証明書を確認する場合は、[フレンドリ名(Friendly Name)] フィールドの下に表示されるテキスト ボックスに "user7" と入力します。このユーザに Cisco ISE によって発行されたすべての証明書が表示されます。フィルタをキャンセルするには、テキスト ボックスから検索語を削除します。また、[拡張フィルタ(Advanced Filter)] オプションを使用して、さまざまな検索基準に基づいてレコードを表示することもできます。
この [エンドポイント証明書(Endpoint Certificates)] ページには、必要に応じてエンドポイント証明書を取り消すためのオプションもあります。
[証明書管理概要(Certificate Management Overview)] ページには、展開内の各 PSN ノードによって発行されたエンドポイント証明書の合計数が表示されます。また、失効した証明書の合計数と失敗した証明書の合計数をノードごとに確認することもできます。このページのデータは任意の属性に基づいてフィルタリングできます。
(注) | pxGrid 証明書は、[エンドポイント証明書(EndpointCertificates)][発行された証明書(Issued Certificates)] ページに表示されません。 |
PPAN に障害が発生し、セカンダリ管理ノードを外部 PKI のルート CA または中間 CA として機能させるために昇格する場合に備え、Cisco ISE CA 証明書およびキーをセキュアにバックアップして、セカンダリ管理ノードにこれらを復元できるようにする必要があります。Cisco ISE 設定のバックアップには、CA 証明書とキーは含まれていません。CA 証明書およびキーをリポジトリにエクスポートおよびインポートするには、代わりにコマンドライン インターフェイス(CLI)を使用する必要があります。application configure ise コマンドには、CA 証明書およびキーのバックアップと復元のための、エクスポートおよびインポート オプションが含まれています。
信頼できる証明書ストアからの次の証明書が、セカンダリ管理ノードで復元されます。
次の場合、Cisco ISE CA 証明書およびキーのバックアップおよび復元が必要となります。
CA 証明書およびキーを PAN からエクスポートし、セカンダリ管理ノードでインポートする必要があります。このオプションでは、PAN がダウンした場合にセカンダリ管理ノードでエンドポイントの証明書を発行および管理し、セカンダリ管理ノードを PAN に昇格させることができます。
CA 証明書およびキーを格納するためのリポジトリを作成したことを確認します。
ステップ 1 | Cisco ISE CLI から application configure ise コマンドを入力します。 |
ステップ 2 | 7 を入力して、証明書およびキーをエクスポートします。 |
ステップ 3 | リポジトリの名前を入力します。 |
ステップ 4 | 暗号キーを入力します。
エクスポートされた証明書のリスト、件名、発行者、およびシリアル番号とともに成功メッセージが表示されます。 例: The following 4 CA key pairs were exported to repository 'sftp' at 'ise_ca_key_pairs_of_ise-vm1': Subject:CN=Cisco ISE Self-Signed CA of ise-vm1 Issuer:CN=Cisco ISE Self-Signed CA of ise-vm1 Serial#:0x621867df-568341cd-944cc77f-c9820765 Subject:CN=Cisco ISE Endpoint CA of ise-vm1 Issuer:CN=Cisco ISE Self-Signed CA of ise-vm1 Serial#:0x7027269d-d80a406d-831d5c26-f5e105fa Subject:CN=Cisco ISE Endpoint RA of ise-vm1 Issuer:CN=Cisco ISE Endpoint CA of ise-vm1 Serial#:0x1a65ec14-4f284da7-9532f0a0-8ae0e5c2 Subject:CN=Cisco ISE OCSP Responder Certificate of ise-vm1 Issuer:CN=Cisco ISE Self-Signed CA of ise-vm1 Serial#:0x6f6d4097-21f74c4d-8832ba95-4c320fb1 ISE CA keys export completed successfully |
セカンダリ管理ノードを登録したら、PAN から CA 証明書およびキーをエクスポートし、セカンダリ管理ノードにインポートします。
ステップ 1 | Cisco ISE CLI から application configure ise コマンドを入力します。 |
ステップ 2 | 8 を入力して、CA 証明書およびキーをインポートします。 |
ステップ 3 | リポジトリの名前を入力します。 |
ステップ 4 | インポートするファイルの名前を入力します。 |
ステップ 5 | ファイルを復号化するための暗号キーを入力します。
処理が正常に完了したことを知らせるメッセージが表示されます。 例: The following 4 CA key pairs were imported: Subject:CN=Cisco ISE Self-Signed CA of ise-vm1 Issuer:CN=Cisco ISE Self-Signed CA of ise-vm1 Serial#:0x21ce1000-8008472c-a6bc4fd9-272c8da4 Subject:CN=Cisco ISE Endpoint CA of ise-vm1 Issuer:CN=Cisco ISE Self-Signed CA of ise-vm1 Serial#:0x05fa86d0-092542b4-8ff68ed4-f1964a56 Subject:CN=Cisco ISE Endpoint RA of ise-vm1 Issuer:CN=Cisco ISE Endpoint CA of ise-vm1 Serial#:0x77932e02-e8c84b3d-b27e2f1c-e9f246ca Subject:CN=Cisco ISE OCSP Responder Certificate of ise-vm1 Issuer:CN=Cisco ISE Self-Signed CA of ise-vm1 Serial#:0x5082017f-330e412f-8d63305d-e13fd2a5 Stopping ISE Certificate Authority Service... Starting ISE Certificate Authority Service... ISE CA keys import completed successfully |
展開をセットアップする場合、Cisco ISE は、プライマリ PAN でルート CA を生成し、ポリシー サービス ノード(PSN)で Cisco ISE CA サービスに対する下位 CA 証明書を生成します。ただし、プライマリ PAN または PSN のドメイン名またはホスト名を変更する場合は、プライマリ PAN でルート CA、PSN で下位 CA をそれぞれ再生成する必要があります。
PSN のホスト名を変更する場合は、プライマリ PAN および PSN でそれぞれルート CA と下位 CA を再生成する代わりに、ホスト名を変更する前に PSN を登録解除し、再登録できます。新しい下位証明書は PSN 上で自動的にプロビジョニングされます。
展開にセカンダリ PAN がある場合は、プライマリ PAN から Cisco ISE CA 証明書およびキーのバックアップを取得し、セカンダリ PAN で復元します。これにより、プライマリ PAN の障害が発生した場合に、セカンダリ PAN がルート CA として機能するようになり、セカンダリ PAN をプライマリ PAN に昇格させることができます。
外部 PKI の下位 CA として機能するプライマリ PAN のルート CA が必要な場合は、ISE 中間 CA 証明書署名要求を生成して、外部 CA に送信し、ルートおよび CA 署名付き証明書を入手して、ルート CA 証明書を信頼できる証明書ストアにインポートし、CA 署名付き証明書を CSR にバインドします。この場合、外部 CA はルート CA、プライマリ PAN は外部 CA の下位 CA、PSN はプライマリ PAN の下位 CA です。
ステップ 1 | 。 |
ステップ 2 | [証明書署名要求(CSR)の生成(Generate Certificate Signing Requests (CSR))] をクリックします。 |
ステップ 3 | [証明書の使用目的(Certificate(s) will be used for)] ドロップダウン リストから [ISE 中間 CA(ISE Intermediate CA)] を選択します。 |
ステップ 4 | [生成(Generate)] をクリックします。 |
ステップ 5 | CSR をエクスポートし、外部 CA に送信して、CA 署名付き証明書を取得します。 |
ステップ 6 | 信頼できる証明書ストアに外部 CA のルート CA 証明書をインポートします。 |
ステップ 7 | CSR に CA 署名付き証明書をバインドします。 |
展開にセカンダリ PAN がある場合は、プライマリ PAN から Cisco ISE CA 証明書およびキーのバックアップを取得し、セカンダリ PAN で復元します。これにより、プライマリ PAN の障害が発生した場合に、セカンダリ PAN が外部 PKI の下位 CA として機能するようになり、セカンダリ PAN をプライマリ PAN に昇格させることができます。
ネットワークに接続するエンドポイント(パーソナル デバイス)の証明書を発行し、管理するように Cisco ISE を設定できます。内部 Cisco ISE 認証局(CA)サービスを使用して、エンドポイントから証明書署名要求(CSR)に署名したり、外部 CA に CSR を転送したりすることができます。
ステップ 1 | Employee ユーザ グループへのユーザの追加 内部 ID ストアまたは Active Directory などの外部 ID ストアにユーザを追加できます。 |
ステップ 2 | TLS ベース認証の証明書認証プロファイルの作成 |
ステップ 3 | TLS ベース認証の ID ソース順序の作成 |
ステップ 4 | クライアント プロビジョニング ポリシーを作成します。 |
ステップ 5 | TLS ベース認証の Dot1X 認証ポリシー ルールの設定 |
ステップ 6 | TLS ベース認証用の許可ポリシー ルールを設定します。
パーソナル デバイスからワイヤレス SSID に接続するときに ECC ベースの証明書を使用すると、2 回目のパスワード入力が求められます。 |
次の手順では、Cisco ISE ID ストアの Employee ユーザ グループにユーザを追加する方法について説明します。外部 ID ストアを使用した場合でも、ユーザを追加できる Employee ユーザ グループがあることを確認します。
ステップ 1 | を選択します。 |
ステップ 2 | [追加(Add)] をクリックします。 |
ステップ 3 | ユーザの詳細情報を入力します。 |
ステップ 4 | [パスワード(Passwords)] セクションで、[ログインパスワード(Login Password)] と [TACACS+イネーブルパスワード(TACACS+ Enable Password)] を選択し、ネットワーク デバイスにアクセス レベルを設定します。 |
ステップ 5 | [ユーザ グループ(User Group)] ドロップダウン リストから [従業員(Employee)] を選択します。 Employee ユーザ グループに属するすべてのユーザが同じ権限セットを共有します。 |
ステップ 6 | [送信(Submit)] をクリックします。 |
ネットワークに接続するエンドポイントの認証に証明書を使用するには、Cisco ISE で証明書認証プロファイルを定義するか、またはデフォルトの Preloaded_Certificate_Profile を編集する必要があります。証明書認証プロファイルには、プリンシパル ユーザ名として使用する必要がある証明書フィールドが含まれています。たとえば、ユーザ名が [一般名(Common Name)] フィールドにある場合は、証明書認証プロファイルを [プリンシパル ユーザ名(Principal Username)] が [サブジェクト - 一般名(Subject - Common Name)] であるとして定義できます。これは ID ストアに照らして確認できます。
証明書認証プロファイルを作成したら、Cisco ISE が証明書の属性を取得し、定義した ID ソースを ID ソース順序で照合できるように、証明書認証プロファイルを ID ソース順序に追加します。
次のタスクが完了していることを確認します。
ステップ 1 | を選択します。 |
ステップ 2 | [追加(Add)] をクリックします。 |
ステップ 3 | ID ソース順序の名前を入力します。たとえば、Dot1X となります。 |
ステップ 4 | [証明書認証プロファイルの選択(Select Certificate Authentication Profile)] チェックボックスをオンにし、作成した証明書認証プロファイル、つまり CAP を選択します。 |
ステップ 5 | ユーザ情報を含む ID ソースを [認証検索リスト(Authentication Search List)] 領域の [選択済み(Selected)] リスト ボックスに移動します。 追加の ID ソースを追加すると、一致が見つかるまで Cisco ISE は、これらのデータ ストアを順に検索します。 |
ステップ 6 | [ユーザが見つからなかったとして処理し、順序内の次のストアに進む(Treat as if the user was not found and proceed to the next store in the sequence)] オプション ボタンをクリックします。 |
ステップ 7 | [送信(Submit)] をクリックします。 |
CSR への署名に外部 CA を使用する場合、外部 CA を設定する必要があります。外部 CA 設定は Cisco ISE の以前のリリースでは、SCEP RA プロファイルと呼ばれていました。Cisco ISE CA を使用する場合、CA 設定を明示的に設定する必要はありません。[管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [内部 CA 設定(Internal CA Settings)] で、内部 CA 設定を確認できます。
ユーザのデバイスが検証済みの証明書を受信すると、証明書はデバイス上の次の表の場所に置かれます。
|
||||
[アプリケーション(Application)] > [ユーティリティ(Utilities)] > [キーチェーン アクセス(Keychain Access)] |
証明書署名要求(CSR)への署名に外部認証局(CA)を使用する場合は、外部 CA の URL が必要となります。
証明書テンプレートは、(内部または外部 CA のために)使用する必要がある SCEP RA プロファイル、キー タイプ、キー サイズ、曲線タイプ、サブジェクト、サブジェクト代替名(SAN)、証明書の有効期間、拡張キーの使用状況を定義します。この例では、内部 Cisco ISE CA を使用すると想定します。外部 CA テンプレートの場合、有効期間は外部 CA によって決定され、指定することはできません。
新しい CA テンプレートを作成するか、デフォルトの証明書テンプレート EAP_Authentication_Certificate_Template を編集できます。
デフォルトでは、次の CA テンプレートが Cisco ISE で使用できます。
CA_SERVICE_Certificate_Template:ISE CA を使用する他のネットワーク サービス用。たとえば、ASA VPN ユーザに対し証明書を発行するには、ISE の設定時にこの証明書テンプレートを使用します。
EAP_Authentication_Certificate_Template:EAP 認証用。
pxGrid_Certificate_Template:証明書プロビジョニング ポータルから証明書を生成する際の pxGrid コントローラ用。
(注) | ECC キー タイプを使用する証明書テンプレートは、内部 Cisco ISE CA とのみ使用することができます。 |
CA が設定されていることを確認します。
ステップ 1 | を選択します。 | |||||||||||
ステップ 2 | 内部 CA テンプレートの名前を入力します。たとえば、Internal_CA_Template とします。 | |||||||||||
ステップ 3 | (オプション)[組織単位(Organizational Unit)]、[組織(Organization)]、[市(City)]、[州/都道府県(State)]、[国(Country)] フィールドに値を入力します。
証明書テンプレート フィールド([組織ユニット(Organizational Unit)]、[組織(Organization)]、[都市(City)]、[州(State)]、および [国(Country)])の UTF-8 文字はサポートしていません。UTF-8 文字を証明書テンプレートで使用すると、証明書プロビジョニングが失敗します。 証明書を生成する内部ユーザのユーザ名が、証明書の共通名として使用されます。Cisco ISE 内部 CA は、「+」または「*」の文字を [共通名(Common Name)] フィールドでサポートしていません。ユーザ名に「+」または「*」の特殊文字が含まれていないことを確認してください。 | |||||||||||
ステップ 4 | サブジェクト代替名(SAN)および証明書の有効期間を指定します。 | |||||||||||
ステップ 5 | キー タイプを指定します。RSA または ECC を選択します。
次の表に、ECC をサポートしているオペレーティング システムおよびバージョンと、サポートされている曲線タイプを示します。デバイスがサポートされているオペレーティング システムを実行していない場合、またはサポートされているバージョンでない場合には、代わりに RSA ベースの証明書を使用することもできます。
Windows 7 と Apple iOS は、EAP-TLS 認証用の ECC をネイティブでサポートしていません。Cisco ISE のこのリリースでは、Mac OS X デバイスでの ECC 証明書の使用はサポートされていません。 ネットワークのデバイスがサポートされていないオペレーティング システム(Windows 7、MAC OS X、Apple iOS)を実行する場合は、キー タイプとして RSA を選択することを推奨します。 | |||||||||||
ステップ 6 | (RSA キー タイプを選択する場合に適用)キー サイズを指定します。1024 以上のキー サイズを選択する必要があります。 | |||||||||||
ステップ 7 | (ECC キー タイプを選択する場合にのみ適用)曲線タイプを指定します。デフォルトは P-384 です。 | |||||||||||
ステップ 8 | ISE 内部 CA を SCEP RA プロファイルとして選択します。 | |||||||||||
ステップ 9 | 有効期間を日数単位で入力します。デフォルトは 730 日です。有効な範囲は 1 ~ 730 です。 | |||||||||||
ステップ 10 | 拡張キーの使用状況を指定します。証明書をクライアント認証に使用する場合は、[クライアント認証(Client Authentication)] チェック ボックスにマークを付けます。証明書をサーバ認証に使用する場合は、[サーバ認証(Server Authentication)] チェック ボックスにマークを付けます。 | |||||||||||
ステップ 11 | [送信(Submit)] をクリックします。 |
内部 CA 証明書テンプレートが作成され、クライアント プロビジョニング ポリシーによって使用されます。
次の作業
ネイティブ サプリカント プロファイルを作成して、ユーザがパーソナル デバイスを企業ネットワークに含めることができます。Cisco ISE では、異なるオペレーティング システムごとに異なるポリシー ルールを使用します。各クライアント プロビジョニング ポリシー ルールには、どのオペレーティング システムにどのプロビジョニング ウィザードを使用するかを指定するネイティブ サプリカント プロファイルが含まれています。
ステップ 1 | を選択します。 | ||
ステップ 2 | を選択します。 | ||
ステップ 3 | ネイティブ サプリカント プロファイルの名前を入力します。たとえば、EAP_TLS_INTERNAL となります。 | ||
ステップ 4 | [オペレーティング システム(Operating System)] ドロップダウン リストから [すべて(ALL)] を選択します。
| ||
ステップ 5 | [有線(Wired)] または [無線(Wireless)] チェックボックスをオンにします。 | ||
ステップ 6 | [許可されるプロトコル(Allowed Protocol)] ドロップダウン リストから [TLS] を選択します。 | ||
ステップ 7 | 以前に作成した CA 証明書テンプレートを選択します。 | ||
ステップ 8 | [送信(Submit)] をクリックします。 |
Cisco サイトからの Windows および Mac OS X オペレーティング システムのエージェント リソースのダウンロード
Windows および Mac OS X オペレーティング システムでは、Cisco サイトからリモート リソースをダウンロードする必要があります。
ネットワークのプロキシ設定が正しく設定されていることを確認し、適切なリモート ロケーションにアクセスして、クライアント プロビジョニング リソースを Cisco ISE にダウンロードできることを確認します。
Apple iOS、Android および MACOSX デバイスのクライアント プロビジョニング ポリシー ルールの作成
クライアント プロビジョニング リソース ポリシーは、どのユーザがリソース(エージェント、エージェント コンプライアンス モジュール、エージェント カスタマイズ パッケージ/プロファイル)のどのバージョン(または複数のバージョン)をログイン時およびユーザ セッション開始時に Cisco ISE から受信するかを決定します。
エージェント コンプライアンス モジュールをダウンロードすると、システムで使用している既存のモジュールがあれば常にそれが上書きされます。
従業員が iOS、Android、および MACOSX デバイスを持ち込むことができるようにするには、[クライアント プロビジョニング ポリシー(Client Provisioning Policy)] ページでこれらの各デバイスのポリシー ルールを作成する必要があります。
必要なネイティブ サプリカント プロファイルを設定し、[クライアント プロビジョニング ポリシー(Client Provisioning Policy)] ページから必要なエージェントをダウンロードしておく必要があります。
TLS ベース認証の Dot1X 認証ポリシー ルールを更新する必要があります。
TLS ベース認証用に作成された証明書認証プロファイルが存在することを確認します。
ステップ 1 |
を選択します。 [ポリシー セット(policy sets)] ページの要素の詳細については、 を参照してください。 |
ステップ 2 | [表示(View)] 列から矢印アイコン をクリックすると、[設定(Set)] ビュー画面が開き、認証ポリシーを表示、管理、および更新できます。 デフォルトのルールベースの認証ポリシーには、Dot1X 認証用のルールが含まれます。 |
ステップ 3 | Dot1X 認証ポリシー ルールの条件を編集するには、[条件(Conditions)] 列のセルにカーソルを合わせ、 をクリックします。[条件スタジオ(Conditions Studio)] が開きます。詳細については、ポリシー条件を参照してください。 |
ステップ 4 | Dot1X ポリシー ルールの [アクション(Actions)] 列で、歯車アイコンをクリックし、必要に応じてドロップダウンメニューから、挿入または複製オプションのいずれかを選択して新しいポリシー セットを挿入します。 [ポリシー セット(Policy Sets)] テーブルに新しい行が表示されます。 |
ステップ 5 | ルールの名前を入力します。たとえば、eap-tls と入力します。 |
ステップ 6 | [条件(Conditions)] 列から、(+)記号をクリックします。 |
ステップ 7 | [条件スタジオ(Conditions Studio)] ページで必要な条件を作成します。[エディタ(Editor)] セクションで、[クリックして属性を追加する(Click To Add an Attribute)] テキスト ボックスをクリックし、必要なディクショナリと属性(たとえば、Network Access:UserName Equals User1)を選択します。
ライブラリ条件を [クリックして属性を追加する(Click To Add An Attribute)] テキスト ボックスにドラッグ アンド ドロップできます。 |
ステップ 8 | [使用(Use)] をクリックします。 |
ステップ 9 | デフォルト ルールは、そのままにします。 |
ステップ 10 | [保存(Save)] をクリックします。 |
許可プロファイルを定義して、証明書ベースの認証の成功後にユーザに付与するアクセスを決定します。
ワイヤレス LAN コントローラ(WLC)に必要なアクセス コントロール リスト(ACL)が設定されていることを確認します。WLC での ACL の作成方法については、『TrustSec How-To Guide: Using Certificates for Differentiated Access』を参照してください。
この例では、WLC で次の ACL が作成されていると仮定します。
ステップ 1 | を選択します。 |
ステップ 2 | 新しい許可プロファイルを作成するには、[追加(Add)] をクリックします。 |
ステップ 3 | 許可プロファイルの名前を入力します。 |
ステップ 4 | [アクセス タイプ(Access Type)] ドロップダウン リストから、[ACCESS_ACCEPT] を選択します。 |
ステップ 5 | 中央 Web 認証、Google Play の中央 Web 認証、ネイティブ サプリカント プロビジョニング、および Google のネイティブ サプリカント プロビジョニングの許可プロファイルを追加するには、[追加(Add)] をクリックします。 |
ステップ 6 | [保存(Save)] をクリックします。 |
Cisco ISE は、許可ポリシー ルールを評価し、ポリシー ルールで指定された許可プロファイルに基づいてネットワーク リソースへのアクセス権をユーザに付与します。
必要な許可プロファイルを作成済みであることを確認します。
ここでは、Cisco ISE CA サービスを有効にする前に作成する必要がある許可ポリシー ルールおよびクライアント プロビジョニング ポリシー ルールの詳細情報について説明します。
ここでは、Cisco ISE 証明書サービスを使用している場合に作成する必要があるクライアント プロビジョニング ポリシー ルールについて説明します。次の表に詳細を示します。
ルール名(Rule Name) | ID グループ | オペレーティング システム | その他の条件 | 結果 |
---|---|---|---|---|
iOS | 任意(Any) | Apple iOS すべて | 条件 | EAP_TLS_INTERNAL(以前に作成したネイティブ サプリカント プロファイル)。外部 CA を使用している場合は、外部 CA 用に作成したネイティブ サプリカント プロファイルを選択します。 |
Android | 任意(Any) | Android | 条件 | EAP_TLS_INTERNAL(以前に作成したネイティブ サプリカント プロファイル)。外部 CA を使用している場合は、外部 CA 用に作成したネイティブ サプリカント プロファイルを選択します。 |
MACOSX | 任意(Any) | MACOSX | 条件 | ネイティブ サプリカントの設定で、次を指定してください。 |
ここでは、Cisco ISE で証明書ベースの認証を有効にするために作成する必要がある許可プロファイルについて説明します。ワイヤレス LAN コントローラ(WLC)の ACL(NSP-ACL および NSP-ACL-Google)がすでに作成されている必要があります。
CWA:このプロファイルは、中央 Web 認証フローを使用するデバイス用です。[Web 認証(Web Authentication)] チェックボックスをオンにして、ドロップダウン リストから [中央集中(Centralized)] を選択し、ACL テキスト ボックスに NSP-ACL を入力します。
CWA_GooglePlay:このプロファイルは、中央 Web 認証フローを使用する Android デバイス用です。このプロファイルによって、Android デバイスは Google Play ストアにアクセスし、Cisco Network Setup Assistant をダウンロードできます。[Web 認証(Web Authentication)] チェックボックスをオンにして、ドロップダウン リストから [中央集中(Centralized)] を選択し、ACL テキスト ボックスに NSP-ACL-Google を入力します。
NSP:このプロファイルは、サプリカント プロビジョニング フローを使用する非 Android デバイス用です。[Web 認証(Web Authentication)] チェックボックスをオンにして、ドロップダウン リストから [サプリカント プロビジョニング(Supplicant Provisioning)] を選択し、ACL テキスト ボックスに NSP-ACL を入力します。
NSP-Google:このプロファイルは、サプリカント プロビジョニング フローを使用する Android デバイス用です。[Web 認証(Web Authentication)] チェックボックスをオンにして、ドロップダウン リストから [サプリカント プロビジョニング(Supplicant Provisioning)] を選択し、ACL テキスト ボックスに NSP-ACL-Google を入力します。
ここでは、Cisco ISE CA サービスを有効にするときに作成する必要がある許可ポリシー ルールについて説明します。
次の表に、Cisco ISE CA サービスの許可ポリシー ルールを設定するときに選択する必要がある属性および値を示します。この例では、Cisco ISE で対応する許可プロファイルも設定しているものと想定します。
ルール名(Rule Name) | 条件(Conditions) | 権限(適用される許可プロファイル) |
---|---|---|
企業資産 | Corp_Assets AND(Wireless 802.1X AND Network Access:AuthenticationMethod EQUALS MSCHAPV2) | PermitAccess |
Android_SingleSSID | (Wireless 802.1X AND Network Access:AuthenticationMethod EQUALS MSCHAPV2 AND Session:Device-OS EQUALS Android) | NSP_Google |
Android_DualSSID | (Wireless_MAB AND Session:Device-OS EQUALS Android) | CWA_GooglePlay |
CWA | Wireless_MAB | CWA |
NSP | (Wireless 802.1X AND Network Access:AuthenticationMethod EQUALS MSCHAPV2) | NSP |
EAP-TLS | (Wireless 802.1X AND Network Access:AuthenticationMethod EQUALS x509_PKI | PermitAccess |
ISE CA は、ASA VPN 経由で接続しているクライアント マシンに証明書を発行します。この機能を使用して、ASA VPN 経由で接続しているエンド デバイスに証明書を自動的にプロビジョニングできます。
Cisco ISE は、Simple Certificate Enrollment Protocol(SCEP)を使用して登録を行い、証明書をクライアント マシンにプロビジョニングします。AnyConnect クライアントは、HTTPS 接続で ASA に SCEP 要求を送信します。ASA は、Cisco ISE と ASA の間に確立された HTTP 接続を介して Cisco ISE に要求を中継する前に、要求を評価し、ポリシーを適用します。Cisco ISE CA からの応答はクライアントに中継されます。ASA は、SCEP メッセージの内容を読み取ることはできず、Cisco ISE CA のプロキシとして機能します。Cisco ISE CA は、クライアントからの SCEP メッセージを復号化し、暗号化された形式で応答を送信します。
ISE CA SCEP URL は http://<IP Address or FQDN of ISE CA server>:9090/auth/caservice/pkiclient.exe です。ISE ノードの FQDN を使用する場合は、ASA に接続されている DNS サーバが FQDN を解決できる必要があります。
AnyConnect クライアント プロファイルの期限が切れる前に、証明書の更新を設定できます。証明書がすでに期限切れの場合、更新フローは新規登録と同様です。
サポートされているバージョンは次のとおりです。
ユーザが VPN 接続を開始します。
AnyConnect クライアントは、クライアント マシンをスキャンし、固有デバイス識別子(たとえば IMEI)などの属性を ASA に送信します。
ASA はクライアントからの証明書ベースの認証を要求します。証明書がないため、認証は失敗します。
ASA は、ユーザ名/パスワードを使用してプライマリ ユーザ認証(AAA)に進み、情報を認証サーバ(ISE)に渡します。
VPN 接続は、関連するポリシーと ACL が適用された後に確立されます。クライアントは、AAA 認証が成功し、VPN 接続が確立された後にのみ、SCEP のキー生成を開始します。
クライアントは、SCEP 登録を開始し、HTTP を介して ASA に SCEP 要求を送信します。
ASA は、要求のセッション情報を検索し、セッションが登録を許可されている場合は、ISE CA に要求をリレーします。
ASA は ISE CA からの応答をクライアントにリレー バックします。
登録が成功すると、クライアントにユーザに対する設定可能メッセージが表示され、VPN セッションが接続解除されます。
ユーザは証明書を使用して再度認証を行うことができ、正常な VPN 接続が確立されます。
ASA VPN ユーザに証明書をプロビジョニングするには、Cisco ISE および ASA で次の設定を行う必要があります。
ステップ 1 | Cisco ISE で ASA をネットワーク アクセス デバイスとして定義します。ネットワーク デバイスとして ASA を追加する方法については、Cisco ISE でのネットワーク デバイス定義の作成 を参照してください。 |
ステップ 2 | ASA でのグループ ポリシーの設定。 |
ステップ 3 | SCEP 登録用の AnyConnect 接続プロファイルの設定. |
ステップ 4 | ASDM での VPN クライアント プロファイルの設定。 |
ステップ 5 | ASA に ISE サーバ証明書をインポートします。 |
Cisco ISE にネットワーク デバイス定義がない場合に Cisco ISE でネットワーク デバイス定義を作成し、デフォルトのネットワーク デバイス定義を使用できます。
ページで、ネットワーク デバイスの定義を作成することもできます。
ステップ 1 | を選択します。 |
ステップ 2 | [追加(Add)] をクリックします。 |
ステップ 3 | [ネットワーク デバイス(Network Devices)] セクションで、必要な情報を入力します。 |
ステップ 4 | [RADIUS認証設定(RADIUS Authentication Settings)] チェックボックスをオンにして、RADIUS プロトコル認証を設定します。 |
ステップ 5 | [TACACS認証設定(TACACS Authentication Settings)] チェックボックスをオンにして、TACACS プロトコル認証を設定します。 |
ステップ 6 | (任意)[SNMP の設定(SNMP Settings)] チェックボックスをオンにして、デバイス情報を収集するプロファイリング サービスの簡易ネットワーク管理プロトコルを設定します。 |
ステップ 7 | (任意)TrustSec 対応デバイスを設定するには [高度なTrustSec設定(Advanced Trustsec Settings)] チェックボックスをオンにします。 |
ステップ 8 | [送信(Submit)] をクリックします。 |
ASA でグループ ポリシーを設定し、SCEP 登録要求を転送するための AnyConnect 用の ISE CA URL を定義します。
ステップ 1 | Cisco ASA ASDM にログインします。 |
ステップ 2 | 左側の [リモートアクセスVPN(Remote Access VPN)] ナビゲーション ペインから、[グループポリシー(Group Policies)] をクリックします。 |
ステップ 3 | [追加(Add)] をクリックして、グループ ポリシーを作成します。 |
ステップ 4 | グループ ポリシーの名前を入力します。たとえば、ISE_CA_SCEP のようになります。 |
ステップ 5 | [SCEP転送URL(SCEP forwarding URL)] フィールドで、[継承(Inherit)] チェックボックスをオフにして、ポート番号を含む ISE SCEP URL を入力します。
ISE ノードの FQDN を使用する場合は、ASA に接続されている DNS サーバが ISE ノードの FQDN を解決できる必要があります。 例:http://ise01.cisco.com:9090/auth/caservice/pkiclient.exe. |
ステップ 6 | [OK] をクリックして、グループ ポリシーを保存します。 |
ISE CA サーバ、認証方式、および ISE CA SCEP URL を指定するには、ASA で AnyConnect 接続プロファイルを設定します。
ステップ 1 | Cisco ASA ASDM にログインします。 |
ステップ 2 | 左側の [リモートアクセスVPN(Remote Access VPN)] ナビゲーション ペインから、[AnyConnect接続プロファイル(AnyConnect Connection Profiles)] をクリックします。 |
ステップ 3 | [追加(Add)] をクリックして、接続プロファイルを作成します。 |
ステップ 4 | 接続プロファイルの名前を入力します。たとえば、Cert-Group と入力します。 |
ステップ 5 | (オプション)[エイリアス(Aliases)] フィールドに接続プロファイルの説明を入力します。たとえば、SCEP-Call-ASA とします。 |
ステップ 6 | [認証(Authentication)] 領域で、次の情報を指定します。 |
ステップ 7 | [クライアントアドレスの割り当て(Client Address Assignment)] 領域で、使用する DHCP サーバおよびクライアント アドレス プールを選択します。 |
ステップ 8 | [デフォルトグループポリシー(Default Group Policy)] 領域で、[管理(Manage)] をクリックし、ISE SCEP URL とポート番号で作成したグループ ポリシーを選択します。 例:たとえば、ISE_CA_SCEP のようになります。 |
ステップ 9 | チェックボックスをオンにします。 を選択し、この接続プロファイルに対して [Simple Certificate Enrollment Protocolを有効にする(Enable Simple Certificate Enrollment Protocol)] |
ステップ 10 | [OK] をクリックします。 AnyConnect 接続プロファイルが作成されます。 |
SCEP 登録用に AnyConnect で VPN クライアント プロファイルを設定します。
ステップ 1 | Cisco ASA ASDM にログインします。 |
ステップ 2 | 左側の [リモートアクセスVPN(Remote Access VPN)] ナビゲーション ペインから、[AnyConnectクライアントプロファイル(AnyConnect Client Profile)] をクリックします。 |
ステップ 3 | 使用するクライアント プロファイルを選択して [編集(Edit)] をクリックします。 |
ステップ 4 | 左側の [プロファイル(Profile)] ナビゲーション ペインで、[証明書の登録(Certificate Enrollment)] をクリックします。 |
ステップ 5 | [証明書の登録(Certificate Enrollment)] チェックボックスをオンにします。 |
ステップ 6 | 次のフィールドに値を入力します。
|
ステップ 7 | 証明書の内容をクライアントが要求する方法を定義する値を [証明書の内容(Certificate Contents)] に入力します。 |
ステップ 8 | [OK] をクリックします。 AnyConnect クライアント プロファイルが作成されます。詳細については、『Cisco AnyConnect Secure Mobility Client Administrator Guide』を参照してください。 |
Cisco ISE 内部 CA 証明書を ASA にインポートします。
Cisco ISE 内部 CA 証明書をエクスポートします。 および [証明書サービスルートCA(Certificate Services Root CA)] 証明書の横にあるチェックボックスをオンにして、それらをエクスポートします。
に移動します。[証明書サービスノードCA(Certificate Services Node CA)]従業員のパーソナル デバイスに対して発行された証明書を取り消す必要がある場合は、[エンドポイント証明書(Endpoint Certificates)] ページから取り消すことができます。たとえば、従業員のデバイスが盗難されたり、紛失したりした場合には、Cisco ISE 管理者ポータルにログインし、そのデバイスに発行された証明書を [エンドポイント証明書(Endpoint Certificates)] ページから取り消すことができます。フレンドリ名、デバイスの一意の ID、シリアル番号に基づいて、このページのデータをフィルタリングできます。PSN(サブ CA)が侵害された場合は、[エンドポイント証明書(Endpoint Certificates)] ページの [発行元(Issued By)] フィールドでフィルタリングすることによって、その PSN によって発行されたすべての証明書を取り消すことができます。
従業員に対して発行された証明書を取り消すときに、アクティブなセッション(その証明書を使用して認証された)がある場合、セッションは即座に終了します。証明書を取り消すと、その直後に、許可されていないユーザはリソースにアクセスできなくなります。
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 チェックの実行に切り替えます。
Cisco ISE CA OCSP 応答側は、OCSP クライアントと通信するサーバです。Cisco ISE CA の OCSP クライアントには、Cisco ISE の内部 OCSP クライアントと適応型セキュリティ アプライアンス(ASA)の OCSP クライアントがあります。OCSP クライアントは、RFC 2560、5019 で定義されている OCSP 要求/応答構造を使用して、OCSP 応答側と通信する必要があります。
Cisco ISE CA は、OCSP 応答側に証明書を発行します。OCSP 応答側は、着信要求をポート 2560 でリッスンします。このポートは、OCSP トラフィックのみを許可するように設定されています。
OCSP 応答側は RFC 2560、5019 で規定された構造に従って要求を受け入れます。OCSP 要求ではナンス拡張がサポートされます。OCSP 応答側は証明書のステータスを取得し、OCSP 応答を作成して署名します。OCSP 応答は、OCSP 応答側ではキャッシュされませんが、クライアントでは最大 24 時間 OCSP 応答をキャッシュすることができます。OCSP クライアントでは、OCSP 応答の署名を検証する必要があります。
PAN 上の自己署名 CA 証明書(ISE が外部 CA の中間 CA として機能する場合は、中間 CA 証明書)によって、OCSP 応答側証明書が発行されます。PAN 上のこの CA 証明書によって、PAN および PSN の OCSP 証明書が発行されます。この自己署名 CA 証明書は、展開全体に対するルート証明書でもあります。展開全体のすべての OCSP 証明書が、これらの証明書を使用して署名された応答を ISE で検証するために、信頼できる証明書ストアに格納されます。
Cisco ISE では CA ごとに最大 2 つの OCSP サーバを設定でき、それらのサーバはプライマリおよびセカンダリ OCSP サーバと呼ばれます。各 OCSP サーバ設定には、次のパラメータが含まれます。
[ナンス(Nonce)]:要求で送信される乱数。このオプションにより、リプレイ アタックで古い通信を再利用できないことが保証されます。
[応答の検証(Validate Response)]:Cisco ISE は OCSP サーバから受信した応答の署名を検証します。
Cisco ISE がプライマリ OCSP サーバと通信しているときに、タイムアウト(5 秒)が発生した場合、Cisco ISE はセカンダリ OCSP サーバに切り替えます。
Cisco ISE はプライマリ サーバの再使用を試行する前に、設定可能な期間セカンダリ OCSP サーバを使用します。
[OCSP クライアント プロファイル(OCSP Client Profile)] ページを使用して、Cisco ISE に新しい OCSP クライアント プロファイルを追加できます。
認証局(CA)が非標準ポート(80 または 443 以外)で OCSP サービスを実行している場合は、そのポートで Cisco ISE と CA 間の通信を可能にするためにスイッチで ACL を設定する必要があります。次に例を示します。
permit tcp <source ip> <destination ip> eq <OCSP port number>
Cisco ISE では、OCSP カウンタを使用して、OCSP サーバのデータと健全性をロギングおよびモニタリングします。ロギングは 5 分ごとに実行されます。Cisco ISE はモニタリング ノードに syslog メッセージを送信し、それはローカル ストアに保持されます。ローカル ストアには過去 5 分のデータが含まれています。Cisco ISE が syslog メッセージを送信した後、カウンタは次の間隔について再計算されます。つまり、5 分後に、新しい 5 分間の間隔が再度開始されます。
次の表に、OCSP syslog メッセージとその説明を示します。