コラボレーション エッジ（MRA）証明書の設定とトラブルシューティング
内容
概要
このドキュメントでは、モバイル リモート アクセス（MRA）の導入に関連する証明書について説明します。
前提条件
要件
このドキュメントに特有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
背景説明
パブリック認証局（CA）とプライベート認証局の比較
Expressway-C および E サーバでの証明書への署名では、いくつかのオプションがあります。GoDaddy、Verisign、またはその他のパブリック CA での証明書署名要求（CSR）による署名を選択するか、内部の独自の認証局（CA） を使用して署名する（openSSL を使用して自己署名するか、Microsoft Windows サーバなどの社内 CA を使用する）ことができます。 これらのいずれかの方法を使用して CSR を作成し署名する方法の詳細については、『Video Communication Server（VCS）証明書作成ガイド』を参照してください。
実際にパブリック CA による署名を必要とするサーバは Expressway-E のみです。 クライアントが MRA 経由での署名時以降に証明書を認識するサーバはこれのみです。したがって、パブリック CA を使用するとユーザは手動で証明書を承諾する必要がなくなります。 内部の CA を使用した Expressway-E の署名は機能しますが、ユーザは初回署名時に信頼されていない証明書を承諾するよう求められます。7800 および 8800 シリーズの電話機における MRA の登録でも、内部証明書は機能しません。これは、電話機の証明書信頼リストを変更できないためです。 簡単のため、Expressway-C と Expressway-E の両方の証明書を同じ CA で署名することをお勧めします。ただし、信頼済み CA リストを両方のサーバで正しく設定していれば、このことは必須ではありません。
証明書チェーンの仕組み
証明書は 2 つ以上の証明書のチェーンへと連結され、サーバ証明書に署名した発行元の確認に使用されます。 チェーン内の証明書には、クライアント/サーバ証明書、中間証明書（一部の場合）、ルート証明書（証明書に署名した最上位の認証局であることからルート CA とも呼ばれます）の 3 種類があります。
証明書には、チェーンを構成する 2 つの主要フィールドとして、サブジェクトと発行者が含まれています。 サブジェクトは、この証明書によって表されるサーバまたは認証局の名前です。 Expressway-C または Expressway-E の場合（あるいは他のユニファイド コミュニケーション（UC）デバイスの場合）、サブジェクトは完全修飾ドメイン名（FQDN）で構成されます。 発行者は、その特定の証明書を検証する認証局です。 最初の証明書（自己署名証明書と呼ばれます）を作成したサーバも含めて、誰もが証明書に署名することができます。そのため、サーバとクライアントには、本物であると信頼している発行者または CA のリストがあります。
証明書チェーンの最後は常に、自己署名の最上位の（ルート）証明書になります。 証明書の階層をたどっていくと、サブジェクトを基準として証明書ごとに発行者が異なっていますが、最終的にはルート CA に到達します。ルート CA ではサブジェクトと発行者が一致します。このことは、ルート CA が最上位の証明書であり、したがって、クライアントまたはサーバの信頼済み CA リストによって信頼される必要があることを示しています。
SSL ハンドシェイクの概要
次のフロー図は、SSL ハンドシェイク プロセスの詳細なシグナリング フローを示しています。図にはキーの交換と生成が含まれており、パケットのキャプチャを調べる際に役立つ場合があります。 トラバーサル ゾーンの場合、Expressway-C は常にクライアントとして動作し、同時に Expressway-E は常にサーバになります。 簡素化された交換は次のように動作します。
Expressway-C Expressway-E
– クライアントHello—>
< – サーバHello—
< – サーバ証明書 –
< – 証明書要求 –
– クライアント証明書 – >
ここではキーは交換の中にあります。接続は常に Expressway-C によって開始され、したがって Expressway-C が常にクライアントになるため、Expressway-E が最初に自身の証明書を送信します。 Expressway-C がこの証明書を検証できない場合、ハンドシェイクは解消され、自身のハンドシェイクを Expressway-E に送信しません。
また、証明書に含まれている、 Transport Layer Security（TLS）Web クライアント認証および TLS Web サーバ認証の属性も重要です。 これらの属性は、CSR に署名しようとする CA の側で決定され（Windows CA を使用している場合は選択したテンプレートによって決定され）、証明書がクライアントまたはサーバ（あるいはその両方）のロールで有効かどうかを示します。 VCS または Expressway の場合は、状況に応じてクライアントとサーバのどちらにもなる必要があるため（トラバーサル ゾーンの場合は常に同じ）、証明書にはクライアントとサーバの両方の認証属性が存在する必要があります。 Expressway-C および Expressway-E では、新しいサーバ証明書をアップロードするときに両方の属性が適用されていなければエラーになります。
証明書にこれらの属性が存在するかどうかがわからない場合は、ブラウザまたは OS で証明書の詳細を開き、[拡張キー使用法（Extended Key Usage）] セクションを調べることができます（スクリーンショットを参照）。 形式はさまざまに異なる可能性があり、証明書の確認方法によって異なります。例：
設定
Expressway-C および Expressway-E トラバーサル ゾーン/信頼
CSR の生成と署名
すでに説明したように、Expressway-C および Expressway-E の証明書は、内部または外部の CA が署名するか、あるいは openSSL を使用して自己署名する必要があります。 Expressway サーバに付属している一時証明書の使用はサポートされていません。 CA が証明書に署名していてもサブジェクト行が具体的に定義されていない、ワイルドカード証明書の使用もサポートされていません。
最初のステップとして、CSR を生成し、優先する CA タイプによる署名を行います。 このプロセスの詳細については、『証明書作成ガイド』を参照してください。 CSR の作成にあたっては、「サブジェクトの別名（SAN）」が必要であり、証明書に含める必要があることに留意してください。SAN は証明書ガイドおよび『モバイル リモート アクセス導入ガイド』にも記載されています。 新機能の導入の際に追加される場合があるため、ガイドの最新バージョンで確認してください。 使用する機能に応じて含める必要がある共通の SAN の一覧を次に示します。
Expressway-C
- ドメイン リストに追加されたすべてのドメイン（内部または外部）。
- すべての永続的なチャット ノード エイリアス（XMPP フェデレーションを使用している場合）。
- CUCM のセキュア デバイス プロファイル名（セキュア デバイス プロファイルを使用している場合）。
Expressway-E
- Expressway-C で設定されたすべてのドメイン
- すべての永続的なチャット ノード エイリアス（XMPP フェデレーションを使用している場合）。
- XMPP フェデレーション用にアドバタイズされたすべてのドメイン。
Expressway-C と Expressway-E の相互信頼設定
ユニファイド コミュニケーションのトラバーサル ゾーンにおいて接続を確立するためには、Expressway-C と Expressway-E が互いの証明書を信頼する必要があります。 次の例では、Expressway-E 証明書が下記の階層を使用してパブリック CA によって署名されたと仮定します。
証明書 3
Issuer:GoDaddy ルート CA
Subject:GoDaddy ルート CA
証明書 2
Issuer:GoDaddy ルート CA
Subject:GoDaddy 中間認証局
証明書 1
Issuer:GoDaddy 中間認証局
Subject:Expressway-E.lab.com
Expressway-C を、上記の信頼証明書 1 を使用して設定する必要があります。 通常は、実際に自身の証明書を送信しているサーバに適用されている信頼証明書に応じて、サーバは最も低いレベルのサーバ証明書のみを送信します。 つまり、Expressway-C が証明書 1 を信頼するためには証明書 2 と証明書 3 の両方を Expressway-C の信頼済み CA リストにアップロードする必要があります（[メンテナンス（Maintenance）] > [セキュリティ（Security）] > [信頼済み CA リスト（Trusted CA List）]）。 中間証明書 2 を省いた場合、Expressway-C が Expressway-E 証明書を受信するときに、その証明書を信頼済みの GoDaddy ルート CA に結び付ける方法がないため拒否されます。
証明書 3
Issuer:GoDaddy ルート CA
Subject:GoDaddy ルート CA
証明書 1
Issuer: GoDaddy 中間認証局 - 信頼されません!
Subject:Expressway-E.lab.com
また、ルートがない中間証明書のみを Expressway-C の信頼済み CA リストにアップロードした場合、Expressway-C では、GoDaddy 中間認証局は、信頼されているものの、より上位の認証局である信頼されていない GoDaddy ルート CA によって署名されていると認識されます。したがって、失敗します。
証明書 2
Issuer: GoDaddy ルート CA - 信頼されません!
Subject:GoDaddy 中間認証局
証明書 1
Issuer:GoDaddy 中間認証局
Subject:Expressway-E.lab.com
すべての中間認証局とルートが信頼済み CA リストに追加されると、証明書を検証できます。
証明書 3
Issuer:GoDaddy ルート CA - 最上位の自己署名証明書が信頼され、チェーンが完成します!
Subject:GoDaddy ルート CA
証明書 2
Issuer:GoDaddy ルート CA
Subject:GoDaddy 中間認証局
証明書 1
Issuer:GoDaddy 中間認証局
Subject:Expressway-E.lab.com
証明書チェーンがどれなのかがわからない場合は、特定の Expressway の Web インターフェイスにログインするときにブラウザで確認できます。 プロセスはブラウザによって多少異なりますが、Firefox では、アドレス バーの左端にあるロック アイコンをクリックできます。 表示されるポップアップで、[詳細情報（More Information）] > [証明書の表示（View Certificate）] > [詳細（Details）] をクリックします。 ブラウザでチェーン全体をまとめて表示できる場合は、チェーンが一番上から一番下まで表示されます。 最上位の証明書でサブジェクトと発行者が一致しない場合は、チェーン全体が表示されていないことになります。 チェーン内の各証明書自体をエクスポートすることもできます。それには、必要な証明書を強調表示した状態でエクスポートをクリックします。 これは、正しい証明書を CA の信頼リストに確実にアップロードしたかどうかわからない場合に役立ちます。
次に、Expressway-C が Expressway-E からの証明書を信頼するようになったので、反対の方向でも機能することを確認します。 Expressway-C 証明書が、Expressway-E に署名した同じ CA によって署名されている場合、プロセスはシンプルです。C に対してすでにアップロードした同じ証明書を Expressway-E の信頼済み CA リストにアップロードするだけです。 C が別の CA によって署名されている場合は、前述と同じプロセスに従う必要があります。ただし、代わりに Expressway-C 証明書に署名したチェーンを使用します。
Cisco Unified Communications Manager（CUCM）と Expressway-C 間のセキュア通信
概要
Expressway-C と Expressway-E 間のトラバーサル ゾーンとは異なり、Expressway-C と CUCM 間ではセキュアなシグナリングは必要ありません。 内部のセキュリティ ポリシーで許可されていない場合を除いて、常に、最初に MRA について CUCM でセキュアでないプロファイルで動作するように設定し、この手順に移る前に以降の導入作業が正しいことを確認してください。
CUCM と Expressway-C 間で有効にできる主なセキュリティ機能として、「TLS 検証」と「セキュア デバイス登録」の 2 つがあります。 SSL ハンドシェイクにおいて CUCM 側からの 2 つの異なる証明書を使用するため、これら 2 つの機能には重要な違いがあります。
TLS 検証 - tomcat 証明書
セキュア SIP 登録 - callmanager 証明書
CUCM と Expressway-C 間での信頼の設定
この場合における概念も、Expressway-C と Expressway-E 間の場合とまったく同じです。 最初に、CUCM が Expressway-C のサーバ証明書を信頼する必要があります。 つまり、CUCM 側で Expressway-C の中間証明書とルート証明書を、TLS 検証機能の場合は tomcat 信頼証明書としてアップロードし、セキュア デバイス登録の場合は callmanager 信頼証明書としてアップロードする必要があります。 それには、CUCM の Web GUI の右上にある [Cisco Unified OS の管理（Cisco Unified OS Administration）] に移動し、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] をクリックします。 ここでは、[証明書/証明書チェーンをアップロード（Upload Certificate/Certificate Chain）] をクリックして正しい信頼形式を選択するか、[検索（Find）] をクリックして現在アップロードされている証明書のリストを表示することができます。
また、Expressway-C が、CUCM 証明書に署名した CA を必ず信頼するように、CUCM 証明書を信頼済み CA リストに追加する必要もあります。 ほとんどの場合、CA を使用して CUCM 証明書に署名した場合は、tomcat 証明書と callmanager 証明書に同じ CA で署名する必要があります。 これらが異なる場合、TLS 検証とセキュア登録を使用するのであれば両方を信頼する必要があります。
セキュア SIP 登録では、デバイスに適用される CUCM 上のセキュア デバイス プロファイル名を必ず Expressway-C 証明書で SAN としてリストする必要もあります。 リストされていない場合、セキュア登録メッセージは、TLS 障害を示す CUCM からの「403」で失敗します。
自己署名証明書を使用している CUCM サーバ
デフォルトでは、CUCM サーバには自己署名証明書が付属しています。 これらが設定されている場合、TLS 検証とセキュア デバイス登録の両方を同時に使用することはできません。 どちらかの機能を独自に使用することは可能ですが、証明書が自己署名されているため、自己署名済みの Tomcat 証明書と自己署名済みの CallManager 証明書の両方を Expressway-C の信頼済み CA リストにアップロードする必要があります。 Expressway-C は、証明書を検証するために自身の信頼リストを検索するとき、サブジェクトが一致するものが見つかると検索を停止します。 そのため、信頼リストで tomcat か callmanager のどちらか上位の機能が動作します。 下位の機能は存在しないものとみなされて失敗します。 この問題を解決するには、CA（パブリックまたはプライベート）を使用して CUCM 証明書に署名し、その CA のみを信頼します。
Expressway-C および Expressway-E クラスタの考慮事項
クラスタ証明書
冗長化の目的で Expressway-C サーバまたは Expressway-E サーバのクラスタを使用している場合は、サーバごとに個別の CSR を生成して CA による署名を行うことを強くお勧めします。 上記のシナリオでは、各ピア証明書の共通名(CN)は同じクラスタの完全修飾ドメイン名(FQDN)、SANはクラスタのFQDNとそれぞれのピアのFQDNです（次に示します）。
クラスタFQDNをCNとして使用し、各ピアのFQDNとSAN内のクラスタFQDNを使用して、クラスタ内のすべてのノードに同じ証明書を使用できます。したがって、パブリックCAによって署名された複数の証明書のコストを回避できます。
どうしても必要な場合は、次の手順で行うことができます。または OpenSSL を使用して秘密キーと CSR の両方を手動で生成できます。
ステップ 1： クラスタのマスターでCSRを生成し、クラスタエイリアスをCNとしてリストするように設定します。 他のすべての必要な SAN と一緒に、クラスタ内のすべてのピアを別名として追加します。
ステップ 2： このCSRに署名し、マスターピアにアップロードします。
ステップ 3： rootとしてマスターにログインし、/tandberg/persistent/certsにある秘密キーをダウンロードします。
ステップ 4： 署名付き証明書と一致する秘密キーの両方をクラスタ内の他のピアにアップロードします。
信頼済み CA リスト
クラスタ内の CUCM サブスクライバとは異なり、Expressway または VCS クラスタ内のピア間で信頼済み CA リストは複製されません。 つまり、クラスタを使用している場合は、手動で各ピアの CA リストに信頼済みの証明書をアップロードする必要があります。
確認
ここでは、設定が正常に機能しているかどうかを確認します。
既存の証明書情報の確認
既存の証明書の情報を確認するにはいくつかの方法があります。 1 つ目のオプションは、Web ブラウザで前項で説明した方法を使用するものです。この方法を使用してチェーン内の特定の証明書をエクスポートすることもできます。 Expressway サーバ証明書に追加した SAN またはその他の属性を確認する必要がある場合は、グラフィカル ユーザ インターフェイス（GUI）で直接確認できます。それには、[メンテナンス（Maintenance）] > [セキュリティ証明書（Security Certificates）] > [サーバ証明書（Server Certificate）] に移動し、[復号結果を表示（Show Decoded）] をクリックします。
証明書をダウンロードしなくても、証明書の具体的な詳細をここで確認できます。 アクティブな CSR についても、関連する署名済み証明書をまだアップロードしていなければ、同じ手順を実行できます。
Wireshark での証明書の読み取り/エクスポート
SSL ハンドシェイクの Wireshark キャプチャ（証明書の交換を含む）がある場合は、実際の証明書の復号化が Wireshark によって行われ、その中からチェーン内の任意の証明書をエクスポートできます（チェーン全体が交換されると仮定）。 証明書の交換における特定のポート（トラバーサル ゾーンの場合は一般に 7001）について、パケット キャプチャをフィルタで絞り込みます。 次に、クライアントとサーバの hello パケットが SSL ハンドシェイクとともに表示されない場合は、TCP ストリーム内のパケットの 1 つを右クリックして [ここで復号化（Decode as Here）] を選択し、[SSL] を選択して、[適用（Apply）] をクリックします。 これで、正しいトラフィックがキャプチャされていれば、証明書の交換が表示されます。 ペイロードに証明書が含まれている、正しいサーバからのパケットを検索します。 以下に示すように、証明書のリストが表示されるまで下側のウィンドウで [SSL] セクションを展開します。
ここで、任意の証明書を展開してすべての詳細を表示することができます。 証明書をエクスポートする場合は、チェーン内の目的の証明書を右クリックし（証明書が複数ある場合）、[選択したパケット バイトをエクスポート（Export Selected Packet Bytes）] を選択します。 証明書の名前を入力し、[保存（Save）] をクリックします。 これで、Windows 証明書ビューアで証明書を開いたり（.cer 拡張子を付けた場合）、他の任意のツールにアップロードして分析したりできます。
トラブルシュート
ここでは、設定のトラブルシューティングに使用できる情報を示します。
証明書が Expressway で信頼されているかどうかのテスト
手動で証明書チェーンを確認し、すべてのメンバーが Expressway の信頼済み CA リストに含まれていることを確認するのが最善の方法ですが、Web GUI の [メンテナンス（Maintenance）] > [セキュリティ証明書（Security Certificates）] にある [テスト済みのクライアント証明書（Client Certificate Tested）] を使用すると、Expressway が特定のクライアント証明書を信頼することをすばやく確認できます。 すべてのデフォルト設定を同じにしたまま、ドロップダウン リストから [テスト ファイルのアップロード（pem 形式）（Upload Test File（pem format））] を選択し、検証するクライアント証明書を選択します。 証明書が信頼されていない場合は、拒否された理由を説明する次のようなエラーが表示されます。 また、エラーの下に、アップロードした証明書の復号化された情報を表示して参照することもできます。
Expressway が証明書の CRL を取得できないことを示すエラーが表示されるものの、Expressway が CRL のチェックを使用していない場合は、証明書が信頼され、他のすべての検証チェックにパスしたことを意味します。
Synergy ライト エンドポイント（7800/8800 シリーズの電話機）
これらの新しいデバイスには、既知のパブリック CA を多数含む、事前設定された証明書信頼リストが付属しています。 この信頼リストは変更できません。つまり、これらのデバイスが動作するためには、必ずこれらの一致するパブリック CA によって Expressway-E 証明書が署名される必要があります。 内部 CA または別のパブリック CA によって署名されている場合、接続は失敗します。 Jabber クライアントのようにユーザが手動で証明書を承諾するオプションはありません。
フィードバック