はじめに
このドキュメントでは、Cisco ISEのTLS/SSL証明書、ISE証明書の種類と役割、および一般的なタスクの実行方法とトラブルシューティング方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Cisco Identity Services Engine(ISE)
- さまざまなタイプのISEおよびAAA導入を説明するために使用される用語。
- RADIUSプロトコルとAAAの基本
- SSL/TLSおよびx509証明書
- 公開キーインフラストラクチャ(PKI)の基本
使用するコンポーネント
このドキュメントの情報は、Cisco ISEリリース2.4 ~ 2.7のソフトウェアとハードウェアのバージョンに基づくものです。 ISEバージョン2.4から2.7までを対象としていますが、特に断りのない限り、他のISE 2.xソフトウェアリリースと類似または同一である必要があります。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
サーバ証明書
サーバ証明書は、サーバがサーバのIDをクライアントに提示して信頼性を確保し、安全な通信チャネルを提供するために使用されます。これらの証明書は、自己署名(サーバが自身に証明書を発行する場所)するか、認証局(組織の内部または有名ベンダーから)から発行されます。
サーバ証明書は通常、サーバのホスト名または完全修飾ドメイン名(FQDN)に対して発行されるか、ワイルドカード証明書(*.domain.com )にすることもできます。発行先のホスト、ドメイン、またはサブドメインは、通常、共通名(CN)またはサブジェクト代替名(SAN)フィールドに示されます。
ワイルドカード証明書は、ワイルドカード表記(ホスト名の代わりにアスタリスクを使用)を使用することにより、組織内の複数のホストで同じ証明書を共有できるSSL証明書です。たとえば、ワイルドカード証明書のサブジェクト名のCN値またはSAN値は、 *.company.com に似ている可能性があり、 server1.com 、 server2.com などこのドメインの任意のホストを保護するために使用できます。
証明書は通常、公開キー暗号化または非対称暗号化を使用します。
- 公開キー:公開キーは、いずれかのフィールドの証明書に存在し、デバイスが公開キーと通信しようとすると、システムによって公開キーが共有されます。
- 秘密キー:秘密キーはエンドシステムに対して秘密であり、公開キーとペアになっています。公開キーで暗号化されたデータは、特定のペア秘密キーでのみ復号でき、その逆も可能です。
ISE証明書
Cisco ISEは公開キーインフラストラクチャ(PKI)を利用して、エンドポイント、ユーザ、管理者などとのセキュアな通信や、マルチノード環境のCisco ISEノード間のセキュアな通信を提供します。PKIは、x.509デジタル証明書を使用して、メッセージの暗号化と復号化のための公開キーを転送し、ユーザおよびデバイスから提示される他の証明書の信頼性を検証します。Cisco ISEには、通常使用される証明書の2つのカテゴリがあります。
- システム証明書:クライアントに対してCisco ISEノードを識別するサーバ証明書です。各Cisco ISEノードには独自のローカル証明書があり、それぞれが対応する秘密キーとともにノードに保存されます。
- 信頼できる証明書ストア証明書:これは、さまざまな目的のためにISEに提示される証明書を検証するために使用される認証局(CA)証明書です。証明書ストア内のこれらの証明書は、プライマリ管理ノードで管理され、分散Cisco ISE導入環境内の他のすべてのノードに複製されます。証明書ストアには、BYOD向けのISEの内部認証局(CA)によってISEノード用に生成された証明書も含まれています。
システム証明書
システム証明書は、1つ以上のロールに使用できます。それぞれの役割は異なる目的を果たします。次にその説明を示します。
- Admin:これは、443(管理GUI)を介したすべての通信を保護するために使用されます。また、レプリケーションや、ここに記載されていないポートまたは使用に対しても使用されます。
- ポータル:これは、集中型Web認証(CWA)ポータル、ゲスト、BYOD、クライアントプロビジョニング、ネイティブサプリカントプロビジョニングポータルなどのポータルを介したHTTP通信を保護するために使用されます。各ポータルは、ポータルグループタグ(デフォルトはDefault Portal Group Tag)にマッピングする必要があります。このタグは、使用する具体的にタグ付けされた証明書をポータルに指示します。証明書の編集オプションのポータルグループタグ名ドロップダウンメニューでは、新しいタグを作成したり、既存のタグを選択したりできます。
- EAP:802.1x認証のためにクライアントに提示する証明書を指定する役割です。証明書は、EAP-TLS、PEAP、EAP-FASTなどのほぼすべての可能なEAP方式で使用されます。PEAPやFASTなどのトンネリングされたEAP方式では、Transport Layer Security(TLS)を使用してクレデンシャル交換が保護されます。クライアントのクレデンシャルは、このトンネルが確立されてセキュアな交換が行われるまで、サーバに送信されません。
- RADIUS DTLS:このロールは、ネットワークアクセスデバイス(NAD)とISE間のRADIUSトラフィックを暗号化するためのDTLS接続(UDP経由のTLS接続)に使用される証明書を指定します。この機能が動作するには、NADがDTLS暗号化対応である必要があります。
- SAML:サーバ証明書は、SAML IDプロバイダー(IdP)との通信を保護するために使用されます。SAML用に指定された証明書は、Admin、EAP認証などの他のサービスには使用できません。
- ISEメッセージングサービス:2.6以降、ISEはレガシーSyslogプロトコルの代わりにISEメッセージングサービスを使用してデータをログします。これは、この通信の暗号化に使用されます。
- PxGrid:この証明書は、ISE上のPxGridサービスに使用されます。
ISEをインストールすると、Default Self-Signed Server Certificateが生成されます。デフォルトでは、これはEAP認証、管理者、ポータル、およびRADIUS DTLSに割り当てられます。これらのロールを内部CAまたは既知のCA署名付き証明書に移動することをお勧めします。
ヒント:ISEサーバのFQDNとIPアドレスの両方をISEシステム証明書のSANフィールドに追加することをお勧めします。 一般に、Cisco ISEでの証明書認証が、証明書による検証機能のわずかな違いの影響を受けないようにするため、ネットワークに導入されているすべてのCisco ISEノードで小文字のホスト名を使用します。
注:ISE証明書の形式は、プライバシー強化メール(PEM)またはDistinguished Encoding Rules(DER)である必要があります。
信頼できる証明書ストア
Administration > System > Certificates > Certificate Store 認証局(CA)証明書はに保存する必要があり、ISEがこれらの証明書を使用してエンドポイント、デバイス、または他のISEノードから提示された証明書を検証することを確認するためのTrust for client authentication ユースケースが必要です。
基本タスク
証明書には有効期限があり、取り消したり、いずれかの時点で交換を要求したりできます。ISEサーバ証明書の期限が切れると、新しい有効な証明書で置き換えない限り、重大な問題が発生する可能性があります。
注:拡張認証プロトコル(EAP)に使用される証明書の有効期限が切れると、クライアントはそのISE証明書を信頼しなくなるため、クライアント認証が失敗する可能性があります。ポータルに使用される証明書の期限が切れると、クライアントとブラウザはポータルへの接続を拒否できます。管理使用証明書の期限が切れると、リスクがさらに大きくなり、管理者がISEにログインできなくなり、分散導入が本来の機能を停止する可能性があります。
自己署名証明書の生成
新しい自己署名証明書を生成するには、Administration > System > Certificates > System Certificatesに移動します。Generate Self Signed Certificateをクリックします。
このリストでは、「自己署名証明書の生成」ページのフィールドについて説明します。
自己署名証明書の設定フィールド名の使用ガイドライン:
- ノードの選択: (必須)システム証明書の生成に必要なノード。
- CN:(SANが指定されていない場合は必須)デフォルトでは、CNは自己署名証明書が生成されるISEノードのFQDNです。
- 組織単位(OU):組織単位の名前。例:エンジニアリング。
- 組織(O):組織名(例:Cisco)。
- 市区町村(L): (省略形を使用しない)市区町村名(例:サンノゼ)。
- 州(ST): (省略形なし)州名。たとえば、California。
- 国(C):国名。2文字のISO国番号が必要です。たとえば、米国です。
- SAN:証明書に関連付けられているIPアドレス、DNS名、またはUniform Resource Identifier(URI)。
- Key Type:公開キーの作成に使用するアルゴリズム(RSAまたはECDSA)を指定します。
- キーの長さ:公開キーのビットサイズを指定します。これらのオプションは、RSAでは512 1024 2048 4096で、ECDSAでは256 384で使用できます。
- ダイジェスト署名:次のハッシュアルゴリズムのいずれかを選択します。SHA-1またはSHA-256。
- Certificate Policies:証明書が準拠する必要がある証明書ポリシーOIDまたはOIDのリストを入力します。OIDを区切るには、カンマまたはスペースを使用します。
- Expiration TTL:証明書が期限切れになるまでの日数を指定します。
- フレンドリ名:証明書のフレンドリ名を入力します。名前を指定しない場合、Cisco ISEは自動的に名前を作成します。
<common name> # <issuer> # <nnnnn> は一意の5桁の番号 <nnnnn> です。
- ワイルドカード証明書を使用する:自己署名ワイルドカード証明書(サブジェクトまたはSANのDNS名のCNにアスタリスク(*)が含まれている証明書)を生成するには、このチェックボックスをオンにします。たとえば、SANに割り当てられたDNS名を
*.domain.comにすることができます。
- 使用法:このシステム証明書を使用する必要があるサービスを選択します。使用可能なオプションは次のとおりです。
- [管理(Admin)]
- EAP Authentication
- RADIUSのDTLS
- pxGrid
- SAML
- ポータル
注:RSA公開キーとECDSA公開キーは、同じセキュリティレベルでもキーの長さが異なる場合があります。パブリックCA署名付き証明書を取得する場合、またはFIPS準拠のポリシー管理システムとしてCisco ISEを導入する場合は、2048を選択します。
自己署名証明書の更新
既存の自己署名証明書を表示するには、ISEコンソールでAdministration > System > Certificates > System Certificatesに移動します。同じISEサーバFQDNで指定されている場合、発行先と発行元が同じ証明書は自己署名証明書です。この証明書を選択し、をクリックしEditます。
[Renew Self Signed Certificate]で、Renewal Periodのボックスをオンにし、必要に応じて有効期限TTLを設定します。最後に、Saveをクリックします。
信頼できる証明書のインストール
Base 64でエンコードされた証明書を、ルートCA、中間CA、信頼に必要なホストから取得します。
1. ISEノードにログインし、次の図に示すようにAdministration > System > Certificate > Certificate Management > Trusted CertificatesImport に移動してクリックします。
2. 次のページで、取得したCA証明書を(前述と同じ順序で)アップロードします。トラッキングを継続するために、証明書の目的を説明するフレンドリ名と説明をユーザに割り当てます。
必要に応じて、次のチェックボックスをオンにします。
- ISE内での認証の信頼:これは、同じ信頼できるCA証明書が信頼できる証明書ストアにロードされている場合に、新しいISEノードを追加することです。
- Trust for client authentication and Syslog:証明書を使用して、EAPを使用してISEに接続するエンドポイントの認証やセキュアSyslogサーバの信頼を行う場合に、このオプションを有効にします。
- シスコサービスの認証の信頼性:これは、フィードサービスなどの外部シスコサービスを信頼する場合にのみ必要です。
3. 最後に、Submitをクリックします。ここで、証明書は信頼ストアで表示され、すべてのセカンダリISEノードに同期される必要があります(導入環境の場合)。
CA署名付き証明書のインストール
ルートCA証明書と中間CA証明書が信頼できる証明書ストアに追加されると、証明書署名要求(CSR)を発行でき、CSRに基づいて署名された証明書をISEノードにバインドできます。
1. これを行うには、Administration > System > Certificates > Certificate Signing RequestsGenerate Certificate Signing Requests (CSR) に移動してクリックし、CSRを生成します。
2. 表示されたページのUsageセクションで、使用するロールをドロップダウンメニューから選択します。
証明書が複数のロールに使用される場合は、Multi-Useを選択します。証明書が生成されると、必要に応じてロールを変更できます。ほとんどの場合、証明書は[Used For]ドロップダウンで多用途に使用されるように設定できます。これにより、すべてのISE Webポータルで証明書を使用できるようになります。
3. ISEノードの横にあるチェックボックスをオンにして、証明書を生成するノードを選択します。
4. ワイルドカード証明書のインストールまたは生成を目的とする場合は、Allow Wildcard Certificatesボックスをオンにします。
5. ホストまたは組織(組織単位、組織、市、州、および国)の詳細に基づいてサブジェクト情報を入力します。
6. これを完了するには、Generateをクリックし、表示されるポップアップExportをクリックします。
これにより、作成されたBase 64でエンコードされた証明書要求要求がダウンロードされます。このPEMファイルは署名のためにCAに送信され、署名済み証明書CERファイル(Base 64エンコード)を取得する必要があります。
注:CNフィールドで、ISEはノードのFQDNを自動入力します。
注:ISE 1.3および1.4では、pxGridを使用するために少なくとも2つのCSRを発行する必要がありました。1つはpxGrid専用で、もう1つは残りのサービス専用です。2.0以降では、これはすべて1つのCSRに対して行われます。
注:証明書がEAP認証に使用される場合、Windowsサプリカントがサーバ証明書を拒否するため、*記号をサブジェクトCNフィールドに含めることはできません。サプリカントでサーバIDの検証が無効になっている場合でも、CNフィールドに「*」が含まれているとSSLハンドシェイクが失敗することがあります。代わりに、汎用FQDNをCNフィールドで使用してから、 *.domain.com をSAN DNS名フィールドで使用できます。一部の認証局(CA)は、CSRにワイルドカード(*)が含まれていなくても、証明書のCNに自動的にワイルドカード(*)を追加できます。このシナリオでは、このアクションを防ぐために特別な要求を発行する必要があります。
7. 証明書がCAによって署名されたら(ビデオに示されているように、CSRから生成され、Microsoft CAが使用されている場合はここ)、ISE GUIに戻り、Administration > System > Certificates > Certificate Management > Certificate Signing Requestの順に移動します。 先に作成したCSRの横にあるチェックボックスをオンにして、Bind Certificateボタンをクリックします。
8. 次に、受信した署名付き証明書をアップロードし、ISEのフレンドリ名を指定します。次に、証明書の必要性に応じて(AdminやEAP認証、ポータルなど)使用法の横にあるボックスを選択し、次の図に示すようにSubmitをクリックします。
この証明書に管理者ロールが選択されている場合、ISEノードはサービスを再起動する必要があります。VMに割り当てられているバージョンとリソースによっては、10 ~ 15分かかる場合があります。アプリケーションのステータスを確認するには、ISEコマンドラインを開いてshow application status iseコマンドを発行します。
証明書のインポート時に管理者ロールまたはポータルロールを選択した場合は、ブラウザの管理者ページまたはポータルページにアクセスしたときに新しい証明書が配置されていることを確認できます。ブラウザでロック記号を選択し、証明書の下で、パスは完全なチェーンが存在し、マシンによって信頼されていることを確認します。証明書チェーンが正しく構築されていて、証明書チェーンがブラウザで信頼されている限り、ブラウザは新しい管理者またはポータル証明書を信頼する必要があります。
注:現在のCA署名付きシステム証明書を更新するには、新しいCSRを生成し、同じオプションで署名付き証明書をシステム証明書にバインドします。アクティブになる前に新しい証明書をISEにインストールできるので、古い証明書が期限切れになる前に新しい証明書のインストールを計画します。古い証明書の有効期限と新しい証明書の開始日が重なり合う期間は、証明書を更新し、ダウンタイムをほとんど、あるいはまったく発生させずに交換を計画する時間を与えます。開始日が古い証明書の失効日より前である新しい証明書を取得します。この 2 つの日付の間の期間が移行期間です。新しい証明書が有効な日付範囲に入ったら、必要なプロトコル(Admin/EAP/Portal)を有効にします。管理者による使用が有効になっている場合は、サービスが再起動されることに注意してください。
ヒント:管理者証明書とEAP証明書、およびゲスト/スポンサー/ホットスポット/その他のポータル用の公開署名証明書には、社内CAを使用することをお勧めします。その理由は、ユーザまたはゲストがネットワークに接続し、ISEポータルがゲストポータル用にプライベート署名付き証明書を使用する場合、証明書エラーが発生するか、ポータルページからのアクセスがブラウザによってブロックされる可能性があるためです。これらをすべて回避するには、ポータルで使用する公開署名証明書を使用して、ユーザエクスペリエンスを向上させます。また、各導入ノードのIPアドレスをSANフィールドに追加して、IPアドレスを使用してサーバにアクセスするときに証明書に関する警告が表示されないようにする必要があります。
バックアップ証明書と秘密キー
次のファイルをエクスポートすることをお勧めします。
1. すべてのシステム証明書(展開内のすべてのノードから取得)とその秘密鍵(再インストールに必要)を安全な場所に保管します。証明書の設定(証明書が使用されたサービス)をメモしておきます。
2. プライマリ管理ノードの信頼された証明書ストアからのすべての証明書。証明書の設定(証明書が使用されたサービス)をメモしておきます。
3. すべての認証局証明書。
そのために –
Administration > System > Certificates > Certificate Management > System Certificatesに移動します。証明書を選択し、Exportをクリックします。Export CertificatesおよびPrivate Keysオプションボタンを選択します。秘密キーのパスワードを入力し、パスワードを確認します。をクリックします。Export
Administration > System > Certificates > Certificate Management > Trusted Certificates - に移動します。証明書を選択し、
Exportをクリックします。Save Fileをクリックして証明書をエクスポートします。
Administration > System > Certificates > Certificate Authority > Certificate Authority Certificates - に移動します。証明書を選択し、をクリックします
Export。Export CertificatesおよびPrivate Keysオプションボタンを選択します。秘密キーのパスワードとパスワードの確認を入力します。をクリックします。ExportSave Fileをクリックして証明書をエクスポートします。
トラブルシュート
証明書の有効性の確認
Cisco ISEの信頼できる証明書またはシステム証明書ストアのいずれかの証明書が期限切れになると、アップグレードプロセスは失敗します。必ずTrusted CertificatesウィンドウとSystem Certificatesウィンドウ(Administration > System > Certificates > Certificate Management)のExpiration Dateフィールドの有効性を確認し、必要に応じてアップグレードの前に証明書を更新してください。
また、CA Certificatesウィンドウ(Administration > System > Certificates > Certificate Authority > Certificate Authority Certificates)で証明書のExpiration Dateフィールドの有効性をチェックし、必要に応じてアップグレードの前に証明書を更新します。
証明書の削除
ISE内の証明書が期限切れになったり、未使用になったりした場合は、削除する必要があります。削除する前に、証明書を(該当する場合は秘密キーとともに)エクスポートしてください。
期限切れの証明書を削除するには、Administration > System > Certificates > Certificate Managementに移動します。をクリックします。System Certificates Store期限切れの証明書を選択し、Deleteをクリックします。
信頼できる証明書ストアと認証局(CA)証明書ストアについても同じ説明を参照してください。
サプリカントが802.1x認証でISEサーバ証明書を信頼しない
ISEがSSLハンドシェイクプロセスの完全な証明書チェーンを送信するかどうかを確認します。
サーバ証明書を必要とするEAP方式(つまり、PEAP)およびクライアントOS設定でサーバIDの検証が選択されている場合、サプリカントは、認証プロセスの一部として、ローカルの信頼ストアにある証明書を使用して証明書チェーンを検証します。SSLハンドシェイクプロセスの一環として、ISEは自身の証明書を提示するだけでなく、証明書チェーンに含まれるルート証明書や中間証明書も提示します。チェーンが不完全な場合、または信頼ストアにこのチェーンがない場合、サプリカントはサーバIDを検証できません。
証明書チェーンがクライアントに返されていることを確認するには、認証時にISE(Operations > Diagnostic Tools > General Tools > TCP Dump)からパケットキャプチャを取得するか、エンドポイントでWiresharkキャプチャを取得します。キャプチャを開き、Wiresharkでフィルタを適用してssl.handshake.certificates、アクセスチャレンジを見つけます。
選択したら、Expand Radius Protocol > Attribute Value Pairs > EAP-Message Last segment > Extensible Authentication Protocol > Secure Sockets Layer > Certificate > Certificatesに移動します。
チェーンが不完全な場合は、ISEAdministration > Certificates > Trusted Certificatesに移動し、ルート証明書または中間証明書(あるいはその両方)が存在することを確認します。証明書チェーンが正常に渡された場合、チェーン自体が次に説明する方法で有効であることを確認する必要があります。
各証明書(サーバ、中間、およびルート)を開き、信頼のチェーンを確認して、各証明書のサブジェクトキー識別子(SKI)と、チェーン内の次の証明書の認証局キー識別子(AKI)が一致するようにします。
ISE証明書チェーンは正しいが、認証中にエンドポイントがISEサーバ証明書を拒否する
ISEがSSLハンドシェイク用の完全な証明書チェーンを提示し、サプリカントが引き続き証明書チェーンを拒否する場合、次の手順は、ルート証明書または中間証明書(あるいはその両方)がクライアントのローカル信頼ストアにあることを確認することです。
これをWindowsデバイスから確認するには、mmc.exe(Microsoft管理コンソール)を起動し、File > Add-Remove Snap-inに移動します。[使用可能なスナップイン]列から[Certificates]を選択し、[Add]をクリックします。使用している認証タイプ(ユーザまたはマシン)に応じてMy user account またはComputer accountのいずれかを選択し、OKをクリックします。
コンソールビューでTrusted Root Certification AuthoritiesおよびIntermediate Certification Authoritiesの順に選択し、ローカルの信頼ストアにルート証明書と中間証明書が存在することを確認します。
これがサーバIDチェックの問題であることを確認する簡単な方法は、サプリカントプロファイル設定の下のValidate Server Certificateのチェックマークを外して、もう一度テストすることです。
よく寄せられる質問(FAQ)
ISEが証明書がすでに存在するという警告をスローした場合の対応
このメッセージは、ISEがまったく同じOUパラメータを持つシステム証明書を検出し、重複する証明書をインストールしようとしたことを意味します。重複したシステム証明書はサポートされていないため、新しい証明書が異なることを確認するために、市/州/部署の値を少し異なる値に変更することを推奨します。
ISEからのポータルページが信頼できないサーバによって表示されることを示す警告がブラウザで表示されるのはなぜですか。
これは、ブラウザがサーバのID証明書を信頼しない場合に発生します。
最初に、ブラウザに表示されるポータル証明書が期待どおりであり、ポータル用にISEで設定されていることを確認します。
次に、FQDN経由でポータルにアクセスします。使用するIPアドレスの場合は、証明書のSANフィールドまたはCNフィールドにFQDNとIPアドレスの両方が含まれていることを確認します。
最後に、ポータル証明書チェーン(ISEポータル、中間CA、ルートCA証明書)がクライアントOSやブラウザソフトウェアにインポートされ、信頼されていることを確認します。
注:iOS、Android OS、およびChrome/Firefoxの一部の新しいバージョンでは、証明書に対する厳格なセキュリティ要件があります。これらのポイントが満たされている場合でも、ポータルCAと中間CAがSHA-256未満であれば、接続を拒否できます。
証明書が無効なためにアップグレードが失敗する場合の対処法
Cisco ISEの信頼できる証明書またはシステム証明書ストアのいずれかの証明書が期限切れになると、アップグレードプロセスは失敗します。必ずTrusted CertificatesウィンドウとSystem Certificatesウィンドウ(Administration > System > Certificates > Certificate Management)のExpiration Dateフィールドの有効性を確認し、必要に応じてアップグレードの前に証明書を更新してください。
また、CA Certificatesウィンドウ(Administration > System > Certificates > Certificate Authority > Certificate Authority Certificates)で証明書のExpiration Dateフィールドの有効性をチェックし、必要に応じてアップグレードの前に証明書を更新します。
ISEをアップグレードする前に、内部CA証明書チェーンが有効であることを確認します。
Administration > System > Certificates > Certificate Authority Certificatesに移動します。展開内の各ノードで、Friendly Name列にCertificate Services Endpoint Sub CAが含まれる証明書を選択します。Viewをクリックし、証明書のステータスが適切であり、表示されていることを確認します。
証明書チェーンが壊れている場合は、Cisco ISEのアップグレードプロセスを開始する前に問題を修正してください。この問題を修正するには、Administration > System > Certificates > Certificate Management > Certificate Signing Requestsに移動し、ISEルートCAオプション用に生成します。
関連情報