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)から配信された証明書も含まれます。これにより、モバイル デバイスを企業ネットワークに登録できるようになります。信頼できる証明書ストア内の証明書はプライマリ管理ノード(PAN)で管理され、Cisco ISE 展開内の他のすべてのノードに自動的に複製されます。
分散展開では、証明書を PAN の証明書信頼リスト(CTL)のみにインポートする必要があります。この証明書はセカンダリ ノードに複製されます。
一般に、Cisco ISE での証明書認証が、証明書による認証機能のわずかな違いの影響を受けないようにするために、ネットワークに展開されているすべての Cisco ISE ノードには小文字のホスト名を使用してください。
証明書の使用
Cisco ISE に証明書を追加またはインポートする場合、証明書の使用目的を指定する必要があります。
-
管理者:ノード間通信および管理者ポータルの認証
-
EAP:TLS ベースの EAP 認証
-
RADIUS DTLS: RADIUS DTLS サーバ認証用
-
ポータル:すべての Cisco ISE エンドユーザ ポータルとの通信
-
xGrid:pxGrid コントローラとの通信
管理者ポータル(管理者)、pxGrid コントローラ(xGrid)との通信および TLS ベースの EAP 認証(EAP)に、各ノードから異なる証明書を関連付けることができます。ただし、これらの各目的に各ノードから関連付けることができる証明書は 1 つのみです。
Web ポータル要求を処理できる展開に複数のポリシー サービス ノード(PSN)がある場合、Cisco ISE には一意の ID が必要です。この ID で、ポータルの通信に使用する必要がある証明書を識別します。ポータルでの使用に指定された証明書を追加またはインポートする場合、証明書グループ タグを定義して、それを展開内の各ノードの対応する証明書に関連付ける必要があります。この証明書グループ タグを対応するエンドユーザ ポータル(ゲスト、スポンサー、およびパーソナル デバイス ポータル)に関連付ける必要があります。この証明書グループ タグは一意の ID で、Cisco ISE が各ポータルと通信する際に使用する必要がある証明書を識別する場合に役立ちます。ポータルごとに各ノードから 1 つの証明書を指定できます。
(注) |
EAP-TLS クライアント証明書では、以下の暗号に対し、KeyUsage=Key Agreement および ExtendedKeyUsage=Client Authentication が必要です。
EAP-TLS クライアント証明書では、以下の暗号に対し、KeyUsage=Key Encipherment および ExtendedKeyUsage=Client Authentication が必要です。
|
Cisco ISE の証明書の一致
展開内で Cisco ISE ノードをセットアップすると、2 つのノードが相互に通信します。システムは各 ISE ノードの FQDN を調べ、FQDN が一致することを確認します(たとえば ise1.cisco.com と ise2.cisco.com、またはワイルドカード証明書を使用している場合は *.cisco.com)。また、外部マシンから ISE サーバに証明書が提示される場合、認証のために提示される外部証明書が、ISE サーバの証明書と照合されます。2 つの証明書が一致すると、認証は成功します。
では、 ノード間(2 ノードの場合)、または と pxGrid の間で照合が実行されます。
Cisco ISE は、サブジェクト名の一致を次のようにして確認します。
-
Cisco ISE により証明書のサブジェクト代替名(SAN)の拡張が確認されます。SAN に 1 つ以上の DNS 名が含まれている場合は、それらの DNS 名の 1 つが Cisco ISE ノードの FQDN に一致している必要があります。ワイルドカード証明書が使用されている場合、ワイルドカード ドメイン名は Cisco ISE ノードの FQDN ドメインに一致している必要があります。
-
SAN に DNS 名が存在しない場合、または SAN 全体が欠落している場合は、証明書の [サブジェクト(Subject)] フィールドの一般名(CN)または証明書の [サブジェクト(Subject)] フィールドのワイルドカード ドメインが、ノードの FQDN に一致している必要があります。
-
一致しない場合、証明書は拒否されます。
(注)
Cisco ISE にインポートされる X.509 証明書は、Privacy Enhanced Mail(PEM)または Distinguished Encoding Rules(DER)形式である必要があります。証明書チェーン(システム証明書、およびその証明書に署名する一連の信頼された証明書)が含まれたファイルはインポートすることができますが、特定の制限の対象となります。
X.509 証明書の有効性
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 展開に登録できないことに注意してください。 展開内でクライアントと PSN の間のセキュアな通信に自己署名証明書を使用する場合、BYOD ユーザがある場所から別の場所に移動すると、EAP-TLS ユーザ認証は失敗します。一部の PSN 間で提供される必要があるこのような認証要求の場合、外部で署名された CA 証明書を使用してクライアントと PSN の間の通信を保護するか、または外部の CA によって署名されたワイルドカード証明書を使用する必要があります。 パブリック署名証明書を取得する場合、または Cisco ISE 展開が FIPS モードで動作する場合は、すべてのシステム証明書および信頼できる証明書が FIPS 準拠であることを確認する必要があります。つまり、各証明書のキー サイズが 2048 バイト以上であり、SHA-1 または SHA-256 暗号化を使用する必要があります。
|
ワイルドカード証明書
ワイルドカード証明書はワイルドカード表記(ドメイン名の前にアスタリスクとピリオドの形式)を使用し、組織の複数のホスト間で証明書を共有できるようにします。たとえば、証明書サブジェクトの 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 サイトの保護に使用されるワイルドカード証明書の例を示します。
Cisco ISE のワイルドカード証明書のサポート
以前のリリースの Cisco ISE では、CN 値を使用して、url-redirect A-V pair 文字列の変数を置き換えていました。この CN 値は、すべての Centralized Web Authentication(CWA)、オンボーディング、ポスチャ リダイレクションなどに使用されました。
Cisco ISE は CN として ISE ノードのホスト名を使用します。
HTTPS および EAP 通信用のワイルドカード証明書
SSL/TLS トンネリングを使用する Admin(Web ベースのサービス)および EAP プロトコルに対して、Cisco ISE でワイルドカード サーバ証明書を使用できます。ワイルドカード証明書を使用することにより、各 Cisco ISE ノードに固有の証明書を生成する必要がなくなります。また、証明書の警告を防ぐために、SAN フィールドに複数の FQDN 値を入力する必要もありません。SAN フィールドでアスタリスク(*)を使用すると、展開内の複数のノードで単一の証明書を共有できるようになり、証明書名の不一致による警告を防止することができます。ただし、ワイルドカード証明書は、各 Cisco ISE ノードに固有のサーバ証明書を割り当てる場合よりも安全性が低いと見なされます。
ゲスト ポータルにパブリック ワイルドカード証明書を割り当て、ルート CA 証明書を使用してサブ CA をインポートする場合、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 リダイレクションの完全修飾ドメイン名
url-redirect=https://ip:port/guestportal/gateway?sessionId=SessionIdValue&action=cwa
この要求を処理するときに、Cisco ISE は文字列の一部のキーワードを実際の値で置き換えます。たとえば、SessionIdValue は、要求の実際のセッション ID に置き換えられます。eth0 インターフェイスの場合、Cisco ISE は URL 内の IP を Cisco ISE ノードの FQDN で置き換えます。eth0 以外のインターフェイスの場合、Cisco ISE は URL 内の IP アドレスを使用します。インターフェイス eth1 から eth3 にはホストのエイリアス(名前)を割り当てることができます。このエイリアスは Cisco ISE が URL リダイレクション中に IP アドレスの代わりに置き換えることができます。
これを行うために、次のように、Cisco ISE CLI の ISE /admin(config)# プロンプトからコンフィギュレーション モードで ip host コマンドを使用できます。
ip host IP_address host-alias FQDN-string
ここで、IP_address はネットワーク インターフェイス(eth1 または eth2 または eth3)の IP アドレスで、host-alias はネットワーク インターフェイスに割り当てる名前です。FQDN-string は、ネットワーク インターフェイスの完全修飾ドメイン名です。このコマンドを使用して、ネットワーク インターフェイスに host-alias または FQDN-string あるいはその両方を割り当てることができます。
ip host コマンドの使用例:ip host a.b.c.d sales sales.amerxyz.cometh0 以外のインターフェイスにホストのエイリアスを割り当てたら、application start ise コマンドを使用して Cisco ISE でアプリケーション サービスを再起動する必要があります。
このホスト エイリアスのネットワーク インターフェイスとの関連付けを削除するには、次のようにこのコマンドの no 形式を使用します。
no ip host IP_address host-alias FQDN-string
ホストのエイリアスの定義を表示するには、show running-config コマンドを使用します。
FQDN 文字列を指定している場合は、その FQDN で URL 内の IP アドレスが置き換えられます。ホストのエイリアスのみを指定した場合は、そのホスト エイリアスと設定された IP ドメイン名を結合して完全な FQDN が結合され、URL 内の IP アドレスがその FQDN で置き換えられます。ネットワーク インターフェイスをホストのエイリアスにマッピングしない場合は、URL 内のネットワーク インターフェイスの IP アドレスが使用されます。
クライアントのプロビジョニング、ネイティブ サプリカント、またはゲスト フローに対して eth0 以外のインターフェイスを使用する場合は、eth0 以外のインターフェイスの IP アドレスまたはホスト エイリアスがポリシー サービス ノードの証明書の SAN フィールドに適切に設定されていることを確認する必要があります。
ワイルドカード証明書を使用する利点
-
コスト削減。サードパーティの認証局によって署名された証明書には高額な費用がかかります(特にサーバ数が多い場合)。ワイルドカード証明書は、Cisco ISE 展開内の複数ノードで使用できます。
-
運用の効率化。ワイルドカード証明書は、すべてのポリシー サービス ノード(PSN)EAP および Web サービスが同じ証明書を共有することを可能にします。証明書を 1 回作成して、すべての PSN に適用することにより、コストを大幅に削減できるだけでなく、証明書の管理も簡素化されます。
-
認証エラーの低減。ワイルドカード証明書は、クライアントがプロファイル内に信頼された証明書を保存しており、そのクライアントが iOS のキーチェーン(署名ルートが信頼されている)に従っていない Apple iOS デバイスで発生する問題に対処します。iOS クライアントが最初に PSN と通信する際、このクライアントはその PSN の証明書を(信頼された認証局が署名している場合でも)明示的に信頼しません。ワイルドカード証明書を使用すると、この証明書がすべての PSN で同一になるため、ユーザは証明書の受け入れを 1 回行えばよく、その後の異なる PSN に対する認証はエラーやプロンプトが表示されることなく進行します。
-
簡素化されたサプリカントの設定。たとえば、PEAP-MSCHAPv2 およびサーバ証明書の信頼が有効になっている Microsoft Windows サプリカントで、各サーバ証明書を信頼するように指定することが必要とされており、そのように指定されていない場合、そのクライアントが別の PSN を使用して接続を行うと、各 PSN 証明書を信用するように、ユーザにプロンプトが出される可能性があります。ワイルドカード証明書を使用すると、各 PSN の個別の証明書ではなく、単一のサーバ証明書を信頼するだけで済みます。
-
ワイルドカード証明書を使用すると、プロンプトの提示が減り、よりシームレスな接続が実現されることにより、ユーザ エクスペリエンスが改善されます。
ワイルドカード証明書を使用することの欠点
-
監査性と否認防止性の低下
-
秘密キーの露出の増加
-
一般的ではなく、管理者により理解されていない
ワイルドカード証明書は ISE ノードごとの固有のサーバ証明書よりも安全性が低いと見なされています。ただし、コスト、およびその他の運用関連の要因がセキュリティ リスクに勝っています。
ASA などのセキュリティ デバイスも、ワイルドカード証明書をサポートしています。
ワイルドカード証明書を展開する場合には注意が必要です。たとえば、*.company.local を使用して証明書を作成したとします。該当の秘密キーを攻撃者が回復できた場合、攻撃者は company.local ドメイン内のすべてのサーバをスプーフィングすることができます。したがって、このタイプの危険を回避するために、ドメイン領域を分割することがベスト プラクティスと見なされています。
この想定される問題に対処し、利用範囲を制限するために、ワイルドカード証明書を使用して組織の特定のサブドメインを保護することもできます。ワイルドカードを指定する一般名のサブドメイン領域に、アスタリスク(*)を追加します。
たとえば、*.ise.company.local に対してワイルドカード証明書を設定すると、その証明書は次のような、DNS 名が「.ise.company.local」で終わるすべてのホストを保護するために使用できます。
-
psn.ise.company.local
-
mydevices.ise.company.local
-
sponsor.ise.company.local
ワイルドカード証明書の互換性
ワイルドカード証明書は通常、証明書サブジェクトの一般名(CN)としてリストされているワイルドカードを使用して作成されます。Cisco ISE は、このタイプの作成をサポートします。ただし、すべてのエンドポイント サプリカントが証明書サブジェクトのワイルドカード文字をサポートするわけではありません。
テスト済みのすべての Microsoft ネイティブ サプリカント(Windows Mobile を含む)の一部は、証明書のサブジェクトのワイルドカード文字をサポートしていません。
Cisco AnyConnect Network Access Manager(NAM)など、[サブジェクト(Subject)] フィールドでのワイルドカード文字の使用をサポートできる他のサプリカントを使用することができます。
また、DigiCert の Wildcard Plus など、証明書のサブジェクト代替名に特定のサブドメインを含めることで、互換性のないデバイスを使用するように設計された、特別なワイルドカード証明書を使用することもできます。
Microsoft サプリカントの制限はワイルドカード証明書の使用にとって妨げになるように見えますが、Microsoft のネイティブ サプリカントを含む、セキュアなアクセスについてテスト済みのすべてのデバイスを使用できるようにする代替の方法があります。
このためには、サブジェクトにワイルドカードを使用する代わりに、[Subject Alterative Name (SAN)] フィールドでワイルドカード文字を使用します。SAN フィールドはドメイン名(DNS 名)を検査するように設計された拡張を保持します。詳細については、RFC 6125 および 2128 を参照してください。
証明書階層
管理者ポータルから、すべてのエンドポイント、システム、および信頼できる証明書の証明書階層または信頼書トラスト チェーンを表示できます。証明書階層には、証明書、すべての中間認証局(CA)の証明書、およびルート証明書が含まれています。たとえば、管理者ポータル からシステム証明書を表示すると、デフォルトでは該当するシステム証明書の詳細が表示されます。証明書階層は、証明書の上部に表示されます。詳細を表示するには、その階層で証明書をクリックします。自己署名証明書には階層または信頼チェーンがありません。
証明書のリスト ページで、[ステータス(Status)] 列に次のアイコンのいずれかが表示されます。
-
緑色のアイコン:有効な証明書(有効な信頼チェーン)を示します
-
赤色のアイコン:エラーを示します(たとえば、信頼証明書の欠落または期限切れ)
-
黄色のアイコン:証明書が期限切れ間近であることを警告し、更新処理を求めます
システム証明書
Cisco ISE システム証明書は、展開内のその他のノードおよびクライアント アプリケーションに対して Cisco ISE ノードを識別するサーバ証明書です。システム証明書の用途は次のとおりです。
-
Cisco ISE 展開でノード間通信に使用されます。この証明書の場合、[使用方法(Usage)] フィールドで [管理(Admin)] オプションを選択します。
-
Cisco ISE Web ポータルに接続するブラウザおよび REST クライアントで使用されます。この証明書の場合、[使用方法(Usage)] フィールドで [ポータル(Portal)] オプションを選択します。
-
PEAP および EAP-FAST を使用する外部 TLS トンネルを形成するために使用されます。EAP-TLS、PEAP、および EAP-FAST の相互認証の場合、[使用方法(Usage)] フィールドで [EAP] オプションを選択します。
-
RADIUS DTLS サーバ認証に使用されます。
-
SAML ID プロバイダー(IdP)との通信に使用されます。この証明書の [使用方法(Usage)] フィールドで [SAML] オプションを選択します。[SAML] オプションを選択すると、その他のサービスにこの証明書を使用することはできません。
-
pxGrid コントローラとの通信に使用されます。この証明書の場合、[使用方法(Usage)] フィールドで [pxGrid] オプションを選択します。
Cisco ISE 展開で、各ノードで有効なシステム証明書をインストールする必要があります。デフォルトでは、インストール時に Cisco ISE ノードに 2 つの自己署名証明書と、内部 Cisco ISE CA により署名された 1 つの証明書が作成されます。
-
[EAP]、[管理(Admin)]、[ポータル(Portal)]、および [RADIUS DTLS] のための自己署名サーバ証明書(キー サイズは 2048 で 1 年間有効です)。
-
SAML IdP との安全な通信に使用できる自己署名 SAML サーバ証明書(キー サイズは 2048 で 1 年間有効です)。
-
pxGrid クライアントとの安全な通信に使用できる内部 Cisco ISE CA 署名付きサーバ証明書(キー サイズは 4096 で 1 年間有効です)。
展開をセットアップし、セカンダリ ノードを登録すると、pxGrid コントローラ用の証明書が自動的にプライマリ ノードの CA 署名付き証明書に置き換わります。したがってすべての pxGrid 証明書が同一 PKI トラスト階層の一部となります。
(注) |
ワイルドカード システム証明書をエクスポートして、(ノード間通信用に)他のノードにインポートする場合は、必ず証明書と秘密キーをエクスポートして、暗号化パスワードを指定してください。インポート時は、証明書、秘密キー、および暗号化パスワードが必要です。 |
(注) |
お使いのリリースでサポートされているキーと暗号情報を確認するには、適切なバージョンの『 Cisco Identity Services Engine Network Component Compatibility 』ガイドを参照してください。 |
シスコでは、セキュリティ向上のために自己署名証明書を CA 署名付き証明書と置き換えることを推奨します。CA 署名付き証明書を取得するには、以下を行う必要があります。
-
証明書署名要求(CSR)を作成します。
-
認証局(CA)に送信します。
-
署名付き証明書を取得します。
-
関連するルートおよび中間 CA 証明書を信頼できる証明書ストアにインポートします。
-
CSR に署名付き証明書をバインドします。
How To: Implement ISE Server-Side Certificates Certificate Renewal on Cisco Identity Services Engine Configuration Guide |
システム証明書の表示
[システム証明書(System Certificate)] ページに、Cisco ISE に追加されたすべてのシステム証明書が一覧表示されます。
始める前に
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
手順
ステップ 1 |
。 を選択します [システム証明書(System Certificate)] ページが表示されます。このページには、システム証明書に関する次の情報が表示されています。
|
ステップ 2 |
証明書を選択し、[表示(View)] を選択して証明書の詳細を表示します。 |
システム証明書のインポート
管理者ポータルから、任意の Cisco ISE ノードのシステム証明書をインポートできます。
始める前に
-
クライアント ブラウザを実行しているシステムに、システム証明書と秘密キー ファイルがあることを確認します。
-
インポートするシステム証明書が外部 CA によって署名されている場合は、関連するルート CA および中間 CA 証明書を信頼できる証明書ストアにインポートします([管理(Administration)] > [システム(System)] > [証明書(Certificates)] > [信頼できる証明書(Trusted Certificates)])。
-
Cisco ISE では、SHA-256 より大きいハッシュ アルゴリズムで署名された証明書はサポートされていません。したがって、SHA-256 より大きいハッシュ アルゴリズムで署名されたサーバ証明書はインポートしないでください。
-
インポートするシステム証明書に、CA フラグが true に設定された基本制約拡張が含まれている場合は、キー使用拡張が存在すること、および keyEncipherment ビットと keyAgreement ビットのいずれかまたは両方が設定されていることを確認します。
-
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
[インポート(Import)] をクリックします。 |
ステップ 3 |
インポートする証明書の値を入力します。 |
ステップ 4 |
[送信(Submit)] をクリックします。 |
自己署名証明書の生成
自己署名証明書を生成することにより、新しいローカル証明書を追加できます。自己署名証明書は、内部テストと評価のニーズに対してのみ使用することを推奨します。実稼働環境に Cisco ISE を展開することを計画している場合は、可能な限り CA 署名付き証明書を使用して、実稼働ネットワーク全体でより均一な受け入れが行われるようにします。
(注) |
自己署名証明書を使用しており、Cisco ISE ノードのホスト名を変更する必要がある場合は、Cisco ISE ノードの管理者用ポータルにログインし、古いホスト名が使用された自己署名証明書を削除し、新しい自己署名証明書を生成します。そうしないと、Cisco ISE は古いホスト名が使用された自己署名証明書を引き続き使用します。 |
始める前に
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
手順
ステップ 1 |
。 を選択します セカンダリ ノードから自己署名証明書を生成するには、 を選択します。 |
ステップ 2 |
[自己署名証明書の生成(Generate Self Signed Certificate)] をクリックし、[自己署名証明書の生成(Generate Self Signed Certificate)] ページに詳細を入力します。 |
ステップ 3 |
自己署名したワイルドカード証明書(サブジェクトの任意の一般名またはサブジェクト代替名の DNS 名、またはその両方にアスタリスク(*)が含まれている証明書)を生成する場合は、[ワイルドカード証明書の許可(Allow Wildcard Certificates)] チェックボックスをオンにします。たとえば、SAN に割り当てられている DNS 名が *.amer.cisco.com の場合です。 |
ステップ 4 |
この証明書を使用するサービスに基づいて [使用方法(Usage)] 領域のチェックボックスをオンにします。 |
ステップ 5 |
証明書を生成するには、[送信(Submit)] をクリックします。 CLI からセカンダリ ノードを再起動するには、指定された順序で次のコマンドを入力します。
|
システム証明書の編集
このページを使用して、システム証明書を編集し、自己署名証明書を更新できます。ワイルドカード証明書を編集すると、変更が展開内のすべてのノードに複製されます。ワイルドカード証明書を削除した場合、そのワイルドカード証明書は展開内のすべてのノードから削除されます。
始める前に
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
手順
ステップ 1 |
。 を選択します |
ステップ 2 |
編集する証明書の横にあるチェックボックスをオンにして、[編集(Edit)] をクリックします。 |
ステップ 3 |
自己署名証明書を更新するには、[更新期間(Renewal Period)] チェックボックスをオンにして、有効期限 TTL(存続可能時間)を日、週、月、または年単位で入力します。 |
ステップ 4 |
[Save(保存)] をクリックして変更内容を保存します。 [管理者(Admin)] チェックボックスがオンになっている場合、Cisco ISE ノードのアプリケーション サーバが再起動されます。また、その Cisco ISE ノードが展開の PAN である場合は、展開内のその他すべてのノードでもアプリケーション サーバが再起動されます。プライマリ管理ノード(PAN)の再起動が完了すると、システムによって一度に 1 つのノードが再起動されます。 |
(注) |
Chrome 65 以上を使用して ISE を起動すると、URL が正しくリダイレクトされたにもかかわらず、BYOD ポータルまたはゲスト ポータルがブラウザで起動に失敗することがあります。これは、すべての [サブジェクトの別名(Subject Alternative Name)] フィールドに証明書を必要とする、Google で導入された新しいセキュリティ機能が原因です。ISE 2.4 以降のリリースの場合、[サブジェクトの別名(Subject Alternative Name)] フィールドを入力する必要があります。 Chrome 65 以上で起動するには、次の手順に従います。 1. [サブジェクトの別名(Subject Alternative Name)] フィールドに入力することで、ISE GUI から新しい自己署名証明書を生成します。DNS と IP アドレスの両方を入力する必要があります。 2. ISE サービスが再起動します。 3. Chrome ブラウザでポータルにリダイレクトされます。 4. ブラウザで [証明書の表示(View Certificate)] > [詳細(Details)] > [コピー(Copy)] の順に選択し、base-64 エンコードを選択して、証明書をコピーします。 5. 高信頼パスで証明書をインストールします。 6. Chrome ブラウザを終了し、ポータルのリダイレクトを試みます。 |
(注) |
Win RS4 または RS5 のオペレーティング システムでブラウザ Firefox 64 以降のワイヤレス BYOD セットアップを設定する場合は、証明書の例外を追加することができない場合があります。この現象は Firefox 64 以降の新規インストール時に発生することがあります。以前のバージョンから Firefox 64 以降にアップグレードした場合は発生しません。次の手順では、このような場合でも証明書の例外を追加することができます。 1. BYOD フローのシングル/デュアル PEAP または TLS を設定します。 2. Windows のすべてのオプションで CP ポリシーを設定します。 3. エンド クライアント Windows RS4/RS5 で Dot1.x/MAB SSID に接続します。 4. ゲスト/BYOD ポータルにリダイレクトするために、FF64 ブラウザに 1.1.1.1 と入力します。 5. をクリックし、フローを続行します。これを回避するには、 に移動して、Firefox 64 に証明書を手動で追加する必要があります。 |
システム証明書の削除
今後使用しないシステム証明書を削除できます。
システム証明書ストアから複数の証明書を一度に削除できますが、管理および EAP 認証に使用できる証明書を少なくとも 1 つ所有する必要があります。また、管理、EAP 認証、ポータル、または pxGrid コントローラに使用される証明書は削除できません。ただし、サービスがディセーブルの場合は、pxGrid 証明書を削除できます。
ワイルドカード証明書を削除することを選択した場合、証明書は展開内のすべてのノードから削除されます。
手順
ステップ 1 |
。 を選択します |
ステップ 2 |
削除する証明書の隣にあるチェックボックスをオンにし、[削除(Delete)] をクリックします。 警告メッセージが表示されます。 |
ステップ 3 |
[はい(Yes)] をクリックして、証明書を削除します。 |
システム証明書のエクスポート
選択したシステム証明書とその証明書に関連付けられている秘密キーをエクスポートできます。証明書とその秘密キーをバックアップ用にエクスポートする場合は、それらを必要に応じて後で再インポートできます。
始める前に
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
手順
ステップ 1 |
。 を選択します |
||
ステップ 2 |
エクスポートする証明書の横にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。 |
||
ステップ 3 |
証明書のみをエクスポートするか、証明書と証明書に関連付けられている秘密キーをエクスポートするかを選択します。
|
||
ステップ 4 |
秘密キーをエクスポートする場合は、パスワードを入力します。パスワードは、8 文字以上にする必要があります。 |
||
ステップ 5 |
[エクスポート(Export)] をクリックして、クライアント ブラウザを実行しているファイル システムに証明書を保存します。 証明書のみをエクスポートする場合、証明書は Privacy Enhanced Mail 形式で保存されます。証明書と秘密キーの両方をエクスポートする場合、証明書は Privacy Enhanced Mail 形式の証明書と暗号化された秘密キー ファイルを含む .zip ファイルとしてエクスポートされます。 |
信頼できる証明書ストア
信頼できる証明書ストアには、信頼に使用される、Simple Certificate Enrollment Protocol(SCEP)用の X.509 証明書が含まれています。
信頼できる証明書ストア内の証明書は PAN で管理され、Cisco ISE 展開内の他のすべてのノードに複製されます。Cisco ISE はワイルドカード証明書をサポートしています。
Cisco ISE は、次の目的で信頼できる証明書を使用します。
-
エンドポイントによる認証と、証明書ベースの管理者認証を使用してISE-PIC管理者ポータルにアクセスする Cisco ISE 管理者による認証に使用するクライアント証明書を確認するため。
-
展開内の Cisco ISE ノード間のセキュアな通信を可能にするため。信頼できる証明書ストアには、展開内の各ノードのシステム証明書との信頼を確立するために必要な CA 証明書のチェーンが含まれている必要があります。
-
自己署名証明書をシステム証明書に使用する場合は、各ノードの自己署名証明書を PAN の信頼できる証明書ストアに配置する必要があります。
-
CA 署名付き証明書をシステム証明書に使用する場合は、CA ルート証明書だけでなく、信頼チェーン内のすべての中間証明書も PAN の信頼できる証明書ストアに配置する必要があります。
-
-
セキュア 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 ノードに複製されます。
(注)
SCEP RA プロファイルが削除されると、関連付けられている CA チェーンが信頼できる証明書ストアからも削除されます。
-
(注) |
|
信頼できる証明書ストアの証明書
信頼できる証明書ストアは、次の信頼できる証明書で事前設定されています。製造業者証明書、ルート証明書、その他の信頼できる証明書。ルート証明書(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 アドレス
-
Othername
信頼できる証明書にサポートされていない制約が含まれており、検証中の証明書に該当のフィールドが含まれていない場合は、Cisco ISE がサポートされない制約を検証できないため、その証明書は拒否されます。
信頼できる証明書内の名前の制約の定義例を次に示します。
X509v3 Name Constraints: critical
Permitted:
othername:<unsupported>
email:.abcde.at
email:.abcde.be
email:.abcde.bg
email:.abcde.by
DNS:.dir
DirName: DC = dir, DC = emea
DirName: C = AT, ST = EMEA, L = AT, O = ABCDE Group, OU = Domestic
DirName: C = BG, ST = EMEA, L = BG, O = ABCDE Group, OU = Domestic
DirName: C = BE, ST = EMEA, L = BN, O = ABCDE Group, OU = Domestic
DirName: C = CH, ST = EMEA, L = CH, O = ABCDE Group, OU = Service Z100
URI:.dir
IP:172.23.0.171/255.255.255.255
Excluded:
DNS:.dir
URI:.dir
受け入れ可能なクライアント証明書のサブジェクトは、次のように上記の定義に一致します。
Subject: DC=dir, DC=emea, OU=+DE, OU=OU-Administration, OU=Users, OU=X1, CN=cwinwell
信頼できるストア証明書の表示
[信頼できる証明書(Trusted Certificates)] ページに、Cisco ISE に追加されたすべての信頼できる証明書が一覧表示されます。 信頼できる証明書を表示するには、スーパー管理者またはシステム管理者である必要があります。
すべての証明書を表示するには、 を選択します。[信頼できる証明書(Trusted Certificates)] ページが表示され、すべての信頼できる証明書が一覧表示されます。
始める前に
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
信頼できる証明書ストアの証明書のステータス変更
証明書のステータスが有効になっている必要があります。これにより、Cisco ISE が信頼の確立にこの証明書を使用できるようになります。証明書が信頼できる証明書ストアにインポートされると、この証明書は自動的に有効になります。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
有効または無効にする証明書の隣にあるチェックボックスをオンにし、[編集(Edit)] をクリックします。 |
ステップ 3 |
ステータスを変更します。 |
ステップ 4 |
[保存(Save)] をクリックします。 |
信頼できる証明書ストアへの証明書の追加
[証明書ストア(Certificate Store)] ページを使用して、Cisco ISE に CA 証明書を追加することができます。
始める前に
-
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
-
ブラウザを実行しているコンピュータのファイル システムに、証明書ストアの証明書が存在することを確認します。証明書は PEM または DER 形式である必要があります。
-
Admin 認証または EAP 認証に証明書を使用する場合は、基本制約が証明書に定義され、CA フラグが true に設定されていることを確認します。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
[インポート(Import)] をクリックします。 |
ステップ 3 |
必要に応じてフィールドの値を設定します。 EAP 認証用または証明書ベースの管理者認証用に証明書チェーンにサブ CA 証明書を使用する場合は、ルート CA までに証明書チェーンにすべての証明書をインポートする際に [クライアント認証およびsyslog用に信頼する(Trust for client authentication and Syslog)] チェックボックスを必ずオンにしてください。CISCO ISE 2.3 パッチ 7 以降、同じサブジェクト名を持つ複数の CA 証明書をインポートできます。証明書ベースの管理者認証の場合は、信頼できる証明書を追加する際に、[証明書ベースの管理者認証用に信頼する(Trust for certificate based admin authentication)] チェックボックスをオンにします。 パスワード ベースの認証から証明書ベースの認証に認証タイプを変更すると、Cisco ISE は展開内の各ノードでアプリケーション サーバを再起動します。PAN のアプリケーション サーバから開始され、その後に各追加ノードが 1 つずつ続きます。 |
信頼できる証明書の編集
証明書を信頼できる証明書ストアに追加したら、編集の設定を使用して、その証明書をさらに編集できます。
始める前に
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
手順
ステップ 1 |
。 |
ステップ 2 |
編集する証明書の横にあるチェックボックスをオンにして、[編集(Edit)] をクリックします。 |
ステップ 3 |
必要に応じて編集可能なフィールドを変更します。 |
ステップ 4 |
[保存(Save)] をクリックして、証明書ストアに対して行った変更を保存します。 |
信頼できる証明書の削除
今後使用しない信頼できる証明書を削除できます。ただし、ISE 内部 CA(認証局)の証明書は削除しないでください。ISE 内部 CA 証明書を削除できるのは、展開全体の ISE ルート証明書チェーンを置き換える場合のみです。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
削除する証明書の隣にあるチェックボックスをオンにし、[削除(Delete)] をクリックします。 警告メッセージが表示されます。ISE 内部 CA 証明書を削除することを選択した場合は、次のとおりにクリックします。
|
ステップ 3 |
[はい(Yes)] をクリックして、証明書を削除します。 |
信頼できる証明書ストアからの証明書のエクスポート
始める前に
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
手順
ステップ 1 |
. 。 |
ステップ 2 |
エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。一度に 1 つの証明書のみをエクスポートできます。 |
ステップ 3 |
クライアント ブラウザを実行しているファイル システムに Privacy Enhanced Mail ファイルを保存します。 |
信頼できる証明書ストアへのルート証明書のインポート
ルート CA 証明書および中間 CA 証明書をインポートするとき、信頼できる CA 証明書を使用する対象のサービスを指定できます。
始める前に
CSR に署名し、デジタルで署名された CA 証明書を返した認証局のルート証明書および他の中間証明書が必要です。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
[インポート(Import)] をクリックします。 |
ステップ 3 |
[参照(Browse)] をクリックして、ルート CA 証明書を選択します。 |
ステップ 4 |
わかりやすい名前を入力します。 |
ステップ 5 |
CA によって返されたルート証明書を選択します。 |
ステップ 6 |
この信頼できる証明書を使用するサービスの横にあるチェックボックスをオンにします。 |
ステップ 7 |
説明を入力します。 |
ステップ 8 |
[送信(Submit)] をクリックします。 |
次のタスク
信頼できる証明書ストアに中間 CA 証明書をインポートします(該当する場合)。
証明書チェーンのインポート
証明書ストアから受信した証明書チェーンを含む単一のファイルから、複数の証明書をインポートすることができます。ファイル内のすべての証明書は Privacy-Enhanced Mail(PEM)の形式であり、証明書は次の順序に並べられている必要があります。
-
ファイル内の最後の証明書は、CA によって発行されたクライアントまたはサーバ証明書である必要があります。
-
前にあるすべての証明書は、ルート CA 証明書と、発行された証明書の署名のチェーンにあるすべて中間 CA 証明書である必要があります。
証明書チェーンのインポートは、次の 2 ステップのプロセスです。
-
管理者ポータルで信頼できる証明書ストアに証明書チェーン ファイルをインポートします。この操作により、信頼できる証明書ストアにある最後の 1 つを除き、すべての証明書がファイルからインポートされます。
-
CA 署名付き証明書のバインド操作を使用して証明書チェーン ファイルをインポートします。この操作により、最後の証明書がローカル証明書としてファイルからインポートされます。
証明書署名要求
認証局(CA)が署名付き証明書を発行するためには、証明書署名要求(CSR)を作成して CA に送信する必要があります。
自分が作成した証明書署名要求(CSR)のリストは、[証明書署名要求(Certificate Signing Requests)] ページで使用できます。認証局(CA)から署名を取得するには、CSR をエクスポートし、その証明書を CA に送信する必要があります。証明書は CA によって署名され、返されます。
管理者ポータルから証明書を一元的に管理できます。展開内のすべてのノードの CSR を作成およびエクスポートできます。その後、CSR を CA に送信し、CA から CA 署名付き証明書を取得し、CA によって返されたルートおよび中間 CA 証明書を信頼できる証明書ストアにインポートし、CSR に CA 署名付き証明書をバインドする必要があります。
証明書署名要求の作成と認証局への CSR の送信
証明書署名要求(CSR)を生成して、展開内のノードの CA 署名付き証明書を取得できます。展開の選択ノードまたは展開のすべてのノード用の CSR を生成できます。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
CSR を生成するための値を入力します。各フィールドの詳細については、「証明書署名要求の設定」を参照してください。 |
ステップ 3 |
[Generate(生成)] をクリックして CSR を生成します。 CSR が生成されます。 |
ステップ 4 |
[Export(エクスポート)] をクリックして、メモ帳で CSR を開きます。 |
ステップ 5 |
「-----BEGIN CERTIFICATE REQUEST-----」から「-----END CERTIFICATE REQUEST-----」までのすべてのテキストをコピーします。 |
ステップ 6 |
選択した CA の証明書要求に、この CSR の内容を貼ってください。 |
ステップ 7 |
署名済みの証明書をダウンロードする。 CA によっては、署名付き証明書が電子メールで送信される場合があります。署名付き証明書は、zip ファイルの形式で、Cisco ISE の信頼された証明書ストアに追加する必要がある、新規発行の証明書と CA のパブリック署名証明書が含まれています。デジタル署名された CA 証明書、ルート CA 証明書、および他の中間 CA 証明書(該当する場合)がクライアント ブラウザを実行するローカル システムにダウンロードされます。 |
CSR への CA 署名付き証明書のバインド
CA からデジタル署名付き証明書を受け取った後、それを証明書署名要求(CSR)にバインドする必要があります。管理者ポータルから展開内のすべてのノードに対してバインド操作を実行できます。
始める前に
-
デジタル署名付き証明書、および関連するルート中間 CA 証明書を CA から受け取る必要があります。
-
関連するルートおよび中間 CA 証明書を信頼できる証明書ストアにインポートします()。
手順
ステップ 1 |
を選択します。 CA 署名付き証明書に CSR をバインドするノードの隣にあるチェックボックスをオンにします。 |
||
ステップ 2 |
[バインド(Bind)] をクリックします。 |
||
ステップ 3 |
[参照(Browse)] をクリックし、CA 署名付き証明書を選択します。 |
||
ステップ 4 |
証明書の [フレンドリ名(Friendly Name)] を指定します。 |
||
ステップ 5 |
Cisco ISE に証明書の拡張の検証を許可する場合は、[証明書の拡張の検証(Validate Certificate Extensions)] チェックボックスをオンにします。 [証明書の拡張の検証(Validate Certificate Extensions)] オプションが有効になっており、インポートする証明書に CA フラグが true に設定された基本制約拡張が含まれている場合は、キー使用拡張が存在すること、および keyEncipherment ビットと keyAgreement ビットのいずれかまたは両方が設定されていることを確認します。
|
||
ステップ 6 |
この証明書が使用領域で使用されるサービスを確認します。 |
||
ステップ 7 |
[送信(Submit)] をクリックし、CA 署名付き証明書をバインドします。 Cisco ISE ノード間通信にこの証明書を使用するように選択した場合、Cisco ISE ノードでアプリケーション サーバが再起動されます。 他のノードで CA 署名付き証明書に CSR をバインドするために、このプロセスを繰り返します。 |
次のタスク
証明書署名要求のエクスポート
このページを使用して、証明書署名要求をエクスポートすることができます。
始める前に
次のタスクを実行するには、スーパー管理者またはシステム管理者である必要があります。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
エクスポートする証明書の隣にあるチェックボックスをオンにし、[エクスポート(Export)] をクリックします。 |
ステップ 3 |
[OK] をクリックして、クライアント ブラウザを実行しているファイル システムにファイルを保存します。 |
Cisco ISE ノード間通信の信頼できる証明書のインストール
展開をセットアップする場合、セカンダリ ノードを登録する前に、セカンダリ ノードの管理者証明書の検証に使用される適切な CA 証明書を PAN の証明書信頼リスト(CTL)に配置する必要があります。PAN の CTL に入力する手順は、シナリオに応じて異なります。
-
セカンダリ ノードが管理者ポータルとの通信に CA 署名付き証明書を使用する場合は、セカンダリ ノードの CA 署名付き証明書、関連する中間証明書(ある場合)、および(セカンダリ ノードの証明書に署名した CA の)ルート CA 証明書を PAN の CTL にインポートする必要があります。
-
セカンダリ ノードが管理者ポータルとの通信に自己署名証明書を使用する場合は、PAN の CTL にセカンダリ ノードの自己署名証明書をインポートできます。
(注)
-
登録されたセカンダリ ノードの管理者証明書を変更する場合は、セカンダリ ノードの管理者証明書の検証に使用できる適切な CA 証明書を取得し、PAN の CTL にインポートする必要があります。
-
展開内でクライアントと PSN の間のセキュアな通信に自己署名証明書を使用する場合、BYOD ユーザがある場所から別の場所に移動すると、EAP-TLS ユーザ認証は失敗します。一部の PSN 間で提供される必要があるこのような認証要求の場合、外部で署名された CA 証明書を使用してクライアントと PSN の間の通信を保護するか、または外部の CA によって署名されたワイルドカード証明書を使用する必要があります。
-
外部 CA から発行された証明書に基本制約が定義されており、CA フラグが true に設定されていることを確認します。ノード間通信の CA 署名付き証明書をインストールするには、次の手順を実行します。
手順
ステップ 1 | |
ステップ 2 | |
ステップ 3 |
ポータルで使用する証明書のセットアップ
Web ポータル要求を処理できる展開に複数のポリシー サービス ノード(PSN)がある場合、Cisco ISE には一意の ID が必要です。この ID で、ポータルの通信に使用する必要がある証明書を識別します。ポータルでの使用に指定された証明書を追加またはインポートする場合、証明書グループ タグを定義して、それを展開内の各ノードの対応する証明書に関連付ける必要があります。この証明書グループ タグを対応するエンドユーザ ポータル(ゲスト、スポンサー、およびパーソナル デバイス ポータル)に関連付ける必要があります。この証明書グループ タグは一意の ID で、Cisco ISE が各ポータルと通信する際に使用する必要がある証明書を識別する場合に役立ちます。ポータルごとに各ノードから 1 つの証明書を指定できます。
(注) |
Cisco ISE は TCP ポート 8443(またはポータルが使用するように設定したポート)でポータル証明書を提示します。 |
手順
ステップ 1 |
すでに定義済みの証明書グループ タグを選択するか、ポータル用に新しく作成する必要があります。たとえば、mydevicesportal などです。 |
ステップ 2 | |
ステップ 3 |
CA 署名付き証明書へのデフォルトのポータル証明書グループ タグの再割り当て
デフォルトでは、すべての Cisco ISE ポータルは自己署名証明書を使用します。ポータルに CA 署名付き証明書を使用する場合は、デフォルトのポータル証明書グループ タグを CA 署名付き証明書に割り当てることができます。既存の CA 署名付き証明書を使用するか、または CSR を生成して、ポータルに使用する新しい CA 署名付き証明書を取得できます。1 つの証明書から別の証明書にポータル グループ タグを再割り当てすることができます。
(注) |
既存の証明書を編集する場合、証明書に関連付けられているポータル タグ(ゲスト)がいずれかのポータルですでに使用されている場合は、デフォルトのポータル証明書グループ タグまたは他のポータル グループ タグをこの証明書に再割り当てすることはできません。「ゲスト」ポータル タグを使用しているポータルのリストが表示されます。 |
次に、CA 署名付き証明書にデフォルトのポータル証明書グループ タグを再割り当てする手順について説明します。
手順
ステップ 1 |
を選択します。 このタグを使用するポータルのリストを表示するには、デフォルトのポータル証明書グループ タグの横にある i アイコンにマウス ポインタを合わせます。このタグが割り当てられているポータル証明書がある展開内の ISE ノードを表示することもできます。 |
ステップ 2 |
ポータルに使用する CA 署名付き証明書の横にあるチェックボックスをオンにして、[編集(Edit)] をクリックします。 いずれのポータルでも使用されていない CA 署名付き証明書を選択してください。 |
ステップ 3 |
[使用方法(Usage)] 領域で、[ポータル(Portal)] チェックボックスをオンにして、デフォルトのポータル証明書グループ タグを選択します。 |
ステップ 4 |
[保存(Save)] をクリックします。 警告メッセージが表示されます。 |
ステップ 5 |
[はい(Yes)] をクリックして、CA 署名付き証明書にデフォルトのポータル証明書グループ タグを再割り当てします。 |
ノードの登録前のポータル証明書タグの関連付け
展開内のすべてのポータルに「デフォルト ポータル証明書グループ」タグを使用する場合は、新しい ISE ノードを登録する前に、関連する CA 署名付き証明書をインポートし、サービスとして「ポータル」を選択し、この証明書に「デフォルト ポータル証明書グループ」タグを関連付けます。
展開に新しいノードを追加すると、デフォルトの自己署名証明書が「デフォルト ポータル証明書グループ」タグに関連付けられ、このタグを使用するようにポータルが設定されます。
新しいノードの登録後、証明書グループ タグの関連付けは変更できません。したがって、展開にノードを登録する前に、次を実行してください。
手順
ステップ 1 |
自己署名証明書を作成し、サービスとして「ポータル」を選択し、別の証明書グループ タグ(たとえば、tempportaltag)を割り当てます。 |
||||||||
ステップ 2 |
新しく作成した証明書グループ タグ(tempportaltag)を使用するようにポータル設定を変更します。 |
||||||||
ステップ 3 |
デフォルト自己署名証明書を編集し、ポータル ロールを削除します。 このオプションは、デフォルト ポータル証明書グループ タグとデフォルト自己署名証明書との関連付けを削除します。 |
||||||||
ステップ 4 |
次のいずれかを実行します。
|
||||||||
ステップ 5 |
展開に ISE ノードを登録します。 |
ユーザおよびエンドポイントの証明書の更新
デフォルトでは、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 | |
ステップ 3 | |
ステップ 4 |
許可されるプロトコルの設定の更新
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
PEAP および EAP-FAST プロトコルの EAP-TLS プロトコルおよび EAP-TLS 内部方式の下の [許可ポリシーの証明書更新を可能にするために失効した証明書の認証を許可(Allow Authentication of expired certificates to allow certificate renewal in Authorization Policy)] チェックボックスをオンにします。 EAP-TLS プロトコルを使用する要求が NSP フローを通過します。 PEAP および EAP-FAST プロトコルについては、要求を処理するように Cisco ISE 向け Cisco AnyConnect を手動で設定する必要があります。 |
ステップ 3 |
[送信(Submit)] をクリックします。 |
次のタスク
CWA リダイレクションの許可ポリシー プロファイルの作成
始める前に
WLC で制限されたアクセス ACL が設定されていることを確認します。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
[追加(Add)] をクリックします。 |
ステップ 3 |
許可プロファイルの名前を入力します。たとえば、CertRenewal_CWA です。 |
ステップ 4 |
[共通タスク(Common Tasks)] 領域の [Web リダイレクション(CWA、DRW、MDM、NSP、CPP)(Web Redirection (CWA, DRW, MDM, NSP, CPP))] チェックボックスをオンにします。 |
ステップ 5 |
ドロップダウン リストの [中央集中 Web 認証(Centralized Web Auth)] および制限されたアクセス ACL を選択します。 |
ステップ 6 |
[証明書更新メッセージの表示(Display Certificates Renewal Message)] チェックボックスをオンにします。 url-redirect 属性値が変更され、この値に証明書が有効である日数が含まれます。 |
ステップ 7 |
[送信(Submit)] をクリックします。 |
(注) |
Cisco ISE 1.2 で無線デバイスの次のデバイス登録 WebAuth(DRW)ポリシーを設定している場合:
ISE 1.3 以上のバージョンにアップグレードした後は、DRW-Allow ポリシー条件を次のように更新する必要があります。
|
次のタスク
証明書を更新する許可ポリシー ルールの作成
始める前に
中央 Web 認証リダイレクションの許可プロファイルが作成されていることを確認します。
でポリシー セットを有効にします。
手順
ステップ 1 |
を選択します。 |
ステップ 2 |
[上を作成(Create Above)] をクリックします。 |
ステップ 3 |
新しいルールの名前を入力します。 |
ステップ 4 |
次の単純条件と結果を選択します。 CertRenewalRequired EQUALS True の場合は、権限用に以前に作成した許可プロファイル(CertRenewal_CWA)を選択します。 |
ステップ 5 |
[保存(Save)] をクリックします。 |
次のタスク
証明書が期限切れになったデバイスを持つ企業ネットワークにアクセスした場合は、[更新(Renew)] をクリックして、デバイスを再設定します。
ゲスト ポータルでの BYOD 設定の有効化
ユーザがパーソナル デバイス証明書を更新できるようにするには、選択したゲスト ポータルで BYOD 設定を有効にする必要があります。
手順
ステップ 1 |
を選択します。
|
ステップ 2 |
[BYOD 設定(BYOD Settings)] から [従業員にネットワークでのパーソナルデバイスの使用を許可する(Allow employees to use personal devices on the network)] チェックボックスをオンにします。 |
ステップ 3 |
[保存(Save)] をクリックします。 |
Apple iOS デバイスの証明書更新の失敗
ISE を使用して Apple iOS デバイスのエンドポイント証明書を更新する場合、「プロファイル済みでインストールできませんでした(Profiled Failed to Install)」エラー メッセージが表示される場合があります。このエラー メッセージは、同じポリシー サービス ノード(PSN)または別の PSN で、期限切れ間近または期限切れのネットワーク プロファイルが更新のプロセス時に使用されるものとは異なる管理者 HTTPS 証明書によって署名されている場合に表示されます。
回避策としては、展開内のすべての PSN で管理者 HTTPS 用にマルチドメイン SSL 証明書(通称 Unified Communications Certificates(UCC))またはワイルドカード証明書を使用します。