ユニファイドコミュニケーションの前提条件
ユニファイドコミュニケーションのセキュアトラバーサルゾーン接続の構成
モバイルおよびリモートアクセスや Jabber Guest などの Unified Communications 機能では、Expressway-C と Expressway-E 間の Unified Communications トラバーサル ゾーン接続が必要です。 これには以下が含まれます。
-
Expressway-C および Expressway-E に適切なセキュリティ証明書をインストールします。
-
Expressway-C と Expressway-E 間の Unified Communications トラバーサルゾーンを設定します。
 （注） |
Expressway トラバーサル ペアごとに 1 つの Unified Communications トラバーサル ゾーン のみを設定します。 つまり、Expressway-C クラスタ上に 1 つの Unified Communications トラバーサル ゾーン があり、Expressway-E クラスタ上に対応する 1 つの Unified Communications トラバーサル ゾーン があります。 |
Expressway セキュリティ証明書のインストール
Expressway-C と Expressway-E の間に信頼関係を設定する必要があります。
-
Expressway-C と Expressway-E の両方に適切なサーバ証明書をインストールします。
-
証明書には クライアント認証 拡張機能が含まれている必要があります。 統合コミュニケーション機能が有効になっている場合、この拡張機能がないとサーバ証明書をアップロードできません。
-
Expressway には、証明書署名要求 (CSR) を生成するためのメカニズムが組み込まれており、CSR を生成するための推奨される方法となっています。
-
要求に署名する CA がクライアント認証拡張機能を削除しないことを確認します。
-
生成された CSR には、クライアント認証要求と、有効になっている統合コミュニケーション機能の関連するサブジェクト代替名が含まれます ( 「統合コミュニケーションのサーバ証明書の要件」 を参照)。
-
-
CSR を生成したり、サーバ証明書を Expressway にアップロードしたりするには、 に移動します。 新しいサーバ証明書を有効にするには、Expressway を再起動する必要があります。
-
-
両方の Expressway に、Expressway のサーバー証明書に署名した機関の信頼できる認証局（CA）証明書をインストールします。
展開されるユニファイド コミュニケーション機能に応じて、追加の信頼要件があります。
モバイルおよびリモート アクセス展開の場合:
-
Expressway-C は、Unified CM および IM&P tomcat 証明書を信頼する必要があります。
-
適切な場合、Expressway-C と Expressway-E の両方がエンドポイントの証明書に署名した認証局を信頼する必要があります。
Jabber Guest の展開の場合:
-
Jabber Guest サーバがインストールされると、デフォルトで自己署名証明書が使用されます。 ただし、信頼できる認証局によって署名された証明書をインストールすることができます。 Expressway-C に、Jabber Guest サーバの自己署名証明書、または Jabber Guest サーバの証明書に署名した認証局の信頼された CA 証明書のいずれかをインストールする必要があります。
信頼できる認証局 (CA) 証明書を Expressway にアップロードするには、に移動します。 新しい信頼された CA 証明書を有効にするには、Expressway を再起動する必要があります。
-
Cisco Expressway 証明書作成および使用に関する導入ガイド（Expressway コンフィギュレーション ガイドページ）を参照してください。
暗号化された Expressway トラバーサルゾーンの設定
Expressway-C と Expressway-E 間の安全なトラバーサル ゾーン接続を介して統合コミュニケーション機能をサポートするには、次の手順を実行します。
-
Expressway-C と Expressway-E を、 Unified Communications トラバーサル タイプのゾーンで設定します。 これにより、 TLS 検証モード が オンに設定され、 メディア暗号化モード が 強制暗号化に設定された SIP TLS を使用する適切なトラバーサル ゾーン（Expressway-C で選択した場合はトラバーサル クライアント ゾーン、Expressway-E で選択した場合はトラバーサル サーバ ゾーン）が自動的に設定されます。
-
両方の Expressway は互いのサーバ証明書を信頼する必要があります。 各 Expressway はクライアントとサーバの両方の役割を果たすため、各 Expressway の証明書がクライアントとサーバの両方として有効であることを確認する必要があります。
-
Expressway は、受信した証明書を検証するために CN (共通名) ではなく SAN 属性 (サブジェクト代替名) を使用することに注意してください。
-
H.323 または暗号化されていない接続が必要な場合は、別のトラバーサル ゾーンのペアを構成します。
（注） |
Expressway-C と Expressway-E の間で ICMP がブロックされている場合、セキュア テストは "<Exp-E FQDN> 到達できません" というエラーで失敗します。 (TAC ラボでは、Expressway-C からの ICMP クエリをドロップするファイアウォール ルールを Expressway-E に作成してシミュレートしました)。 |
安全なトラバーサルゾーンを設定するには
手順
|
ステップ 1 |
に移動します。 |
||||||||||||||||||||||||||||||||||||||||||||
|
ステップ 2 |
[新規]をクリックします。 |
||||||||||||||||||||||||||||||||||||||||||||
|
ステップ 3 |
次のようにフィールドを設定します (他のすべてのフィールドはデフォルト値のままにします)。
|
||||||||||||||||||||||||||||||||||||||||||||
|
ステップ 4 |
ゾーンの作成をクリックします。 |
||||||||||||||||||||||||||||||||||||||||||||
統合コミュニケーションのサーバ証明書要件
Cisco Unified Communications Manager 証明書
モバイルおよびリモート アクセスには、次の 2 つの Cisco Unified Communications Manager 証明書が重要です。
-
CallManager 証明書
-
tomcat 証明書
これらの証明書は Cisco Unified Communications Manager に自動的にインストールされ、デフォルトでは自己署名され、同じ共通名 (CN) を持ちます。
CA 署名付き証明書の使用を推奨します。 ただし、自己署名証明書を使用する場合、2 つの証明書は異なる共通名を持つ必要があります。 Expressway は同じ CN を持つ 2 つの自己署名証明書を許可しません。 したがって、Expressway の信頼できる CA リスト内で、 CallManager と tomcat の自己署名証明書の CN が同じである場合、Expressway はそのうちの 1 つだけを信頼できます。 これは、Expressway-C と Cisco Unified Communications Manager の間のセキュアな HTTP またはセキュアな SIP のいずれかが失敗することを意味します。
（注） |
Unified CM のホスト名/IP アドレス (FQDN を推奨) 内で Unified CM ノードを定義するために使用されるパラメータは、 Unified CM tomcat 証明書内にサブジェクト別名 (SAN) として存在している必要があります。 |
また、Cisco Collaboration Systems リリース 10.5.2 の製品に対して tomcat 証明書署名要求を生成する場合は、 CSCus47235 に注意する必要があります。 この問題を回避して、ノードの FQDN が証明書にサブジェクト別名 (SAN) エントリとして含まれていることを確認する必要があります。 「リリースノート」ページの Expressway X8.5.3 リリースノートに、回避策の詳細を記載しています。
IM およびプレゼンス サービス証明書
XMPP を使用する場合、次の 2 つの IM およびプレゼンス サービス証明書が重要になります。
-
cup-xmpp 証明書
-
tomcat 証明書
CA 署名付き証明書の使用を推奨します。 ただし、自己署名証明書を使用する場合、2 つの証明書は異なる共通名を持つ必要があります。 Expressway は同じ CN を持つ 2 つの自己署名証明書を許可しません。 cup-xmpp 証明書と tomcat （自己署名）証明書の CN が同じ場合、Expressway はそのうちの 1 つだけを信頼し、Cisco Expressway-E と IM およびプレゼンス サービス サーバ間の一部の TLS 試行は失敗します。 詳細については、 CSCve56019 を参照してください。
Expressway 証明書
Expressway 証明書署名要求 (CSR) ツールは、Expressway でサポートされるユニファイド コミュニケーション機能に適切な、関連するサブジェクト代替名 (SAN) エントリを要求し、組み込みます。
次の表は、どの CSR 代替名要素がどの Unified Communications 機能に適用されるかを示しています。
|
これらの項目をサブジェクト代替名として追加します。  |
これらの目的で CSR を生成する場合 |
|||
|---|---|---|---|---|
 |
 |
|||
|
モバイルおよびリモート アクセス |
Jabber Guest |
XMPP フェデレーション |
企業間通話 |
|
|
登録ドメイン（名前に反して、Unified CM SIP 登録ドメインよりもサービス検出ドメインと共通点があります） |
Expressway-E でのみ必要 |
- |
- |
- |
|
XMPP フェデレーションドメイン |
- |
- |
Expressway-E でのみ必要 |
- |
|
IM and Presence チャット ノード エイリアス (フェデレーション グループ チャット) |
- |
- |
Required |
- |
|
Unified CM 電話セキュリティ プロファイル名 |
Expressway-C でのみ必要 |
- |
- |
- |
|
（クラスタ化システムのみ）Expressway クラスタ名 |
Expressway-C でのみ必要 |
Expressway-C でのみ必要 |
Expressway-C でのみ必要 |
- |
（注） |
|
Expressway-C / Expressway-E ごとの個別の機能要件の詳細については、以下で説明します。
Expressway-C サーバ証明書の要件
Expressway-C サーバ証明書には、サブジェクト別名 (SAN) のリストに以下の要素が含まれている必要があります。
-
Unified CM 電話セキュリティ プロファイル名: Unified CM の 電話セキュリティ プロファイル の名前は、暗号化されたトランスポート層セキュリティ (TLS) 用に設定されており、リモートアクセスを必要とするデバイスに使用されます。 完全修飾ドメイン名 (FQDN) 形式を使用し、複数のエントリはコンマで区切ります。
新しい Expressway-C ノードを既存の Expressway-C クラスタに追加するときに、新しいノードの証明書署名要求 (CSR) を生成することが重要です。 モバイルおよびリモート アクセス（MRA）クライアントのセキュアな登録が MRA 経由で必要な場合は、CUCM 上と同じようにセキュアなプロファイル名を付けることが義務付けられています。 "Unified CM 電話セキュリティプロファイル名" が単なる名前、または CUCM デバイスセキュリティプロファイルのホスト名である場合、新しいノードでの CSR の作成は失敗します。 これにより、管理者はセキュア電話プロファイル ページで、CUCM の "Unified CM 電話セキュリティ プロファイル名"の値を変更する必要が生じます。
X12.6 以降では、Unified CM 電話のセキュリティ プロファイル名は完全修飾ドメイン名 (FQDN) である必要があることが必須です。 任意の名前、ホスト名、または値にすることはできません。
たとえば、
jabbersecureprofile.domain.com、DX80SecureProfile.domain.com（注）
FQDN は複数のレベルで構成できます。 各レベルの名前には文字、数字、ハイフンのみを含めることができ、各レベルはピリオド (ドット) で区切られます。 レベル名はハイフンで始まったり終わったりすることはできず、最終的なレベル名は文字で始まる必要があります。
エンドポイントは OAuth 認証機能をサポートしています。 電話セキュリティ プロファイルの設定の詳細は次の通りです。
-
エンドポイントが電話セキュリティ プロファイルにリンクされ、デバイス セキュリティ モードが 暗号化 に設定され、 OAuth 認証が有効 になっている場合、電話のセキュリティ プロファイル名が Expressway-C 証明書のサブジェクト代替名 (SAN) リストの一部である必要はありません。
-
エンドポイントが電話セキュリティ プロファイルにリンクされており、デバイス セキュリティ モードが 暗号化 に設定されているが、 OAuth 認証が有効になっていない 場合、電話のセキュリティ プロファイル名が Expressway-C 証明書のサブジェクト代替名 (SAN) リストに含まれている必要があります。
セキュア電話プロファイルを別名として持つことは、Unified CM がそれらのプロファイルを使用するデバイスからのメッセージを転送するときに、Transport Line Signaling (TLS) を介して Expressway-C と通信できることを意味します。
-
-
IM and Presence チャット ノード エイリアス (フェデレーション グループ チャット): IM and Presence サーバーで設定されている チャット ノード エイリアス (例: chatroom1.example.com)。 これらは、フェデレーションされた連絡先との TLS 経由のグループ チャットをサポートすることを目的とした、Unified Communications XMPP フェデレーション展開にのみ必要です。
Expressway-C は、IM&P サーバーのセットを検出すると、CSR にチャット ノード エイリアスを自動的に含めます。
CSR を生成するときは、チャット ノード エイリアスに DNS 形式を使用することをお勧めします。 Expressway-E サーバ証明書の代替名に同じチャット ノード エイリアスを含める必要があります。
Expressway-E サーバ証明書の要件
Expressway-E サーバー証明書は、サブジェクト代替名 (SAN) のリストで以下に示す要素を含む必要があります。 Expressway-E が他の FQDN でも認識される場合は、 すべてのエイリアス をサーバ証明書 SAN に含める必要があります。
-
Unified CM 登録ドメイン: Unified CM 登録用に Expressway-C で設定されているすべてのドメイン。 エンドポイントデバイスと Expressway-E 間の安全な通信に必要です。
Expressway 設定および Expressway-E 証明書で使用される Unified CM 登録ドメインは、モバイルおよびリモート アクセス クライアントによって、サービス検出中に _collab-edge DNS SRV レコードを検索するために使用されます。 これらは、Unified CM での MRA 登録を可能にし、主にサービス検出を目的としています。
これらのサービス検出ドメインは SIP 登録ドメインと一致する場合と一致しない場合があります。 展開によって異なり、一致する必要はありません。 一例として、内部ネットワーク上の Unified CM で .local または同様のプライベート ドメインを使用し、Expressway-E FQDN およびサービス検出にパブリック ドメイン名を使用する展開が挙げられます。 この場合、パブリックドメイン名を SAN として Expressway-E 証明書に含める必要があります。 Unified CM で使用されるプライベートドメイン名を含める必要はありません。エッジドメインを SAN としてリストするだけで済みます。
DNS 形式を選択し、必要な FQDN を手動で指定します。 複数のドメインが必要な場合は、カンマで FQDN を区切ります。 代わりに CollabEdgeDNS 形式を選択することもできます。この形式では、入力したドメインにプレフィックス collab-edge. が追加されるだけです。 トップレベルドメインを SAN として含めたくない場合は、この形式の使用をお勧めします (次のスクリーンショットの例を参照)。
-
XMPP フェデレーション ドメイン: ポイントツーポイント XMPP フェデレーションに使用されるドメイン。 これらは IM&P サーバ上で設定され、Expressway-C でも XMPP フェデレーションのドメインとして設定する必要があります。
DNS 形式を選択し、必要な FQDN を手動で指定します。 複数のドメインが必要な場合は、カンマで FQDN を区切ります。
（注）
XMPPAddress 形式は CA によってサポートされていない可能性があり、Expressway ソフトウェアの将来のバージョンでは廃止される可能性があるため、使用しないでください。
-
IM およびプレゼンス チャット ノード エイリアス (フェデレーション グループ チャット): Expressway-C の証明書に入力されたのと同じ チャット ノード エイリアス のセット。 これらは、フェデレーションされた連絡先との TLS 経由のグループ チャットをサポートする音声およびプレゼンスの展開にのみ必要です。
（注）
チャット ノード エイリアスのリストは、Expressway-C の同等の CSR の生成 ページからコピーできます。
詳細については、「Expressway 構成ガイド」ページの「 Cisco Expressway 証明書の作成および使用の導入ガイド 」を参照してください。 http://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-installation-and-configuration-guides-list.html
MRA オンボーディングを使用する場合の mTLS の証明書
MRA 経由のアクティベーション コードのオンボーディングを有効にすると、相互 TLS に必要な CA 証明書が自動的に生成されます (相互 TLS はアクティベーション コードのオンボーディングの要件です)。 証明書は、からアクセスできる mTLS 用の CA 証明書ページで入手できます。
ドメイン証明書とサーバ名表示の管理
マルチテナンシーは Cisco Hosted Collaboration Solution (HCS) の一部であり、サービス プロバイダーが複数のテナント間で Expressway-E クラスターを共有できるようにします。
TLS 内の Server Name Indication (SNI) プロトコル拡張を使用することで、Expressway は TLS ハンドシェイク中にクライアントに提供できるドメイン固有の証明書を保存および使用できるようになりました。 この機能により、マルチテナント環境で MRA を介して登録されたエンドポイントをシームレスに統合できるようになり、証明書のドメイン名がクライアントのドメインと一致することが保証されます。 TLS ハンドシェイク中に、クライアントは ClientHello リクエストに SNI フィールドを含めます。 Expressway は証明書ストアを検索し、SNI ホスト名に一致するものを見つけようとします。 一致が見つかった場合、ドメイン固有の証明書がクライアントに返されます。
（注） |
マルチテナント モードでは、Cisco Expressway-E の ページでシステム ホスト名を、DNS で設定されているホスト名と一致するように設定する必要があります (X8.10.1 より前は大文字と小文字が区別されますが、X8.10.1 以降は大文字と小文字は区別されません)。 そうしないと、Cisco Jabber クライアントは MRA に正常に登録できません。 |
「Cisco Hosted Collaboration Solution」ページの「Multitenancy with Cisco Expressway」を参照してください。
SNI コールフロー
-
登録中の MRA クライアントで、ユーザは bob@example.com を入力します。ここで example.com はユーザのサービス ドメイン (顧客ドメイン) です。
-
クライアントは DNS 解決を実行します。
-
_collab-edge._tls.example.com に対して DNS SRV 要求を送信します。
-
DNS は要求に対して次のように応答します。
-
単一テナント設定の場合: DNS 応答には通常、サービス ドメイン内のホスト名が含まれます (例: mra-host.example.com)。
-
マルチテナント設定の場合: DNS は、ユーザのサービス ドメインとは異なるサービス プロバイダーのドメイン内のサービス プロバイダーの MRA ホスト名を返すことがあります (例: mra-host.sp.com)。
-
-
-
クライアントは SSL 接続を設定します。
-
クライアントは SNI 拡張を使用して SSL ClientHello 要求を送信します。
-
DNS によって返されたホスト名がユーザのサービス ドメインと同じドメインである場合、SNI server_name では DNS ホスト名が使用されます (変更なし)。
-
それ以外の場合、ドメインが一致しない場合は、クライアントは SNI server_name を DNS hostname とサービスドメインに設定します（たとえば、DNS によって返された mra host.sp.com の代わりに mra-host.example.com に変更します）。
-
-
Expressway-E は証明書ストアを検索し、SNI ホスト名に一致する証明書を見つけます。
-
一致が見つかった場合、Expressway-E は証明書 (SAN/dnsName=SNI ホスト名) を送り返します。
-
それ以外の場合、MRA はプラットフォーム証明書を返します。
-
-
クライアントはサーバ証明書を検証します。
-
証明書が検証されると、SSL セットアップが続行され、SSL セットアップが正常に完了します。
-
そうでない場合、証明書エラーが発生します。
-
-
-
アプリケーションデータの処理が開始されます。
（注）
SIP および HTTPS の場合、アプリケーションは SSL ネゴシエーションを直ちに開始します。 XMPP の場合、クライアントが XMPP StartTLS を受信すると SSL 接続が開始されます。
Expressway のドメイン証明書の管理
Expressway のドメイン証明書は、 ドメイン証明書 ページ () から管理します。 これらの証明書は、マルチテナント環境内の複数の顧客が Expressway-E クラスタを共有し、TLS 暗号化を使用してクライアント システムと通信したり、HTTPS 経由で Web ブラウザと通信したりする場合に、ドメインを識別するために使用されます。 ドメイン証明書ページを使用して、次のことができます。
-
現在ロードされている証明書の詳細を表示します。
-
証明書署名要求（CSR）を生成します。
-
新しいドメイン証明書をアップロードします。
-
自動証明書管理環境 (ACME) サービスを構成して、CSR を ACME プロバイダーに自動的に送信し、結果として得られたサーバ証明書を自動的に展開します。
（注） |
RSA キーに基づく証明書の使用を強くお勧めします。 DSA キーに基づく証明書などの他のタイプの証明書はテストされていないため、すべてのシナリオで Expressway で機能しない可能性があります。 信頼された CA 証明書 ページを使用して、この Expressway によって信頼されている証明機関 (CA) の証明書のリストを管理します。 |
現在アップロードされているドメイン証明書の表示
ドメインをクリックすると、ドメイン証明書データ セクションに、Expressway に現在ロードされている特定のドメイン証明書に関する情報が表示されます。
現在アップロードされているドメイン証明書ファイルを表示するには、 [表示 (デコード済み)] をクリックして判読可能な形式で表示するか、 [表示 (PEM ファイル)] をクリックして生の形式でファイルを表示します。
現在アップロードされているドメインを削除するには、[削除（Delete）] をクリックします。
（注） |
ドメイン証明書の有効期限が切れないようにしてください。期限が切れると、他の外部システムが証明書を拒否し、Expressway がそれらのシステムに接続できなくなる可能性があります。 |
新しいドメインの追加
手順
|
ステップ 1 |
に移動します。 |
|
ステップ 2 |
[新規]をクリックします。 |
|
ステップ 3 |
新しいローカルドメインの下に、追加するドメインの名前を入力します。 例:100.example-name.com です。
|
|
ステップ 4 |
[ ドメインの作成] をクリックします。 |
|
ステップ 5 |
新しいドメインは ドメイン証明書 ページに追加され、ドメインの証明書のアップロードに進むことができます。 |
証明書署名要求の生成
Expressway はドメイン CSR を生成できるため、証明書要求を生成および取得するために外部メカニズムを使用する必要がなくなります。
（注） |
|
手順
|
ステップ 1 |
に移動します。 |
||
|
ステップ 2 |
CSR を生成するドメインをクリックします。 |
||
|
ステップ 3 |
をクリックして、 [CSR の生成] ページに移動します。 |
||
|
ステップ 4 |
証明書に必要なプロパティを入力します。 Expressway がクラスタの一部である場合は、 「ドメイン証明書とクラスタ化されたシステム」（145 ページ）を参照してください。 |
||
|
ステップ 5 |
[CSR の作成（Generate CSR）]をクリックします。 システムは署名要求と関連する秘密鍵を生成します。 秘密鍵は Expressway 上に安全に保存され、表示したりダウンロードしたりすることはできません。
|
||
|
ステップ 6 |
ドメイン証明書 ページに戻ります。 ここから次のことができます:
|
新しいドメイン証明書のアップロード
署名されたドメイン証明書を認証局から受け取ったら、それを Expressway にアップロードする必要があります。 現在のドメイン証明書を新しい証明書に置き換えるには、 新しい証明書のアップロード セクションを使用します。
手順
|
ステップ 1 |
に移動します。 |
|
ステップ 2 |
[新しい証明書のアップロード（Upload new certificate）] セクションのボタンを使って、ドメイン証明書の PEM ファイルを選択してアップロードします。 |
|
ステップ 3 |
CSR を生成するために外部システムを使用した場合は、ドメイン証明書の暗号化に使用されたサーバ秘密キー PEM ファイルもアップロードする必要があります。 (このドメイン証明書の CSR を生成するために Expressway が使用された場合、秘密キー ファイルは事前に自動的に生成され、保存されています。)
|
|
ステップ 4 |
ドメイン証明書データのアップロードをクリックします。 |
自動証明書管理環境サービス
Expressway-E バージョン X12.5 以降の Automated Certificate Management Environment (ACME) サービスは、ドメイン証明書 (SNI で使用される) をリクエストおよび導入できます。
に移動すると、ドメインのリストに ACME 列が表示され、各ドメインの ACME サービスのステータスが表示されます。
ACME サービスを有効にするには、ドメイン名の横にある をクリックします。
ドメイン証明書用に ACME サービスを設定するプロセスは、サーバ証明書の場合と同じですが、Expressway-E インターフェイス内の場所が異なります。
「Expressway 構成ガイド」 ページの 「Cisco Expressway 証明書の作成および使用の導入ガイド」 を参照してください。
ドメイン証明書とクラスタシステム
CSR が生成されると、そのピアに対してのみ単一のリクエストと秘密キーの組み合わせが生成されます。
Expressway のクラスタがある場合は、ピアごとに個別の署名要求を生成する必要があります。 これらのリクエストは認証局に送信され、返されたドメイン証明書は関連する各ピアにアップロードされる必要があります。
（注） |
正しいドメイン証明書が適切なピアにアップロードされていることを確認してください。そうでない場合、各ピアに保存されている秘密キーは、アップロードされた証明書に対応しなくなります。 |
フィードバック