このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
CiscoIdentityServicesEngineリリース2.7管理者ガイド
ChapterTitle
証明書は、個人、サーバ、会社、またはその他のエンティティを識別し、そのエンティティを公開キーに関連付ける電子文書です。自己署名証明書は、独自の作成者によって署名されます。証明書は、自己署名したり、外部の認証局（CA）がデジタルで署名したりできます。CA署名付きデジタル証明書は、業界標準であり、よりセキュアです。
証明書は、ネットワークに対するセキュアなアクセスを提供するために使用されます。CiscoISEは、ノード間通信、およびsyslogサーバ、フィードサーバ、すべてのエンドユーザポータル（ゲスト、スポンサーおよびパーソナルデバイスポータル）などの外部サーバとの通信に証明書を使用します。証明書は、エンドポイントに対してCiscoISEノードを識別し、そのエンドポイントとCiscoISEノード間の通信を保護します。
展開内のすべてのノードの証明書を管理するには、管理者ポータルを使用できます。
CiscoIdentityServicesEngine（ISE）は、公開キーインフラストラクチャ（PKI）に依存して、エンドポイントおよび管理者の両方とのセキュアな通信、そしてマルチノード展開内の複数のCiscoISEノード間のセキュアな通信を実現しています。PKIはX.509デジタル証明書に依存して、メッセージの暗号化と復号化のための公開キーの転送、およびユーザとデバイスを表す他の証明書の信頼性の検証を行います。CiscoISEには、次の2つのX.509証明書のカテゴリを管理する、管理者ポータルが用意されています。
分散展開では、証明書をPANの証明書信頼リスト（CTL）のみにインポートする必要があります。この証明書はセカンダリノードに複製されます。
一般に、CiscoISEでの証明書認証が、証明書による認証機能のわずかな違いの影響を受けないようにするために、ネットワークに展開されているすべてのCiscoISEノードには小文字のホスト名を使用してください。
CiscoISEに証明書を追加またはインポートする場合、証明書の使用目的を指定する必要があります。
管理者ポータル（管理者）、pxGridコントローラ（xGrid）との通信およびTLSベースのEAP認証（EAP）に、各ノードから異なる証明書を関連付けることができます。ただし、これらの各目的に各ノードから関連付けることができる証明書は1つのみです。
Webポータル要求を処理できる展開に複数のポリシーサービスノード（PSN）がある場合、CiscoISEには一意のIDが必要です。このIDで、ポータルの通信に使用する必要がある証明書を識別します。ポータルでの使用に指定された証明書を追加またはインポートする場合、証明書グループタグを定義して、それを展開内の各ノードの対応する証明書に関連付ける必要があります。この証明書グループタグを対応するエンドユーザポータル（ゲスト、スポンサー、およびパーソナルデバイスポータル）に関連付ける必要があります。この証明書グループタグは一意のIDで、CiscoISEが各ポータルと通信する際に使用する必要がある証明書を識別する場合に役立ちます。ポータルごとに各ノードから1つの証明書を指定できます。
EAP-TLSクライアント証明書では、以下の暗号に対し、KeyUsage=KeyAgreementおよびExtendedKeyUsage=ClientAuthenticationが必要です。
EAP-TLSクライアント証明書では、以下の暗号に対し、KeyUsage=KeyEnciphermentおよびExtendedKeyUsage=ClientAuthenticationが必要です。
展開内でCiscoISEノードをセットアップすると、2つのノードが相互に通信します。システムは各ISEノードのFQDNを調べ、FQDNが一致することを確認します（たとえばise1.cisco.comとise2.cisco.com、またはワイルドカード証明書を使用している場合は*.cisco.com）。また、外部マシンからISEサーバに証明書が提示される場合、認証のために提示される外部証明書が、ISEサーバの証明書と照合されます。2つの証明書が一致すると、認証は成功します。
では、ノード間（2ノードの場合）、またはとpxGridの間で照合が実行されます。
CiscoISEは、サブジェクト名の一致を次のようにして確認します。
X.509証明書が有効なのは、指定された特定の日付までのみです。システム証明書が期限切れになった場合、その証明書に依存するCiscoISE機能が影響を受けます。CiscoISEは、有効期限が90日以内になると、システム証明書の有効期間の残りについて通知します。この通知は、いくつかの方法で表示されます。
失効した証明書が自己署名証明書の場合は、この証明書を編集して有効期限を延長できます。CA署名付き証明書の場合は、CAから新しい証明書を取得するのに十分な期間を確保する必要があります。
公開キーインフラストラクチャ（PKI）は、セキュアな通信を可能にし、デジタル署名を使用してユーザのIDを確認する暗号化技術です。
EAP-TLSなどのTLS対応認証プロトコル、管理者ポータルの認証、CiscoISEWebポータルにアクセスするブラウザおよびRESTクライアント、およびpxGridコントローラ向けのシステム証明書を各展開ノードで確立します。
デフォルトで、CiscoISEノードにはEAP認証、管理者用ポータル、ポータル、pxGridコントローラに使用される自己署名証明書があらかじめインストールされています。一般的な企業環境では、この証明書は、信頼されたCAによって署名されたサーバ証明書に置き換えられます。
信頼できる証明書ストアに、ユーザとの信頼を確立するために必要なCA証明書と、CiscoISEに提示されるデバイス証明書を配置します。
証明書チェーンがルートCA証明書と1つ以上の中間CA証明書で構成される場合は、ユーザまたはデバイスの証明書の信頼性を検証するために、信頼できる証明書ストアにそのチェーン全体をインポートする必要があります。
ノード間の通信では、CiscoISE展開内の各ノードに属する管理者システム証明書を検証するために必要な信頼された証明書を、信頼できる証明書ストアに配置する必要があります。ノード間の通信にデフォルトの自己署名証明書を使用する場合は、各CiscoISEノードの[システム証明書（SystemCertificates）]ページからこの証明書をエクスポートし、信頼できる証明書ストアにインポートする必要があります。自己署名証明書をCA署名証明書で置き換える場合に必要なのは、適切なルートCA証明書および中間CA証明書を信頼できる証明書ストアに配置することだけです。この手順を完了するまでは、ノードをCiscoISE展開に登録できないことに注意してください。
展開内でクライアントとPSNの間のセキュアな通信に自己署名証明書を使用する場合、BYODユーザがある場所から別の場所に移動すると、EAP-TLSユーザ認証は失敗します。一部のPSN間で提供される必要があるこのような認証要求の場合、外部で署名されたCA証明書を使用してクライアントとPSNの間の通信を保護するか、または外部のCAによって署名されたワイルドカード証明書を使用する必要があります。
パブリック署名証明書を取得する場合、またはCiscoISE展開がFIPSモードで動作する場合は、すべてのシステム証明書および信頼できる証明書がFIPS準拠であることを確認する必要があります。つまり、各証明書のキーサイズが2048バイト以上であり、SHA-1またはSHA-256暗号化を使用する必要があります。
スタンドアロンのCiscoISEまたはPANからバックアップを取得した後に、展開内の1つ以上のノードの証明書設定を変更する場合は、データを復元するために別のバックアップを取得する必要があります。そうしないで古いバックアップを使用してデータを復元すると、ノード間の通信が失敗する可能性があります。
ワイルドカード証明書はワイルドカード表記（ドメイン名の前にアスタリスクとピリオドの形式）を使用し、組織の複数のホスト間で証明書を共有できるようにします。たとえば、証明書サブジェクトのCN値はaaa.ise.localなどの汎用ホスト名であり、SANフィールドには、同じ汎用ホスト名とDNS.1=aaa.ise.localおよびDNS.2=*.ise.localなどのワイルドカード表記が含まれます。
のように*.ise.localを使用してワイルドカード証明書を設定すると、その同じ証明書を使用して、次のようなDNS名が「.ise.local」で終了する他のすべてのホストを保護することができます。：
ワイルドカード証明書は通常の証明書と同じ方法で通信を保護し、要求は同じ検証方式を使用して処理されます。
次の図に、Webサイトの保護に使用されるワイルドカード証明書の例を示します。
以前のリリースのCiscoISEでは、CN値を使用して、url-redirectA-Vpair文字列の変数を置き換えていました。このCN値は、すべてのCentralizedWebAuthentication（CWA）、オンボーディング、ポスチャリダイレクションなどに使用されました。
CiscoISEはCNとしてISEノードのホスト名を使用します。
SSL/TLSトンネリングを使用するAdmin（Webベースのサービス）およびEAPプロトコルに対して、CiscoISEでワイルドカードサーバ証明書を使用できます。ワイルドカード証明書を使用することにより、各CiscoISEノードに固有の証明書を生成する必要がなくなります。また、証明書の警告を防ぐために、SANフィールドに複数のFQDN値を入力する必要もありません。SANフィールドでアスタリスク（*）を使用すると、展開内の複数のノードで単一の証明書を共有できるようになり、証明書名の不一致による警告を防止することができます。ただし、ワイルドカード証明書は、各CiscoISEノードに固有のサーバ証明書を割り当てる場合よりも安全性が低いと見なされます。
ゲストポータルにパブリックワイルドカード証明書を割り当て、ルートCA証明書を使用してサブCAをインポートする場合、ISEサービスが再起動されるまで証明書チェーンは送信されません。
ワイルドカード証明書を使用する場合は、セキュリティを強化するためにドメイン領域を分割することを推奨します。たとえば、*.example.comの代わりに*.amer.example.comを使用して領域を分割することができます。ドメインを分割しないと、重大なセキュリティ問題が発生する可能性があります。
ワイルドカード証明書では、ドメイン名の前にアスタリスク（*）およびピリオドが使用されます。たとえば、証明書のサブジェクト名のCN値はaaa.ise.localなどの汎用ホスト名になり、SANフィールドには*.ise.localのようなワイルドカード文字が入力されます。CiscoISEは、ワイルドカード証明書（提示されるIDの一番左の文字がワイルドカード文字（*））をサポートします。たとえば、*.example.comまたは*.ind.example.comです。提示されるIDに追加の文字とワイルドカード文字が含まれた証明書はサポートされません。たとえば、abc*.example.com、a*b.example.com、または*abc.example.comです。
この要求を処理するときに、CiscoISEは文字列の一部のキーワードを実際の値で置き換えます。たとえば、SessionIdValueは、要求の実際のセッションIDに置き換えられます。eth0インターフェイスの場合、CiscoISEはURL内のIPをCiscoISEノードのFQDNで置き換えます。eth0以外のインターフェイスの場合、CiscoISEはURL内のIPアドレスを使用します。インターフェイスeth1からeth3にはホストのエイリアス（名前）を割り当てることができます。このエイリアスはCiscoISEがURLリダイレクション中にIPアドレスの代わりに置き換えることができます。
これを行うために、次のように、CiscoISECLIのISE/admin(config)#プロンプトからコンフィギュレーションモードでiphostコマンドを使用できます。
iphostIP_addresshost-aliasFQDN-string
ここで、IP_addressはネットワークインターフェイス（eth1またはeth2またはeth3）のIPアドレスで、host-aliasはネットワークインターフェイスに割り当てる名前です。FQDN-stringは、ネットワークインターフェイスの完全修飾ドメイン名です。このコマンドを使用して、ネットワークインターフェイスにhost-aliasまたはFQDN-stringあるいはその両方を割り当てることができます。
eth0以外のインターフェイスにホストのエイリアスを割り当てたら、applicationstartiseコマンドを使用してCiscoISEでアプリケーションサービスを再起動する必要があります。
このホストエイリアスのネットワークインターフェイスとの関連付けを削除するには、次のようにこのコマンドのno形式を使用します。
noiphostIP_addresshost-aliasFQDN-string
ホストのエイリアスの定義を表示するには、showrunning-configコマンドを使用します。
FQDN文字列を指定している場合は、そのFQDNでURL内のIPアドレスが置き換えられます。ホストのエイリアスのみを指定した場合は、そのホストエイリアスと設定されたIPドメイン名を結合して完全なFQDNが結合され、URL内のIPアドレスがそのFQDNで置き換えられます。ネットワークインターフェイスをホストのエイリアスにマッピングしない場合は、URL内のネットワークインターフェイスのIPアドレスが使用されます。
クライアントのプロビジョニング、ネイティブサプリカント、またはゲストフローに対してeth0以外のインターフェイスを使用する場合は、eth0以外のインターフェイスのIPアドレスまたはホストエイリアスがポリシーサービスノードの証明書のSANフィールドに適切に設定されていることを確認する必要があります。
ワイルドカード証明書はISEノードごとの固有のサーバ証明書よりも安全性が低いと見なされています。ただし、コスト、およびその他の運用関連の要因がセキュリティリスクに勝っています。
ASAなどのセキュリティデバイスも、ワイルドカード証明書をサポートしています。
ワイルドカード証明書を展開する場合には注意が必要です。たとえば、*.company.localを使用して証明書を作成したとします。該当の秘密キーを攻撃者が回復できた場合、攻撃者はcompany.localドメイン内のすべてのサーバをスプーフィングすることができます。したがって、このタイプの危険を回避するために、ドメイン領域を分割することがベストプラクティスと見なされています。
この想定される問題に対処し、利用範囲を制限するために、ワイルドカード証明書を使用して組織の特定のサブドメインを保護することもできます。ワイルドカードを指定する一般名のサブドメイン領域に、アスタリスク（*）を追加します。
たとえば、*.ise.company.localに対してワイルドカード証明書を設定すると、その証明書は次のような、DNS名が「.ise.company.local」で終わるすべてのホストを保護するために使用できます。
ワイルドカード証明書は通常、証明書サブジェクトの一般名（CN）としてリストされているワイルドカードを使用して作成されます。CiscoISEは、このタイプの作成をサポートします。ただし、すべてのエンドポイントサプリカントが証明書サブジェクトのワイルドカード文字をサポートするわけではありません。
テスト済みのすべてのMicrosoftネイティブサプリカント（WindowsMobileを含む）の一部は、証明書のサブジェクトのワイルドカード文字をサポートしていません。
CiscoAnyConnectNetworkAccessManager（NAM）など、[サブジェクト（Subject）]フィールドでのワイルドカード文字の使用をサポートできる他のサプリカントを使用することができます。
また、DigiCertのWildcardPlusなど、証明書のサブジェクト代替名に特定のサブドメインを含めることで、互換性のないデバイスを使用するように設計された、特別なワイルドカード証明書を使用することもできます。
Microsoftサプリカントの制限はワイルドカード証明書の使用にとって妨げになるように見えますが、Microsoftのネイティブサプリカントを含む、セキュアなアクセスについてテスト済みのすべてのデバイスを使用できるようにする代替の方法があります。
このためには、サブジェクトにワイルドカードを使用する代わりに、[SubjectAlterativeName(SAN)]フィールドでワイルドカード文字を使用します。SANフィールドはドメイン名（DNS名）を検査するように設計された拡張を保持します。詳細については、RFC6125および2128を参照してください。
管理者ポータルから、すべてのエンドポイント、システム、および信頼できる証明書の証明書階層または信頼書トラストチェーンを表示できます。証明書階層には、証明書、すべての中間認証局（CA）の証明書、およびルート証明書が含まれています。たとえば、管理者ポータルからシステム証明書を表示すると、デフォルトでは該当するシステム証明書の詳細が表示されます。証明書階層は、証明書の上部に表示されます。詳細を表示するには、その階層で証明書をクリックします。自己署名証明書には階層または信頼チェーンがありません。
証明書のリストページで、[ステータス（Status）]列に次のアイコンのいずれかが表示されます。
CiscoISEシステム証明書は、展開内のその他のノードおよびクライアントアプリケーションに対してCiscoISEノードを識別するサーバ証明書です。システム証明書の用途は次のとおりです。
CiscoISE展開で、各ノードで有効なシステム証明書をインストールする必要があります。デフォルトでは、インストール時にCiscoISEノードに2つの自己署名証明書と、内部CiscoISECAにより署名された1つの証明書が作成されます。
展開をセットアップし、セカンダリノードを登録すると、pxGridコントローラ用の証明書が自動的にプライマリノードのCA署名付き証明書に置き換わります。したがってすべてのpxGrid証明書が同一PKIトラスト階層の一部となります。
ワイルドカードシステム証明書をエクスポートして、（ノード間通信用に）他のノードにインポートする場合は、必ず証明書と秘密キーをエクスポートして、暗号化パスワードを指定してください。インポート時は、証明書、秘密キー、および暗号化パスワードが必要です。
シスコでは、セキュリティ向上のために自己署名証明書をCA署名付き証明書と置き換えることを推奨します。CA署名付き証明書を取得するには、以下を行う必要があります。
[システム証明書（SystemCertificate）]ページに、CiscoISEに追加されたすべてのシステム証明書が一覧表示されます。
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[システム証明書（SystemCertificates）]を選択します。
[システム証明書（SystemCertificate）]ページが表示されます。このページには、システム証明書に関する次の情報が表示されています。
証明書を選択し、[表示（View）]を選択して証明書の詳細を表示します。
管理者ポータルから、任意のCiscoISEノードのシステム証明書をインポートできます。
[インポート（Import）]をクリックします。
インポートする証明書の値を入力します。
[送信（Submit）]をクリックします。
自己署名証明書を生成することにより、新しいローカル証明書を追加できます。自己署名証明書は、内部テストと評価のニーズに対してのみ使用することを推奨します。実稼働環境にCiscoISEを展開することを計画している場合は、可能な限りCA署名付き証明書を使用して、実稼働ネットワーク全体でより均一な受け入れが行われるようにします。
自己署名証明書を使用しており、CiscoISEノードのホスト名を変更する必要がある場合は、CiscoISEノードの管理者用ポータルにログインし、古いホスト名が使用された自己署名証明書を削除し、新しい自己署名証明書を生成します。そうしないと、CiscoISEは古いホスト名が使用された自己署名証明書を引き続き使用します。
セカンダリノードから自己署名証明書を生成するには、[管理（Administration）]>[システム（System）]>[サーバ証明書（ServerCertificate）]を選択します。
[自己署名証明書の生成（GenerateSelfSignedCertificate）]をクリックし、[自己署名証明書の生成（GenerateSelfSignedCertificate）]ページに詳細を入力します。
自己署名したワイルドカード証明書（サブジェクトの任意の一般名またはサブジェクト代替名のDNS名、またはその両方にアスタリスク（*）が含まれている証明書）を生成する場合は、[ワイルドカード証明書の許可（AllowWildcardCertificates）]チェックボックスをオンにします。たとえば、SANに割り当てられているDNS名が*.amer.cisco.comの場合です。
この証明書を使用するサービスに基づいて[使用方法（Usage）]領域のチェックボックスをオンにします。
証明書を生成するには、[送信（Submit）]をクリックします。
CLIからセカンダリノードを再起動するには、指定された順序で次のコマンドを入力します。
このページを使用して、システム証明書を編集し、自己署名証明書を更新できます。ワイルドカード証明書を編集すると、変更が展開内のすべてのノードに複製されます。ワイルドカード証明書を削除した場合、そのワイルドカード証明書は展開内のすべてのノードから削除されます。
編集する証明書の横にあるチェックボックスをオンにして、[編集（Edit）]をクリックします。
自己署名証明書を更新するには、[更新期間（RenewalPeriod）]チェックボックスをオンにして、有効期限TTL（存続可能時間）を日、週、月、または年単位で入力します。
[Save（保存）]をクリックして変更内容を保存します。
[管理者（Admin）]チェックボックスがオンになっている場合、CiscoISEノードのアプリケーションサーバが再起動されます。また、そのCiscoISEノードが展開のPANである場合は、展開内のその他すべてのノードでもアプリケーションサーバが再起動されます。プライマリ管理ノード（PAN）の再起動が完了すると、システムによって一度に1つのノードが再起動されます。
Chrome65以上を使用してISEを起動すると、URLが正しくリダイレクトされたにもかかわらず、BYODポータルまたはゲストポータルがブラウザで起動に失敗することがあります。これは、すべての[サブジェクトの別名（SubjectAlternativeName）]フィールドに証明書を必要とする、Googleで導入された新しいセキュリティ機能が原因です。ISE2.4以降のリリースの場合、[サブジェクトの別名（SubjectAlternativeName）]フィールドを入力する必要があります。
Chrome65以上で起動するには、次の手順に従います。
1.[サブジェクトの別名（SubjectAlternativeName）]フィールドに入力することで、ISEGUIから新しい自己署名証明書を生成します。DNSとIPアドレスの両方を入力する必要があります。
2.ISEサービスが再起動します。
3.Chromeブラウザでポータルにリダイレクトされます。
4.ブラウザで[証明書の表示（ViewCertificate）]>[詳細（Details）]>[コピー（Copy）]の順に選択し、base-64エンコードを選択して、証明書をコピーします。
5.高信頼パスで証明書をインストールします。
6.Chromeブラウザを終了し、ポータルのリダイレクトを試みます。
WinRS4またはRS5のオペレーティングシステムでブラウザFirefox64以降のワイヤレスBYODセットアップを設定する場合は、証明書の例外を追加することができない場合があります。この現象はFirefox64以降の新規インストール時に発生することがあります。以前のバージョンからFirefox64以降にアップグレードした場合は発生しません。次の手順では、このような場合でも証明書の例外を追加することができます。
1.BYODフローのシングル/デュアルPEAPまたはTLSを設定します。
2.WindowsのすべてのオプションでCPポリシーを設定します。
3.エンドクライアントWindowsRS4/RS5でDot1.x/MABSSIDに接続します。
4.ゲスト/BYODポータルにリダイレクトするために、FF64ブラウザに1.1.1.1と入力します。
5.[例外を追加（AddException）]>[証明書を追加できない（Unabletoaddcertificate）]をクリックし、フローを続行します。
これを回避するには、[オプション（Options）]>[プライバシーと設定（Privacy&Settings）]>[証明書の表示（Viewcertificates）]>[サーバ（Servers）]>[例外を追加（AddException）]に移動して、Firefox64に証明書を手動で追加する必要があります。
今後使用しないシステム証明書を削除できます。
システム証明書ストアから複数の証明書を一度に削除できますが、管理およびEAP認証に使用できる証明書を少なくとも1つ所有する必要があります。また、管理、EAP認証、ポータル、またはpxGridコントローラに使用される証明書は削除できません。ただし、サービスがディセーブルの場合は、pxGrid証明書を削除できます。
ワイルドカード証明書を削除することを選択した場合、証明書は展開内のすべてのノードから削除されます。
削除する証明書の隣にあるチェックボックスをオンにし、[削除（Delete）]をクリックします。
警告メッセージが表示されます。
[はい（Yes）]をクリックして、証明書を削除します。
選択したシステム証明書とその証明書に関連付けられている秘密キーをエクスポートできます。証明書とその秘密キーをバックアップ用にエクスポートする場合は、それらを必要に応じて後で再インポートできます。
エクスポートする証明書の横にあるチェックボックスをオンにし、[エクスポート（Export）]をクリックします。
証明書のみをエクスポートするか、証明書と証明書に関連付けられている秘密キーをエクスポートするかを選択します。
値が公開される可能性があるため、証明書に関連付けられている秘密キーのエクスポートは推奨しません。秘密キーをエクスポートする必要がある場合（たとえば、ワイルドカードシステム証明書をエクスポートしてノード間通信用に他のノードにインポートする場合）は、その秘密キーの暗号化パスワードを指定します。このパスワードは、証明書を別のCiscoISEノードにインポートするときに指定して、秘密キーを復号化する必要があります。
秘密キーをエクスポートする場合は、パスワードを入力します。パスワードは、8文字以上にする必要があります。
[エクスポート（Export）]をクリックして、クライアントブラウザを実行しているファイルシステムに証明書を保存します。
証明書のみをエクスポートする場合、証明書はPrivacyEnhancedMail形式で保存されます。証明書と秘密キーの両方をエクスポートする場合、証明書はPrivacyEnhancedMail形式の証明書と暗号化された秘密キーファイルを含む.zipファイルとしてエクスポートされます。
信頼できる証明書ストアには、信頼に使用される、SimpleCertificateEnrollmentProtocol（SCEP）用のX.509証明書が含まれています。
信頼できる証明書ストア内の証明書はPANで管理され、CiscoISE展開内の他のすべてのノードに複製されます。CiscoISEはワイルドカード証明書をサポートしています。
CiscoISEは、次の目的で信頼できる証明書を使用します。
SCEPプロトコルでは、これらの2つの証明書がRAによって登録デバイスに提供されている必要があります。信頼できる証明書ストアにこの2つの証明書を配置すると、これらのノードのRAが使用するために、証明書がすべてのPSNノードに複製されます。
SCEPRAプロファイルが削除されると、関連付けられているCAチェーンが信頼できる証明書ストアからも削除されます。
信頼できる証明書ストアは、次の信頼できる証明書で事前設定されています。製造業者証明書、ルート証明書、その他の信頼できる証明書。ルート証明書（CiscoRootCA）は、製造業者（CiscoCAManufacturing）証明書に署名します。これらの証明書は、デフォルトでは無効になっています。展開でエンドポイントとしてCiscoIPPhoneを使用している場合は、これら2つの証明書を有効にして、この電話用にシスコが署名した証明書の認証ができるようにします。
CTLの信頼できる証明書には名前の制約の拡張が含まれている場合があります。この拡張は、証明書チェーンの後続のすべての証明書のサブジェクト名とサブジェクト代替名フィールドの値の名前空間を定義します。CiscoISEは、ルート証明書で指定された制約を検査しません。
次の名前の制約がサポートされています。
次の名前の制約はサポートされていません。
信頼できる証明書にサポートされていない制約が含まれており、検証中の証明書に該当のフィールドが含まれていない場合は、CiscoISEがサポートされない制約を検証できないため、その証明書は拒否されます。
信頼できる証明書内の名前の制約の定義例を次に示します。
X509v3NameConstraints:criticalPermitted:othername:
Subject:DC=dir,DC=emea,OU=+DE,OU=OU-Administration,OU=Users,OU=X1,CN=cwinwell信頼できるストア証明書の表示[信頼できる証明書（TrustedCertificates）]ページに、CiscoISEに追加されたすべての信頼できる証明書が一覧表示されます。信頼できる証明書を表示するには、スーパー管理者またはシステム管理者である必要があります。
すべての証明書を表示するには、[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[信頼できる証明書（TrustedCertificates）]を選択します。[信頼できる証明書（TrustedCertificates）]ページが表示され、すべての信頼できる証明書が一覧表示されます。
証明書のステータスが有効になっている必要があります。これにより、CiscoISEが信頼の確立にこの証明書を使用できるようになります。証明書が信頼できる証明書ストアにインポートされると、この証明書は自動的に有効になります。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[信頼できる証明書（TrustedCertificates）]を選択します。
有効または無効にする証明書の隣にあるチェックボックスをオンにし、[編集（Edit）]をクリックします。
ステータスを変更します。
[保存（Save）]をクリックします。
[証明書ストア（CertificateStore）]ページを使用して、CiscoISEにCA証明書を追加することができます。
必要に応じてフィールドの値を設定します。
EAP認証または証明書ベースの管理者認証用に証明書チェーンにサブCA証明書を使用する場合は、ルートCAまでに証明書チェーンにすべての証明書をインポートする際に[クライアント認証およびsyslog用に信頼する（TrustforclientauthenticationandSyslog）]チェックボックスを必ずオンにしてください。CiscoISE2.6パッチ1以降では、同じサブジェクト名を持つ複数のCA証明書をインポートできます。証明書ベースの管理者認証の場合は、信頼できる証明書を追加する際に、[管理者認証に基づく証明書への信頼（Trustforcertificatebasedadminauthentication）]チェックボックスをオンにします。
パスワードベースの認証から証明書ベースの認証に認証タイプを変更すると、CiscoISEは展開内の各ノードでアプリケーションサーバを再起動します。PANのアプリケーションサーバから開始され、その後に各追加ノードが1つずつ続きます。
証明書を信頼できる証明書ストアに追加したら、編集の設定を使用して、その証明書をさらに編集できます。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[信頼できる証明書（TrustedCertificates）]。
必要に応じて編集可能なフィールドを変更します。
[保存（Save）]をクリックして、証明書ストアに対して行った変更を保存します。
今後使用しない信頼できる証明書を削除できます。ただし、ISE内部CA（認証局）の証明書は削除しないでください。ISE内部CA証明書を削除できるのは、展開全体のISEルート証明書チェーンを置き換える場合のみです。
警告メッセージが表示されます。ISE内部CA証明書を削除することを選択した場合は、次のとおりにクリックします。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[信頼できる証明書（TrustedCertificates）]。.
エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート（Export）]をクリックします。一度に1つの証明書のみをエクスポートできます。
クライアントブラウザを実行しているファイルシステムにPrivacyEnhancedMailファイルを保存します。
ルートCA証明書および中間CA証明書をインポートするとき、信頼できるCA証明書を使用する対象のサービスを指定できます。
CSRに署名し、デジタルで署名されたCA証明書を返した認証局のルート証明書および他の中間証明書が必要です。
[参照（Browse）]をクリックして、ルートCA証明書を選択します。
わかりやすい名前を入力します。
CAによって返されたルート証明書を選択します。
この信頼できる証明書を使用するサービスの横にあるチェックボックスをオンにします。
説明を入力します。
信頼できる証明書ストアに中間CA証明書をインポートします（該当する場合）。
証明書ストアから受信した証明書チェーンを含む単一のファイルから、複数の証明書をインポートすることができます。ファイル内のすべての証明書はPrivacy-EnhancedMail（PEM）の形式であり、証明書は次の順序に並べられている必要があります。
証明書チェーンのインポートは、次の2ステップのプロセスです。
認証局（CA）が署名付き証明書を発行するためには、証明書署名要求（CSR）を作成してCAに送信する必要があります。
自分が作成した証明書署名要求（CSR）のリストは、[証明書署名要求（CertificateSigningRequests）]ページで使用できます。認証局（CA）から署名を取得するには、CSRをエクスポートし、その証明書をCAに送信する必要があります。証明書はCAによって署名され、返されます。
管理者ポータルから証明書を一元的に管理できます。展開内のすべてのノードのCSRを作成およびエクスポートできます。その後、CSRをCAに送信し、CAからCA署名付き証明書を取得し、CAによって返されたルートおよび中間CA証明書を信頼できる証明書ストアにインポートし、CSRにCA署名付き証明書をバインドする必要があります。
証明書署名要求（CSR）を生成して、展開内のノードのCA署名付き証明書を取得できます。展開の選択ノードまたは展開のすべてのノード用のCSRを生成できます。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[証明書署名要求（CertificateSigningRequests）]を選択します。
[Generate（生成）]をクリックしてCSRを生成します。
CSRが生成されます。
[Export（エクスポート）]をクリックして、メモ帳でCSRを開きます。
「-----BEGINCERTIFICATEREQUEST-----」から「-----ENDCERTIFICATEREQUEST-----」までのすべてのテキストをコピーします。
選択したCAの証明書要求に、このCSRの内容を貼ってください。
署名済みの証明書をダウンロードする。
CAによっては、署名付き証明書が電子メールで送信される場合があります。署名付き証明書は、zipファイルの形式で、CiscoISEの信頼された証明書ストアに追加する必要がある、新規発行の証明書とCAのパブリック署名証明書が含まれています。デジタル署名されたCA証明書、ルートCA証明書、および他の中間CA証明書（該当する場合）がクライアントブラウザを実行するローカルシステムにダウンロードされます。
CAからデジタル署名付き証明書を受け取った後、それを証明書署名要求（CSR）にバインドする必要があります。管理者ポータルから展開内のすべてのノードに対してバインド操作を実行できます。
CA署名付き証明書にCSRをバインドするノードの隣にあるチェックボックスをオンにします。
[バインド（Bind）]をクリックします。
[参照（Browse）]をクリックし、CA署名付き証明書を選択します。
証明書の[フレンドリ名（FriendlyName）]を指定します。
CiscoISEに証明書の拡張の検証を許可する場合は、[証明書の拡張の検証（ValidateCertificateExtensions）]チェックボックスをオンにします。
[証明書の拡張の検証（ValidateCertificateExtensions）]オプションが有効になっており、インポートする証明書にCAフラグがtrueに設定された基本制約拡張が含まれている場合は、キー使用拡張が存在すること、およびkeyEnciphermentビットとkeyAgreementビットのいずれかまたは両方が設定されていることを確認します。
ISEでは、EAP-TLSクライアント証明書にデジタル署名キー使用拡張を使用する必要があります。
この証明書が使用領域で使用されるサービスを確認します。
[送信（Submit）]をクリックし、CA署名付き証明書をバインドします。
CiscoISEノード間通信にこの証明書を使用するように選択した場合、CiscoISEノードでアプリケーションサーバが再起動されます。
他のノードでCA署名付き証明書にCSRをバインドするために、このプロセスを繰り返します。
このページを使用して、証明書署名要求をエクスポートすることができます。
エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート（Export）]をクリックします。
[OK]をクリックして、クライアントブラウザを実行しているファイルシステムにファイルを保存します。
展開をセットアップする場合、セカンダリノードを登録する前に、セカンダリノードの管理者証明書の検証に使用される適切なCA証明書をPANの証明書信頼リスト（CTL）に配置する必要があります。PANのCTLに入力する手順は、シナリオに応じて異なります。
外部CAから発行された証明書に基本制約が定義されており、CAフラグがtrueに設定されていることを確認します。ノード間通信のCA署名付き証明書をインストールするには、次の手順を実行します。
CiscoISEはTCPポート8443（またはポータルが使用するように設定したポート）でポータル証明書を提示します。
すでに定義済みの証明書グループタグを選択するか、ポータル用に新しく作成する必要があります。たとえば、mydevicesportalなどです。
デフォルトでは、すべてのCiscoISEポータルは自己署名証明書を使用します。ポータルにCA署名付き証明書を使用する場合は、デフォルトのポータル証明書グループタグをCA署名付き証明書に割り当てることができます。既存のCA署名付き証明書を使用するか、またはCSRを生成して、ポータルに使用する新しいCA署名付き証明書を取得できます。1つの証明書から別の証明書にポータルグループタグを再割り当てすることができます。
既存の証明書を編集する場合、証明書に関連付けられているポータルタグ（ゲスト）がいずれかのポータルですでに使用されている場合は、デフォルトのポータル証明書グループタグまたは他のポータルグループタグをこの証明書に再割り当てすることはできません。「ゲスト」ポータルタグを使用しているポータルのリストが表示されます。
次に、CA署名付き証明書にデフォルトのポータル証明書グループタグを再割り当てする手順について説明します。
このタグを使用するポータルのリストを表示するには、デフォルトのポータル証明書グループタグの横にあるiアイコンにマウスポインタを合わせます。このタグが割り当てられているポータル証明書がある展開内のISEノードを表示することもできます。
ポータルに使用するCA署名付き証明書の横にあるチェックボックスをオンにして、[編集（Edit）]をクリックします。
いずれのポータルでも使用されていないCA署名付き証明書を選択してください。
[使用方法（Usage）]領域で、[ポータル（Portal）]チェックボックスをオンにして、デフォルトのポータル証明書グループタグを選択します。
[はい（Yes）]をクリックして、CA署名付き証明書にデフォルトのポータル証明書グループタグを再割り当てします。
展開内のすべてのポータルに「デフォルトポータル証明書グループ」タグを使用する場合は、新しいISEノードを登録する前に、関連するCA署名付き証明書をインポートし、サービスとして「ポータル」を選択し、この証明書に「デフォルトポータル証明書グループ」タグを関連付けます。
展開に新しいノードを追加すると、デフォルトの自己署名証明書が「デフォルトポータル証明書グループ」タグに関連付けられ、このタグを使用するようにポータルが設定されます。
新しいノードの登録後、証明書グループタグの関連付けは変更できません。したがって、展開にノードを登録する前に、次を実行してください。
自己署名証明書を作成し、サービスとして「ポータル」を選択し、別の証明書グループタグ（たとえば、tempportaltag）を割り当てます。
新しく作成した証明書グループタグ（tempportaltag）を使用するようにポータル設定を変更します。
デフォルト自己署名証明書を編集し、ポータルロールを削除します。
このオプションは、デフォルトポータル証明書グループタグとデフォルト自己署名証明書との関連付けを削除します。
次のいずれかを実行します。
CSRの生成
CSRを生成するときは、次を実行します。
秘密キーとCA署名付き証明書のインポート
CA署名付き証明書をインポートするときは、次を実行します。
既存のCA署名付き証明書の編集
既存のCA署名付き証明書を編集するときは、次を実行します。
この証明書を使用する「ポータル」をサービスとして選択し、「デフォルトポータル証明書グループ」タグを関連付けます。
展開にISEノードを登録します。
デフォルトでは、CiscoISEは証明書が期限切れになったデバイスからの要求を拒否します。ただし、このデフォルト動作を変更し、このような要求を処理し、ユーザに証明書の更新を求めるようにISEを設定できます。
ユーザが証明書を更新することを許可する場合は、要求をさらに処理する前に証明書が更新されたかどうかを判断する許可ポリシールールを設定することを推奨します。証明書が期限切れになったデバイスからの要求を処理することで、潜在的なセキュリティ脅威が発生する可能性があります。組織のセキュリティが侵害されていないことを保証するには、適切な許可プロファイルおよびルールを設定する必要があります。
あるデバイスは有効期限の前後に証明書を更新できます。ただし、Windowsデバイスでは、期限切れになる前にだけ証明書を更新できます。AppleiOS、MacOSX、およびAndroidデバイスでは、有効期限の前または後に証明書を更新できます。
CiscoISE証明書ディクショナリには、ユーザに証明書更新を許可するポリシー条件で使用される次の属性が含まれます。
許可ポリシーでCertRenewalRequiredの単純条件（デフォルトで使用可能）を使用すると、CiscoISEが要求を処理する前に証明書（有効期限切れまたはまもなく有効期限が切れる）を更新できます。
ユーザ証明書が期限切れになる前に失効している場合、CiscoISEは、CAがパブリッシュしたCRLをチェックして認証要求を拒否します。失効した証明書の期限が切れている場合は、CAがCRLでこの証明書をパブリッシュしない可能性があります。このシナリオでは、失効した証明書がCiscoISEによって更新される可能性があります。このことを避けるために、証明書を更新する前に、要求が中央Web認証（CWA）にリダイレクトされ、完全認証が実行されるようにします。CWAのユーザをリダイレクトするには、許可プロファイルを作成する必要があります。
ユーザが証明書を更新できるようにCiscoISEを設定するには、この手順で示すタスクを実行する必要があります。
WLCで制限されたアクセスACLを設定して、CWA要求をリダイレクトします。
[ポリシー（Policy）]>[ポリシー要素（PolicyElements）]>[結果（Results）]>[認証（Authentication）]>[許可されるプロトコル（AllowedProtocols）]>[デフォルトネットワークアクセス（DefaultNetworkAccess）]を選択します。
PEAPおよびEAP-FASTプロトコルのEAP-TLSプロトコルおよびEAP-TLS内部方式の下の[許可ポリシーの証明書更新を可能にするために失効した証明書の認証を許可（AllowAuthenticationofexpiredcertificatestoallowcertificaterenewalinAuthorizationPolicy）]チェックボックスをオンにします。
EAP-TLSプロトコルを使用する要求がNSPフローを通過します。
PEAPおよびEAP-FASTプロトコルについては、要求を処理するようにCiscoISE向けCiscoAnyConnectを手動で設定する必要があります。
WLCで制限されたアクセスACLが設定されていることを確認します。
[ポリシー（Policy）]>[ポリシー要素（PolicyElements）]>[結果（Results）]>[許可（Authorization）]>[許可プロファイル（AuthorizationProfiles）]を選択します。
[追加（Add）]をクリックします。
許可プロファイルの名前を入力します。たとえば、CertRenewal_CWAです。
[共通タスク（CommonTasks）]領域の[Webリダイレクション（CWA、DRW、MDM、NSP、CPP）（WebRedirection(CWA,DRW,MDM,NSP,CPP)）]チェックボックスをオンにします。
ドロップダウンリストの[中央集中Web認証（CentralizedWebAuth）]および制限されたアクセスACLを選択します。
[証明書更新メッセージの表示（DisplayCertificatesRenewalMessage）]チェックボックスをオンにします。
url-redirect属性値が変更され、この値に証明書が有効である日数が含まれます。
CiscoISE1.2で無線デバイスの次のデバイス登録WebAuth（DRW）ポリシーを設定している場合：
ISE1.3以上のバージョンにアップグレードした後は、DRW-Allowポリシー条件を次のように更新する必要があります。
中央Web認証リダイレクションの許可プロファイルが作成されていることを確認します。
[管理（Administration）]>[システム（System）]>[設定（Settings）]>[ポリシーセット（PolicySets）]でポリシーセットを有効にします。
[ワークセンター（WorkCenters）]>[デバイス管理（DeviceAdministration）]>[ポリシーセット（PolicySets）]を選択します。
[上を作成（CreateAbove）]をクリックします。
新しいルールの名前を入力します。
次の単純条件と結果を選択します。
CertRenewalRequiredEQUALSTrueの場合は、権限用に以前に作成した許可プロファイル（CertRenewal_CWA）を選択します。
証明書が期限切れになったデバイスを持つ企業ネットワークにアクセスした場合は、[更新（Renew）]をクリックして、デバイスを再設定します。
ユーザがパーソナルデバイス証明書を更新できるようにするには、選択したゲストポータルでBYOD設定を有効にする必要があります。
[ワークセンター（WorkCenter）]>[ゲストアクセス（GuestAccess）]>[ポータルとコンポーネント（Portals&Components）]>[ゲストポータル（GuestPortals）]を選択します。
[BYOD設定（BYODSettings）]から[従業員にネットワークでのパーソナルデバイスの使用を許可する（Allowemployeestousepersonaldevicesonthenetwork）]チェックボックスをオンにします。
ISEを使用してAppleiOSデバイスのエンドポイント証明書を更新する場合、「プロファイル済みでインストールできませんでした（ProfiledFailedtoInstall）」エラーメッセージが表示される場合があります。このエラーメッセージは、同じポリシーサービスノード（PSN）または別のPSNで、期限切れ間近または期限切れのネットワークプロファイルが更新のプロセス時に使用されるものとは異なる管理者HTTPS証明書によって署名されている場合に表示されます。
回避策としては、展開内のすべてのPSNで管理者HTTPS用にマルチドメインSSL証明書（通称UnifiedCommunicationsCertificates（UCC））またはワイルドカード証明書を使用します。
証明書は、自己署名したり、外部の認証局（CA）がデジタルで署名したりできます。CiscoISE内部認証局（ISECA）は、従業員が企業ネットワークでパーソナルデバイスを使用できるように、一元的なコンソールからエンドポイントのデジタル証明書を発行し、管理します。CA署名付きデジタル証明書は、業界標準であり、よりセキュアです。プライマリPANは、ルートCAです。ポリシーサービスノード（PSN）は、プライマリPANの下位CAです（SCEPRA）。ISECAには次の機能があります。
CAサービスがプライマリ管理ノードで無効になっている場合でも、CAサービスはセカンダリ管理ノードのCLIで実行中として表示されます。理想的には、CAサービスが無効であると表示される必要があります。これは、CiscoISEの既知の問題です。
インストール後に、CiscoISEノードはルートCA証明書およびノードCA証明書でプロビジョニングされ、エンドポイントの証明書が管理されます。
展開をセットアップすると、プライマリ管理ノード（PAN）として指定したノードがルートCAになります。PANには、ルートCA証明書と、ルートCAによって署名されたノードCA証明書があります。
PANにセカンダリ管理ノードを登録すると、ノードCA証明書が生成され、プライマリ管理ノードでルートCAによって署名されます。
PANに登録したポリシーサービスノード（PSN）には、エンドポイントCAと、PANのノードCAによって署名されたOCSP証明書がプロビジョニングされます。ポリシーサービスノード（PSN）は、PANの下位CAです。ISECAを使用すると、PSNのエンドポイントCAによってネットワークにアクセスするエンドポイントに証明書が発行されます。
CiscoISECAチェーンを再生成すると、ルートCA、ノードCA、およびエンドポイントCA証明書を含むすべての証明書が再生成されます。PANまたはPSNのドメイン名またはホスト名を変更すると、ISECAチェーンを再生する必要があります。以前のリリースから2.0以降にアップグレードするときには、2つのルート階層から1つのルート階層に移行するようにISECAチェーンを再生成することをお勧めします。
システム証明書を再生成すると、ルートCAまたは中間CA証明書のいずれでも、ISEメッセージングサービスが再起動して新しい証明書チェーンがロードされます。監査ログは、ISEメッセージングサービスが再び利用可能になるまで失われます。
展開でCiscoISEの内部CAを置き換えるたびに、完全な証明書チェーンを取得するようにISEメッセージングサービスも更新する必要があります。
CiscoISECAサービスが、楕円曲線暗号化（ECC）アルゴリズムに基づく証明書をサポートするようになりました。ECCでは、大幅に小さいキーサイズを使用している場合でも、他の暗号化アルゴリズムよりもセキュリティが向上し、パフォーマンスが向上します。
次の表に、ECCおよびRSAのキーサイズとセキュリティ強度を比較します。
キーのサイズが小さいほど、暗号化が迅速になります。
CiscoISEでは、次のECC曲線タイプがサポートされています。曲線タイプまたはキーサイズが大きくなると、セキュリティが強化されます。
ISEは、証明書のEC部分の明示的なパラメータをサポートしていません。明示的なパラメータで証明書をインポートしようとすると、「証明書の検証に失敗しました」というエラーが表示されます。名前付きECParametersのみがサポートされています。
CiscoISECAサービスは、BYODフローを介して接続するデバイスのECC証明書をサポートします。また、証明書プロビジョニングポータルからECC証明書を生成することもできます。
次の表に、ECCをサポートしているオペレーティングシステムおよびバージョンと、サポートされている曲線タイプを示します。デバイスがサポートされているオペレーティングシステムを実行していない場合、またはサポートされているバージョンでない場合には、代わりにRSAベースの証明書を使用することもできます。
Android6.0は、ECC証明書をサポートするために2016年5月のパッチが必要です。
Windows7とAppleiOSは、EAP-TLSを介する認証用のECCをネイティブでサポートしていません。CiscoISEのこのリリースでは、MacOSXデバイスでのECC証明書の使用はサポートされていません。
EnrollmentoverSecureTransport（EST）プロトコルを備えたBYODフローが適切に機能しない場合は、次のことを確認します。
CiscoISEのこのリリースでは、ESTクライアントがCiscoISEに存在するESTサーバに対して直接認証を行うことはサポートされていません。
AndroidまたはWindowsエンドポイントでのオンボーディング時に、要求がECCベースの証明書用である場合には、ISEがESTフローをトリガーします。
[認証局（CA）証明書（CertificateAuthority(CA)Certificates）]ページには、内部CiscoISECAに関連するすべての証明書が表示されます。以前のリリースでは、これらのCA証明書は信頼できる証明書ストアにありましたが、現在は[CA証明書（CACertificates）]ページに移動しています。これらの証明書は、このページにノード方式で表示されます。ノードを展開して、その特定のノードのISECA証明書をすべて表示することができます。プライマリおよびセカンダリ管理ノードには、ルートCA、ノードCA、下位CA、OCSPレスポンダ証明書があります。展開内の他のノードには、エンドポイント下位CAおよびOCSP証明書があります。
CiscoISECAサービスを有効にすると、すべてのノードでこれらの証明書が自動的に生成され、インストールされます。また、ISEルートCAチェーン全体を置き換えると、すべてのノードでこれらの証明書が自動的に再生成され、インストールされます。手動による介入は必要ありません。
CiscoISECA証明書はCertificateServices<エンドポイントサブCA/ノードCA/ルートCA/OCSPレスポンダ>-<ノードのホスト名>#証明書番号という命名規則に従います。
[CA証明書（CACertificates）]ページでCiscoISECA証明書を編集、インポート、エクスポート、削除、表示できます。
証明書をCiscoISECA証明書ストアに追加したら、編集の設定を使用して、その証明書をさらに編集できます。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[認証局（CertificateAuthority）]>[認証局証明書（CertificateAuthorityCertificates）]の順に選択します。.
CiscoISEルートCAおよびノードCA証明書をエクスポートするには、次の手順を実行します。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[認証局（CertificateAuthority）]>[認証局証明書（CertificateAuthorityCertificates）]の順に選択します。
エンドポイントが別の展開のCiscoISECAによって発行された証明書を使用してネットワークへの認証を試みる場合、CiscoISEルートCA、ノードCA、エンドポイントサブCA証明書をその展開からCiscoISEの信頼できる証明書ストアにインポートする必要があります。
エンドポイントが認証されている展開の管理者用ポータルにログインします。
クライアント証明書ベースの認証が有効である場合は、CiscoISEにより展開内の各ノードのアプリケーションサーバが再起動されます（最初にPANのアプリケーションサーバが再起動され、続いて追加のノードのアプリケーションサーバが1つずつ再起動されます）。
証明書テンプレートには、そのテンプレートに基づいて認証局（CA）によって発行されたすべての証明書に共通のプロパティが含まれています。証明書テンプレートは、件名、サブジェクト代替名（SAN）、キータイプ、キーサイズ、使用する必要があるSCEPRAプロファイル、証明書の有効期間、証明書がクライアントまたはサーバの認証またはその両方に使用される必要があるかどうかを指定した拡張キーの使用状況（EKU）を定義します。内部CiscoISECA（ISECA）は、証明書テンプレートを使用し、そのテンプレートに基づいて証明書を発行します。
CiscoISEには、次のISECAのデフォルトの証明書テンプレートが付属しています。必要に応じて、追加の証明書テンプレートを作成できます。デフォルトの証明書テンプレートは次のとおりです。
CiscoISEの内部CAには、エンドポイント証明書を作成するために使用された証明書テンプレートを表す拡張子が含まれています。内部CAによって発行されたすべてのエンドポイント証明書には、証明書テンプレート名の拡張子が含まれています。この拡張子は、そのエンドポイント証明書を作成するために使用された証明書テンプレートを表します。拡張子のIDは1.3.6.1.4.1.9.21.2.5です。CERTIFICATE:テンプレート名属性を許可ポリシーの条件に使用して、評価の結果に基づいて適切なアクセス権限を割り当てることができます。
許可ポリシールールで証明書テンプレート名の拡張子を使用できます。
[ポリシー（Policy）]>[ポリシーセット（PolicySets）]を選択し、許可ポリシールールを表示するデフォルトのポリシーセットを展開します。
新しいルールを追加するか、既存のルールを編集します。次に、Compliant_Device_Accessルールを編集する例を示します。
CiscoISECAは、証明書プロビジョニングポータルから証明書を生成するためのpxGridコントローラの証明書テンプレートを提供します。
pxGridクライアントの証明書署名要求（CSR）を生成し、CSRの内容をクリップボードにコピーします。
ネットワークアクセスユーザアカウントを作成します（[管理（Administration）]>[IDの管理（IdentityManagement）]>[ID（Identities）]>[ユーザ（Users）]>[追加（Add）]）。
ユーザが割り当てられているユーザグループをメモします。
証明書プロビジョニングポータルの設定を編集します（[管理（Administration）]>[デバイスポータル管理（DevicePortalManagement）]>[証明書プロビジョニング（CertificateProvisioning）]）。
証明書プロビジョニングポータルを起動します。[ポータルテストURL（PortaltestURL）]リンクをクリックします。
pxGridクライアントの信頼できる証明書ストアにCiscoISECAチェーンをインポートします。
ユーザがネットワークで登録できるさまざまなモバイルデバイスの証明書のプロビジョニング機能を有効にするために、1つ以上のSimpleCertificateEnrollmentProtocol（SCEP）認証局（CA）プロファイル（CiscoISE外部CA設定と呼ばれます）を設定して、CiscoISEに複数のCAの場所を指定できます。複数のプロファイルを使用できる利点は、ハイアベイラビリティを実現し、指定したCAの場所の間でロードバランシングを実行できることです。特定のSCEPCAへの要求に3回連続して応答がなかった場合、CiscoISEは特定のサーバが使用不能であると宣言し、次に負荷が小さく応答時間が短い既知のCAに自動的に移動し、サーバがオンラインに復帰するまで、定期的なポーリングを開始します。
MicrosoftSCEPサーバをCiscoISEと相互運用するように設定する方法については、次を参照してください。
管理者ポータルには、内部ISECAによってエンドポイントに対して発行されたすべての証明書のリストが示されます（[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[エンドポイント証明書（EndpointCertificates）]）。[発行された証明書（IssuedCertificates）]ページでは、証明書ステータスを一目で確認できます。証明書が失効している場合は、[ステータス（Status）]列の上にマウスカーソルを移動すると、失効の理由を確認できます。[証明書テンプレート（CertificateTemplate）]列の上にマウスカーソルを移動すると、キータイプ、キーサイズ、曲線タイプ、サブジェクト、サブジェクト代替名（SAN）、証明書の有効性などの詳細情報を表示できます。エンドポイント証明書クリックして、証明書を表示できます。
ISECAによって発行されたすべての証明書（BYODフローを介して自動的にプロビジョニングされた証明書と証明書プロビジョニングポータルから取得された証明書）は、[エンドポイント証明書（EndpointCertificates）]ページにリストされます。このページからこれらの証明書を管理できます。
たとえばuser7に発行された証明書を確認する場合は、[フレンドリ名（FriendlyName）]フィールドの下に表示されるテキストボックスに「user7」と入力します。このユーザにCiscoISEによって発行されたすべての証明書が表示されます。フィルタをキャンセルするには、テキストボックスから検索語を削除します。また、[拡張フィルタ（AdvancedFilter）]オプションを使用して、さまざまな検索基準に基づいてレコードを表示することもできます。
この[エンドポイント証明書（EndpointCertificates）]ページには、必要に応じてエンドポイント証明書を取り消すためのオプションもあります。
[証明書管理概要（CertificateManagementOverview）]ページには、展開内の各PSNノードによって発行されたエンドポイント証明書の合計数が表示されます。また、失効した証明書の合計数と失敗した証明書の合計数をノードごとに確認することもできます。このページのデータは任意の属性に基づいてフィルタリングできます。
PPANに障害が発生し、セカンダリ管理ノードを外部PKIのルートCAまたは中間CAとして機能させるために昇格する場合に備え、CiscoISECA証明書およびキーをセキュアにバックアップして、セカンダリ管理ノードにこれらを復元できるようにする必要があります。CiscoISE設定のバックアップには、CA証明書とキーは含まれていません。CA証明書およびキーをリポジトリにエクスポートおよびインポートするには、代わりにコマンドラインインターフェイス（CLI）を使用する必要があります。applicationconfigureiseコマンドには、CA証明書およびキーのバックアップと復元のためのエクスポートおよびインポートのオプションが含まれています。
信頼できる証明書ストアからの次の証明書が、セカンダリ管理ノードで復元されます。
次の場合、CiscoISECA証明書およびキーのバックアップおよび復元が必要となります。
CA証明書およびキーをPANからエクスポートし、セカンダリ管理ノードでインポートする必要があります。このオプションでは、PANがダウンした場合にセカンダリ管理ノードでエンドポイントの証明書を発行および管理し、セカンダリ管理ノードをPANに昇格させることができます。
CA証明書およびキーを格納するためのリポジトリを作成したことを確認します。
CiscoISECLIから、applicationconfigureiseコマンドを入力します。
7を入力して、証明書およびキーをエクスポートします。
リポジトリの名前を入力します。
暗号キーを入力します。
エクスポートされた証明書のリスト、件名、発行者、およびシリアル番号とともに成功メッセージが表示されます。
Thefollowing4CAkeypairswereexportedtorepository'sftp'at'ise_ca_key_pairs_of_ise-vm1':Subject:CN=CiscoISESelf-SignedCAofise-vm1Issuer:CN=CiscoISESelf-SignedCAofise-vm1Serial#:0x621867df-568341cd-944cc77f-c9820765Subject:CN=CiscoISEEndpointCAofise-vm1Issuer:CN=CiscoISESelf-SignedCAofise-vm1Serial#:0x7027269d-d80a406d-831d5c26-f5e105faSubject:CN=CiscoISEEndpointRAofise-vm1Issuer:CN=CiscoISEEndpointCAofise-vm1Serial#:0x1a65ec14-4f284da7-9532f0a0-8ae0e5c2Subject:CN=CiscoISEOCSPResponderCertificateofise-vm1Issuer:CN=CiscoISESelf-SignedCAofise-vm1Serial#:0x6f6d4097-21f74c4d-8832ba95-4c320fb1ISECAkeysexportcompletedsuccessfullyCiscoISECA証明書およびキーのインポートセカンダリ管理ノードを登録したら、PANからCA証明書およびキーをエクスポートし、セカンダリ管理ノードにインポートします。
8を入力して、CA証明書およびキーをインポートします。
インポートするファイルの名前を入力します。
ファイルを復号化するための暗号キーを入力します。
処理が正常に完了したことを知らせるメッセージが表示されます。
PSNのホスト名を変更する場合は、プライマリPANおよびPSNでそれぞれルートCAと下位CAを再生成する代わりに、ホスト名を変更する前にPSNを登録解除し、再登録できます。新しい下位証明書はPSN上で自動的にプロビジョニングされます。
[証明書署名要求（CSR）の生成（GenerateCertificateSigningRequests(CSR)）]をクリックします。
[証明書の使用先（Certificate(s)willbeusedfor）]ドロップダウンリストからISEルートCAを選択します。
[ISEルートCA証明書チェーンの置き換え（ReplaceISERootCACertificatechain）]をクリックします。
ルートCAと下位CA証明書が、展開内のすべてのノードに対して生成されます。
展開にセカンダリPANがある場合は、プライマリPANからCiscoISECA証明書およびキーのバックアップを取得し、セカンダリ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です。
[証明書の使用目的（Certificate(s)willbeusedfor）]ドロップダウンリストから[ISE中間CA（ISEIntermediateCA）]を選択します。
[生成（Generate）]をクリックします。
CSRをエクスポートし、外部CAに送信して、CA署名付き証明書を取得します。
信頼できる証明書ストアに外部CAのルートCA証明書をインポートします。
CSRにCA署名付き証明書をバインドします。
展開にセカンダリPANがある場合は、プライマリPANからCiscoISECA証明書およびキーのバックアップを取得し、セカンダリPANで復元します。これにより、プライマリPANの障害が発生した場合に、セカンダリPANが外部PKIの下位CAとして機能するようになり、セカンダリPANをプライマリPANに昇格させることができます。
ネットワークに接続するエンドポイント（パーソナルデバイス）の証明書を発行し、管理するようにCiscoISEを設定できます。内部CiscoISE認証局（CA）サービスを使用して、エンドポイントから証明書署名要求（CSR）に署名したり、外部CAにCSRを転送したりすることができます。
クライアントプロビジョニングポリシーを作成します。
TLSベース認証用の許可ポリシールールを設定します。
パーソナルデバイスからワイヤレスSSIDに接続するときにECCRSAベースの証明書を使用すると、2回目のパスワード入力を行うよう求められます。
次の手順では、CiscoISEIDストアのEmployeeユーザグループにユーザを追加する方法について説明します。外部IDストアを使用した場合でも、ユーザを追加できるEmployeeユーザグループがあることを確認します。
[管理（Administration）]>[IDの管理（IdentityManagement）]>[ID（Identities）]>[ユーザ（Users）]を選択します。
ユーザの詳細情報を入力します。
[パスワード（Passwords）]セクションで、[ログインパスワード（LoginPassword）]と[TACACS+イネーブルパスワード（TACACS+EnablePassword）]を選択し、ネットワークデバイスにアクセスレベルを設定します。
[ユーザグループ（UserGroup）]ドロップダウンリストから[従業員（Employee）]を選択します。
ネットワークに接続するエンドポイントの認証に証明書を使用するには、CiscoISEで証明書認証プロファイルを定義するか、またはデフォルトのPreloaded_Certificate_Profileを編集する必要があります。証明書認証プロファイルには、プリンシパルユーザ名として使用する必要がある証明書フィールドが含まれています。たとえば、ユーザ名が[一般名（CommonName）]フィールドにある場合は、証明書認証プロファイルを[プリンシパルユーザ名（PrincipalUsername）]が[サブジェクト-一般名（Subject-CommonName）]であるとして定義できます。これはIDストアに照らして確認できます。
[管理（Administration）]>[IDの管理（IdentityManagement）]>[外部IDソース（ExternalIdentitySources）]>[証明書認証プロファイル（CertificateAuthenticationProfile）]を選択します。
証明書認証プロファイルの名前を入力します。たとえば、CAPとなります。
[サブジェクト-一般名（Subject-CommonName）]に[プリンシパルユーザ名X509属性（PrincipalUsernameX509Attribute）]を選択します。
証明書認証プロファイルを作成したら、CiscoISEが証明書の属性を取得し、定義したIDソースをIDソース順序で照合できるように、証明書認証プロファイルをIDソース順序に追加します。
次のタスクが完了していることを確認します。
[管理（Administration）]>[IDの管理（IdentityManagement）]>[IDソース順序（IdentitySourceSequences）]を選択します。
IDソース順序の名前を入力します。たとえば、Dot1Xとなります。
[証明書認証プロファイルの選択（SelectCertificateAuthenticationProfile）]チェックボックスをオンにし、作成した証明書認証プロファイル、つまりCAPを選択します。
ユーザ情報を含むIDソースを[認証検索リスト（AuthenticationSearchList）]領域の[選択済み（Selected）]リストボックスに移動します。
[ユーザが見つからなかったとして処理し、順序内の次のストアに進む（Treatasiftheuserwasnotfoundandproceedtothenextstoreinthesequence）]オプションボタンをクリックします。
CSRへの署名に外部CAを使用する場合、外部CAを設定する必要があります。外部CA設定はCiscoISEの以前のリリースでは、SCEPRAプロファイルと呼ばれていました。CiscoISECAを使用する場合、CA設定を明示的に設定する必要はありません。[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[内部CA設定（InternalCASettings）]で、内部CA設定を確認できます。
ユーザのデバイスが検証済みの証明書を受信すると、証明書はデバイス上の次の表の場所に置かれます。
Device
証明書ストレージの場所
アクセス方式
iPhone/iPad
標準の証明書ストア
[設定（Settings）]>[一般（General）]>[プロファイル（Profile）]
Android
暗号化された証明書ストア
エンドユーザに不可視です。
証明書は、[設定（Settings）]>[ロケーションおよびセキュリティ（Location&Security）]>[ストレージのクリア（ClearStorage）]を使用して削除できます。
Windows
/cmdプロンプトからmmc.exeを起動するか、または証明書スナップインで表示します。
Mac
[アプリケーション（Application）]>[ユーティリティ（Utilities）]>[キーチェーンアクセス（KeychainAccess）]
証明書署名要求（CSR）への署名に外部認証局（CA）を使用する場合は、外部CAのURLが必要となります。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[外部CA設定（ExternalCASettings）]を選択します。
外部CA設定の名前を入力します。たとえば、EXTERNAL_SCEPなどです。
[URL]テキストボックスに、外部CAサーバのURLを入力します。
証明書テンプレートは、（内部または外部CAのために）使用する必要があるSCEPRAプロファイル、キータイプ、キーサイズ、曲線タイプ、サブジェクト、サブジェクト代替名（SAN）、証明書の有効期間、拡張キーの使用状況を定義します。この例では、内部CiscoISECAを使用すると想定します。外部CAテンプレートの場合、有効期間は外部CAによって決定され、指定することはできません。
新しいCAテンプレートを作成するか、デフォルトの証明書テンプレートEAP_Authentication_Certificate_Templateを編集できます。
デフォルトでは、次のCAテンプレートがCiscoISEで使用できます。
ECCキータイプを使用する証明書テンプレートは、内部CiscoISECAとのみ使用することができます。
CAが設定されていることを確認します。
[管理（Administration）]>[システム（System）]>[CAサービス（CAService）]>[内部CA証明書テンプレート（InternalCACertificateTemplate）]を選択します。
内部CAテンプレートの名前を入力します。たとえば、Internal_CA_Templateとします。
（オプション）[組織単位（OrganizationalUnit）]、[組織（Organization）]、[市（City）]、[州/都道府県（State）]、[国（Country）]フィールドに値を入力します。
証明書テンプレートフィールド（[組織ユニット（OrganizationalUnit）]、[組織（Organization）]、[都市（City）]、[州（State）]、および[国（Country）]）のUTF-8文字はサポートしていません。UTF-8文字を証明書テンプレートで使用すると、証明書プロビジョニングが失敗します。
証明書を生成する内部ユーザのユーザ名が、証明書の共通名として使用されます。CiscoISE内部CAは、「+」または「*」の文字を[共通名（CommonName）]フィールドでサポートしていません。ユーザ名に「+」または「*」の特殊文字が含まれていないことを確認してください。
サブジェクト代替名（SAN）および証明書の有効期間を指定します。
キータイプを指定します。RSAまたはECCを選択します。
Windows7とAppleiOSは、EAP-TLS認証用のECCをネイティブでサポートしていません。CiscoISEのこのリリースでは、MacOSXデバイスでのECC証明書の使用はサポートされていません。
ネットワークのデバイスがサポートされていないオペレーティングシステム（Windows7、MACOSX、AppleiOS）を実行する場合は、キータイプとしてRSAを選択することを推奨します。
（RSAキータイプを選択する場合に適用）キーサイズを指定します。1024以上のキーサイズを選択する必要があります。
（ECCキータイプを選択する場合にのみ適用）曲線タイプを指定します。デフォルトはP-384です。
ISE内部CAをSCEPRAプロファイルとして選択します。
有効期間を日数単位で入力します。デフォルトは730日です。有効な範囲は1～730です。
拡張キーの使用状況を指定します。証明書をクライアント認証に使用する場合は、[クライアント認証（ClientAuthentication）]チェックボックスにマークを付けます。証明書をサーバ認証に使用する場合は、[サーバ認証（ServerAuthentication）]チェックボックスにマークを付けます。
内部CA証明書テンプレートが作成され、クライアントプロビジョニングポリシーによって使用されます。
ネイティブサプリカントプロファイルを作成して、ユーザがパーソナルデバイスを企業ネットワークに含めることができます。CiscoISEでは、異なるオペレーティングシステムごとに異なるポリシールールを使用します。各クライアントプロビジョニングポリシールールには、どのオペレーティングシステムにどのプロビジョニングウィザードを使用するかを指定するネイティブサプリカントプロファイルが含まれています。
[ポリシー（Policy）]>[ポリシー要素（PolicyElements）]>[結果（Results）]>[クライアントプロビジョニング（ClientProvisioning）]>[リソース（Resources）]を選択します。
[追加（Add）]>[ネイティブサプリカントプロファイル（NativeSupplicantProfile）]を選択します。
ネイティブサプリカントプロファイルの名前を入力します。たとえば、EAP_TLS_INTERNALとなります。
[オペレーティングシステム（OperatingSystem）]ドロップダウンリストから[すべて（ALL）]を選択します。
MACOSバージョン10.10のユーザは、デュアルSSIDPEAPフローに対してプロビジョニングされたSSIDに手動で接続する必要があります。
[有線（Wired）]または[無線（Wireless）]チェックボックスをオンにします。
[許可されるプロトコル（AllowedProtocol）]ドロップダウンリストから[TLS]を選択します。
以前に作成したCA証明書テンプレートを選択します。
WindowsおよびMacOSXオペレーティングシステムでは、Ciscoサイトからリモートリソースをダウンロードする必要があります。
ネットワークのプロキシ設定が正しく設定されていることを確認し、適切なリモートロケーションにアクセスして、クライアントプロビジョニングリソースをCiscoISEにダウンロードできることを確認します。
[ポリシー（Policy）]>[ポリシー要素（PolicyElements）]>[リソース（Resources）]>[クライアントプロビジョニング（ClientProvisioning）]>[リソース（Resources）]を選択します。
[追加（Add）]>[Ciscoサイトのエージェントリソース（AgentresourcesfromCiscosite）]を選択します。
[Windows]および[MACOSX]パッケージの隣にあるチェックボックスをオンにします。必ず最新バージョンを含めます。
クライアントプロビジョニングリソースポリシーは、どのユーザがリソース（エージェント、エージェントコンプライアンスモジュール、エージェントカスタマイズパッケージ/プロファイル）のどのバージョン（または複数のバージョン）をログイン時およびユーザセッション開始時にCiscoISEから受信するかを決定します。
エージェントコンプライアンスモジュールをダウンロードすると、システムで使用している既存のモジュールがあれば常にそれが上書きされます。
従業員がiOS、Android、およびMACOSXデバイスを持ち込むことができるようにするには、[クライアントプロビジョニングポリシー（ClientProvisioningPolicy）]ページでこれらの各デバイスのポリシールールを作成する必要があります。
必要なネイティブサプリカントプロファイルを設定し、[クライアントプロビジョニングポリシー（ClientProvisioningPolicy）]ページから必要なエージェントをダウンロードしておく必要があります。
[ポリシー（Policy）]>[クライアントプロビジョニング（ClientProvisioning）]を選択します。
AppleiOS、AndroidおよびMACOSXデバイスのクライアントプロビジョニングポリシールールを作成します。
このタスクは、TLSベース認証のDot1X認証ポリシールールを更新する方法を示します。
TLSベース認証用に作成された証明書認証プロファイルが存在することを確認します。
[ポリシー（Policy）]>[ポリシーセット（PolicySets）]を選択します。
[表示（View）]列から矢印アイコンをクリックすると、[設定（Set）]ビュー画面が開き、認証ポリシーを表示、管理、および更新できます。
デフォルトのルールベースの認証ポリシーには、Dot1X認証用のルールが含まれます。
Dot1X認証ポリシールールの条件を編集するには、[条件（Conditions）]列のセルにカーソルを合わせ、をクリックします。[条件スタジオ（ConditionsStudio）]が開きます。
Dot1Xポリシールールの[アクション（Actions）]列で、歯車アイコンをクリックし、必要に応じてドロップダウンメニューから、挿入または複製オプションのいずれかを選択して新しいポリシーセットを挿入します。
ルールの名前を入力します。たとえば、eap-tlsと入力します。
[条件（Conditions）]列から、（+）記号をクリックします。
[条件スタジオ（ConditionsStudio）]ページで必要な条件を作成します。[エディタ（Editor）]セクションで、[クリックして属性を追加する（ClickToAddanAttribute）]テキストボックスをクリックし、必要なディクショナリと属性（たとえば、NetworkAccess:UserNameEqualsUser1）を選択します。
ライブラリ条件を[クリックして属性を追加する（ClickToAddAnAttribute）]テキストボックスにドラッグアンドドロップできます。
[使用（Use）]をクリックします。
デフォルトルールは、そのままにします。
許可プロファイルを定義して、証明書ベースの認証の成功後にユーザに付与するアクセスを決定します。
ワイヤレスLANコントローラ（WLC）に必要なアクセスコントロールリスト（ACL）が設定されていることを確認します。WLCでのACLの作成方法については、『TrustSecHow-ToGuide:UsingCertificatesforDifferentiatedAccess』を参照してください。
この例では、WLCで次のACLが作成されていると仮定します。
新しい許可プロファイルを作成するには、[追加（Add）]をクリックします。
許可プロファイルの名前を入力します。
[アクセスタイプ（AccessType）]ドロップダウンリストから、[ACCESS_ACCEPT]を選択します。
中央Web認証、GooglePlayの中央Web認証、ネイティブサプリカントプロビジョニング、およびGoogleのネイティブサプリカントプロビジョニングの許可プロファイルを追加するには、[追加（Add）]をクリックします。
CiscoISEは、許可ポリシールールを評価し、ポリシールールで指定された許可プロファイルに基づいてネットワークリソースへのアクセス権をユーザに付与します。
必要な許可プロファイルを作成済みであることを確認します。
[ポリシー（Policy）]>[ポリシーセット（PolicySets）]を選択し、許可ポリシールールを表示するポリシーセットを展開します。
デフォルトのルールの上に追加のポリシールールを挿入します。
ここでは、CiscoISECAサービスを有効にする前に作成する必要がある許可ポリシールールおよびクライアントプロビジョニングポリシールールの詳細情報について説明します。
ここでは、CiscoISE証明書サービスを使用している場合に作成する必要があるクライアントプロビジョニングポリシールールについて説明します。次の表に詳細を示します。
ここでは、CiscoISEで証明書ベースの認証を有効にするために作成する必要がある許可プロファイルについて説明します。ワイヤレスLANコントローラ（WLC）のACL（NSP-ACLおよびNSP-ACL-Google）がすでに作成されている必要があります。
ここでは、CiscoISECAサービスを有効にするときに作成する必要がある許可ポリシールールについて説明します。
次の表に、CiscoISECAサービスの許可ポリシールールを設定するときに選択する必要がある属性および値を示します。この例では、CiscoISEで対応する許可プロファイルも設定しているものと想定します。
ISECAは、ASAVPN経由で接続しているクライアントマシンに証明書を発行します。この機能を使用して、ASAVPN経由で接続しているエンドデバイスに証明書を自動的にプロビジョニングできます。
CiscoISEは、SimpleCertificateEnrollmentProtocol（SCEP）を使用して登録を行い、証明書をクライアントマシンにプロビジョニングします。AnyConnectクライアントは、HTTPS接続でASAにSCEP要求を送信します。ASAは、CiscoISEとASAの間に確立されたHTTP接続を介してCiscoISEに要求を中継する前に、要求を評価し、ポリシーを適用します。CiscoISECAからの応答はクライアントに中継されます。ASAは、SCEPメッセージの内容を読み取ることはできず、CiscoISECAのプロキシとして機能します。CiscoISECAは、クライアントからのSCEPメッセージを復号化し、暗号化された形式で応答を送信します。
AnyConnectクライアントプロファイルの期限が切れる前に、証明書の更新を設定できます。証明書がすでに期限切れの場合、更新フローは新規登録と同様です。
サポートされているバージョンは次のとおりです。
ASAVPNユーザに証明書をプロビジョニングするには、CiscoISEおよびASAで次の設定を行う必要があります。
CiscoISEにネットワークデバイス定義がない場合にCiscoISEでネットワークデバイス定義を作成し、デフォルトのネットワークデバイス定義を使用できます。
[ワークセンター（WorkCenters）]>[デバイス管理（DeviceAdministration）]>[ネットワークリソース（NetworkResources）]>[ネットワークデバイス（NetworkDevices）]ページで、ネットワークデバイスの定義を作成することもできます。
[管理（Administration）]>[ネットワークリソース（NetworkResources）]>[ネットワークデバイス（NetworkDevices）]を選択します。
必須フィールドをすべて指定します。
[RADIUS認証設定（RADIUSAuthenticationSettings）]チェックボックスをオンにして、RADIUSプロトコル認証を設定します。
[TACACS認証設定（TACACSAuthenticationSettings）]チェックボックスをオンにして、TACACSプロトコル認証を設定します。
（任意）[SNMPの設定（SNMPSettings）]チェックボックスをオンにして、デバイス情報を収集するプロファイリングサービスの簡易ネットワーク管理プロトコルを設定します。
（任意）TrustSec対応デバイスを設定するには[高度なTrustSec設定（AdvancedTrustsecSettings）]チェックボックスをオンにします。
ASAでグループポリシーを設定し、SCEP登録要求を転送するためのAnyConnect用のISECAURLを定義します。
CiscoASAASDMにログインします。
左側の[リモートアクセスVPN（RemoteAccessVPN）]ナビゲーションペインから、[グループポリシー（GroupPolicies）]をクリックします。
[追加（Add）]をクリックして、グループポリシーを作成します。
グループポリシーの名前を入力します。たとえば、ISE_CA_SCEPのようになります。
[SCEP転送URL（SCEPforwardingURL）]フィールドで、[継承（Inherit）]チェックボックスをオフにして、ポート番号を含むISESCEPURLを入力します。
ISEノードのFQDNを使用する場合は、ASAに接続されているDNSサーバがISEノードのFQDNを解決できる必要があります。
[OK]をクリックして、グループポリシーを保存します。
ISECAサーバ、認証方式、およびISECASCEPURLを指定するには、ASAでAnyConnect接続プロファイルを設定します。
左側の[リモートアクセスVPN（RemoteAccessVPN）]ナビゲーションペインから、[AnyConnect接続プロファイル（AnyConnectConnectionProfiles）]をクリックします。
[追加（Add）]をクリックして、接続プロファイルを作成します。
接続プロファイルの名前を入力します。たとえば、Cert-Groupと入力します。
（オプション）[エイリアス（Aliases）]フィールドに接続プロファイルの説明を入力します。たとえば、SCEP-Call-ASAとします。
[認証（Authentication）]領域で、次の情報を指定します。
[クライアントアドレスの割り当て（ClientAddressAssignment）]領域で、使用するDHCPサーバおよびクライアントアドレスプールを選択します。
[デフォルトグループポリシー（DefaultGroupPolicy）]領域で、[管理（Manage）]をクリックし、ISESCEPURLとポート番号で作成したグループポリシーを選択します。
[詳細設定（Advanced）]>[一般（General）]を選択し、この接続プロファイルに対して[SimpleCertificateEnrollmentProtocolを有効にする（EnableSimpleCertificateEnrollmentProtocol）]チェックボックスをオンにします。
[OK]をクリックします。
SCEP登録用にAnyConnectでVPNクライアントプロファイルを設定します。
左側の[リモートアクセスVPN（RemoteAccessVPN）]ナビゲーションペインから、[AnyConnectクライアントプロファイル（AnyConnectClientProfile）]をクリックします。
使用するクライアントプロファイルを選択して[編集（Edit）]をクリックします。
左側の[プロファイル（Profile）]ナビゲーションペインで、[証明書の登録（CertificateEnrollment）]をクリックします。
[証明書の登録（CertificateEnrollment）]チェックボックスをオンにします。
次のフィールドに値を入力します。
証明書の内容をクライアントが要求する方法を定義する値を[証明書の内容（CertificateContents）]に入力します。
CiscoISE内部CA証明書をASAにインポートします。
CiscoISE内部CA証明書をエクスポートします。[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[認証局（CertificateAuthority）]>[認証局証明書（CertificateAuthorityCertificates）]に移動します。[証明書サービスノードCA（CertificateServicesNodeCA）]および[証明書サービスルートCA（CertificateServicesRootCA）]証明書の横にあるチェックボックスをオンにして、これらの証明書を一度に1つずつエクスポートします。
左側の[リモートアクセスVPN（RemoteAccessVPN）]ナビゲーションペインから、[証明書管理（CertificateManagement）]>[CA証明書（CACertificates）]を選択します。
[追加（Add）]をクリックしてCiscoISE内部CA証明書を選択し、ASAにインポートします。
従業員のパーソナルデバイスに対して発行された証明書を取り消す必要がある場合は、[エンドポイント証明書（EndpointCertificates）]ページから取り消すことができます。たとえば、従業員のデバイスが盗難されたり、紛失したりした場合には、CiscoISE管理者ポータルにログインし、そのデバイスに発行された証明書を[エンドポイント証明書（EndpointCertificates）]ページから取り消すことができます。フレンドリ名、デバイスの一意のID、シリアル番号に基づいて、このページのデータをフィルタリングできます。
PSN（サブCA）が侵害された場合は、[エンドポイント証明書（EndpointCertificates）]ページの[発行元（IssuedBy）]フィールドでフィルタリングすることによって、そのPSNによって発行されたすべての証明書を取り消すことができます。
従業員に対して発行された証明書を取り消すときに、アクティブなセッション（その証明書を使用して認証された）がある場合、セッションは即座に終了します。証明書を取り消すと、その直後に、許可されていないユーザはリソースにアクセスできなくなります。
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[認証局（CertificateAuthority）]>[発行された証明書（CertificatesIssued）]を選択します。
取り消すエンドポイント証明書の隣にあるチェックボックスをオンにし、[失効（Revoke）]をクリックします。
証明書を取り消す理由を入力します。
[Yes]をクリックします。
OnlineCertificateStatusProtocol（OCSP）は、x.509デジタル証明書のステータスのチェックに使用されるプロトコルです。このプロトコルは証明書失効リスト（CRL）に代わるものであり、CRLの処理が必要となる問題に対処します。
CiscoISEにはHTTPを介してOCSPサーバと通信し、認証で証明書のステータスを検証する機能があります。OCSPのコンフィギュレーションは、CiscoISEで設定されるいずれかの認証局（CA）証明書から参照できる再利用可能な設定オブジェクトで設定されます。
CRL検証とOCSP検証の両方または一方をCAごとに設定できます。両方を選択すると、CiscoISEでは最初にOCSPを介した検証が実行されます。プライマリOCSPサーバとセカンダリOCSPサーバの両方で通信の問題が検出された場合、または特定の証明書に対して不明のステータスが返された場合、CiscoISEはCRLチェックの実行に切り替えます。
CiscoISECAOCSP応答側は、OCSPクライアントと通信するサーバです。CiscoISECAのOCSPクライアントには、CiscoISEの内部OCSPクライアントと適応型セキュリティアプライアンス（ASA）のOCSPクライアントがあります。OCSPクライアントは、RFC2560、5019で定義されているOCSP要求/応答構造を使用して、OCSP応答側と通信する必要があります。
CiscoISECAは、OCSP応答側に証明書を発行します。OCSP応答側は、着信要求をポート2560でリッスンします。このポートは、OCSPトラフィックのみを許可するように設定されています。
OCSP応答側はRFC2560、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サービスでは、所定の証明書要求に対して次の値が返されます。
CiscoISEではCAごとに最大2つのOCSPサーバを設定でき、それらのサーバはプライマリおよびセカンダリOCSPサーバと呼ばれます。各OCSPサーバ設定には、次のパラメータが含まれます。
CiscoISEがプライマリOCSPサーバと通信しているときに、タイムアウト（5秒）が発生した場合、CiscoISEはセカンダリOCSPサーバに切り替えます。
CiscoISEはプライマリサーバの再使用を試行する前に、設定可能な期間セカンダリOCSPサーバを使用します。
3つの一般的なOCSP障害のシナリオは次のとおりです。
[OCSPクライアントプロファイル（OCSPClientProfile）]ページを使用して、CiscoISEに新しいOCSPクライアントプロファイルを追加できます。
認証局（CA）が非標準ポート（80または443以外）でOCSPサービスを実行している場合は、そのポートでCiscoISEとCA間の通信を可能にするためにスイッチでACLを設定する必要があります。次に例を示します。
permittcp
[管理（Administration）]>[システム（System）]>[証明書（Certificates）]>[証明書管理（CertificateManagement）]>[OCSPクライアントプロファイル（OCSPClientProfile）]を選択します。
OCSPクライアントプロファイルを追加するための値を入力します。
CiscoISEでは、OCSPカウンタを使用して、OCSPサーバのデータと健全性をロギングおよびモニタリングします。ロギングは5分ごとに実行されます。CiscoISEはモニタリングノードにsyslogメッセージを送信し、それはローカルストアに保持されます。ローカルストアには過去5分のデータが含まれています。CiscoISEがsyslogメッセージを送信した後、カウンタは次の間隔について再計算されます。つまり、5分後に、新しい5分間の間隔が再度開始されます。
次の表に、OCSPsyslogメッセージとその説明を示します。
メッセージ
説明
OCSPPrimaryNotResponsiveCount
応答のないプライマリ要求の数
OCSPSecondaryNotResponsiveCount
応答のないセカンダリ要求の数
OCSPPrimaryCertsGoodCount
プライマリOCSPサーバを使用して返された所定のCAの「良好な」証明書の数
OCSPSecondaryCertsGoodCount
プライマリOCSPサーバを使用して返された所定のCAの「良好な」ステータスの数
OCSPPrimaryCertsRevokedCount
プライマリOCSPサーバを使用して返された所定のCAの「失効した」ステータスの数
OCSPSecondaryCertsRevokedCount
セカンダリOCSPサーバを使用して返された所定のCAの「失効した」ステータスの数
OCSPPrimaryCertsUnknownCount
プライマリOCSPサーバを使用して返された所定のCAの「不明の」ステータスの数
OCSPSecondaryCertsUnknownCount
セカンダリOCSPサーバを使用して返された所定のCAの「不明の」ステータスの数
OCSPPrimaryCertsFoundCount
プライマリの送信元からのキャッシュ内に見つかった証明書の数
OCSPSecondaryCertsFoundCount
セカンダリの送信元からのキャッシュ内に見つかった証明書の数