ISE 2.0 にサード パーティ CA 認証をインストールして下さい

概要

この資料は Cisco Identity Services Engine にサード パーティ CA 署名入り認証をインストールすることを記述します。

プロセスは最終的な認証ロール（EAP 認証、ポータル、Admin および pxGrid）に関係なく同じです。

要件

基本的な公開鍵インフラストラクチャ ナレッジ。

使用するコンポーネント

この文書に記載されている情報は次のハードウェア および ソフトウェア バージョンに基づいています:

• Cisco Identity Services Engine （ISE）リリース 2.0。 同じ 設定はリリース 1.3 および 1.4 に適用されます。

設定

証明書署名要求（CSR）の生成:

CSR を生成するために Administration > 認証 > 証明書署名要求に行き、Certificate Signing Requests （CSR）を『Generate』 を選択 して下さい。

• 使用方法 セクションの下でロールをメニューから廃棄使用されるために選択して下さい。 認証が複数のロールのために使用されればマルチユースを選択できます。 認証が生成されればロールは必要ならば変更することができます。
• 認証が生成されるノードを選択して下さい。
• 必要として情報に記入して下さい（組織ユニット、組織、都市、状態および国）。

注: Common Name （CN） フィールド ISE の下でオートにデータを入力する ノードか。s 完全修飾ドメイン名 （FQDN）。

ワイルドカード:

• 目標がワイルドカード 認証 チェックを生成することならか。割り当てワイルドカード 認証か。 ボックス。 
• 認証が EAP 認証のために使用されればか。*か。 シンボルはサブジェクト CN フィールドに Windows 要求元がサーバ証明を拒否するのでないはずです。
• 時でさえか。サーバ識別を検証して下さいか。 、SSL ハンドシェイクはサプリカントで失敗してもよいです時ディセーブルにされますか。*か。 CN フィールドにあります。 
• その代り次に、ジェネリック FQDN は CN フィールドで使用しか。*.domain.com か。 認証対象代替名（SAN） DNS名 フィールドで使用することができます。

注:  何人かの認証機関（CA）はそれ CSR のない提供自動的に認証の CN のワイルドカードを（*）追加するかもしれなくても。 このシナリオではこの操作を防ぐために、特別な要求は私を作りました必要とします。

個々のサーバ 認証 CSR 例:

ワイルドカード CSR 例:

注: 各 Deployment ノードか。s IP アドレスは SAN フィールドに IP アドレスによってサーバにアクセスするとき認証警告を避けるために追加することができます。

CSR が作成されたら、ISE はそれをエクスポートするオプションのウィンドウの上の pop を表示する。 エクスポートされて、このファイルは署名のための CA に送信 する必要があります。

新しい証明書 チェーンのインポート:

認証局は完全な署名チェーン（ルート/中間物）と共に署名されたサーバ証明を戻します。 受け取られる、ISE サーバに認証をインポートするために下記のステップに従って下さい。

1. 行くことによる CA によって提供される Administration > 認証 > 信頼できる証明書にルートおよび（または）中間認証をインポートして下さい。
2. 管理 >> 認証 >> 証明書署名要求に行くことによってサーバ証明をインポートして下さい。
3. 以前に作成される CSR を選択し、バインド認証をクリックして下さい。
4. 新しい認証 位置を選択すれば ISE はデータベースで作成され、保存されたプライベートキーに認証を結合 します。

注: Admin ロールがこの認証に選択される場合、ISE はサービスを再開します。

検証

admin 役割が certificate import の間に選択されたら新しい認証がブラウザことをで管理者ページをロードすることによってきちんと整っていることを確認できます。  ブラウザはチェーンが正しく構築された限り、そして証明書 チェーンがブラウザによって信頼されれば新しい admin 認証を信頼するはずです。

追加確認に関してはブラウザのロック シンボルを選択すれば認証 パスの下で完全なチェーンがマシンによって信頼されてあることを確認すれば。  これは完全なチェーンがサーバ ローカル信頼ストアに基づいてサーバ証明を信頼することできるブラウザのインジケータを正しく伝えられたこと直接インジケータではないです。

トラブルシューティング

サプリカントは dot1x 認証の間に ISE ローカルサーバ 認証を信頼しません。

ISE が SSL ハンドシェイク プロセスの間に完全な証明書 チェーンを渡していることを確認して下さい。

いつサーバ証明（すなわち PEAP）を必要とする EAP メソッドを使用してか。サーバ識別を検証して下さいか。 、サプリカント検証します認証プロセスの一部としてローカル信頼ストアで持っている認証を使用して証明書 チェーンを選択されます。 SSL ハンドシェイク プロセスの一部として ISE はチェーンで現在の認証およびまたルートおよび（または）中間認証を示します。  勝たれるサプリカントか。t はチェーンが不完全である場合サーバ識別を検証できます。 証明書 チェーンを確認することはクライアントに戻って、次のステップを実行できます渡されます:

1. 認証の間に ISE （TCPDump）からのキャプチャを奪取 して下さい。 オペレーション > Diagostic ツールの下で > 汎用ツール > TCP ダンプする見つけました
2. ダウンロードし、/キャプチャを開き、フィルタを適用して下さいか。ssl.handshake.certificates か。  Wireshark でアクセス チャレンジを見つければ。
3. 選択される、RADIUSプロトコル > 属性値ペア > EAP メッセージ最後セグメント > Extensible Authentication Protocol > Secure Sockets Layer > 認証 > 認証を拡張して下さい

 キャプチャの証明書 チェーン。

チェーンが完了しなかった場合 ISE Administration > 認証 > 信頼できる証明書に行き、ルートおよび（または）中間認証があることを確認する必要があります。 証明書 チェーンが正常に渡される場合、チェーン自体は有効なとして下記に説明されている方式の使用によって確認する必要があります。 

各認証（サーバ、中間物およびルート）を開き、チェーンの次の認証の機関キー識別子（AKI）に各認証のサブジェクト キー識別子（スキー）を一致させることによって信頼のチェーンを確認して下さい。

証明書 チェーンの例。 

ISE 証明書 チェーンは正しいしかしエンドポイント リジェクト ISE ですか。認証の間の s サーバ証明。

ISE が示せば SSL ハンドシェイクおよびサプリカントの間の完全な証明書 チェーンはまだ証明書 チェーンを拒否しています; 次 の ステップはルート and（or）中間認証がクライアント ローカル信頼ストアにあることを確認することです。

これを > 利用可能 なスナップ ins カラム選定された認証 > Add からの Windows デバイス開いた mmc.exe ファイル > Add Remove Snap-In から確認するために > どちらかを選択して下さいか。ユーザアカウントか。 コンピューター アカウントか。 使用中の認証種別によって（ユーザかマシン）。  > 良い

コンソール ビューの下で選択して下さいか。信頼されたルート認証局か。 およびか。中間認証局 （CA）か。 ローカル信頼ストアのルートおよび中間物認証の存在を確認するため。

これがサーバ識別チェック問題であることを確認する簡単な方法は、チェックを外しますか。サーバ証明を検証して下さいか。 サプリカント プロファイル設定の下でそれを再度テストすれば。

注: ISE は署名アルゴリズムとして RSASSA-PSS を使用して現在 認証の処理をサポートしません。 これにはサーバ証明、ルート、中間物またはクライアント 認証（すなわち TLS、PEAP （TLS）、等）が含まれています。  不具合 CSCug22137 を参照して下さい。  

参考資料

• Cisco Identity Services Engine 管理者ガイド、リリース 2.0