Cisco Identity Services Engine 管理者ガイド リリース 1.3
証明書の管理
証明書の管理

目次

証明書の管理

Cisco ISE での証明書の管理

証明書は、個人、サーバ、会社、またはその他のエンティティを識別し、そのエンティティを公開キーに関連付ける電子文書です。 自己署名証明書は、独自の作成者によって署名されます。 証明書は、自己署名したり、外部の認証局(CA)がデジタルで署名したりできます。 CA 署名付きデジタル証明書は、業界標準であり、よりセキュアです。

証明書は、ネットワークに対するセキュアなアクセスを提供するために使用されます。 Cisco ISE は、ノード間通信、および syslog サーバ、フィード サーバ、すべてのエンドユーザ ポータル(ゲスト、スポンサーおよびパーソナル デバイス ポータル)などの外部サーバとの通信に証明書を使用します。 証明書は、エンドポイントに対して Cisco ISE ノードを識別し、そのエンドポイントと 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)から配信された証明書も含まれます。これにより、モバイル デバイスを企業ネットワークに登録できるようになります。 信頼できる証明書ストア内の証明書はプライマリ管理ノードで管理され、Cisco ISE 展開内の他のすべてのノードに自動的に複製されます。

分散展開では、証明書をプライマリ管理ノードの証明書信頼リスト(CTL)のみにインポートする必要があります。 この証明書はセカンダリ ノードに複製されます。

一般に、Cisco ISE での証明書認証が、証明書による認証機能のわずかな違いの影響を受けないようにするために、ネットワークに展開されているすべての Cisco ISE ノードには小文字のホスト名を使用してください。

証明書の使用

Cisco ISE に証明書を追加またはインポートする場合、証明書の使用目的を指定する必要があります。

  • 管理者:ノード間の通信

  • EAP:TLS-based の EAP 認証

  • HTTPS:外部サーバとの通信

  • ポータル:すべての Cisco ISE エンドユーザ ポータルとの通信

  • xGrid:pxGrid コントローラとの通信

管理者ポータル(管理者)、外部サーバ(HTTPS)、pxGrid コントローラ(xGrid)との通信および TLS-based の EAP 認証(EAP)に、各ノードから異なる証明書を関連付けることができます。 ただし、これらの各目的に各ノードから関連付けることができる証明書は 1 つのみです。

Web ポータル要求を処理できる展開に複数のポリシー サービス ノード(PSN)がある場合、Cisco ISE には一意の ID が必要です。この ID で、ポータルの通信に使用する必要がある証明書を識別します。 ポータルでの使用に指定された証明書を追加またはインポートする場合、証明書グループ タグを定義して、それを展開内の各ノードの対応する証明書に関連付ける必要があります。 この証明書グループ タグを対応するエンドユーザ ポータル(ゲスト、スポンサー、およびパーソナル デバイス ポータル)に関連付ける必要があります。 この証明書グループ タグは一意の ID で、Cisco ISE が各ポータルと通信する際に使用する必要がある証明書を識別する場合に役立ちます。 ポータルごとに各ノードから 1 つの証明書を指定できます。

Cisco ISE の証明書の一致

Cisco ISE は、サブジェクト名の一致を次のようにして確認します。

  1. 証明書のサブジェクト代替名(SAN)の拡張が確認されます。 SAN に 1 つ以上の DNS 名が含まれている場合は、それらの DNS 名の 1 つが Cisco ISE ノードの FQDN に一致している必要があります。 ワイルドカード証明書が使用されている場合、ワイルドカード ドメイン名は Cisco ISE ノードの FQDN ドメインに一致している必要があります。

  2. SAN に DNS 名が存在しない場合、または SAN 全体が欠落している場合は、証明書の [サブジェクト(Subject)] フィールドの一般名(CN)または証明書の [サブジェクト(Subject)] フィールドのワイルドカード ドメインが、ノードの FQDN に一致している必要があります。

  3. 一致しない場合、証明書は拒否されます。


    (注)  


    Cisco ISE にインポートされる X.509 証明書は、Privacy Enhanced Mail(PEM)または Distinguished Encoding Rules(DER)形式である必要があります。 証明書チェーン(システム証明書、およびその証明書に署名する一連の信頼された証明書)が含まれたファイルはインポートすることができますが、特定の制限の対象となります。


X.509 証明書の有効性

X.509 証明書が有効なのは、指定された特定の日付までのみです。 システム証明書が期限切れになった場合、その証明書に依存する Cisco ISE 機能が影響を受けます。 Cisco ISE は、有効期限が 90 日以内になると、システム証明書の有効期間の残りについて通知します。 この通知は、いくつかの方法で表示されます。

  • 配色された有効期限の状態アイコンが、[システム証明書(System Certificates)] ページに表示されます。

  • 期限切れメッセージが Cisco ISE システム診断レポートに表示されます。

  • 有効期限のアラームは、有効期限の 90 日前、60 日前に生成され、有効期限前の最後の 30 日間には毎日生成されます。

失効した証明書が自己署名証明書の場合は、この証明書を編集して有効期限を延長できます。 CA 署名付き証明書の場合は、CA から新しい証明書を取得するのに十分な期間を確保する必要があります。

Cisco ISE での PKI の有効化

公開キー インフラストラクチャ(PKI)は、セキュアな通信を可能にし、デジタル署名を使用してユーザの ID を確認する暗号化技術です。

手順
    ステップ 1   EAP-TLS などの TLS 対応認証プロトコル、管理者ポータルの認証、Cisco ISE Web ポータルにアクセスするブラウザおよび REST クライアント、および pxGrid サービス向けのシステム証明書を各展開ノードで確立します。

    デフォルトでは、Cisco ISE ノードは EAP、管理者、ポータル、pxGrid サービスに使用される自己署名証明書があらかじめインストールされています。 一般的な企業環境では、この証明書は、信頼された CA によって署名されたサーバ証明書に置き換えられます。

    ステップ 2   信頼できる証明書ストアに、ユーザとの信頼を確立するために必要な CA 証明書と、Cisco ISE に提示されるデバイス証明書を配置します。

    証明書チェーンがルート CA 証明書と 1 つ以上の中間 CA 証明書で構成される場合は、ユーザまたはデバイスの証明書の信頼性を検証するために、信頼できる証明書ストアにそのチェーン全体をインポートする必要があります。

    ノード間の通信では、Cisco ISE 展開内の各ノードに属する管理者システム証明書を検証するために必要な信頼された証明書を、信頼できる証明書ストアに配置する必要があります。 ノード間の通信にデフォルトの自己署名証明書を使用する場合は、各 Cisco ISE ノードの [システム証明書(System Certificates)] ページからこの証明書をエクスポートし、信頼できる証明書ストアにインポートする必要があります。 自己署名証明書を CA 署名証明書で置き換える場合に必要なのは、適切なルート CA 証明書および中間 CA 証明書を信頼できる証明書ストアに配置することだけです。 この手順を完了するまでは、ノードを Cisco ISE 展開に登録できないことに注意してください。

    (注)     

    スタンドアロンの Cisco ISE またはプライマリ管理ノードからバックアップを取得した後に展開内の 1 つ以上のノードの証明書設定を変更する場合は、データを復元するために、もう一度バックアップを取得する必要があります。 そうしないで古いバックアップを使用してデータを復元すると、ノード間の通信が失敗する可能性があります。


    ワイルドカード証明書

    ワイルドカード証明書はワイルドカード表記(ドメイン名の前にアスタリスクとピリオドの形式)を使用し、組織の複数のホスト間で証明書を共有できるようにします。 たとえば、証明書サブジェクトの CN 値は aaa.ise.local などの汎用ホスト名であり、SAN フィールドには、同じ汎用ホスト名と DNS.1=aaa.ise.local および DNS.2=*.ise.local などのワイルドカード表記が含まれます。

    *.ise.local を使用してワイルドカード証明書を設定すると、その同じ証明書を使用して、次のような、DNS 名が「.ise.local」で終了する他のすべてのホストを保護することができます。

    • aaa.ise.local

    • psn.ise.local

    • mydevices.ise.local

    • sponsor.ise.local

    ワイルドカード証明書は通常の証明書と同じ方法で通信を保護し、要求は同じ検証方式を使用して処理されます。

    次の図に、Web サイトの保護に使用されるワイルドカード証明書の例を示します。

    図 1. ワイルドカード証明書の例

    Cisco ISE のワイルドカード証明書のサポート

    Cisco ISE はワイルドカード証明書をサポートしています。 以前のリリースの Cisco ISE では、HTTPS に対して有効になったすべての証明書を検証し、CN フィールドがホストの完全修飾(FQDN)が正確に一致することを確認していました。 フィールドが一致しない場合、その証明書は HTTPS 通信に使用できませんでした。

    以前のリリースの Cisco ISE では、CN 値を使用して、url-redirect A-V pair 文字列の変数を置き換えていました。 この CN 値は、すべての Centralized Web Authentication(CWA)、オンボーディング、ポスチャ リダイレクションなどに使用されました。

    Cisco ISE 1.2 は CN フィールドを使用する代わりに CN としてこのホスト名を使用します。

    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 です。

    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 の 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.com

    eth0 以外のインターフェイスにホストのエイリアスを割り当てたら、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」で終わるすべてのホストを保護するために使用できます。

    • psn.ise.company.local

    • mydevices.ise.company.local

    • sponsor.ise.company.local

    ワイルドカード証明書の互換性

    ワイルドカード証明書は、通常図 8-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 フィールドはドメイン名(DNS 名)を検査するように設計された拡張を保持します。 詳細については、RFC 6125 および 2128 を参照してください。

    システム証明書

    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] オプションを選択します。

    • pxGrid コントローラとの通信に使用されます。 この証明書の場合、[使用方法(Usage)] フィールドで [pxGrid] オプションを選択します。

    Cisco ISE 展開で、各ノードで有効なシステム証明書をインストールする必要があります。 デフォルトでは、自己署名証明書はインストール時に Cisco ISE ノードで作成されます。また、この証明書は、[EAP]、[管理(Admin)]、[ポータル(Portal)]、および [pxGrid] を使用するために設計されています(キーの長さは 1024 で、1 年間有効です)。

    シスコでは、セキュリティ向上のために自己署名証明書を CA 署名付き証明書と置き換えることを推奨します。 CA 署名付き証明書を取得するには、証明書署名要求(CSR)を作成して認証局(CA)に送信し、署名付き証明書を入手して CSR にバインドし、信頼できる証明書ストアに関連したルートおよび中間 CA 証明書をインポートする必要があります。

    システム証明書の表示

    [システム証明書(System Certificate)] ページに、Cisco ISE に追加されたすべてのシステム証明書が一覧表示されます。

    はじめる前に

    次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

    手順
    [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [システム証明書(System Certificates)] を選択します。

    [システム証明書(System Certificate)] ページが表示されます。このページには、システム証明書に関する次の情報が表示されています。

    • [フレンドリ名(Friendly Name)]:証明書の名前。

    • [グループ タグ(Group Tag)]:ポータルを使用するように指定された証明書に対してのみ適用できます。 どの証明書をポータルに使用しなければならないかを指定します。

    • [使用者(Used By)]:この証明書が使用されるサービス。

    • [発行先(Issued To)]:証明書のサブジェクトの一般名。

    • [発行元(Issued By)]:証明書発行者の一般名

    • [有効期限の開始(Valid From)]:証明書の作成日付(Not Before 証明書属性)。

    • [期限日(Expiration Date)]:証明書の有効期限(Not After 証明書属性)。 証明書の有効期限を示します。 ここには、アイコンが関連付けられた 5 つのカテゴリがあります。
      • [91 日以上で期限切れ(Expiring in more than 90 days)](緑のアイコン)

      • [90 日以内に期限切れ(Expiring in 90 days or less)](青のアイコン)

      • [60 日以内に期限切れ(Expiring in 60 days or less)](黄色のアイコン)

      • [30 日以内に期限切れ(Expiring in 30 days or less)](オレンジのアイコン)

      • [期限切れ(Expired)](赤のアイコン)


    システム証明書の追加

    Cisco ISE にシステム証明書を追加するには、その証明書をインポートするか、または自己署名証明書を生成します。

    (注)  


    Firefox および Internet Explorer 8 ブラウザを使用している場合、あるノードにある管理システム証明書を変更すると、そのノードに接続された既存のブラウザ セッションでは新しい証明書への自動的な切り替えは行われません。 新しい証明書を表示するには、ブラウザを再起動する必要があります。


    システム証明書のインポート

    管理者ポータルから、任意の Cisco ISE ノードのシステム証明書をインポートできます。

    はじめる前に
    • クライアント ブラウザを実行しているシステムに、システム証明書と秘密キー ファイルがあることを確認します。

    • Cisco ISE では、SHA-256 より大きいハッシュ アルゴリズムで署名された証明書はサポートされていません。 したがって、SHA-256 より大きいハッシュ アルゴリズムで署名されたサーバ証明書はインポートしないでください。

    • インポートするシステム証明書に、CA フラグが true に設定された基本制約拡張が含まれている場合は、キー使用拡張が存在すること、および keyEncipherment ビットと keyAgreement ビットのいずれかまたは両方が設定されていることを確認します。

    • 次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

    手順
      ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [システム証明書(System Certificates)] を選択します。
      ステップ 2   インポートする証明書の値を入力します。
      ステップ 3   [送信(Submit)] をクリックします。

      自己署名証明書の生成

      自己署名証明書を生成することにより、新しいローカル証明書を追加できます。 自己署名証明書は、内部テストと評価のニーズに対してのみ使用することを推奨します。 実稼働環境に Cisco ISE を展開することを計画している場合は、可能な限り CA 署名付き証明書を使用して、実稼働ネットワーク全体でより均一な受け入れが行われるようにします。

      (注)  


      自己署名証明書を使用しており、Cisco ISE ノードのホスト名を変更する必要がある場合は、Cisco ISE ノードの管理者ポータルにログインし、古いホスト名が使用された自己署名証明書を削除し、新しい自己署名証明書を生成します。 そうしないと、Cisco ISE は古いホスト名が使用された自己署名証明書を引き続き使用します。


      はじめる前に

      次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

      手順
        ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [システム証明書(System Certificates)] を選択します。

        セカンダリ ノードから自己署名証明書を生成するには、[管理(Administration)] > [システム(System)] > [サーバ証明書(Server Certificate)] を選択します。

        ステップ 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. application stop ise
        2. application start ise

        システム証明書の編集

        このページを使用して、システム証明書を編集し、自己署名証明書を更新できます。

        はじめる前に

        次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

        手順
          ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [システム証明書(System Certificates)] を選択します。
          ステップ 2   編集する証明書の横にあるチェックボックスをオンにして、[編集(Edit)] をクリックします。
          ステップ 3   自己署名証明書を更新するには、[自己署名証明書の更新(Renew Self Signed Certificate)] チェックボックスをオンにして、有効期限 TTL(存続可能時間)を日、週、月、または年単位で入力します。
          ステップ 4   [Save(保存)] をクリックして変更内容を保存します。

          [管理者(Admin)] チェックボックスがオンになっている場合、Cisco ISE ノードのアプリケーション サーバが再起動されます。 また、その Cisco ISE ノードが展開のプライマリ管理ノードである場合は、展開内のその他すべてのノードでもアプリケーション サーバが再起動されます。 プライマリ管理ノードの再起動が完了すると、一度に 1 つのノードが再起動されます。

          CLI からセカンダリ ノードを再起動するには、指定された順序で次のコマンドを入力します。

          1. application stop ise
          2. application start ise

          システム証明書のエクスポート

          選択したシステム証明書とその証明書に関連付けられている秘密キーをエクスポートできます。 証明書とその秘密キーをバックアップ用にエクスポートする場合は、それらを必要に応じて後で再インポートできます。

          はじめる前に

          次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

          手順
            ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [システム証明書(System Certificates)] を選択します。
            ステップ 2   エクスポートする証明書の横にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。
            ステップ 3   証明書のみをエクスポートするか、証明書と証明書に関連付けられている秘密キーをエクスポートするかを選択します。
            ヒント   

            値が公開される可能性があるため、証明書に関連付けられている秘密キーのエクスポートは推奨しません。 秘密キーをエクスポートする必要がある場合は、秘密キーの暗号化パスワードを指定します。 このパスワードは、証明書を別の Cisco ISE サーバにインポートするときに指定して、秘密キーを復号化する必要があります。

            ステップ 4   秘密キーをエクスポートする場合は、パスワードを入力します。 パスワードは、8 文字以上にする必要があります。
            ステップ 5   [エクスポート(Export)] をクリックして、クライアント ブラウザを実行しているファイル システムに証明書を保存します。

            証明書のみをエクスポートする場合、証明書は Privacy Enhanced Mail 形式で保存されます。 証明書と秘密キーの両方をエクスポートする場合、証明書は Privacy Enhanced Mail 形式の証明書と暗号化された秘密キー ファイルを含む .zip ファイルとしてエクスポートされます。


            信頼できる証明書ストア

            信頼できる証明書ストアには、信頼に使用される、Simple Certificate Enrollment Protocol(SCEP)用の X.509 証明書が含まれています。 信頼できる証明書ストア内の証明書はプライマリ管理ノードで管理され、Cisco ISE 展開内の他のすべてのノードに複製されます。 Cisco ISE はワイルドカード証明書をサポートしています。

            Cisco ISE は、次の目的で信頼できる証明書を使用します。

            • エンドポイントによる認証と、証明書ベースの管理者認証を使用して管理者ポータルにアクセスする Cisco ISE 管理者による認証に使用するクライアント証明書を確認するため。

            • 展開内の Cisco ISE ノード間のセキュアな通信を可能にするため。 信頼できる証明書ストアには、展開内の各ノードのシステム証明書との信頼を確立するために必要な CA 証明書のチェーンが含まれている必要があります。

              • 自己署名証明書をシステム証明書に使用する場合は、各ノードの自己署名証明書をプライマリ管理ノードの信頼できる証明書ストアに配置する必要があります。

              • CA 署名付き証明書をシステム証明書に使用する場合は、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 つの証明書が信頼できる証明書ストアに自動的に追加されます。
              • CA 証明書(自己署名証明書)

              • CA によって署名された RA 証明書(証明書要求のエージェントの証明書)。

              SCEP プロトコルでは、これらの 2 つの証明書が RA によって登録デバイスに提供されている必要があります。 信頼できる証明書ストアにこの 2 つの証明書を配置すると、これらのノードの RA が使用するために、証明書がすべての PSN ノードに複製されます。


              (注)  


              Cisco ISE にインポートされる X.509 証明書は、Privacy Enhanced Mail(PEM)または Distinguished Encoding Rules(DER)形式である必要があります。 証明書チェーン(システム証明書、およびその証明書に署名する一連の信頼された証明書)が含まれたファイルはインポートすることができますが、特定の制限の対象となります。


            信頼できる証明書ストアの証明書

            信頼できる証明書ストアは、次の信頼できる証明書で事前設定されています。製造業者証明書、ルート証明書、エンドポイント CA、エンドポイント RA、その他の信頼できる証明書。 ルート証明書(Cisco Root CA)は、製造業者(Cisco CA Manufacturing)証明書に署名します。 これらの証明書は、デフォルトでは無効になっています。 展開でエンドポイントとして Cisco IP Phone を使用している場合は、これら 2 つの証明書を有効にして、この電話用にシスコが署名した証明書の認証ができるようにします。

            信頼できる証明書の命名の制約

            CTL の信頼できる証明書には名前の制約の拡張が含まれている場合があります。 この拡張は、証明書チェーンの後続のすべての証明書のサブジェクト名とサブジェクト代替名フィールドの値の名前空間を定義します。 Cisco ISE は、ルート証明書で指定された制約を検査しません。

            次の名前の制約がサポートされています。

            • ディレクトリ名

              ディレクトリ名の制限は、サブジェクト/SAN のディレクトリ名のプレフィクスです。 次に例を示します。

              • 正しいサブジェクト プレフィクス:

                CA 証明書の名前の制約:Permitted: O=Cisco

                クライアント証明書のサブジェクト:O=Cisco,CN=Salomon

              • 不正なサブジェクト プレフィクス:

                CA 証明書の名前の制約:Permitted: O=Cisco

                クライアント証明書のサブジェクト:CN=Salomon,O=Cisco

            • DNS

            • E-mail

            • URI(URI の制約は、http://、https://、ftp://、または ldap:// のような URI プレフィクスで始まる必要があります)。

            次の名前の制約はサポートされていません。

            • IP address

            • Othername

            信頼できる証明書にサポートされていない制約が含まれており、検証中の証明書に該当のフィールドが含まれていない場合は、Cisco ISE がサポートされない制約を検証できないため、その証明書は拒否されます。

            信頼できる証明書内の名前の制約の定義例を次に示します。

            
            X509v3 Name Constraints: critical
                            Permitted:
                              othername:<unsupported>
                              email:.stihl.at
                              email:.stihl.be
                              email:.stihl.bg
                              email:.stihl.by
                              DNS:.dir
                              DirName: DC = dir, DC = emea
                              DirName: C = AT, ST = EMEA, L = AT, O = STIHL Group, OU = Domestic
                              DirName: C = BG, ST = EMEA, L = BG, O = STIHL Group, OU = Domestic
                              DirName: C = BE, ST = EMEA, L = BN, O = STIHL Group, OU = Domestic
                              DirName: C = CH, ST = EMEA, L = CH, O = STIHL 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=flovison
            

            信頼できるストア証明書の表示

            [信頼できる証明書(Trusted Certificates)] ページに、Cisco ISE に追加されたすべての信頼できる証明書が一覧表示されます。 信頼できる証明書を表示するには、スーパー管理者またはシステム管理者である必要があります。

            すべての証明書を表示するには、[管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [信頼できる証明書(Trusted Certificates)] を選択します。 [信頼できる証明書(Trusted Certificates)] ページが表示され、すべての信頼できる証明書が一覧表示されます。

            信頼できる証明書ストアの証明書のステータスの変更

            証明書のステータスが有効になっている必要があります。これにより、Cisco ISE が信頼の確立にこの証明書を使用できるようになります。 証明書が信頼できる証明書ストアにインポートされると、この証明書は自動的に有効になります。

            手順
              ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [信頼できる証明書(Trusted Certificates)] を選択します。
              ステップ 2   有効または無効にする証明書の隣にあるチェックボックスをオンにし、[編集(Edit)] をクリックします。
              ステップ 3   ステータスを変更します。
              ステップ 4   [保存(Save)] をクリックします。

              信頼できる証明書ストアへの証明書の追加

              [証明書ストア(Certificate Store)] ページを使用して、Cisco ISE に CA 証明書を追加することができます。

              はじめる前に
              • 次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

              • ブラウザを実行しているコンピュータのファイル システムに、証明書ストアの証明書が存在することを確認します。 証明書は PEM または DER 形式である必要があります。

              • Admin 認証または EAP 認証に証明書を使用する場合は、基本制約が証明書に定義され、CA フラグが true に設定されていることを確認します。

              手順
                ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [信頼できる証明書(Trusted Certificates)] を選択します。
                ステップ 2   [インポート(Import)] をクリックします。
                ステップ 3   必要に応じてフィールドの値を設定します。

                クライアント証明書ベースの認証が有効である場合は、展開内の各ノードのアプリケーション サーバが再起動されます(最初にプライマリ管理ノードのアプリケーション サーバが再起動され、続いて追加のノードのアプリケーション サーバが 1 つずつ再起動されます)。


                信頼できる証明書の編集

                証明書を信頼できる証明書ストアに追加したら、編集の設定を使用して、その証明書をさらに編集できます。

                はじめる前に

                次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

                手順
                  ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [信頼できる証明書(Trusted Certificates)] を選択します。
                  ステップ 2   編集する証明書の横にあるチェックボックスをオンにして、[編集(Edit)] をクリックします。
                  ステップ 3   必要に応じて編集可能なフィールドを変更します。
                  ステップ 4   [保存(Save)] をクリックして、証明書ストアに対して行った変更を保存します。

                  信頼できる証明書ストアからの証明書のエクスポート

                  はじめる前に

                  次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

                  手順
                    ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [信頼できる証明書(Trusted Certificates)] を選択します。
                    ステップ 2   エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。 一度に 1 つの証明書のみをエクスポートできます。
                    ステップ 3   クライアント ブラウザを実行しているファイル システムに Privacy Enhanced Mail ファイルを保存します。

                    信頼できる証明書ストアへのルート証明書のインポート

                    ルート CA 証明書および中間 CA 証明書をインポートするとき、信頼できる CA 証明書を使用する対象のサービスを指定できます。

                    はじめる前に

                    CSR に署名し、デジタルで署名された CA 証明書を返した認証局のルート証明書および他の中間証明書が必要です。

                    手順
                      ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [信頼できる証明書(Trusted Certificates)] を選択します。
                      ステップ 2   [インポート(Import)] をクリックします。
                      ステップ 3   [参照(Browse)] をクリックして、ルート CA 証明書を選択します。
                      ステップ 4   わかりやすい名前を入力します。 わかりやすい名前を入力しない場合、このフィールドは、common-name#issuer#nnnnn の形式でわかりやすい名前が自動的に入力されます。ここで、nnnnn は一意の番号です。 再度証明書を編集して、わかりやすい名前を変更できます。
                      ステップ 5   CA によって返されたルート証明書を選択します。
                      ステップ 6   この信頼できる証明書を使用するサービスの横にあるチェックボックスをオンにします。
                      ステップ 7   説明を入力します。
                      ステップ 8   [送信(Submit)] をクリックします。

                      次の作業

                      信頼できる証明書ストアに中間 CA 証明書をインポートします(該当する場合)。

                      証明書チェーンのインポート

                      証明書ストアから受信した証明書チェーンを含む単一のファイルから、複数の証明書をインポートすることができます。 ファイル内のすべての証明書は Privacy-Enhanced Mail(PEM)の形式であり、証明書は次の順序に並べられている必要があります。

                      • ファイル内の最後の証明書は、CA によって発行されたクライアントまたはサーバ証明書である必要があります。

                      • 前にあるすべての証明書は、ルート CA 証明書と、発行された証明書の署名のチェーンにあるすべて中間 CA 証明書である必要があります。

                      証明書チェーンのインポートは、次の 2 ステップのプロセスです。

                      1. 管理者ポータルで信頼できる証明書ストアに証明書チェーン ファイルをインポートします。 この操作により、信頼できる証明書ストアにある最後の 1 つを除き、すべての証明書がファイルからインポートされます。

                      2. CA 署名付き証明書のバインド操作を使用して証明書チェーン ファイルをインポートします。 この操作により、最後の証明書がローカル証明書としてファイルからインポートされます。

                      証明書署名要求

                      認証局(CA)が署名付き証明書を発行するためには、証明書署名要求(CSR)を作成して CA に送信する必要があります。

                      自分が作成した証明書署名要求(CSR)のリストは、[証明書署名要求(Certificate Signing Requests)] ページで使用できます。 認証局(CA)から署名を取得するには、CSR をエクスポートし、その証明書を CA に送信する必要があります。 証明書は CA によって署名され、返されます。

                      管理者ポータルから証明書を一元的に管理できます。 展開内のすべてのノードの CSR を作成およびエクスポートできます。 その後、CSR を CA に送信し、CA から CA 署名付き証明書を取得し、CSR に CA 署名付き証明書をバインドし、信頼できる証明書ストアに CA から返されたルートおよび中間 CA 証明書をインポートする必要があります。

                      証明書署名要求の作成と認証局への CSR の送信

                      証明書署名要求(CSR)を生成して、展開内のノードの CA 署名付き証明書を取得できます。 展開の選択ノードまたは展開のすべてのノード用の CSR を生成できます。

                      手順
                        ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [証明書署名要求(Certificate Signing Requests)] を選択します。
                        ステップ 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 証明書(該当する場合)がクライアント ブラウザを実行するローカル システムにダウンロードされます。


                        CSR への CA 署名付き証明書のバインド

                        CA からデジタル署名付き証明書を受け取った後、それを証明書署名要求(CSR)にバインドする必要があります。 管理者ポータルから展開内のすべてのノードに対してバインド操作を実行できます。

                        はじめる前に

                        認証局(CA)からデジタル署名付き証明書を受け取る必要があります。

                        手順
                          ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [証明書署名要求(Certificate Signing Requests)] を選択します。

                          CA 署名付き証明書に CSR をバインドするノードの隣にあるチェックボックスをオンにします。

                          ステップ 2   [バインド(Bind)] をクリックします。
                          ステップ 3   [参照(Browse)] をクリックし、CA 署名付き証明書を選択します。
                          ステップ 4   証明書のフレンドリ名を指定します。
                          ステップ 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 での選択に基づいて自動入力されます。
                          ステップ 8   [送信(Submit)] をクリックし、CA 署名付き証明書をバインドします。

                          Cisco ISE ノード間通信にこの証明書を使用するように選択した場合、Cisco ISE ノードでアプリケーション サーバが再起動されます。

                          ステップ 9   他のノードで CA 署名付き証明書に CSR をバインドするために、このプロセスを繰り返すことができます。

                          次の作業

                          信頼できる証明書ストアへのルート証明書のインポート

                          証明書署名要求のエクスポート

                          このページを使用して、証明書署名要求をエクスポートすることができます。

                          はじめる前に

                          次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。

                          手順
                            ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [証明書署名要求(Certificate Signing Requests)] を選択します。
                            ステップ 2   エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。
                            ステップ 3   [OK] をクリックして、クライアント ブラウザを実行しているファイル システムにファイルを保存します。

                            Cisco ISE ノード間通信の信頼できる証明書のインストール

                            展開をセットアップする場合、セカンダリ ノードを登録する前に、セカンダリ ノードの管理者証明書の検証に使用される適切な CA 証明書をプライマリ管理ノードの証明書信頼リスト(CTL)に配置する必要があります。 プライマリ管理ノード(PAN)の CTL に入力する手順は、シナリオに応じて異なります。

                            • セカンダリ ノードが管理者ポータルとの通信に CA 署名付き証明書を使用する場合は、PAN の CTL にセカンダリ ノードの CA 署名付き証明書をインポートする必要があります。

                            • セカンダリ ノードが管理者ポータルとの通信に自己署名証明書を使用する場合は、PAN の CTL にセカンダリ ノードの自己署名証明書をインポートできます。


                              (注)  


                              登録されたセカンダリ ノードの管理者証明書を変更する場合は、セカンダリ ノードの管理者証明書の検証に使用できる適切な CA 証明書を取得し、PAN の CTL にインポートする必要があります。


                            外部 CA から発行された証明書に基本制約が定義されており、CA フラグが true 設定されていることを確認します。 ノード間通信の CA 署名付き証明書をインストールするには、次の手順を実行します。

                            手順
                              ステップ 1   証明書署名要求の作成と認証局への CSR の送信
                              ステップ 2   CSR への CA 署名付き証明書のバインド
                              ステップ 3   信頼できる証明書ストアへのルート証明書のインポート

                              ポータルで使用する証明書の設定

                              Web ポータル要求を処理できる展開に複数のポリシー サービス ノード(PSN)がある場合、Cisco ISE には一意の ID が必要です。この ID で、ポータルの通信に使用する必要がある証明書を識別します。 ポータルでの使用に指定された証明書を追加またはインポートする場合、証明書グループ タグを定義して、それを展開内の各ノードの対応する証明書に関連付ける必要があります。 この証明書グループ タグを対応するエンドユーザ ポータル(ゲスト、スポンサー、およびパーソナル デバイス ポータル)に関連付ける必要があります。 この証明書グループ タグは一意の ID で、Cisco ISE が各ポータルと通信する際に使用する必要がある証明書を識別する場合に役立ちます。 ポータルごとに各ノードから 1 つの証明書を指定できます。

                              手順
                                ステップ 1   証明書署名要求の作成と認証局への CSR の送信

                                すでに定義済みの証明書グループ タグを選択するか、ポータル用に新しく作成する必要があります。 たとえば、mydevicesportal などです。

                                ステップ 2   CSR への CA 署名付き証明書のバインド
                                ステップ 3   信頼できる証明書ストアへのルート証明書のインポート

                                ノードの登録前のポータル証明書タグの関連付け

                                展開内のすべてのポータルに「デフォルト ポータル証明書グループ」タグを使用する場合は、新しい ISE ノードを登録する前に、関連する CA 署名付き証明書をインポートし、サービスとして「ポータル」を選択し、この証明書に「デフォルト ポータル証明書グループ」タグを関連付けます。

                                展開に新しいノードを追加すると、デフォルトの自己署名証明書が「デフォルト ポータル証明書グループ」タグに関連付けられ、このタグを使用するようにポータルが設定されます。

                                新しいノードの登録後、証明書グループ タグの関連付けは変更できません。 したがって、展開にノードを登録する前に、次を実行してください。

                                手順
                                  ステップ 1   自己署名証明書を作成し、サービスとして「ポータル」を選択し、別の証明書グループ タグ(たとえば、tempportaltag)を割り当てます。
                                  ステップ 2   新しく作成した証明書グループ タグ(tempportaltag)を使用するようにポータル設定を変更します。
                                  ステップ 3   デフォルト自己署名証明書を編集し、ポータル ロールを削除します。

                                  このオプションは、デフォルト ポータル証明書グループ タグとデフォルト自己署名証明書との関連付けを削除します。

                                  ステップ 4   次のいずれかを実行します。
                                  オプション 説明

                                  CSR の生成

                                  CSR を生成するときは、次を実行します。

                                  1. この証明書を使用する「ポータル」をサービスとして選択し、「デフォルト ポータル証明書グループ」タグを関連付けます。

                                  2. CSR を CA に送信し、署名付きの証明書を取得します。

                                  3. CSR に CA 署名付き証明書をバインドします。

                                  4. 信頼できる証明書ストアに証明書に署名した CA のルートおよび他の中間証明書をインポートします。

                                  秘密キーと CA 署名付き証明書のインポート

                                  CA 署名付き証明書をインポートするときは、次を実行します。

                                  1. この証明書を使用する「ポータル」をサービスとして選択し、「デフォルト ポータル証明書グループ」タグを関連付けます。

                                  2. 信頼できる証明書ストアに証明書に署名した CA のルートおよび他の中間証明書をインポートします。

                                  既存の CA 署名付き証明書の編集

                                  既存の CA 署名付き証明書を編集するときは、次を実行します。

                                  この証明書を使用する「ポータル」をサービスとして選択し、「デフォルト ポータル証明書グループ」タグを関連付けます。

                                  ステップ 5   展開に ISE ノードを登録します。 展開内のポータル構成は「デフォルト ポータル証明書グループ」タグに設定され、ポータルは新しいノードの「デフォルト ポータル証明書グループ」タグに関連付けられた CA 署名付き証明書を使用するように設定されます。

                                  証明書の更新

                                  デフォルトでは、Cisco ISE は証明書が期限切れになったデバイスからの要求を拒否します。 ただし、このデフォルト動作を変更し、このような要求を処理し、ユーザに証明書の更新を求めるように ISE を設定できます。

                                  ユーザが証明書を更新することを許可する場合は、要求をさらに処理する前に証明書が更新されたかどうかを判断する許可ポリシー ルールを設定することを推奨します。 証明書が期限切れになったデバイスからの要求を処理することで、潜在的なセキュリティ脅威が発生する可能性があります。 組織のセキュリティが侵害されていないことを保証するには、適切な許可プロファイルおよびルールを設定する必要があります。

                                  あるデバイスは有効期限の前後に証明書を更新できます。 ただし、Windows デバイスでは、期限切れになる前にだけ証明書を更新できます。 Apple iOS、Mac OSX、および Android デバイスでは、有効期限の前または後に証明書を更新できます。

                                  ポリシー条件で証明書更新に使用されるディクショナリ属性

                                  Cisco ISE 証明書ディクショナリには、ユーザに証明書更新を許可するポリシー条件で使用される次の属性が含まれます。

                                  • [有効期限までの日数(Days to Expiry)]:この属性は、証明書が有効な日数を指定します。 この属性を使用して、許可ポリシーで使用できる条件を作成できます。 この属性には、0 ~ 15 の値を指定できます。 0 の値は、証明書の有効期限がすでに切れていることを示します。 1 の値は、証明書の有効期限が切れるまで 1 日未満であることを示します。

                                  • [有効期限切れ(Is Expired)]:このブール属性は、証明書が有効期限切れかどうかを示します。 証明書の有効期限が近く、有効期限切れではない場合にのみ証明書更新を許可する場合は、許可ポリシー条件でこの属性を使用します。

                                  証明書更新用の許可ポリシー条件

                                  許可ポリシーで CertRenewalRequired の単純条件(デフォルトで使用可能)を使用すると、Cisco ISE が要求を処理する前に証明書(有効期限切れまたはまもなく有効期限が切れる)を更新できます。

                                  証明書を更新するための CWA リダイレクト

                                  ユーザ証明書が期限切れになる前に失効している場合、Cisco ISE は、CA がパブリッシュした CRL をチェックして認証要求を拒否します。 失効した証明書の期限が切れている場合は、CA が CRL でこの証明書をパブリッシュしない可能性があります。 このシナリオでは、失効した証明書が Cisco ISE によって更新される可能性があります。 このことを避けるために、証明書を更新する前に、要求が中央 Web 認証(CWA)にリダイレクトされ、完全認証が実行されるようにします。 CWA のユーザをリダイレクトするには、許可プロファイルを作成する必要があります。

                                  ユーザによる証明書の更新を許可する Cisco ISE の設定

                                  ユーザが証明書を更新できるように Cisco ISE を設定するには、この手順で示すタスクを実行する必要があります。

                                  はじめる前に

                                  WLC で制限されたアクセス ACL を設定して、CWA 要求をリダイレクトします。

                                  手順
                                    ステップ 1   許可されるプロトコルの設定の更新
                                    ステップ 2   CWA リダイレクションの許可ポリシー プロファイルの作成
                                    ステップ 3   証明書を更新する許可ポリシー ルールの作成

                                    許可されるプロトコルの設定の更新

                                    手順
                                      ステップ 1   [ポリシー(Policy)] > [ポリシー要素(Policy Elements)] > [結果(Results)] > [認証(Authentication)] > [許可されるプロトコル(Allowed Protocols)] > [デフォルト ネットワーク アクセス(Default Network Access)] を選択します。
                                      ステップ 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)] をクリックします。

                                      次の作業

                                      CWA リダイレクションの許可ポリシー プロファイルの作成

                                      CWA リダイレクションの許可ポリシー プロファイルの作成

                                      はじめる前に

                                      WLC で制限されたアクセス ACL が設定されていることを確認します。

                                      手順
                                        ステップ 1   [ポリシー(Policy)] > [ポリシー要素(Policy Elements)] > [結果(Results)] > [許可(Authorization)] > [許可プロファイル(Authorization Profiles)] を選択します。
                                        ステップ 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)] をクリックします。

                                        次の作業

                                        証明書を更新する許可ポリシー ルールの作成

                                        証明書を更新する許可ポリシー ルールの作成

                                        はじめる前に

                                        中央 Web 認証リダイレクションの許可プロファイルが作成されていることを確認します。

                                        手順
                                          ステップ 1   [ポリシー(Policy)] > [ポリシー セット(Policy Sets)] を選択します。
                                          ステップ 2   [上を作成(Create Above)] をクリックします。
                                          ステップ 3   新しいルールの名前を入力します。
                                          ステップ 4   次の単純条件と結果を選択します。

                                          CertRenewalRequired EQUALS True の場合は、権限用に以前に作成した許可プロファイル(CertRenewal_CWA)を選択します。

                                          ステップ 5   [保存(Save)] をクリックします。

                                          次の作業

                                          証明書が期限切れになったデバイスを持つ企業ネットワークにアクセスした場合は、[更新(Renew)] をクリックして、デバイスを再設定します。

                                          Cisco ISE CA サービス

                                          Cisco ISE 認証局(CA)は、従業員が企業ネットワークでパーソナル デバイスを使用できるように、一元的なコンソールからエンドポイントのデジタル証明書を発行し、管理します。 プライマリ管理ノード(PAN)は、ルート CA です。 ポリシー サービス ノード(PSN)は、PAN の下位 CA です(SCEP RA)。 CA サービスは次の機能を提供します。

                                          • 証明書の発行:ネットワークに接続するエンドポイントの証明書署名要求(CSR)を検証し、署名します。

                                          • キー管理:PAN および PSN の両方のノードにキーおよび証明書を生成し、セキュアに保存します。

                                          • 証明書ストレージ:ユーザやデバイスに発行された証明書を保存します。

                                          • Online Certificate Status Protocol(OCSP)サポート:OCSP 応答側に証明書の有効性を確認する手段を提供します。

                                          プライマリ管理ノードとポリシー サービス ノードでプロビジョニングされる証明書

                                          インストール後に、エンドポイントの証明書を発行し、管理するために、Cisco ISE ノードは Cisco ISE ノードの自己署名された CA および下位 CA(サブ CA)の証明書を使用してプロビジョニングされます。 PAN に登録する PSN は、PAN によって署名されたサブ CA 証明書を使用してプロビジョニングされます。 Cisco ISE 内部 CA サービスを使用し、エンドポイントがネットワークにアクセスすると、PSN ノードのサブ CA がエンドポイントに証明書を発行します。

                                          図 2. ノード登録でプロビジョニングされた証明書:PSN は、PAN からエンドポイント CA および OCSP 証明書を取得する



                                          Simple Certificate Enrollment Protocol プロファイル

                                          ユーザがネットワークで登録できるさまざまなモバイル デバイスの証明書のプロビジョニング機能を有効にするために、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

                                          エンドポイント証明書

                                          管理者ポータルには、エンドポイントに対して発行されたすべての証明書のリストが示されます([管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [エンドポイント証明書(Endpoint Certificates)])。 [エンドポイント証明書(Endpoint Certificates)] ページでは、証明書のステータスを一目で確認できます。 証明書が失効している場合は、[ステータス(Status)] 列の上にマウス カーソルを移動すると、失効の理由を確認できます。 [証明書テンプレート(Certificate Template)] 列の上にマウス カーソルを移動すると、キー サイズ、サブジェクト、サブジェクト代替名(SAN)、証明書の有効性などの詳細情報を表示できます。 エンドポイント証明書クリックして、証明書を表示できます。

                                          たとえば user7 に発行された証明書を確認する場合は、[フレンドリ名(Friendly Name)] フィールドの下に表示されるテキスト ボックスに "user7" と入力します。 このユーザに Cisco ISE によって発行されたすべての証明書が表示されます。 フィルタをキャンセルするには、テキスト ボックスから検索語を削除します。 また、[拡張フィルタ(Advanced Filter)] オプションを使用して、さまざまな検索基準に基づいてレコードを表示することもできます。

                                          この [エンドポイント証明書(Endpoint Certificates)] ページには、必要に応じてエンドポイント証明書を取り消すためのオプションもあります。

                                          [証明書管理概要(Certificate Management Overview)] ページには、展開内の各 PSN ノードによって発行されたエンドポイント証明書の合計数が表示されます。 また、失効した証明書の合計数と失敗した証明書の合計数をノードごとに確認することもできます。 このページのデータは任意の属性に基づいてフィルタリングできます。

                                          Cisco ISE CA 証明書およびキーのバックアップと復元

                                          プライマリ管理ノード(PAN)に障害が発生し、セカンダリ管理ノードを外部 PKI のルート CA または中間 CA として機能させるためにセカンダリ管理ノードを昇格する場合に備え、Cisco ISE CA 証明書およびキーをセキュアにバックアップして、セカンダリ ノードにこれらを復元できるようにする必要があります。 Cisco ISE 設定のバックアップには CA 証明書およびキーは含まれていません。 CA 証明書およびキーをリポジトリにエクスポートおよびインポートするには、代わりにコマンドライン インターフェイス(CLI)を使用する必要があります。 application configure ise コマンドには、CA 証明書およびキーのバックアップと復元のための、エクスポートおよびインポート オプションが含まれています。

                                          信頼できる証明書ストアからの次の証明書が、セカンダリ管理ノードで復元されます。

                                          • Cisco ISE ルート CA 証明書

                                          • Cisco ISE サブ CA 証明書

                                          • Cisco ISE エンドポイント RA 証明書

                                          • Cisco ISE OCSP 応答側証明書

                                          次の場合、Cisco ISE CA 証明書およびキーのバックアップおよび復元が必要となります。

                                          • 展開内にセカンダリ管理ノードが存在する

                                          • Cisco ISE CA ルート チェーン全体を置き換える

                                          • 外部 PKI の下位 CA として機能するように Cisco ISE ルート CA を設定する

                                          • リリース 1.2 から 1.3 へアップグレードする

                                          • 設定のバックアップからデータを復元する この場合、最初に Cisco ISE CA ルート チェーンを再生成し、次に 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

                                            Cisco ISE CA 証明書およびキーのインポート

                                            セカンダリ管理ノードを登録したら、プライマリ管理ノードから 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
                                              
                                              

                                              PAN および PSN でのルート CA および下位 CA の生成

                                              展開をセットアップする場合、Cisco ISE はプライマリ管理ノード(PAN)で Cisco ISE CA サービスに対するルート CA を生成し、ポリシー サービス ノード(PSN)で下位 CA 証明書を生成します。 ただし、PAN または PSN のドメイン名またはホスト名を変更する場合は、PAN でルート CA、PSN で下位 CA をそれぞれ再生成する必要があります。

                                              PSN のホスト名を変更する場合は、PAN および PSN でそれぞれルート CA と下位 CA を再生成する代わりに、ホスト名を変更する前に PSN を登録解除し、再登録できます。 新しい下位証明書は PSN 上で自動的にプロビジョニングされます。

                                              手順
                                                ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [証明書署名要求(Certificate Signing Requests)] を選択します。
                                                ステップ 2   [証明書署名要求(CSR)の生成(Generate Certificate Signing Requests (CSR))] をクリックします。
                                                ステップ 3   [証明書の使用先(Certificate(s) will be used for)] ドロップダウン リストから ISE ルート CA を選択します。
                                                ステップ 4   [ISE ルート CA 証明書チェーンの置き換え(Replace ISE Root CA Certificate chain)] をクリックします。

                                                ルート CA と下位 CA 証明書が、展開内のすべてのノードに対して生成されます。


                                                次の作業

                                                展開にセカンダリ管理ノードがある場合は、PAN から Cisco ISE CA 証明書およびキーのバックアップを取得し、セカンダリ管理ノードで復元します。 これにより、PAN の障害時にセカンダリ管理ノードがルート CA として機能するようになり、セカンダリ管理ノードを PAN に昇格させることができます。

                                                外部 PKI の下位 CA としての Cisco ISE ルート CA の設定

                                                外部 PKI の下位 CA として機能する PAN のルート CA が必要な場合は、ISE 中間 CA 証明書署名要求を生成して、外部 CA に送信し、CA 署名付き証明書を入手して、CSR にバインドします。 この場合、外部 CA は、ルート CA で、PAN は外部 CA の下位 CA で、PSN は PAN の下位 CA です。

                                                手順
                                                  ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [証明書署名要求(Certificate Signing Requests)] を選択します。
                                                  ステップ 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   CSR に CA 署名付き証明書をバインドします。
                                                  ステップ 7   信頼できる証明書ストアに外部 CA のルート CA 証明書をインポートします。

                                                  次の作業

                                                  展開にセカンダリ管理ノードがある場合は、PAN から Cisco ISE CA 証明書およびキーのバックアップを取得し、セカンダリ管理ノードで復元します。 これにより、PAN の障害が発生した場合に、セカンダリ管理ノードが外部 PKI の下位 CA として機能するようになり、セカンダリ管理ノードを PAN に昇格させることができます。

                                                  証明書を使用してパーソナル デバイスを許可するための Cisco ISE の設定

                                                  ネットワークに接続するエンドポイント(パーソナル デバイス)の証明書を発行し、管理するように Cisco ISE を設定できます。 内部 Cisco ISE 認証局(CA)サービスを使用して、エンドポイントから証明書署名要求(CSR)に署名したり、外部 CA に CSR を転送したりすることができます。

                                                  はじめる前に
                                                  • PAN から Cisco ISE CA 証明書およびキーのバックアップを取得し、ディザスタ リカバリのため、安全な場所に保管してください。

                                                  • 展開にセカンダリ管理ノードがある場合は、PAN から Cisco ISE CA 証明書およびキーをバックアップし、セカンダリ管理ノードで復元します。

                                                  手順
                                                    ステップ 1   従業員ユーザ グループへのユーザの追加
                                                    内部 ID ストアまたは Active Directory などの外部 ID ストアにユーザを追加できます。
                                                    ステップ 2   TLS-based の認証の証明書認証プロファイルの作成
                                                    ステップ 3   TLS-based の認証の ID ソース順序の作成
                                                    ステップ 4   クライアント プロビジョニング ポリシーを作成します。
                                                    1. 認証局の設定
                                                    2. CA テンプレートの作成
                                                    3. クライアント プロビジョニング ポリシーで使用されるネイティブ サプリカント プロファイルの作成
                                                    4. Cisco サイトからの Windows および Mac OS X オペレーティング システムのエージェント リソースのダウンロード
                                                    5. Apple iOS、Android および MACOSX デバイスのクライアント プロビジョニング ポリシー ルールの作成
                                                    ステップ 5   TLS-based の認証の Dot1X 認証ポリシー ルールの設定
                                                    ステップ 6   TLS-based の認証用の許可ポリシー ルールを設定します。
                                                    1. 中央 Web 認証とサプリカント プロビジョニング フローの許可プロファイルの作成
                                                    2. 許可ポリシー ルールの作成

                                                    従業員ユーザ グループへのユーザの追加

                                                    次の手順では、Cisco ISE ID ストアの従業員ユーザ グループにユーザを追加する方法について説明します。 外部 ID ストアを使用した場合でも、ユーザを追加できる従業員ユーザ グループがあることを確認します。

                                                    手順
                                                      ステップ 1   [管理(Administration)] > [ID の管理(Identity Management)] > [ID(Identities)] > [ユーザ(Users)] を選択します。
                                                      ステップ 2   [追加(Add)] をクリックします。
                                                      ステップ 3   ユーザの詳細情報を入力します。
                                                      ステップ 4   [ユーザ グループ(User Group)] ドロップダウン リストから [従業員(Employee)] を選択します。 従業員ユーザ グループに属するすべてのユーザが同じ権限セットを共有します。
                                                      ステップ 5   [送信(Submit)] をクリックします。

                                                      次の作業

                                                      TLS-based の認証の証明書認証プロファイルの作成

                                                      TLS-based の認証の証明書認証プロファイルの作成

                                                      ネットワークに接続するエンドポイントの認証に証明書を使用するには、Cisco ISE で証明書認証プロファイルを定義するか、またはデフォルトの Preloaded_Certificate_Profile を編集する必要があります。 証明書認証プロファイルには、プリンシパル ユーザ名として使用する必要がある証明書フィールドが含まれています。 たとえば、ユーザ名が [一般名(Common Name)] フィールドにある場合は、証明書認証プロファイルを [プリンシパル ユーザ名(Principal Username)] が [サブジェクト - 一般名(Subject - Common Name)] であるとして定義できます。これは ID ストアに照らして確認できます。

                                                      手順
                                                        ステップ 1   [管理(Administration)] > [ID の管理(Identity Management)] > [外部 ID ソース(External Identity Sources)] > [証明書認証プロファイル(Certificate Authentication Profile)] を選択します。
                                                        ステップ 2   証明書認証プロファイルの名前を入力します。 たとえば、CAP となります。
                                                        ステップ 3   [サブジェクト - 一般名(Subject - Common Name)] に [プリンシパル ユーザ名 X509 属性(Principal Username X509 Attribute)] を選択します。
                                                        ステップ 4   [保存(Save)] をクリックします。

                                                        次の作業

                                                        TLS-based の認証の ID ソース順序の作成

                                                        TLS-based の認証の ID ソース順序の作成

                                                        証明書認証プロファイルを作成したら、Cisco ISE が証明書の属性を取得し、定義した ID ソースを ID ソース順序で照合できるように、証明書認証プロファイルを ID ソース順序に追加します。

                                                        はじめる前に

                                                        次のタスクが完了していることを確認します。

                                                        • 従業員ユーザ グループへのユーザの追加。

                                                        • 証明書ベースの認証の証明書認証プロファイルの作成。

                                                        手順
                                                          ステップ 1   [管理(Administration)] > [ID の管理(Identity Management)] > [ID ソース順序(Identity Source Sequences)] を選択します。
                                                          ステップ 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 設定を確認できます。

                                                          ユーザのデバイスが検証済みの証明書を受信すると、証明書はデバイス上の次の表の場所に置かれます。

                                                          表 1 デバイス証明書の場所

                                                          デバイス

                                                          証明書の格納場所

                                                          アクセス方式

                                                          iPhone/iPad

                                                          標準の証明書ストア

                                                          [設定(Settings)] > [一般(General)] > [プロファイル(Profile)]

                                                          Android

                                                          暗号化された証明書ストア

                                                          エンドユーザに不可視です。

                                                          (注)     

                                                          証明書は、[設定(Settings)] > [ロケーションおよびセキュリティ(Location & Security)] > [ストレージのクリア(Clear Storage)] を使用して削除できます。

                                                          Windows

                                                          標準の証明書ストア

                                                          /cmd プロンプトから mmc.exe を起動するか、または証明書スナップインで表示します。

                                                          Mac

                                                          標準の証明書ストア

                                                          [アプリケーション(Application)] > [ユーティリティ(Utilities)] > [キーチェーン アクセス(Keychain Access)]

                                                          はじめる前に

                                                          証明書署名要求(CSR)への署名に外部認証局(CA)を使用する場合は、外部 CA の URL が必要となります。

                                                          手順
                                                            ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [外部 CA 設定(External CA Settings)] を選択します。
                                                            ステップ 2   [追加(Add)] をクリックします。
                                                            ステップ 3   外部 CA 設定の名前を入力します。 たとえば、EXTERNAL_SCEP などです。
                                                            ステップ 4   [URL] テキスト ボックスに、外部 CA サーバの URL を入力します。 外部 CA が到達可能かどうかを確認するには、[テスト接続(Test Connection)] をクリックします。 追加 CA サーバの URL を入力するには、[+] ボタンをクリックします。
                                                            ステップ 5   [送信(Submit)] をクリックします。

                                                            次の作業

                                                            CA テンプレートの作成

                                                            CA テンプレートの作成

                                                            証明書テンプレートでは、使用する必要がある SCEP RA プロファイル(内部または外部 CA の場合)、キー サイズ、サブジェクト、サブジェクト代替名(SAN)、および証明書の有効期間が定義されます。 この例では、内部 Cisco ISE CA を使用すると想定します。 外部 CA テンプレートの場合、有効期間は外部 CA によって決定され、指定することはできません。 新しい CA テンプレートを作成するか、デフォルトの証明書テンプレート EAP_Authentication_Certificate_Template を編集できます。

                                                            はじめる前に

                                                            CA が設定されていることを確認します。

                                                            手順
                                                              ステップ 1   [管理(Administration)] > [システム(System)] > [CA サービス(CA Service)] > [内部 CA 証明書テンプレート(Internal CA Certificate Template)] を選択します。
                                                              ステップ 2   内部 CA テンプレートの名前を入力します。 たとえば、Internal_CA_Template とします。
                                                              ステップ 3   キー サイズを指定します。 1024 以上のキー サイズを選択する必要があります。
                                                              ステップ 4   サブジェクト代替名(SAN)および証明書の有効期間を指定します。
                                                              ステップ 5   [送信(Submit)] をクリックします。

                                                              内部 CA 証明書テンプレートが作成され、クライアント プロビジョニング ポリシーによって使用されます。

                                                              次の作業

                                                              クライアント プロビジョニング ポリシーで使用されるネイティブ サプリカント プロファイルの作成

                                                              クライアント プロビジョニング ポリシーで使用されるネイティブ サプリカント プロファイルの作成

                                                              ネイティブ サプリカント プロファイルを作成して、ユーザがパーソナル デバイスを企業ネットワークに含めることができます。 Cisco ISE では、異なるオペレーティング システムごとに異なるポリシー ルールを使用します。 各クライアント プロビジョニング ポリシー ルールには、どのオペレーティング システムにどのプロビジョニング ウィザードを使用するかを指定するネイティブ サプリカント プロファイルが含まれています。

                                                              はじめる前に
                                                              • Cisco ISE で CA 証明書テンプレートを設定します。

                                                              • TCP ポート 8909 および UDP ポート 8909 を開き、Cisco NAC Agent、Cisco NAC Web Agent、およびサプリカント プロビジョニング ウィザードのインストールを有効にしてください。 ポートの使用法の詳細については、『Cisco Identity Services Engine Hardware Installation Guide』の付録「Cisco ISE Appliance Ports Reference」を参照してください。

                                                              手順
                                                                ステップ 1   [ポリシー(Policy)] > [ポリシー要素(Policy Elements)] > [結果(Results)] > [クライアント プロビジョニング(Client Provisioning)] > [リソース(Resources)] を選択します。
                                                                ステップ 2   [追加(Add)] > [ネイティブ サプリカント プロファイル(Native Supplicant Profile)] を選択します。
                                                                ステップ 3   ネイティブ サプリカント プロファイルの名前を入力します。 たとえば、EAP_TLS_INTERNAL となります。
                                                                ステップ 4   [オペレーティング システム(Operating System)] ドロップダウン リストから [すべて(ALL)] を選択します。
                                                                ステップ 5   [有線(Wired)] または [無線(Wireless)] チェックボックスをオンにします。 [無線(Wireless)] 接続タイプを選択した場合は、次のことを確認します。
                                                                1. 接続先の無線 SSID を指定します。
                                                                2. 無線セキュリティ タイプを指定します。
                                                                ステップ 6   [許可されるプロトコル(Allowed Protocol)] ドロップダウン リストから [TLS] を選択します。
                                                                ステップ 7   以前に作成した CA 証明書テンプレートを選択します。
                                                                ステップ 8   [送信(Submit)] をクリックします。

                                                                次の作業

                                                                Cisco サイトからの Windows および Mac OS X オペレーティング システムのエージェント リソースのダウンロード

                                                                Cisco サイトからの Windows および Mac OS X オペレーティング システムのエージェント リソースのダウンロード

                                                                Windows および Mac OS X オペレーティング システムでは、Cisco サイトからリモート リソースをダウンロードする必要があります。

                                                                はじめる前に

                                                                ネットワークのプロキシ設定が正しく設定されていることを確認し、適切なリモート ロケーションにアクセスして、クライアント プロビジョニング リソースを Cisco ISE にダウンロードできることを確認します。

                                                                手順
                                                                  ステップ 1   [ポリシー(Policy)] > [ポリシー要素(Policy Elements)] > [リソース(Resources)] > [クライアント プロビジョニング(Client Provisioning)] > [リソース(Resources)] を選択します。
                                                                  ステップ 2   [追加(Add)] > [Cisco サイトのエージェント リソース(Agent resources from Cisco site)] を選択します。
                                                                  ステップ 3   [Windows] および [MAC OS X] パッケージの隣にあるチェックボックスをオンにします。 必ず最新バージョンを含めます。
                                                                  ステップ 4   [保存(Save)] をクリックします。

                                                                  次の作業

                                                                  Apple iOS、Android および MACOSX デバイスのクライアント プロビジョニング ポリシー ルールの作成

                                                                  Apple iOS、Android および MACOSX デバイスのクライアント プロビジョニング ポリシー ルールの作成

                                                                  クライアント プロビジョニング リソース ポリシーは、どのユーザがリソース(エージェント、エージェント コンプライアンス モジュール、エージェント カスタマイズ パッケージ/プロファイル)のどのバージョン(または複数のバージョン)をログイン時およびユーザ セッション開始時に Cisco ISE から受信するかを決定します。

                                                                  エージェント コンプライアンス モジュールをダウンロードすると、システムで使用している既存のモジュールがあれば常にそれが上書きされます。

                                                                  従業員が iOS、Android、および MACOSX デバイスを持ち込むことができるようにするには、[クライアント プロビジョニング ポリシー(Client Provisioning Policy)] ページでこれらの各デバイスのポリシー ルールを作成する必要があります。

                                                                  はじめる前に

                                                                  必要なネイティブ サプリカント プロファイルを設定し、[クライアント プロビジョニング ポリシー(Client Provisioning Policy)] ページから必要なエージェントをダウンロードしておく必要があります。

                                                                  手順
                                                                    ステップ 1   [ポリシー(Policy)] > [クライアント プロビジョニング(Client Provisioning)] を選択します。
                                                                    ステップ 2   Apple iOS、Android および MACOSX デバイスのクライアント プロビジョニング ポリシー ルールを作成します。
                                                                    ステップ 3   [保存(Save)] をクリックします。

                                                                    次の作業

                                                                    TLS-based の認証の Dot1X 認証ポリシー ルールの設定

                                                                    TLS-based の認証の Dot1X 認証ポリシー ルールの設定

                                                                    TLS-based の認証の Dot1X 認証ポリシー ルールを更新する必要があります。

                                                                    はじめる前に

                                                                    TLS-based の認証用に作成された証明書認証プロファイルが存在することを確認します。

                                                                    手順
                                                                      ステップ 1   [ポリシー(Policy)] > [認証(Authentication)] を選択します。
                                                                      ステップ 2   [ルールベース(Rule-Based)] オプション ボタンをクリックします。 デフォルトのルールベースの認証ポリシーには、Dot1X 認証用のルールが含まれます。
                                                                      ステップ 3   Dot1X 認証ポリシー ルールを編集します。
                                                                      ステップ 4   Dot1X ポリシー ルールから [アクション(Actions)] > [新規行を上に挿入(Insert new row above)] を選択します。
                                                                      ステップ 5   ルールの名前を入力します。 たとえば、eap-tls と入力します。
                                                                      ステップ 6   式ビルダーを使用して、Network Access:EapAuthentication が EAP-TLS に等しい場合は、以前に作成した証明書認証プロファイルを使用するというポリシー条件を作成します。
                                                                      ステップ 7   デフォルト ルールは、そのままにします。
                                                                      ステップ 8   [保存(Save)] をクリックします。

                                                                      次の作業

                                                                      中央 Web 認証とサプリカント プロビジョニング フローの許可プロファイルの作成

                                                                      中央 Web 認証とサプリカント プロビジョニング フローの許可プロファイルの作成

                                                                      許可プロファイルを定義して、証明書ベースの認証の成功後にユーザに付与するアクセスを決定します。

                                                                      はじめる前に

                                                                      ワイヤレス LAN コントローラ(WLC)に必要なアクセス コントロール リスト(ACL)が設定されていることを確認します。 WLC での ACL の作成方法については、『TrustSec How-To Guide: Using Certificates for Differentiated Access』を参照してください。

                                                                      この例では、WLC で次の ACL が作成されていると仮定します。

                                                                      • NSP-ACL:ネイティブ サプリカント プロビジョニング用

                                                                      • BLACKHOLE:ブラックリストに登録されているデバイスへのアクセスの制限

                                                                      • NSP-ACL-Google:Android デバイスのプロビジョニング

                                                                      手順
                                                                        ステップ 1   [ポリシー(Policy)] > [ポリシー要素(Policy Elements)] > [結果(Results)] > [許可(Authorization)] > [許可プロファイル(Authorization Profiles)] を選択します。
                                                                        ステップ 2   新しい許可プロファイルを作成するには、[追加(Add)] をクリックします。
                                                                        ステップ 3   許可プロファイルの名前を入力します。
                                                                        ステップ 4   [アクセス タイプ(Access Type)] ドロップダウン リストから、[ACCESS_ACCEPT] を選択します。
                                                                        ステップ 5   中央 Web 認証、Google Play の中央 Web 認証、ネイティブ サプリカント プロビジョニング、および Google のネイティブ サプリカント プロビジョニングの許可プロファイルを追加するには、[追加(Add)] をクリックします。
                                                                        ステップ 6   [保存(Save)] をクリックします。

                                                                        次の作業

                                                                        許可ポリシー ルールの作成

                                                                        許可ポリシー ルールの作成

                                                                        ユーザ(ゲスト、スポンサー、従業員)のアクセス要求への応答に使用するポータルのリダイレクション URL を設定するには、そのポータル用の許可ポリシー ルールを定義する必要があります。

                                                                        url-redirect は、ポータル タイプに基づいて次の形式になります。

                                                                        ip:port = IP アドレスとポート番号

                                                                        PortalID = 一意のポータル名

                                                                        ホットスポット ゲスト ポータル:https://ip:port/guestportal/gateway?sessionID=SessionIdValue&portal=PortalID&action=cwa&type=drw

                                                                        モバイル デバイス管理(MDM)ポータル:https://ip:port/mdmportal/gateway?sessionID=SessionIdValue&portal=PortalID&action=mdm

                                                                        手順
                                                                          ステップ 1   [ポリシー(Policy)] > [許可(Authorization)] を選択して、[標準(Standard)] ポリシーで新しい許可ポリシー ルールを作成します。
                                                                          ステップ 2   [条件(Conditions)] には、ポータルの検証に使用するエンドポイント ID グループを選択します。 たとえば、ホットスポット ゲスト ポータルの場合は、デフォルトの [GuestEndpoints] エンドポイント ID グループを選択し、MDM、ポータルの場合は、デフォルトの [RegisteredDevices] エンドポイント ID グループを選択します。
                                                                          (注)      ホットスポット ゲスト ポータルは、Termination CoA だけを発行するため、ゲスト ポリシー セットの検証条件の 1 つとして [Network Access:UseCase EQUALS Guest Flow] を使用しないでください。
                                                                          ステップ 3   [権限(Permissions)] には、作成したポータル許可プロファイルを選択します。

                                                                          CA サービス ポリシーのリファレンス

                                                                          ここでは、Cisco ISE CA サービスを有効にする前に作成する必要がある許可ポリシー ルールおよびクライアント プロビジョニング ポリシー ルールの詳細情報について説明します。

                                                                          証明書サービスのクライアント プロビジョニング ポリシー ルール

                                                                          ここでは、Cisco ISE 証明書サービスを使用している場合に作成する必要があるクライアント プロビジョニング ポリシー ルールについて説明します。 次の表に詳細を示します。

                                                                          ルール名 ID グループ オペレーティング システム その他の条件 結果
                                                                          iOS 任意 Apple iOS すべて 条件 EAP_TLS_INTERNAL(以前に作成したネイティブ サプリカント プロファイル)。 外部 CA を使用している場合は、外部 CA 用に作成したネイティブ サプリカント プロファイルを選択します。
                                                                          Android 任意 Android 条件 EAP_TLS_INTERNAL(以前に作成したネイティブ サプリカント プロファイル)。 外部 CA を使用している場合は、外部 CA 用に作成したネイティブ サプリカント プロファイルを選択します。
                                                                          MACOSX 任意 MACOSX 条件 ネイティブ サプリカントの設定で、次を指定してください。
                                                                          1. 構成ウィザード:シスコのサイトからダウンロードした MACOSX サプリカントのウィザードを選択します。
                                                                          2. ウィザードのプロファイル:以前作成した EAP_TLS_INTERNAL ネイティブ サプリカントのプロファイルを選択します。 外部 CA を使用している場合は、外部 CA 用に作成したネイティブ サプリカント プロファイルを選択します。

                                                                          証明書サービスの許可プロファイル

                                                                          ここでは、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 を入力します。

                                                                          デフォルトの Blackhole_Wireless_Access 許可プロファイルを確認します。 高度な属性設定を次のように設定する必要があります。
                                                                          • Cisco:cisco-av-pair = url-redirect=https://ip:port/blackhole/blackhole.jsp
                                                                          • Cisco:cisco-av-pair = url-redirect-acl=BLACKHOLE

                                                                          証明書サービスの許可ポリシー ルール

                                                                          ここでは、Cisco ISE CA サービスを有効にするときに作成する必要がある許可ポリシー ルールについて説明します。

                                                                          • 企業資産:このルールは、802.1X および MSCHAPV2 プロトコルを使用して企業のワイヤレス SSID に接続する企業のデバイス用です。
                                                                          • Android_SingleSSID:このルールは、Google Play ストアにアクセスして、プロビジョニングのために Cisco Network Setup Assistant をダウンロードする Android デバイス用です。 このルールは、シングル SSID 設定に固有です。
                                                                          • Android_DualSSID:このルールは、Google Play ストアにアクセスして、プロビジョニングのために Cisco Network Setup Assistant をダウンロードする Android デバイス用です。 このルールは、デュアル SSID 設定に固有です。
                                                                          • CWA:このルールは、中央 Web 認証フローを使用するデバイス用です。
                                                                          • NSP:このルールは、EAP-TLS 認証の証明書を使用するネイティブ サプリカント プロビジョニング フローを使用するデバイス用です。
                                                                          • EAP-TLS:このルールは、サプリカント プロビジョニング フローを完了したデバイスおよび証明書でプロビジョニングされるデバイス用です。 デバイスには、ネットワークへのアクセス権限が付与されます。

                                                                          次の表に、Cisco ISE CA サービスの許可ポリシー ルールを設定するときに選択する必要がある属性および値を示します。 この例では、Cisco ISE で対応する許可プロファイルも設定しているものと想定します。

                                                                          ルール名 条件 権限(適用される許可プロファイル)
                                                                          企業資産 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

                                                                          エンドポイント証明書の失効

                                                                          従業員のパーソナル デバイスに対して発行された証明書を取り消す必要がある場合は、[エンドポイント証明書(Endpoint Certificates)] ページから取り消すことができます。 たとえば、従業員のデバイスが盗難されたり、紛失したりした場合には、Cisco ISE 管理者ポータルにログインし、そのデバイスに発行された証明書を [エンドポイント証明書(Endpoint Certificates)] ページから取り消すことができます。 フレンドリ名、デバイスの一意の ID、シリアル番号に基づいて、このページのデータをフィルタリングできます。 PSN(サブ CA)が侵害された場合は、[エンドポイント証明書(Endpoint Certificates)] ページの [発行元(Issued By)] フィールドでフィルタリングすることによって、その PSN によって発行されたすべての証明書を取り消すことができます。

                                                                          手順
                                                                            ステップ 1   [管理(Administration)] > [システム(System)] > [CA サービス(CA Service)] > [エンドポイント証明書(Endpoint Certificates)] を選択します。
                                                                            ステップ 2   取り消すエンドポイント証明書の隣にあるチェックボックスをオンにし、[失効(Revoke)] をクリックします。 フレンドリ名とデバイス タイプに基づいて証明書を検索できます。
                                                                            ステップ 3   証明書を取り消す理由を入力します。
                                                                            ステップ 4   [はい(Yes)] をクリックします。

                                                                            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 チェックの実行に切り替えます。

                                                                            Cisco ISE CA サービスの Online Certificate Status Protocol 応答側

                                                                            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 で検証するために、信頼できる証明書ストアに格納されます。

                                                                            OCSP 証明書のステータスの値

                                                                            OCSP サービスでは、所定の証明書要求に対して次の値が返されます。

                                                                            • [良好(Good)]:ステータスの問い合わせへの肯定的な応答を示します。 証明書が失効していないこと、および状態が次の時間間隔(存続可能時間)値までは良好であることを示します。

                                                                            • [失効(Revoked)]:証明書は失効しています。

                                                                            • [不明(Unknown)]:証明書のステータスは不明です。 この OCSP 応答側の CA で証明書が発行されなかった場合、OCSP サービスはこの値を返します。

                                                                            • [エラー(ERROR)]:OCSP 要求に対する応答を受信しませんでした。

                                                                            OCSP ハイ アベイラビリティ

                                                                            Cisco ISE では CA ごとに最大 2 つの OCSP サーバを設定でき、それらのサーバはプライマリおよびセカンダリ OCSP サーバと呼ばれます。 各 OCSP サーバ設定には、次のパラメータが含まれます。

                                                                            • [URL]:OCSP サーバの URL。

                                                                            • [ナンス(Nonce)]:要求で送信される乱数。 このオプションにより、リプレイ アタックで古い通信を再利用できないことが保証されます。

                                                                            • [応答の検証(Validate Response)]:Cisco ISE は OCSP サーバから受信した応答の署名を検証します。

                                                                            Cisco ISE がプライマリ OCSP サーバと通信しているときに、タイムアウト(5 秒)が発生した場合、Cisco ISE はセカンダリ OCSP サーバに切り替えます。

                                                                            Cisco ISE はプライマリ サーバの再使用を試行する前に、設定可能な期間セカンダリ OCSP サーバを使用します。

                                                                            OCSP の障害

                                                                            3 つの一般的な OCSP 障害のシナリオは次のとおりです。

                                                                            • OCSP キャッシュまたは OCSP クライアント側(Cisco ISE)の失敗による障害。

                                                                            • OCSP 応答側の失敗のシナリオ。例:

                                                                              最初のプライマリ OCSP 応答側が応答せず、セカンダリ OCSP 応答側が Cisco ISE OCSP 要求に応答します。

                                                                              Cisco ISE OCSP 要求からエラーまたは応答が受信されません。

                                                                              OCSP 応答側が、Cisco ISE OCSP 要求への応答を提供しないか、失敗の OCSP 応答のステータスを返している可能性があります。 OCSP 応答のステータス値は次のようになります。

                                                                              • tryLater

                                                                              • signRequired

                                                                              • unauthorized

                                                                              • internalError

                                                                              • malformedRequest

                                                                                OCSP 要求には、多数の日時チェック、署名の有効性チェックなどがあります。 詳細については、「RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP(RFC 2560 X.509 インターネット パブリック キー インフラストラクチャのオンライン証明書ステータスのプロトコル:OCSP)」を参照してください。これにはエラー ステータスを含む、可能性があるすべてのステータスが説明されています。

                                                                            • OCSP レポートの失敗

                                                                            OCSP クライアント プロファイルの追加

                                                                            [OCSP クライアント プロファイル(OCSP Client Profile)] ページを使用して、Cisco ISE に新しい OCSP クライアント プロファイルを追加できます。

                                                                            はじめる前に

                                                                            Cisco ISE と外部 OCSP サーバが通信できるように展開内のスイッチを設定します。

                                                                            手順
                                                                              ステップ 1   [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [証明書管理(Certificate Management)] > [OCSP クライアント プロファイル(OCSP Client Profile)] を選択します。
                                                                              ステップ 2   OCSP クライアント プロファイルを追加するための値を入力します。
                                                                              ステップ 3   [送信(Submit)] をクリックします。

                                                                              OCSP 統計情報カウンタ

                                                                              Cisco ISE では、OCSP カウンタを使用して、OCSP サーバのデータと健全性をロギングおよびモニタリングします。 ロギングは 5 分ごとに実行されます。 Cisco ISE はモニタリング ノードに syslog メッセージを送信し、それはローカル ストアに保持されます。 ローカル ストアには過去 5 分のデータが含まれています。 Cisco ISE が syslog メッセージを送信した後、カウンタは次の間隔について再計算されます。 つまり、5 分後に、新しい 5 分間の間隔が再度開始されます。

                                                                              次の表に、OCSP syslog メッセージとその説明を示します。

                                                                              表 2 OCSP Syslog メッセージ

                                                                              メッセージ

                                                                              説明

                                                                              OCSPPrimaryNotResponsiveCount

                                                                              応答のないプライマリ要求の数

                                                                              OCSPSecondaryNotResponsiveCount

                                                                              応答のないセカンダリ要求の数

                                                                              OCSPPrimaryCertsGoodCount

                                                                              プライマリ OCSP サーバを使用して返された所定の CA の「良好な」証明書の数

                                                                              OCSPSecondaryCertsGoodCount

                                                                              プライマリ OCSP サーバを使用して返された所定の CA の「良好な」ステータスの数

                                                                              OCSPPrimaryCertsRevokedCount

                                                                              プライマリ OCSP サーバを使用して返された所定の CA の「失効した」ステータスの数

                                                                              OCSPSecondaryCertsRevokedCount

                                                                              セカンダリ OCSP サーバを使用して返された所定の CA の「失効した」ステータスの数

                                                                              OCSPPrimaryCertsUnknownCount

                                                                              プライマリ OCSP サーバを使用して返された所定の CA の「不明の」ステータスの数

                                                                              OCSPSecondaryCertsUnknownCount

                                                                              セカンダリ OCSP サーバを使用して返された所定の CA の「不明の」ステータスの数

                                                                              OCSPPrimaryCertsFoundCount

                                                                              プライマリの送信元からのキャッシュ内に見つかった証明書の数

                                                                              OCSPSecondaryCertsFoundCount

                                                                              セカンダリの送信元からのキャッシュ内に見つかった証明書の数

                                                                              ClearCacheInvokedCount

                                                                              一定間隔の後にキャッシュのクリアがトリガーされた回数

                                                                              OCSPCertsCleanedUpCount

                                                                              t 間隔の後にクリーンアップされたキャッシュ エントリの数

                                                                              NumOfCertsFoundInCache

                                                                              キャッシュから実行された要求の数

                                                                              OCSPCacheCertsCount

                                                                              OCSP キャッシュ内に見つかった証明書の数