Cisco Identity Services Engine ユーザ ガイド リリース 1.2
証明書の管理
証明書の管理
発行日;2014/01/15 | 英語版ドキュメント(2013/10/25 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 7MB) | フィードバック

目次

証明書の管理

Cisco ISE 証明書を使用した HTTPS 通信

Cisco ISE 証明書を使用した EAP 通信

Cisco ISE がセキュアなアクセスを提供できるようにする証明書

Cisco ISE での PKI の有効化

ローカル証明書

ワイルドカード証明書

HTTPS および EAP 通信でのワイルドカード証明書

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

URL リダイレクションでの完全修飾ドメイン名

ワイルドカード証明書の使用の利点

ワイルドカード証明書の使用の欠点

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

ワイルドカード証明書の作成

Cisco ISE でのワイルドカード証明書のインストール

ワイルドカード証明書の証明書署名要求の作成

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

認証局への CSR の提出

証明書ストアへのルート証明書のインポート

新しい公開証明書での CSR のバインド

CA 署名付き証明書と秘密キーのエクスポート

ポリシー サービス ノードへの CA 署名付き証明書のインポート

Cisco ISE での CA 署名付き証明書のインストール

ローカル証明書の表示

ローカル証明書の追加

ローカル証明書のインポート

自己署名証明書の生成

証明書署名要求の生成

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

ローカル証明書の編集

ローカル証明書のエクスポート

証明書署名要求

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

証明書ストア

X.509 証明書の有効期限

CA 証明書の命名制約

証明書ストア証明書の表示

証明書ストアでの証明書のステータスの変更

証明書ストアへの証明書の追加

証明書ストアの証明書の編集

証明書ストアからの証明書のエクスポート

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

Cisco ISE ノード間通信用の CA 証明書のインストール

セカンダリ ノードからプライマリ ノードの CTL への CA 署名付き証明書のインポート

自己署名証明書のセカンダリ ノードからプライマリ ノードの CTL へのインポート

Simple Certificate Enrollment Protocol プロファイル

Simple Certificate Enrollment Protocol プロファイルの追加

OCSP サービス

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

OCSP のハイ アベイラビリティ

OCSP 障害

OCSP サービスの追加

OCSP 統計情報カウンタ

OCSP のモニタリング

証明書の管理

証明書は、ネットワークでセキュアなアクセスを提供するために使用されます。証明書は、エンドポイントに Cisco ISE であることを識別させ、また、そのエンドポイントと Cisco ISE ノード間でセキュアな通信を確立するために使用されます。証明書は、すべての HTTPS 通信および拡張認証プロトコル(EAP)通信で使用されます。

Cisco ISE 証明書を使用した HTTPS 通信

次のすべての Cisco ISE Web ポータルは、リリース 1.1.0 から HTTPS(TLS 暗号化 HTTP 通信)プロトコルを使用してセキュリティで保護されています。

管理ポータル

中央集中 Web 認証ポータル

スポンサー ポータル

クライアント プロビジョニング ポータル

デバイス ポータル

図 8-1 は、管理ポータルと通信する時の TLS 暗号化プロセスを示します。

図 8-1 HTTPS(TLS 暗号化 HTTP 通信)

 

Cisco ISE 証明書を使用した EAP 通信

証明書はほとんどすべての EAP 方式で使用されます。次の EAP 方式が一般に使用されています。

EAP-TLS

PEAP

EAP-FAST

PEAP や FAST などのトンネル EAP 方式の場合、クレデンシャルの交換をセキュリティ保護するために、Transport Layer Security(TLS)が使用されます。HTTPS Web サイトへの要求と同様に、クライアントはサーバとの接続を確立します。サーバがクライアントに証明書を提示します。クライアントが証明書を信頼する場合、TLS トンネルが形成されます。クライアントのクレデンシャルはトンネルが確立されるまでサーバに送信されないため、セキュアな交換が保証されます。セキュアなアクセス展開において、クライアントはサプリカントであり、サーバは ISE ポリシー サービス ノードです。図 8-2 に、PEAP の使用例を示します。

図 8-2 EAP 通信

 

Cisco ISE がセキュアなアクセスを提供できるようにする証明書

Cisco Identity Services Engine (ISE) は、公開キー インフラストラクチャ (PKI) に依存して、エンドポイントと管理者の両方でのセキュアな通信、およびマルチノード展開での Cisco ISE ノード間のセキュアな通信を提供します。PKI は、X.509 デジタル証明書に依存して、メッセージの暗号化と復号化のために公開キーを転送し、ユーザおよびデバイスを表す他の証明書の信頼性を確認します。Cisco ISE では、X.509 証明書の次の 2 つのカテゴリを管理するために管理者ポータルが用意されています。

ローカル証明書:これらはクライアント アプリケーションに Cisco ISE ノードであることを識別させるサーバ証明書です。すべての Cisco ISE ノードには独自のローカル証明書があり、それぞれ対応する秘密キーとともにノードに格納されています。

証明書ストア証明書:これらは、ユーザとデバイスから受信した公開キーの信頼を確立するために使用される認証局(CA)の証明書です。証明書ストアには、企業ネットワークにモバイル デバイスを登録できるようにする Simple Certificate Enrollment Protocol (SCEP) から配布された証明書も含まれます。証明書ストアの証明書はプライマリ管理ノードで管理され、Cisco ISE 展開内の他のすべてのノードに自動的に複製されます。

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

一般に、Cisco ISE の証明書認証が証明書駆動の検証機能のわずかな違いによって影響されないようにするには、ネットワークに配置されているすべての Cisco ISE ノードに対して小文字のホスト名を使用します。

Cisco ISE での PKI の有効化

Cisco ISE で PKI を次のように有効にする必要があります。


ステップ 1 各展開ノード上で、TLS 対応認証プロトコル(たとえば、EAP-TLS プロトコル)、およびブラウザおよび REST クライアントが Cisco ISE Web ポータルにアクセスするために使用される HTTPS に対してローカル証明書を確立します。

デフォルトでは、Cisco ISE ノードには、両方の目的に使用される自己署名証明書が事前にインストールされています。一般的な企業環境では、この証明書は信頼できる CA によって署名される 1 つまたは 2 つのサーバ証明書に置き換えられます。

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

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


 

関連項目

証明書署名要求を生成し、CA 署名付き証明書をインポートする方法の詳細については、「ローカル証明書」 を参照してください。

これらの証明書チェーンをインポートする方法の詳細については、「証明書ストア」 を参照してください。

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

Cisco ISE 展開を FIPS モードで動作させる場合、すべてのローカル証明書および証明書ストアの証明書が FIPS 準拠であることを確認する必要があります。これは、各証明書の最小キー サイズが 2048 バイトであり、SHA-256 または SHA-1 暗号化を使用する必要があることを意味します。


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


この章は、次の内容で構成されています。

「ローカル証明書」

「証明書署名要求」

「証明書ストア」

「Simple Certificate Enrollment Protocol プロファイル」

「OCSP サービス」

ローカル証明書

Cisco ISE ローカル証明書は、クライアント アプリケーションに Cisco ISE ノードであることを識別させるサーバ証明書です。ローカル証明書は、

Cisco ISE Web ポータルに接続するブラウザおよび REST クライアントによって使用されます。これらの接続には HTTPS プロトコルを使用する必要があります。

PEAP および EAP-FAST で外部 TLS トンネルを形成するために使用されます。これらの証明書は、EAP-TLS、PEAP、および EAP-FAST での相互認証に使用できます。

Cisco ISE 展開内の各ノードに HTTPS および EAP-TLS の有効なローカル証明書をインストールする必要があります。デフォルトでは、インストール時に自己署名証明書が Cisco ISE ノードに作成され、この証明書は HTTPS および EAP-TLS の使用に対して指定されています(キーの長さは 1024 で、1 年間有効です)。セキュリティを強化するために、自己署名証明書を CA 署名付き証明書で置き換えることを推奨します。

ワイルドカード証明書

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

ワイルドカード証明書を設定して *.ise.local を使用する場合、次のような DNS 名が「.ise.local」で終わるすべてのホストをセキュリティで保護するために同じ証明書を使用できます。

aaa.ise.local

psn.ise.local

mydevices.ise.local

sponsor.ise.local

図 8-3 には、Web サイトをセキュリティで保護するために使用されるワイルドカード証明書の例を示します。

図 8-3 ワイルドカードの証明書の例

 

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

関連項目

「HTTPS および EAP 通信でのワイルドカード証明書」

「Cisco ISE 1.2 でのワイルドカード証明書のサポート」

「URL リダイレクションでの完全修飾ドメイン名」

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

「ワイルドカード証明書の作成」

「Cisco ISE でのワイルドカード証明書のインストール」

HTTPS および EAP 通信でのワイルドカード証明書

Cisco ISE で HTTPS(Web ベースのサービス)と、SSL/TLS トンネリングを使用する EAP プロトコルのワイルドカード サーバ証明書を使用できます。ワイルドカード証明書を使用すると、Cisco ISE ノードごとに一意の証明書を生成する必要がなくなります。また、証明書の警告を防止するために複数の FQDN 値を SAN フィールドに入力する必要がなくなります。SAN フィールドにアスタリスク(*)を使用することにより、展開内の複数のノードで単一の証明書の共有を許可することができ、証明書名の不一致の警告を防止するのに役立ちます。ただし、ワイルドカード証明書の使用は、Cisco ISE ノードごとに一意のサーバ証明書を割り当てるよりもセキュリティは低いと見なされています。


) ワイルドカード証明書を使用する場合は、セキュリティを強化するためにドメイン領域を分割することを推奨します。たとえば、*.example.com の代わりに、*.amer.example.com のように分割できます。ドメインを分割しなければ、重大なセキュリティ上の問題につながることがあります。


ワイルドカード証明書は、ドメイン名の前にアスタリスク(*)およびピリオドを使用します。たとえば、証明書のサブジェクト名の CN 値は aaa.ise.local などの一般的なホスト名であり、SAN フィールドには *.ise.local などのワイルドカード文字が含まれます。Cisco ISE では、ワイルドカード文字(*)が提示された識別子の左端の文字になるワイルドカードがサポートされます。たとえば、*.example.com または *.ind.example.com。Cisco ISE では、提示された識別子にワイルドカード文字とともに追加の文字が含まれる証明書はサポートされません。たとえば、abc*.example.com または a*b.example.com または *abc.example.com。

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

Cisco ISE リリース 1.2 では、ワイルドカード証明書がサポートされます。リリース 1.2 の前では、Cisco ISE は CN フィールドがホストの完全修飾ドメイン名(FQDN)に正確に一致するように、HTTPS が有効な証明書を確認します。フィールドが一致しなかった場合、証明書は HTTPS 通信に使用できませんでした。

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

Cisco ISE 1.2 では、CN フィールドに依存しないで、ホスト名を CN として使用します。

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 に置き換えます。non-eth0 インターフェイスの場合、Cisco ISE は URL に IP アドレスを使用します。eth1 から eth3 のインターフェイスにホスト エイリアス(名前)を割り当てることができ、これにより Cisco ISE は URL のリダイレクト中に IP アドレスの代わりにそれで置き換えることができます。これを行うには、Cisco ISE CLI からコンフィギュレーション モードで ip host コマンドを使用できます。

ISE /admin(config)# ip host IP_address host-alias FQDN-string

ここで、 IP_address は、ネットワーク インターフェイス(eth1 か eth2 または eth3)の IP アドレスです

host-alias は、ネットワーク インターフェイスに割り当てる名前です

FQDN-string は、ネットワーク インターフェイスの完全修飾ドメイン名です

このコマンドを使用すると、ネットワーク インターフェイスに host-alias FQDN-string 、またはその両方を割り当てることができます。

次に例を示します。

ISE/admin(config)# ip host a.b.c.d sales sales.amer.xyz.com

non-eth0 インターフェイスにホスト エイリアスを割り当てたら、 application start ise コマンドを使用して Cisco ISE 上のアプリケーション サービスを再起動します。

ネットワーク インターフェイスとホスト エイリアスの関連付けを削除するには、このコマンドの no 形式を使用します。

ISE/admin(config)# no ip-host IP_address host-alias FQDN-string

ホスト エイリアスの定義を表示するには、 show running-config コマンドを使用します。

FQDN-string を指定している場合、Cisco ISE は URL の IP アドレスを FQDN で置き換えられます。ホストのエイリアスのみを指定した場合、Cisco ISE はホスト エイリアスを、設定された IP ドメイン名と組み合わせて完全な FQDN を形成し、URL の IP アドレスを FQDN で置き換えます。ネットワーク インターフェイスをホスト エイリアスにマッピングしなかった場合、Cisco ISE はネットワーク インターフェイスの IP アドレスを URL で使用します。

クライアント プロビジョニング、またはネイティブ サプリカントまたはゲストのフローに non-eth0 インターフェイスを使用する場合、non-eth0 インターフェイスの IP アドレスまたはホスト エイリアスがポリシー サービス ノードの証明書の SAN フィールドに適切に設定されていることを確認する必要があります。

ワイルドカード証明書の使用の利点

コスト節約。サードパーティの認証局によって署名された証明書は、特にサーバ数が増加すると、コストがかかります。ワイルドカード証明書は、Cisco ISE 展開内の複数のノードで使用できます。

運用効率。ワイルドカード証明書では、すべてのポリシー サービス ノード (PSN) EAP および Web サービスが同じ証明書を共有できます。大幅なコスト節約に加えて、証明書を一度作成し、すべての PSN に適用することにより、証明書の管理も簡素化されます。

認証エラーの減少。ワイルドカード証明書は、クライアントがプロファイル内に信頼できる証明書を保存する Apple iOS デバイスで見られる問題に対処し、署名ルートが信頼できる iOS のキーチェーンに従いません。iOS クライアントは最初に PSN と通信するときに、信頼できる認証局が証明書に署名した場合でも、明示的に PSN 証明書を信頼しません。ワイルドカードの証明書を使用すると、証明書がすべての PSN で同じになるで、ユーザは一度だけ証明書を受け入れる必要があり、異なる 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 を含む)が証明書サブジェクトのワイルドカード文字をサポートするわけではありません。

[サブジェクト(Subject)] フィールド フィールドでワイルドカード文字を使用できる Cisco AnyConnect ネットワーク アクセス マネージャ(NAM)など、別のサプリカントを使用できます。

また、証明書のサブジェクト代替名に特定のサブドメインを含めることで、互換性のないデバイスを使用するように設計されている DigiCert の Wildcard Plus のような特殊なワイルドカード証明書を使用できます。

Microsoft サプリカントの制限がワイルドカード証明書の使用を防止する方法のように見えますが、セキュアなアクセスに対してテストされたすべてのデバイス(Microsoft ネイティブ サプリカントを含む)を使用できるようにする、ワイルドカード証明書を作成する別の方法があります。

この方法を行うには、サブジェクトにワイルドカード文字を使用する代わりに、[サブジェクト代替名(Subject Alternative Name)](SAN)フィールドにワイルドカード文字を使用する必要があります。SAN フィールドでは、ドメイン名(DNS 名)を確認するように設計された拡張機能が維持されます。詳細については、RFC 6125 および 2128 を参照してください。

ワイルドカード証明書の Microsoft サポートの詳細については、 http://technet.microsoft.com/en-US/cc730460 を参照してください。

ワイルドカード証明書の作成

ここでは、ワイルドカードの証明書を作成する方法について説明します。この手順は、ほとんどの SSL 証明書プロバイダーで機能します。

ただし、使用している SSL 証明書プロバイダーが証明書の SAN フィールドでのワイルドカード値をサポートしていない場合、各 ISE ノードおよびインターフェイスの FQDN を証明書 SAN に入力する必要があります(ip host コマンドを使用して指定されたエイリアスごとに)。この証明書は、複数ドメイン証明書と呼ばれます。デバイス ポータルおよびスポンサー ポータルに使用されるような特定のサービスのエイリアスの FQDN も、証明書 SAN に含める必要があります。ISE 管理者ポータル、スポンサー ポータル、およびデバイス ポータルへのローカル Web 認証などのいくつかのサービスは、ロード バランサを使用できます。このような場合、ロード バランシングが行われているサービスの仮想 IP アドレスに割り当てられた FQDN を証明書の SAN フィールドに含める必要があります。


) HTTPS 認証用と EAP 認証用とで別々の証明書にすることも可能です。HTTPS に対して指定された証明書は、ノード間通信、および、中央集中 Web 認証、DRW、ポスチャの検出と評価、モバイル デバイス管理、ネイティブ サプリカント プロビジョニング、スポンサー、およびデバイス ポータルを含むすべての Web ポータル サービスをセキュリティで保護するために使用されます。EAP に対して指定された証明書は、PEAP、EAP-FAST、および EAP-TLS など、EAP プロトコルを使用してすべてのクライアント認証をセキュリティで保護するために使用されます。


たとえば、2 つの PSN ノード(eth0、eth1、および eth2 インターフェイスが有効な psn1 および psn2)を持つ ISE 展開があり、ワイルドカードなしで複数ドメインの証明書を作成する場合、値は次のとおりです。

CN=aaa.company.local(展開内の ISE ノードの FQDN)

SAN=DNS.1=aaa.company.local, DNS.2=psn1.company.local, DNS.3=psn2.company.local, DNS.4=psn1-e1.company.local, DNS.5=psn2-e1.company.local, DNS.6=psn1-e2.company.local, DNS.7=psn2-e2.company.local.


ヒント 今後追加のポリシー サービス ノードの導入を予定する場合は、新しいノードの導入時に同じ証明書を再利用できるように SAN フィールドに追加の DNS 名のエントリを追加できます。

IP アドレスを証明書の SAN フィールドに指定する必要がある場合(たとえば、URL リダイレクションの固定 IP アドレスを持つ DMZ)、証明書の SAN フィールドにポリシー サービス ノードの IP アドレスを DNS 名と IP アドレスとして指定していることを確認します。たとえば、CN=psn.ise.local および SAN=DNS.1=psn.ise.local、DNS.2=*.ise.local、DNS.3=10.1.1.20、IP.1=10.1.1.20。

はじめる前に

Microsoft のネイティブ サプリカントの場合、証明書の SAN フィールドにワイルドカードを使用します。


ステップ 1 サブジェクトの CN フィールドに汎用ホスト名を入力します。たとえば、CN=aaa.ise.local。

ステップ 2 証明書の SAN フィールドに同じ汎用ホスト名とワイルドカード表記を入力します。たとえば、DNS Name=aaa.ise.local、DNS Name=*.ise.local。 図 8-3 を参照してください。

この方法は、Comodo.com や SSL.com などのテスト済み商用 CA の大部分で成功します。これらの商用 CA では、「ユニファイド コミュニケーション証明書(UCC)」を要求する必要があります。


 

次の作業

ワイルドカード証明書をポリシー サービス ノードにインポートします。

関連項目

「Cisco ISE でのワイルドカード証明書のインストール」

Cisco ISE でのワイルドカード証明書のインストール

はじめる前に

non-eth0 インターフェイスを有効にしている場合は、CLI で ip host コマンドを使用して、インターフェイスにホスト エイリアスをマップしていることを確認します。詳細については、 URL リダイレクションでの完全修飾ドメイン名を参照してください。

ワイルドカード証明書をインストールするには、次のタスクを実行する必要があります。


ステップ 1 ワイルドカード証明書の証明書署名要求を作成します。 「ワイルドカード証明書の証明書署名要求の作成」 を参照してください。

ステップ 2 証明書署名要求をエクスポートします。 「証明書署名要求のエクスポート」 を参照してください。

ステップ 3 証明書署名要求を認証局に送信します。 「認証局への CSR の提出」 を参照してください。

ステップ 4 証明書ストアにルート証明書をインポートします。 「証明書ストアへのルート証明書のインポート」 を参照してください。

ステップ 5 新しい公開証明書を使用して証明書署名要求をバインドします。 「新しい公開証明書での CSR のバインド」 を参照してください。

ステップ 6 CA 署名付き証明書と秘密キーをエクスポートします。 「CA 署名付き証明書と秘密キーのエクスポート」 を参照してください。

ステップ 7 すべてのポリシー サービス ノードに CA 署名付き証明書と秘密キーをインポートします。 「ポリシー サービス ノードへの CA 署名付き証明書のインポート」 を参照してください。


 

ワイルドカード証明書の証明書署名要求の作成


ステップ 1 [管理(Administration)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

ステップ 2 [追加(Add)] > [証明書署名要求の生成(Generate Certificate Signing Request)] をクリックします。

ステップ 3 証明書サブジェクトで、ポリシー サービス ノードのいずれかの一般的な FQDN を入力します。たとえば、CN=psn.ise.local。

ステップ 4 SAN に 2 つの値を入力します。値の 1 つは、証明書サブジェクトに入力した CN と同じである必要があります。もう一方の値は、ワイルドカード表記です。たとえば、DNS name=psn.ise.local、DNS name=*.ise.local。

ステップ 5 [ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。

図 8-4 ワイルドカード表記を使用した証明書署名要求

 

ステップ 6 [送信(Submit)] をクリックします。


 

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


ステップ 1 [管理(Administration)] > [証明書(Certificates)] > [証明書署名要求(Certificate Signing Requests)] をクリックします。

ステップ 2 作成した CSR の隣にあるチェックボックスをオンにします。たとえば、psn.ise.local。

ステップ 3 [エクスポート(Export)] をクリックします。

ステップ 4 ローカル システムに CSR を保存します。


 

認証局への CSR の提出


ステップ 1 メモ帳などのテキスト エディタで CSR を開きます。

ステップ 2 "-----BEGIN CERTIFICATE REQUEST-----" から "-----END CERTIFICATE REQUEST-----" までのすべてのテキストをコピーします。

ステップ 3 選択した CA の証明書要求に CSR の内容を貼り付けます。 図 8-5 を参照してください。

図 8-5 証明書要求フォームでの CSR の内容 - Active Directory CA

 

ステップ 4 署名済みの証明書をダウンロードします。

CA の中には、署名済みの証明書を電子メールで送信するものがあります。署名済みの証明書は、新しく発行された証明書と CA の公開署名証明書を含む zip ファイルの形式です。Cisco ISE の信頼できる証明書ストアにそれらを追加する必要があります。 図 8-6 を参照してください。

図 8-6 CA によって返される証明書

 


 

証明書ストアへのルート証明書のインポート

はじめる前に

Cisco ISE 上で新しい署名済みの証明書を CSR にバインドする前に、署名ルート証明書が Cisco ISE 証明書ストアにあることを確認します。


ステップ 1 [管理(Administration)] > [証明書(Certificates)] > [証明書ストア(Certificate Store)] を選択します。

ステップ 2 [インポート(Import)] をクリックします。

ステップ 3 その CA によって返されたルート証明書を選択します。


 

新しい公開証明書での CSR のバインド


ステップ 1 [管理(Administration)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

ステップ 2 [追加(Add)] > [CA 署名付き証明書のバインド(Bind CA Signed Certificate)] をクリックします。

ステップ 3 CA 署名付き証明書を選択します。

ステップ 4 [ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。

ステップ 5 プロトコルを選択します。

ステップ 6 [送信(Submit)] をクリックします。


 

CA 署名付き証明書と秘密キーのエクスポート


ステップ 1 [管理(Administration)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

ステップ 2 CA 署名付き証明書の隣にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。

ステップ 3 ファイルをローカル システムに保存します。


 

ポリシー サービス ノードへの CA 署名付き証明書のインポート


ステップ 1 [管理(Administration)] > [証明書(Certificates)] > [証明書ストア(Certificate Store)] を選択します。

ステップ 2 エクスポートした CA 署名付き証明書を選択します。

ステップ 3 [送信(Submit)] をクリックします。


 

Cisco ISE での CA 署名付き証明書のインストール

CA 署名付き証明書をインストールする手順は次のとおりです。


ステップ 1 CA 署名付き証明書を必要とするノードの Cisco ISE 管理インターフェイスで、証明書署名要求(CSR)を生成します。

ステップ 2 ファイルに CSR をエクスポートします。

ステップ 3 CSR ファイルを認証局に提供し、CSR で指定された属性を使用して証明書を作成し、署名するように CA に要求します。CA は、証明書をファイルで返す必要があります。

ステップ 4 同じノードの Cisco ISE 管理インターフェイスで、CA 署名付き証明書を、ノード上で CSR と一緒に保持されている秘密キーにバインドします。HTTPS、EAP-TLS、またはその両方での使用として証明書を指定します。


 


) HTTPS で CA 署名付き証明書を使用する場合、CSR に指定されたサブジェクトの一般名が Cisco ISE ノードの完全修飾ドメイン名(FQDN)に一致するか、または証明書の SAN/CN フィールドに指定されているワイルドカードのドメイン名に一致する必要があります。


Cisco ISE は、一致するサブジェクト名を次のようにチェックします。

1. Cisco ISE は、証明書の Subject Alternative Name(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 証明書は、特定の日付までのみ有効です。ローカル証明書が期限切れになったときは、証明書に依存する Cisco ISE 機能が影響を受けます。Cisco ISE は、有効期限が 90 日以内になったときに、ローカル証明書の期限切れが迫っていることを通知します。この通知はいくつかの方法で表示されます。

色付きの有効期限ステータス アイコンが [ローカル証明書(Local Certificates)] ページに表示されます。

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

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

期限切れになる証明書が自己署名証明書である場合、証明書を編集して有効期限を延長できます。CA 署名付き証明書の場合、CA から代わりの証明書を取得するのに十分時間をかける必要があります。

ローカル証明書を管理するために、Cisco ISE 管理インターフェイスから次のタスクを実行できます。

Cisco ISE ノードに保存されたローカル証明書のリストを参照します。リストには、有効期限ステータスとともに各証明書のプロトコル割り当て(HTTPS、EAP-TLS)が表示されます。

CSR の作成

CSR のエクスポート

CA 署名付き証明書のその秘密キーとのバインド

ローカル証明書と、任意で、秘密キーのエクスポート

ローカル証明書と秘密キーのインポート

自己署名ローカル証明書の生成

ローカル証明書の編集(証明書が自己署名の場合の有効期限の延長を含む)

ローカル証明書の削除

CSR の削除

この項では、次のトピックを扱います。

「ローカル証明書の表示」

「ローカル証明書の追加」

「ローカル証明書の編集」

「ローカル証明書のエクスポート」

関連項目

「ワイルドカード証明書」

「URL リダイレクションでの完全修飾ドメイン名」

「ローカル証明書のインポート」

「証明書署名要求の生成」

「CA 署名付き証明書のバインド」

ローカル証明書の表示

[ローカル証明書(Local Certificate)] ページに、Cisco ISE に追加されたすべてのローカル証明書が一覧表示されます。

はじめる前に

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


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

[ローカル証明書(Local Certificate)] ページが表示され、ローカル証明書に関する次の情報が表示されます。

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

[プロトコル(Protocol)]:証明書を使用するプロトコル。

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

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

[有効期限の開始(Valid From)]:証明書が作成された日付で、Not Before 証明書属性とも呼ばれています。

[有効期限(Expiration Data)]:証明書の有効期限で、Not After 証明書属性とも呼ばれています。

有効期限ステータス:証明書の有効期限が切れる時間を示します。アイコンと関連付けられている 5 つのカテゴリがあり、次のように表示されます。

1. 90 日を超えると期限切れ(緑色のアイコン)

2. 90 日以内で期限切れ(青色のアイコン)

3. 60 日以内で期限切れ(黄色のアイコン)

4. 30 日以内で期限切れ(オレンジ色のアイコン)

5. 有効期限切れ(赤色のアイコン)


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ワイルドカード証明書」

ローカル証明書の追加

次のいずれかの方法でローカル証明書を Cisco ISE に追加できます。

「ローカル証明書のインポート」

「自己署名証明書の生成」

「証明書署名要求の生成」および「CA 署名付き証明書のバインド」

ワイルドカード証明書をインポートする場合は、次の項を読んでおく必要があります。

「ワイルドカード証明書」

「ワイルドカード証明書の作成」

「Cisco ISE でのワイルドカード証明書のインストール」


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


ローカル証明書のインポート

ローカル証明書をインポートして新しいローカル証明書を追加できます。

はじめる前に

クライアント ブラウザを実行しているシステム上にローカル証明書および秘密キーのファイルがあることを確認します。

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

インポートするローカル証明書に基本制約拡張が含まれていて CA フラグが true に設定されている場合は、キー使用拡張が存在することと、keyEncipherment ビットと keyAgreement ビットの一方または両方が設定されていることを確認してください。


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

ローカル証明書をセカンダリ ノードにインポートするには、[管理(Administration)] > [システム(System)] > [サーバ証明書(Server Certificate)] を選択します。

ステップ 2 [追加(Add)] > [ローカル サーバ証明書のインポート(Import Local Server Certificate)] を選択します。

ステップ 3 [参照(Browse)] をクリックして、クライアント ブラウザを実行しているシステムから証明書ファイルと秘密キーを選択します。

秘密キーが暗号化されている場合は、[パスワード(Password)] に入力して復号化します。

ステップ 4 証明書のフレンドリ名を入力します。名前を指定しない場合は、 <common name> # <issuer> # <nnnnn> という形式の名前が自動的に作成されます。 <nnnnn> は一意の 5 桁の番号です。

ステップ 5 Cisco ISE に証明書拡張を検証させる場合は、[証明書拡張の検証の有効化(Enable Validation of Certificate Extensions)] チェックボックスをオンにします。

[証明書拡張の検証の有効化(Enable Validation of Certificate Extensions)] チェックボックスをオンにし、インポートしているローカル証明書に基本制約拡張が含まれていて CA フラグが true に設定されている場合は、キー使用拡張が存在することと、keyEncipherment ビットと keyAgreement ビットの一方または両方も設定されていることを確認してください。

ステップ 6 ワイルドカード証明書(サブジェクトの一般名、サブジェクト代替名の DNS 名、またはその両方にアスタリスク(*)を含む証明書)をインポートする場合は、[ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。

ステップ 7 [プロトコル(Protocol)] グループ ボックスで次のとおりに操作します。

EAP プロトコルでこの証明書を使用して Cisco ISE ノードを識別するには、[EAP] チェックボックスをオンにします。

この証明書を Web サーバの認証に使用するには、[HTTPS] チェックボックスをオンにします。

[管理インターフェイス(Management Interface)] チェックボックスをオンにする場合は、証明書サブジェクトの一般名の値がノードの完全修飾ドメイン名(FQDN)またはワイルドカード表記(ワイルドカード証明書を使用する場合)に一致することを確認してください。完全修飾ドメイン名でない場合、インポート プロセスは失敗します。

ステップ 8 [証明書の置き換え(Replace Certificate)] チェックボックスは、既存の証明書を複製の証明書で置き換える場合にオンにします。証明書が複製であると見なされるのは、既存の証明書とサブジェクトまたは発行者が同一であり、シリアル番号も同一である場合です。このオプションを選択すると、証明書の内容が更新されますが、その証明書に対する既存のプロトコル選択は維持されます。


) Cisco ISE が FIPS モードで動作するように設定されている場合は、証明書の RSA キー サイズは 2048 ビット以上にする必要があり、SHA-1 または SHA-256 ハッシュ アルゴリズムを使用します。


ステップ 9 [送信(Submit)] をクリックしてローカル証明書をインポートします。

プライマリ Cisco ISE ノードにローカル証明書をインポートし、展開内のそのノードで管理インターフェイス オプションが有効になっている場合は、そのノード上のアプリケーション サーバが自動的に再起動されます。それ以外の場合は、プライマリ Cisco ISE ノードに接続されているセカンダリ ノードを再起動する必要があります。

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

a. application stop ise

b. application start ise

これらのコマンドの詳細については、『 Cisco Identity Services Engine CLI Reference Guide, Release 1.2 』を参照してください。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ワイルドカード証明書」

「ワイルドカード証明書の作成」

「Cisco ISE でのワイルドカード証明書のインストール」

自己署名証明書の生成

自己署名証明書を生成して新しいローカル証明書を追加できます。シスコは、内部テストと評価のニーズに対してのみ自己署名証明書を使用することを推奨します。実稼働環境に Cisco ISE の導入を予定している場合は、実稼働ネットワーク内でより均一な受け入れを保証するために、可能な場合は CA 署名付き証明書を使用してください。

はじめる前に

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


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

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

ステップ 2 [追加(Add)] > [自己署名証明書の生成(Generate Self Signed Certificate)] を選択します。

ステップ 3 [自己署名証明書の生成(Generate Self Signed Certificate)] ページで次の情報を入力します。

[証明書サブジェクト(Certificate Subject)]:証明書に関連付けられているエンティティを識別する識別名(DN)。 DN には一般名(CN)値が含まれている必要があります。

[サブジェクト代替名(Subject Alternative Name)]:証明書に関連付けられた IP アドレスまたは DNS 名。

必要な [キーの長さ(Key Length)]:有効な値は 512、1024、2048、および 4096 です。Cisco ISE を FIPS 準拠のポリシー管理エンジンとして展開する場合は、2048 ビット以上のキーの長さを指定する必要があります。

[署名するダイジェスト(Digest to Sign With)]:SHA-1 または SHA-256 を使用して証明書を暗号化および復号化できます。

証明書の 有効期限 TTL 。有効期限期間を日、週、月、年で指定できます。

証明書のフレンドリ名を指定する場合は、秘密キー パスワードの下の [フレンドリ名(Friendly Name)] フィールドに入力します。名前を指定しない場合は、 <common name> # <issuer> # <nnnnn> という形式の名前が自動的に作成されます。 <nnnnn> は一意の 5 桁の番号です。

ステップ 4 自己署名ワイルドカード証明書(サブジェクトの一般名、サブジェクト代替名の DNS 名、またはその両方にアスタリスク(*)を含む証明書)を生成する場合は、[ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。たとえば、*.amer.cisco.com のような DNS 名が SAN に割り当てられます。

ステップ 5 [プロトコル(Protocol)] グループ ボックスで次のとおりに操作します。

SSL/TLS トンネリングを使用する EAP プロトコルでこの証明書を使用するには、[EAP] チェックボックスをオンにします。

この証明書を Cisco ISE ポータルの認証に使用するには、[HTTPS] チェックボックスをオンにします。

[管理インターフェイス(Management Interface)] チェックボックスをオンにする場合は、証明書サブジェクトの一般名の値がノードの完全修飾ドメイン名(FQDN)に一致することを確認してください。そうでない場合、自己署名証明書は生成されません。

ステップ 6 [オーバーライド ポリシー(Override Policy)] 領域の [証明書の置き換え(Replace Certificate)] チェックボックスは、既存の証明書を複製の証明書で置き換える場合にオンにします。証明書が複製であると見なされるのは、既存の証明書とサブジェクトまたは発行者が同一であり、シリアル番号も同一である場合です。このオプションを選択すると、証明書の内容が更新されますが、その証明書に対する既存のプロトコル選択は維持されます。

ステップ 7 [送信(Submit)] をクリックして証明書を生成します。

[HTTPS] チェックボックスがチェックされている場合、Cisco ISE ノード上のアプリケーション サーバが再起動されます。さらに、Cisco ISE ノードが展開内のプライマリ管理ノードの場合、展開内の他のすべてのノード上のアプリケーション サーバも再起動されます。プライマリ管理ノードの再起動が完了したら、それらは一度に 1 つのノードを再起動します。

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

a. application stop ise

b. application start ise

これらのコマンドの詳細については、『 Cisco Identity Services Engine CLI Reference Guide, Release 1.1.1 』を参照してください。


 


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


関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ワイルドカード証明書」

「Cisco ISE でのワイルドカード証明書のインストール」

証明書署名要求の生成

証明書署名要求を生成し、CA 署名付き証明書をバインドすることによって、新しいローカル証明書を追加できます。

はじめる前に

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


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

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

ステップ 2 [追加(Add)] > [証明書署名要求の生成(Generate Certificate Signing Request)] を選択します。

ステップ 3 証明書サブジェクトおよび必要なキーの長さを入力します。証明書サブジェクトは、証明書に関連付けられているエンティティを識別する識別名(DN)です。DN には一般名の値が含まれている必要があります。識別名の要素は次のとおりです。

C = 国

ST = テスト州または都道府県

L = テスト地名(都市)

O = 組織名

OU = 組織ユニット名

CN = 一般名

E = 電子メール アドレス

たとえば、CSR の証明書サブジェクトは次の値を指定できます。"CN=Host-ISE.cisco.com, OU=Cisco, O=security, C=US, ST=NC, L=RTP, e=test@test.com" または "CN=aaa.amer.cisco.com, DNS name in SAN=*.amer.cisco.com, OU=Cisco, O=security, C=US, ST=NC, L=RTP, e=abc@xyz.com"。


) [証明書サブジェクト(Certificate Subject)] フィールドに入力するときは、文字列を引用符でカプセル化しないでください。


この CSR から生成された証明書を HTTPS 通信に使用する場合は、証明書サブジェクトの一般名の値がノードの FQDN であることを確認してください。そうでない場合は、生成された証明書をバインドするときに [管理インターフェイス(Management Interface)] を選択できません。

ステップ 4 [サブジェクト代替名(Subject Alternative Name)]:証明書に関連付けられた IP アドレスまたは DNS 名。

ステップ 5 SHA-1 または SHA-256 を使用して証明書を暗号化および復号化することを選択します。


) Cisco ISE が FIPS モードで動作するように設定されている場合は、証明書の RSA キー サイズは 2048 ビット以上にする必要があり、SHA-1 または SHA-256 ハッシュ アルゴリズムを使用します。


ステップ 6 証明書サブジェクトにワイルドカード FQDN が指定された CN または SAN が含まれる場合は、[ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。

ステップ 7 [送信(Submit)] をクリックして CSR を生成します。

CSR および秘密キーが生成され、Cisco ISE に保存されます。この CSR は、[証明書署名要求(Certificate Signing Requests)] ページで表示できます。CSR をエクスポートし、CA に送信して署名を取得できます。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ワイルドカード証明書」

「ワイルドカード証明書の証明書署名要求の作成」

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

証明書署名要求が認証局によって署名され、返された後、Cisco ISE にローカル証明書を追加するプロセスを完了するために、CA 署名付き証明書を秘密キーにバインドする必要があります。

はじめる前に

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


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

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

ステップ 2 [追加(Add)] > [CA 証明書のバインド(Bind CA Certificate)] を選択します。

ステップ 3 [参照(Browse)] をクリックし、適切な CA 署名付き証明書を選択します。

ステップ 4 証明書の フレンドリ名 を指定します。名前を指定しない場合は、 <common name> # <issuer> # <nnnnn> という形式の名前が自動的に作成されます。 <nnnnn> は一意の 5 桁の番号です。

ステップ 5 Cisco ISE に証明書拡張を検証させる場合は、[証明書拡張の検証の有効化(Enable Validation of Certificate Extensions)] チェックボックスをオンにします。


) [証明書拡張の検証の有効化(Enable Validation of Certificate Extensions)] オプションを有効にし、インポートしているローカル証明書に基本制約拡張が含まれていて CA フラグが true に設定されている場合は、キー使用拡張が存在することと、keyEncipherment ビットと keyAgreement ビットの一方または両方も設定されていることを確認してください。


ステップ 6 サブジェクトの CN またはサブジェクト代替名の DNS 名にワイルドカード文字のアスタリスク(*)を含む証明書をバインドするには、[ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。

ステップ 7 [プロトコル(Protocol)] グループ ボックスで次のとおりに操作します。

SSL/TLS トンネリングを使用する EAP プロトコルでこの証明書を使用するには、[EAP] チェックボックスをオンにします。

この証明書を Cisco ISE Web ポータルの認証に使用するには、[HTTPS] チェックボックスをオンにします。


) [管理インターフェイス(Management Interface)] チェックボックスをオンにする場合は、証明書サブジェクトの一般名の値がノードの完全修飾ドメイン名(FQDN)またはワイルドカード表記(ワイルドカード証明書を使用する場合)に一致することを確認してください。完全修飾ドメイン名でない場合、バインド操作は失敗します。


ステップ 8 [証明書の置き換え(Replace Certificate)] チェックボックスは、既存の証明書を複製の証明書で置き換える場合にオンにします。証明書が複製であると見なされるのは、既存の証明書とサブジェクトまたは発行者が同一であり、シリアル番号も同一である場合です。このオプションを選択すると、証明書の内容が更新されますが、その証明書に対する既存のプロトコル選択は維持されます。

ステップ 9 [送信(Submit)] をクリックし、CA 署名付き証明書をバインドします。

[HTTPS] チェックボックスがチェックされている場合、Cisco ISE ノード上のアプリケーション サーバが再起動されます。さらに、Cisco ISE ノードが展開内のプライマリ管理ノードの場合、展開内の他のすべてのノード上のアプリケーション サーバも再起動されます。プライマリ管理ノードの再起動が完了したら、それらは一度に 1 つのノードを再起動します。

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

a. application stop ise

b. application start ise

これらのコマンドの詳細については、『 Cisco Identity Services Engine CLI Reference Guide, Release 1.1.1 』を参照してください。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ワイルドカード証明書」

「Cisco ISE でのワイルドカード証明書のインストール」

ローカル証明書の編集

ローカル証明書を編集するには、このページを使用できます。

はじめる前に

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


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

ローカル証明書をセカンダリ ノードで編集するには、[管理(Administration)] > [システム(System)] > [サーバ証明書(Server Certificate)] を選択します。

ステップ 2 編集する証明書の隣のチェックボックスをオンにして、[編集(Edit)] をクリックします。

ステップ 3 次の情報を編集できます。

フレンドリ名(Friendly Name)

説明(Description)

プロトコル(Protocols)

有効期限 TTL(Expiration TTL)(証明書が自己署名の場合)

ステップ 4 この証明書を識別するために、任意でフレンドリ名と説明を入力します。

ステップ 5 [プロトコル(Protocol)] グループ ボックスで次のとおりに操作します。

SSL/TLS トンネリングを使用する EAP プロトコルでこの証明書を使用するには、[EAP] チェックボックスをオンにします。

この証明書を Cisco ISE Web ポータルの認証に使用するには、[HTTPS] チェックボックスをオンにします。


) [管理インターフェイス(Management Interface)] チェックボックスをオンにする場合は、証明書サブジェクトの一般名の値がノードの完全修飾ドメイン名(FQDN)またはワイルドカード表記(ワイルドカード証明書を使用する場合)に一致することを確認してください。一般名の値がブランクの場合、編集操作は失敗します。
たとえば、現在 local_certificate_1 が EAP に対して指定されており、local_certificate_2 の編集時に [EAP] チェックボックスをオンにした場合、local_certificate_2 への変更を保存した後は、local_certificate_1 の EAP への関連付けは解除されています。


ステップ 6 自己署名証明書を編集していて、有効期限を延長する場合は、[自己署名証明書の更新(Renew Self Signed Certificate)] チェックボックスをオンにします。

ステップ 7 有効期限 TTL(存続可能時間)を日、週、月、年で入力します。

ステップ 8 [保存(Save)] をクリックして変更を保存します。

[HTTPS] チェックボックスがチェックされている場合、Cisco ISE ノード上のアプリケーション サーバが再起動されます。さらに、Cisco ISE ノードが展開内のプライマリ管理ノードの場合、展開内の他のすべてのノード上のアプリケーション サーバも再起動されます。プライマリ管理ノードの再起動が完了したら、それらは一度に 1 つのノードを再起動します。

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

a. application stop ise

b. application start ise

これらのコマンドの詳細については、『 Cisco Identity Services Engine CLI Reference Guide, Release 1.2 』を参照してください。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ワイルドカード証明書」

「ワイルドカード証明書の作成」

「Cisco ISE でのワイルドカード証明書のインストール」

ローカル証明書のエクスポート

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

はじめる前に

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


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [ローカル証明書(Local Certificates)] を選択します。

ローカル証明書をセカンダリ ノードからエクスポートするには、[管理(Administration)] > [システム(System)] > [サーバ証明書(Server Certificate)] を選択します。

ステップ 2 エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。

ステップ 3 証明書のみをエクスポートするか、または証明書とそれに関連付けられた秘密キーをエクスポートするかを選択できます。


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

ステップ 4 エクスポートする証明書コンポーネントを選択します。

ステップ 5 秘密キーをエクスポートする場合は、パスワードを入力します。パスワードは、8 文字以上にする必要があります。

ステップ 6 [OK] をクリックして、クライアント ブラウザを実行しているファイル システムに証明書を保存します。

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


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ローカル証明書のインポート」

証明書署名要求

作成した証明書署名要求(CSR)のリストは、[証明書署名要求(Certificate Signing Requests)] ページで使用できます。CA から署名を取得するには、クライアント ブラウザを実行しているローカル ファイル システムに CSR をエクスポートする必要があります。その後 CA に証明書を送信します。証明書は CA によって署名され、返されます。


) Cisco ISE 展開で分散セットアップに複数のノードがある場合は、展開内の各ノードから CSR を個別にエクスポートする必要があります。


関連項目

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

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

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

はじめる前に

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


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

セカンダリ ノードから CSRs をエクスポートするには、[管理(Administration)] > [システム(System)] > [証明書署名要求(Certificate Signing Requests)] を選択します。

ステップ 2 エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。

ステップ 3 [OK] をクリックして、クライアント ブラウザを実行しているファイル システムにファイルを保存します。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ワイルドカード証明書」

証明書ストア

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

Cisco ISE では、ワイルドカード証明書がサポートされます。

Cisco ISE は、次の目的で証明書ストアの証明書を使用します。

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

展開内の Cisco ISE ノード間のセキュアな通信を可能にするため。証明書ストアは、展開内の各ノード上のローカル HTTPS サーバ証明書で信頼を確立するために必要な CA 証明書のチェーンを含む必要があります。

自己署名証明書がサーバ証明書として使用される場合は、各ノードからの自己署名証明書をプライマリ管理ノードの証明書ストアに配置する必要があります。

CA 署名付き証明書がサーバ証明書として使用される場合は、信頼チェーン内のすべての中間証明書のほか、CA ルート証明書をプライマリ管理ノードの証明書ストアに配置する必要があります。

セキュアな LDAP 認証を可能にするため。SSL を介してアクセスされる LDAP ID ソースを定義するときに、証明書ストアから証明書を選択する必要があります。

デバイス ポータルを使用してネットワークに登録する準備をしているモバイル デバイスへの配布のため。Cisco ISE は、モバイル デバイス登録をサポートするために、ポリシー サービス ノード(PSN)上に SCEP を実装します。登録するデバイスは、SCEP プロトコルを使用して PSN からクライアント証明書を要求します。PSN には仲介役として機能する登録局(RA)があり、登録するデバイスからの要求を受信および検証し、その後、クライアントの証明書を実際に発行する CA に要求を転送します。CA は RA に証明書を送り返し、RA はそれをデバイスに返します。

Cisco ISE によって使用される各 SCEP CA は、SCEP RA プロファイルで定義されます。SCEP RA プロファイルを作成すると、次の 2 つの証明書が自動的に証明書ストアに追加されます。

a. CA 証明書(自己署名証明書)

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

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


) Cisco ISE にインポートされる X.509 証明書は、Privacy Enhanced Mail(PEM)または Distinguished Encoding Rules(DER)形式にする必要があります。 証明書チェーン(ローカル証明書および、それに署名した一連の信頼証明書)を含むファイルは、特定の制限に従ってインポートできます。


関連項目

「管理者アカウントのパスワード ポリシーの設定」

「LDAP ID ソースの追加」

「Simple Certificate Enrollment Protocol プロファイル」

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

「X.509 証明書の有効期限」

「CA 証明書の命名制約」

「証明書ストア証明書の表示」

「証明書ストアでの証明書のステータスの変更」

「証明書ストアへの証明書の追加」

「証明書ストアの証明書の編集」

「証明書ストアからの証明書のエクスポート」

X.509 証明書の有効期限

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

色付きの有効期限ステータス アイコンが [証明書ストア(Certificate Store)] ページに表示されます。

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

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

証明書ストアには、次の 2 つのシスコ CA 証明書が事前に追加されています。製造業者証明書とルート証明書。ルート証明書は製造業者証明書に署名します。これらの証明書は、デフォルトでは無効になっています。展開内にエンドポイントとして Cisco IP フォンがある場合は、電話機のシスコ署名付きクライアント証明書を認証できるように、これら 2 つの証明書を有効にする必要があります。

この項では、次のトピックを扱います。

「証明書ストア証明書の表示」

「証明書ストアへの証明書の追加」

「証明書ストアの証明書の編集」

「証明書ストアからの証明書のエクスポート」

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

「Cisco ISE ノード間通信用の CA 証明書のインストール」

CA 証明書の命名制約

CTL の CA 証明書に、命名制約の拡張が含まれる場合があります。この拡張は、証明書チェーン内の後続の証明書のサブジェクト名とサブジェクト代替名のすべてのフィールドの値のネームスペースを定義します。Cisco ISE は、ルート証明書で指定された制約をチェックしません。

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

ディレクトリ名

ディレクトリ名の制約は、subject/SAN 内のディレクトリ名のプレフィックスにしてください。次に例を示します。

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

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

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

誤ったサブジェクト プレフィックス:

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

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

DNS

電子メール

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

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

IP アドレス

その他の名前

CA 証明書にサポートされていない制約が含まれていて、検証中の証明書に適切なフィールドが含まれていない場合は、Cisco ISE はサポートされない制約を検証できないため、拒否されます。

次に、CA 証明書内の名前制約の定義の例を示します。

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

証明書ストア証明書の表示

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

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

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「証明書ストア ページ」

証明書ストアでの証明書のステータスの変更

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


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

ステップ 2 有効または無効にする証明書の隣にあるチェックボックスをオンにして、[ステータスの変更(Change Status)] をクリックします。


 

証明書ストアへの証明書の追加

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

はじめる前に

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

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


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

ステップ 2 [インポート(Import)] をクリックします。

ステップ 3 必要に応じてフィールド値を設定します。

クライアント証明書ベースの認証が有効のときは、Cisco ISE によって、展開内の各ノード上のアプリケーション サーバが再起動されます。このときに、プライマリ管理ノード上のアプリケーション サーバが最初に起動され、その後で他のノードのアプリケーション サーバが 1 つずつ順に起動されます。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「証明書ストア インポートの設定」

証明書ストアの証明書の編集

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

はじめる前に

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


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

ステップ 2 編集する証明書の隣のチェックボックスをオンにして、[編集(Edit)] をクリックします。

ステップ 3 必要に応じて編集可能フィールドを変更します。

ステップ 4 [保存(Save)] をクリックして、証明書ストアに対する変更を保存します。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「証明書ストア編集の設定」

証明書ストアからの証明書のエクスポート

はじめる前に

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


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

ステップ 2 エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。一度に 1 つの証明書のみをエクスポートできます。

ステップ 3 クライアント ブラウザを実行しているファイル システムに Privacy Enhanced Mail ファイルを保存します。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

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

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

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

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

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


ステップ 1 証明書ストアへの証明書の追加操作を使用して、証明書チェーン ファイルを証明書ストアにインポートします。この操作により、ファイルから最後の証明書を除くすべての証明書が証明書ストアにインポートされます。プライマリ管理ノードでのみこのステップを実行できます。

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


 

Cisco ISE ノード間通信用の CA 証明書のインストール

分散展開では、セカンダリ ノードを登録する前に、セカンダリ ノードの HTTPS 証明書を検証するために使用する適切な CA 証明書をプライマリ ノードの CTL に入力する必要があります。プライマリ ノードの CTL に入力する手順は、シナリオに応じて異なります。

セカンダリ ノードで HTTPS 通信に CA 署名付き証明書が使用されている場合は、セカンダリ ノードの CA 署名付き証明書をプライマリ ノードの CTL にインポートする必要があります。

セカンダリ ノードで HTTPS 通信に自己署名証明書が使用されている場合は、セカンダリ ノードの自己署名証明書をプライマリ ノードの CTL にインポートできます。


) セカンダリ ノードをプライマリ ノードに登録した後で、登録されたセカンダリ ノードで HTTPS 証明書を変更した場合は、セカンダリ ノードの HTTPS 証明書を検証するために使用できる適切な CA 証明書を取得する必要があります。


関連項目

「セカンダリ ノードからプライマリ ノードの CTL への CA 署名付き証明書のインポート」

「自己署名証明書のセカンダリ ノードからプライマリ ノードの CTL へのインポート」

セカンダリ ノードからプライマリ ノードの CTL への CA 署名付き証明書のインポート

はじめる前に

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


ステップ 1 セカンダリ ノードとして登録するノードの管理者ポータルにログインし、HTTPS 通信に使用される CA 署名付き証明書を、クライアント ブラウザを実行しているファイル システムにエクスポートします。

ステップ 2 [エクスポート(Export)] ダイアログボックスの [証明書のみをエクスポート(Export Certificate Only)] オプション ボタンをクリックします。

ステップ 3 プライマリ ノードの管理者ポータルにログインし、セカンダリ ノードの CA 署名付き証明書をプライマリ ノードの CTL にインポートします。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「証明書ストアからの証明書のエクスポート」

「証明書ストアへの証明書の追加」

自己署名証明書のセカンダリ ノードからプライマリ ノードの CTL へのインポート

はじめる前に

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


ステップ 1 セカンダリ ノードとして登録するノードの管理者ポータルにログインし、HTTPS 通信に使用される自己署名証明書を、クライアント ブラウザを実行しているファイル システムにエクスポートします。

ステップ 2 [エクスポート(Export)] ダイアログボックスの [証明書のみをエクスポート(Export Certificate Only)] オプション ボタンをクリックします。

ステップ 3 プライマリ ノードの管理者ポータルにログインし、セカンダリ ノードの自己署名証明書をプライマリ ノードの CTL にインポートします。


 

関連項目

「Cisco ISE 管理者グループ、アクセス レベル、権限、および制約事項」

「ローカル証明書のエクスポート」

「証明書ストアへの証明書の追加」

Simple Certificate Enrollment Protocol プロファイル

ユーザがネットワークで登録できるさまざまなモバイル デバイスの証明書のプロビジョニング機能を有効にするために、Cisco ISE では 1 つ以上の Simple Certificate Enrollment Protocol(SCEP)認証局(CA)プロファイルを設定し、Cisco ISE で複数の CA の場所を指定できます。複数のプロファイルを使用できる利点は、ハイ アベイラビリティを実現し、指定した CA の場所の間でロード バランシングを実行できることです。特定の SCEP CA への要求に 3 回連続して応答がなかった場合、Cisco ISE は特定のサーバが使用不能であると宣言し、次に負荷が小さく応答時間が短い既知の CA に自動的に移動し、サーバがオンラインに復帰するまで、定期的なポーリングを開始します。

Microsoft SCEP サーバをセットアップして Cisco ISE と相互運用する方法の詳細については、次を参照してください。

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/howto_60_byod_certificates.pdf

関連項目

「Simple Certificate Enrollment Protocol プロファイルの追加」

「OCSP サービス」

Simple Certificate Enrollment Protocol プロファイルの追加


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [SCEP CA プロファイル(SCEP CA Profile)] を選択します。

ステップ 2 他の SCEP CS プロファイル名と区別するために、プロファイルの名前を指定します。

ステップ 3 任意でプロファイルの説明を入力します。

ステップ 4 ユーザがモバイル デバイスからネットワークにアクセスしたときに Cisco ISE が SCEP CA 要求を転送できる当該の SCEP CA サーバの URL を指定します。

[送信(Submit)] ボタンをクリックしてセッションを終了する前に、任意で隣接する [接続のテスト(Test Connectivity)] ボタンを使用して、指定した URL のサーバに Cisco ISE が到達できることを確認できます。(いずれにしても、Cisco ISE ではプロファイルを保存する前に URL がテストされます)。

ステップ 5 [送信(Submit)] をクリックします。


 

参照用:

ユーザのデバイスが検証済みの証明書を受信すると、 表 8-1 に示すように、証明書はデバイスに置かれます。

 

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

デバイス
証明書ストレージの場所
アクセス方法

iPhone/iPad

標準の証明書ストア

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

Android

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

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

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

Windows

標準の証明書ストア

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

Mac

標準の証明書ストア

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

OCSP サービス

Online Certificate Status Protocol(OCSP)は、x.509 デジタル証明書のステータスのチェックに使用されるプロトコルです。このプロトコルは証明書失効リスト(CRL)に代わるものであり、CRL の処理をもたらす問題に対処します。

Cisco ISE には HTTP を介して OCSP サーバと通信し、認証で証明書のステータスを検証する機能があります。OCSP のコンフィギュレーションは、Cisco ISE で設定されるいずれかの認証局(CA)証明書から参照できる再利用可能な設定オブジェクトで設定されます。 「証明書ストアの証明書の編集」 を参照してください。

CRL 検証と OCSP 検証の両方または一方を CA ごとに設定できます。両方を選択すると、Cisco ISE では最初に OCSP を介した検証が実行されます。プライマリ OCSP サーバとセカンダリ OCSP サーバの両方で通信の問題が検出された場合、または特定の証明書に対して不明のステータスが返された場合、Cisco ISE は CRL のチェックに切り替わります。

この項では、次のトピックを扱います。

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

「OCSP のハイ アベイラビリティ」

「OCSP サービスの追加」

「OCSP 統計情報カウンタ」

「OCSP 障害」

「OCSP のモニタリング」

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

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

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

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

[不明(Unknown)]:証明書のステータスは不明です。これは、OCSP が特定の証明書 CA を処理するように設定されていない場合に発生することがあります。

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

関連項目

「OCSP 統計情報カウンタ」

OCSP のハイ アベイラビリティ

Cisco ISE には、CA ごとに最大 2 台の OCSP サーバを設定する機能があり、それらはプライマリ 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 障害のシナリオは次のとおりです。

1. 失敗した OCSP キャッシュまたは OCSP クライアント側(Cisco ISE)の障害。

2. 失敗した OCSP 応答側のシナリオ。例:

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

b. 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 』を参照してください。

3. 失敗した OCSP レポート

OCSP サービスの追加

Cisco ISE に新しい OCSP サービスを追加するには、[OCSP の追加(add OCSP)] ページを使用できます。


ステップ 1 [管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [OCSP サービス(OCSP Services)] を選択します。

ステップ 2 [追加(Add)] をクリックします。

ステップ 3 OCSP サービスに名前と説明を入力します。

ステップ 4 ハイ アベイラビリティを有効にする場合は、[セカンダリ サーバの有効化(Enable Secondary Server)] チェックボックスをオンにします。

ステップ 5 ハイ アベイラビリティの次のいずれかのオプションを選択します。

[常にプライマリ サーバに最初にアクセスする(Always Access Primary Server First)]:このオプションは、セカンダリ サーバへの移動を試行する前にプライマリ サーバをチェックする場合に使用します。プライマリが以前にチェックされ、応答しないことがわかっている場合にも、Cisco ISE はセカンダリ サーバに移動する前にプライマリ サーバへの要求の送信を試行します。

[時間を置いてプライマリ サーバにフォールバックする(Fallback to Primary Server After Interval)]:このオプションは、Cisco ISE がセカンダリ サーバに移動してから、再度プライマリ サーバにフォールバックする場合に使用します。この場合、その他の要求はすべてスキップされ、テキスト ボックスで設定した時間セカンダリ サーバが使用されます。設定できる時間の範囲は 1 ~ 999 分です。

ステップ 6 プライマリおよびセカンダリの OCSP サーバの URL または IP アドレスを指定します。

ステップ 7 次のオプションをオンまたはオフにします。

[ナンス(Nonce)]:ナンスが OCSP 要求の一部として送信されるように設定できます。ナンスには OCSP 要求の疑似乱数が含まれます。応答で受信される数値は要求に含まれる数値と同じであることが検証されています。このオプションにより、リプレイ アタックで古い通信を再利用できないことが保証されます。

[応答の署名の検証(Validate Response Signature)]:OCSP 応答側は次のいずれかの署名を使用して応答に署名します。

CA 証明書

CA 証明書とは別の証明書

Cisco ISE が応答の署名を検証するためには、OCSP 応答側が応答を証明書とともに送信する必要があります。そうでない場合、応答の検証は失敗し、証明書のステータスは利用できません。RFC に従い、OCSP は異なる証明書を使用して応答に署名できます。このことは、OCSP が Cisco ISE による検証用に応答に署名した証明書を送信する限り当てはまります。OCSP が Cisco ISE で設定されていない異なる証明書を使用して応答に署名した場合、応答の検証は失敗します。

ステップ 8 キャッシュ エントリの存続可能時間を分単位で入力します。

OCSP サーバからの各応答には nextUpdate 値が含まれています。この値は、証明書のステータスがサーバで次にいつ更新されるかを示します。OCSP 応答がキャッシュされるとき、2 つの値(1 つは設定から、もう 1 つは応答から)が比較され、この 2 つの最小値の時間だけ応答がキャッシュされます。nextUpdate 値が 0 の場合、応答はまったくキャッシュされません。

Cisco ISE は設定された時間 OCSP 応答をキャッシュします。キャッシュは複製されず、永続的でもないため、Cisco ISE が再起動するとキャッシュはクリアされます。

OCSP キャッシュは、OCSP 応答を保持するため、および次の理由で使用されます。

既知の証明書に関する OCSP サーバからのネットワーク トラフィックと負荷を低減するため

既知の証明書のステータスをキャッシュすることによって Cisco ISE のパフォーマンスを向上させるため

ステップ 9 OCSP サービスに接続されているすべての認証局のエントリをクリアするには、[キャッシュのクリア(Clear Cache)] をクリックします。

展開内で、キャッシュのクリアはすべてのノードと相互作用し、処理を実行します。このメカニズムでは、展開内のすべてのノードが更新されます。


 

OCSP 統計情報カウンタ

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

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

 

表 8-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 キャッシュ内に見つかった証明書の数

OCSP のモニタリング

OCSP サービス データを OCSP モニタリング レポートの形式で表示できます。Cisco ISE レポートの詳細については、「レポート」を参照してください。