はじめに
このドキュメントでは、サードパーティの認証局(CA)によって署名された証明書をCisco Identity Services Engine(ISE)にインストールする方法について説明します。
前提条件
要件
基本的な公開キーインフラストラクチャ(PKI)に関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントの情報は、Cisco Identity Services Engine(ISE)リリース3.0に基づくものです。同じ設定がリリース2.Xにも適用されます
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
このプロセスは、最終的な証明書ロール(EAP認証、ポータル、管理者、およびpxGrid)に関係なく同じです。
設定
ステップ 1:証明書署名要求(CSR)の生成
CSRを生成するには、Administration > Certificates > Certificate Signing Requestsの順に移動し、Generate Certificate Signing Requests(CSR)をクリックします。
- 「使用」セクションで、ドロップダウンメニューから使用するロールを選択します。証明書が複数のロールに使用されている場合は、[複数回使用]を選択できます。証明書が生成されてからも、必要に応じてロールを変更できます。
- 証明書を生成できるノードを選択します。
- 必要な情報を入力します(組織単位、組織、市区町村、都道府県、国)。
注:Common Name(CN)フィールドに、ノードの完全修飾ドメイン名(FQDN)が自動的に入力されます。
ワイルドカード:
- ワイルドカード証明書を生成する場合は、Allow Wildcard Certificatesボックスにチェックマークを入れます。
- 証明書がEAP認証に使用される場合、Windowsサプリカントがサーバ証明書を拒否するため、件名CNフィールドに*記号を入れないでください。
- サプリカントでサーバIDの検証が無効になっている場合でも、CNフィールドに*があると、SSLハンドシェイクが失敗する可能性があります。
- 代わりに、汎用FQDNをCNフィールドで使用し、サブジェクト代替名(SAN)DNS名フィールドで「
*.domain.com
」を使用できます。
注:一部の認証局(CA)は、CSRにワイルドカードが含まれていなくても、証明書のCNに自動的にワイルドカード(*)を追加できます。このシナリオでは、このアクションを防ぐために特別な要求を発行する必要があります。
個々のサーバ証明書 CSR の例
ワイルドカード CSR の例
注:各導入ノードのIPアドレスをSANフィールドに追加すると、IPアドレスでサーバにアクセスするときに証明書に関する警告が表示されるのを回避できます。
CSRが作成されると、ISEにポップアップウィンドウが表示され、CSRをエクスポートするオプションが示されます。 エクスポートした後、このファイルは署名のためにCAに送信する必要があります。
ステップ 2:新しい証明書チェーンをインポートします。
認証局(CA)は、完全な証明書チェーン(ルート/中間)とともに署名付きサーバ証明書を返します。証明書を受け取ったら、次の手順を実行して証明書をISEサーバにインポートします。
- CAから提供されたルート証明書または中間証明書(あるいはその両方)をインポートするには、Administration > Certificates > Trusted Certificatesの順に選択します。
- Importをクリックし、ルート証明書または中間証明書(あるいはその両方)を選択し、送信に適用するチェックボックスをオンにします。
- サーバ証明書をインポートするため、Administration > Certificates > Certificate Signing Requestsの順に選択します。
- 前に作成した CSR を選択してから、[Bind Certificate] をクリックします。
- 新しい証明書の場所を選択すると、ISEはデータベースに作成および保存されている秘密キーに証明書をバインドします。
注:この証明書に対して管理者ロールが選択されている場合、特定のISEサーバサービスが再起動します。
注意:インポートされた証明書が展開のプライマリ管理ノード用であり、管理者ロールが選択されている場合、すべてのノードのサービスが次々に再起動されます。これは正常な動作であり、このアクティビティを実行するにはダウンタイムが推奨されます。
確認
照明書をインポートする際に管理ロールを選択した場合は、ブラウザに管理ページを読み込むことによって、新しい証明書を検証できます。証明書チェーンが正しく構築されていて、その証明書チェーンがブラウザで信頼されている限り、ブラウザは新しい管理証明書を信頼する必要があります。
さらに詳しく検証するには、ブラウザで南京錠シンボルを選択し、証明書パスに完全なチェーンが含まれていて、そのチェーンがマシンで信頼されていることを確認します。これは、サーバが完全なチェーンを渡したことを直接示すことにはなりませんが、ブラウザがローカルの信頼ストアに基づいてサーバ証明書を信頼できることを示します。
トラブルシュート
dot1x認証中にサプリカントがISEローカルサーバ証明書を信頼しない
SSL ハンドシェーク プロセス中に ISE が完全な証明書チェーンを渡していることを確認します。
サーバ証明書を必要とするEAP方式(PEAP)を使用し、サーバIDの検証が選択されている場合、サプリカントは認証プロセスの一部としてローカルの信頼ストアにある証明書を使用して証明書チェーンを検証します。SSLハンドシェイクプロセスの一環として、ISEは自身の証明書を提示するだけでなく、自身のチェーンに含まれるルート証明書や中間証明書も提示します。チェーンが完全でないと、サプリカントはサーバ ID を検証できません。証明書チェーンがクライアントに返されることを確認するには、次の手順を実行します。
- 認証中にISE(TCPDump)からキャプチャを取得するには、Operations > Diagnostic 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の順に移動し、ルート証明書と(または)中間証明書が存在することを確認します。証明書チェーンが正常に渡された場合、ここで説明する方法を使用して、チェーン自体が有効であることを確認する必要があります。
各証明書(サーバ、中間、ルート)を開き、証明書のサブジェクトキー識別子(SKI)を、チェーン内の次の証明書の認証局キー識別子(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のチェックマークを外して、もう一度テストします。
関連情報