はじめに
このドキュメントでは、Cisco Identity Services Engine(ISE)でのサードパーティCA署名付き証明書のインストールについて説明します。 最終的な証明書ロール(EAP認証、ポータル、管理、およびpxGrid)に関係なく、プロセスは同じです。
前提条件
要件
基本的な公開キーインフラストラクチャに関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントの情報は、Cisco Identity Services Engine(ISE)リリース3.0に基づいています。同じ設定がリリース2.Xにも適用されます
本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
設定
ステップ1:証明書署名要求(CSR)を生成します。
CSRを生成するには、[Administration] > [Certificates] > [Certificate Signing Requests]に移動し、[Generate Certificate Signing Requests (CSR)]をクリックします。

- [Usage]セクションで、ドロップダウンメニューから使用するロールを選択します。証明書が複数のロールに使用されている場合は、[Multi-Use]を選択できます。証明書が生成されてからも、必要に応じてロールを変更できます。
- 証明書を生成する対象のノードを選択します。
- 必要な情報を入力します(組織単位、組織、市区町村、都道府県、国)。
注:[Common Name (CN)]フィールドで、ISEはノードの完全修飾ドメイン名(FQDN)を自動的に入力します。
ワイルドカード:
- ワイルドカード証明書を生成することを目的とする場合は、[ワイルドカード証明書を許可する]チェックボックスをオンにします。
- 証明書がEAP認証に使用されている場合、Windowsサプリカントがサーバ証明書を拒否するため、*記号が[サブジェクトCN]フィールドに含まれていてはなりません。
- サプリカントで[Validate Server Identity]が無効になっている場合でも、*がCNフィールドにある場合にSSLハンドシェイクが失敗する可能性があります。
- 代わりに、[CN]フィールドで汎用FQDNを使用でき、[サブジェクト代替名(SAN) DNS名(Subject Alternative Name (SAN) DNS名)]フィールドで*.domain.comを使用できます。
注:一部の認証局(CA)は、CSR にワイルドカードが含まれていないとしても、証明書の CN に自動的にワイルドカード(*)を追加することがあります。このシナリオでは、このアクションを防止するために特別な要求を生成する必要があります。
個々のサーバ証明書 CSR の例

ワイルドカード CSR の例

注:IPアドレスを介してサーバにアクセスする際に証明書の警告が表示されないように、各導入ノードのIPアドレスを[SAN]フィールドに追加できます。
CSRが作成されると、ISEはポップアップウィンドウを表示し、エクスポートするオプションを指定します。エクスポートされたファイルは、署名用にCAに送信されます。

ステップ2:新しい証明書チェーンをインポートします。
認証局(CA)は、完全な証明書チェーン(ルート/中間)とともに署名付きサーバ証明書を返します。 証明書を受信したら、次の手順に従って証明書をISEサーバにインポートします。
- CAによって提供されるルート証明書および(または)中間証明書をインポートするには、[Administration] > [Certificates] > [Trusted Certificates]に移動します。
- [Import] をクリックし、[Root]または[Intermediate certificate]を選択し、送信するチェックボックスをオンにします。
- サーバ証明書をインポートするには、[Administration] > [Certificates] > [Certificate Signing Requests]に移動します。
- 前に作成した CSR を選択してから、[Bind Certificate] をクリックします。
- 新しい証明書の場所を選択し、ISEはデータベースに作成および保存された秘密キーに証明書をバインドします。
注:この証明書に[Admin Role]を選択すると、特定のISEサーバサービスが再起動します。
注意:インポートされた証明書が展開のプライマリ管理ノード用であり、管理者ロールが選択されている場合、すべてのノードのサービスが次々に再起動します。この作業を実行するには、ダウンタイムが推奨されます。
確認
照明書をインポートする際に管理ロールを選択した場合は、ブラウザに管理ページを読み込むことによって、新しい証明書を検証できます。 チェーンが正しく構築されていて、証明書チェーンがブラウザによって信頼されている場合、ブラウザは新しい管理証明書を信頼する必要があります。

さらに詳しく検証するには、ブラウザで南京錠シンボルを選択し、証明書パスに完全なチェーンが含まれていて、そのチェーンがマシンで信頼されていることを確認します。これは、サーバが完全なチェーンを渡したことを直接示すことにはなりませんが、ブラウザがローカルの信頼ストアに基づいてサーバ証明書を信頼できることを示します。
トラブルシューティング
dot1x認証中にサプリカントがISEローカルサーバ証明書を信頼しない
SSL ハンドシェーク プロセス中に ISE が完全な証明書チェーンを渡していることを確認します。
サーバ証明書を必要とするEAP方式(PEAPなど)と[サーバIDの検証]が選択されている場合、サプリカントは認証プロセスの一部としてローカル信頼ストアに格納されている証明書を使用して証明書チェーンを検証します。SSLハンドシェイクプロセスの一部として、ISEは自身の証明書と、チェーンに存在するルート証明書および(または)中間証明書も提示します。チェーンが完全でないと、サプリカントはサーバ ID を検証できません。次の手順に従うことで、証明書チェーンがクライアントに返されることを確認できます。
- 認証中にISE(TCPDump)からキャプチャを取得するには、[Operations] > [Diagostic Tools] > [General Tools] > [TCP Dump]に移動します。
- キャプチャをダウンロードまたは開き、Wiresharkでフィルタssl.handshake.certificatesを適用し、アクセスチャレンジを見つけます。
- 選択したら、[Expand Radius Protocol] > [Attribute Value Pairs] > [EAP-Message Last segment] > [Extensible Authentication Protocol] > [Secure Sockets Layer] > [Certificate] > [Certificates]に移動します。
以下に、キャプチャした証明書チェーンの例を示します。

チェーンが不完全な場合は、[ISE Administration] > [Certificates] > [Trusted Certificates]に移動し、ルート証明書と(または)中間証明書が存在することを確認します。証明書チェーンが正常に渡された場合は、ここに示す方法を使用して、チェーン自体を有効として検証する必要があります。
各証明書(サーバ、中間、ルート)を開き、各証明書のSubject Key Identifier(SKI)をチェーン内の次の証明書のAuthority Key Identifier(AKI)に一致させることで、信頼のチェーンを確認します。
証明書チェーンの例。

ISE証明書チェーンは正しいが、認証中にエンドポイントがISEのサーバ証明書を拒否する
SSLハンドシェイク中にISEが完全な証明書チェーンを提示していて、サプリカントが証明書チェーンを拒否している場合、次のステップとして、ルート証明書と中間証明書のすべてがクライアントのローカル信頼ストアに存在することを確認します。
Windowsデバイスでこれを確認するには、[mmc.exe File] > [Add-Remove Snap-in]に移動します。[Available snap-ins]列から[Certificates]を選択し、[Add]をクリックします。使用中の認証タイプ(ユーザーまたはマシン)に応じて[ユーザーアカウント]または[コンピューターアカウント]を選択し、[OK]をクリックします。
コンソールビューで、[Trusted Root Certification Authorities]および[Intermediate Certification Authorities]を選択し、ローカルの信頼ストアにルート証明書と中間証明書が存在することを確認します。

これがサーバIDチェックの問題であることを確認する簡単な方法として、サプリカントプロファイル設定の下の[Validate Server Certificate]をオフにしてから、再度テストします。

関連情報