ユニファイドコミュニケーションの前提条件
ユニファイド コミュニケーションのためのセキュアなトラバーサル ゾーン接続の設定
ユニファイド コミュニケーション機能(Mobile & Remote Access、または Jabber Guest など)には、Expressway-C と Expressway-E 間にユニファイド コミュニケーション トラバーサル ゾーン接続が必要です。これには、以下が含まれます。
-
Expressway-C と Expressway-E に適切なセキュリティ証明書をインストールする。
-
Expressway-C と Expressway-E 間のユニファイド コミュニケーション トラバーサル ゾーンを設定する。
(注) |
ユニファイドコミュニケーショントラバーサルゾーンは Expressway のトラバーサルペアごとに 1 つだけ設定します。つまり、Expressway-C クラスタに 1 つのユニファイド コミュニケーション トラバーサル ゾーンと、Expressway-E クラスタに対応する 1 つのユニファイド コミュニケーション トラバーサル ゾーンです。 |
Expressway のセキュリティ証明書のインストール
Expressway-C と Expressway-E 間の信頼を設定する必要があります。
-
Expressway-C と Expressway-E の両方に適したサーバ証明書をインストールします。
-
証明書には、Client Authentication 拡張子を含める必要があります。システムにより、ユニファイド コミュニケーション機能が有効になっている場合、この拡張子を指定せずにサーバ証明書をアップロードすることはできません。
-
Expressway には、証明書署名要求(CSR)を生成する機能が組み込まれており、CSR を生成する場合に推奨される方法です。
-
要求に署名する CA がクライアント認証拡張子を除外していないことを確認します。
-
生成した CSR には、クライアント認証要求と有効化されたユニファイド コミュニケーション機能に関連するサブジェクト代替名が含まれます(「ユニファイドコミュニケーションのサーバ証明書要件」を参照してください)。
-
-
CSR を生成するか Expressway にサーバ証明書をアップロードするには、
に移動します。新しいサーバ証明書を有効にするには、Expressway を再起動する必要があります。
-
-
両方の Expressway に Expressway のサーバ証明書に署名した CA の信頼できる認証局(CA)証明書をインストールします。
展開されるユニファイド コミュニケーション機能に基づいて、次のように信頼要件が追加されます。
Mobile & Remote Access を導入する場合:
-
Expressway-C は Unified CM と IM&P の Tomcat 証明書を信頼する必要があります。
-
状況に応じて、Expressway-C と Expressway-E の両方で、エンドポイントの証明書に署名した認証局を信頼する必要があります。
Jabber Guest を導入する場合:
-
Jabber Guest サーバがインストールされると、自己署名証明書がデフォルトで使用されます。ただし、信頼できる認証局によって署名された証明書をインストールできます。Expressway-C に Jabber Guest サーバの自己署名証明書、または Jabber Guest サーバの証明書に署名した CA の信頼済み CA 証明書をインストールする必要があります。
信頼できる認証局(CA)証明書を Expressway にアップロードするには、
を選択します。新しい信頼できる CA 証明書を有効にするには、Expressway を再起動する必要があります。 -
Expressway 構成ガイドページの『Cisco Expressway 証明書作成および使用導入ガイド』を参照してください。
暗号化された Expressway トラバーサル ゾーンの設定
Expressway-C と Expressway-E 間のセキュアなトラバーサル ゾーン接続によってユニファイド コミュニケーション機能をサポートするには、次の手順を実行します。
-
ゼロタイプの Unified Communications トラバーサル を使用して Expressway-C と Expressway-E を構成します。これは自動的に適切なトラバーサル ゾーン(Expressway-C 上で選択されたときは、トラバーサル クライアント ゾーン、Expressway-E 上で選択されたときは、トラバーサル サーバ ゾーン)を設定します。そのゾーンは、[TLS 検証モード(TLS verify mode)] が [オン(On)] かつ [メディア暗号化モード(Media encryption mode)] が [強制暗号化(Force encrypted)] の状態で SIP TLS を使用します。
-
両方の Expressway はサーバ証明書を相互に信頼する必要があります。各 Expressway は、クライアントとサーバーの両方として動作するので、各 Expressway の証明書がクライアントとサーバーの両方で有効であることを確認します。
-
Expressway は、CN(共通名)ではなく SAN 属性(サブジェクトの別名)を使用して、受信した証明書を検証することに注意してください。
-
H.323 または 暗号化されていない接続が必要な場合は、トラバーサルゾーンの別のペアを構成します。
(注) |
Expressway-C と Expressway-E の間で ICMP がブロックされている場合、"<Exp-E FQDN> cannot be reached" というエラーが表示され、セキュアテストに失敗します。(TAC ラボで、Expressway-C から ICMP クエリをドロップするように Expressway-E でファイアウォールルールを作成してシミュレート)。 |
安全なトラバーサルゾーンをセットアップするには
手順
ステップ 1 |
へ移動します。 |
||||||||||||||||||||||||||||||||||||||||||||
ステップ 2 |
[新規(New)] をクリックします。 |
||||||||||||||||||||||||||||||||||||||||||||
ステップ 3 |
次のようにフィールドを設定します(他のすべてのフィールドはデフォルト値のままにします)。
|
||||||||||||||||||||||||||||||||||||||||||||
ステップ 4 |
[ゾーンの作成(Create zone)] をクリックします。 |
ユニファイド コミュニケーションのサーバ証明書要件
Cisco Unified Communications Manager の証明書
Mobile & Remote Access で重要な Cisco Unified Communications Manager 証明書は、次の 2 つです。
-
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 は失敗します。
また、シスコ コラボレーション システム リリース 10.5.2 内の製品に対して tomcat 証明書の署名要求を生成する場合、CSCus47235 に注意する必要があります。ノードの FQDN がサブジェクト代替名(SAN)エントリとして証明書に含まれるようにするため、この問題を回避する必要があります。「リリースノート」ページにある Expressway X8.5.3 のリリースノートに回避策の詳細が記載されています。
IM and Presence Service の証明書
XMPP を使用する場合に重要となる IM and Presence Service 証明書は、次の 2 つです。
-
cup-xmpp 証明書
-
tomcat 証明書
CA によって署名された証明書を使用することを推奨します。ただし、自己署名証明書を使用する場合、2 つの証明書の一般名は異なる必要があります。Expressway では同じ CN を持つ 2 つの自己署名証明書は許可されません。cup-xmpp 証明書と tomcat(自己署名)証明書が同じ CN を持つ場合、Expressway はそのうちの 1 つしか信頼せず、Cisco Expressway サーバと IM and Presence Service サーバ間の一部の TLS 試行が失敗します。詳細については、CSCve56019 を参照してください。
Expressway 証明書
Expressway の証明書署名要求(CSR)ツールでは、Expressway でサポートされるユニファイド コミュニケーション機能に適した関連するサブジェクト代替名(SAN)について確認が求められ、組み込まれます。
次の表は、どのユニファイド コミュニケーションの機能にどの CSR 代替名の要素が適用されるかを示します。
サブジェクト代替名としてこれらの項目を追加します |
これらの目的で CSR を生成する場合 |
|||
---|---|---|---|---|
モバイル & リモート アクセス |
Jabber Guest |
XMPP フェデレーション |
ビジネス ツー ビジネス コール |
|
Unified CM 登録ドメイン(ドメイン名にかかわらず、これらは Unified CM SIP 登録ドメインよりもサービス検出ドメインと共通点があります) |
Expressway-E でのみ必要 |
- |
- |
- |
XMPP フェデレーション ドメイン |
- |
- |
Expressway-E でのみ必要 |
- |
IM and Presence チャット ノード エイリアス(フェデレーテッド グループ チャット) |
- |
- |
必須 |
- |
Unified CM 電話セキュリティ プロファイル名 |
Expressway-C でのみ必要 |
- |
- |
- |
(クラスタ化されたシステムのみ)Expressway クラスタ名 |
Expressway-C でのみ必要 |
Expressway-C でのみ必要 |
Expressway-C でのみ必要 |
- |
(注) |
|
Expressway-C/Expressway-E の個々の機能要件についての詳細は、次のとおりです。
Expressway-C のサーバ証明書の要件
Expressway-E サーバ証明書には、そのサブジェクト代替名(SAN)のリストに次の要素が含まれる必要があります。
-
Unified CM 電話セキュリティ プロファイル名:暗号化されたトランスポートライン(TLS)用に設定され、リモートアクセスを必要とするデバイスに使用される Unified CM の電話セキュリティプロファイルの名前。完全修飾ドメイン名(FQDN)形式を使用し、複数のエントリをカンマで区切ります。
Expressway-C の既存のクラスタに新しい Expressway-C ノードを追加する間は、新しいノードの証明書署名要求(CSR)を生成する必要があります。CUCM でモバイルおよびリモートアクセス(CUCM)クライアントの安全な登録が必要な場合、CUCM に安全なプロファイル名を付ける必要があります。"Unified CM Phone のセキュリティプロファイル名"が CUCM デバイスのセキュリティプロファイルの名前またはホスト名だけである場合、新しいノードでの CSR の作成は失敗します。これにより、管理者は [安全な電話機プロファイル(Secure Phone Profile)] ページの下で、CUCM で "Unified CM Phone のセキュリティプロファイル名"の値を変更する必要があります。
X12.6 から、Unified CM のセキュリティプロファイル名は完全修飾ドメイン名(FQDN)である必要があります。名前、ホスト名、または値だけでは使用できません。
たとえば、
jabbersecureprofile.domain.com
、DX80SecureProfile.domain.com
(注)
FQDN は複数レベルで構成できます。各レベルの名前に使用できるのは文字、数字、ハイフンのみで、各レベルはピリオド(ドット)で区切ります。レベル名はハイフンで開始または終了できません。また、最後のレベル名は文字で開始する必要があります。
エンドポイントは OAuth 認証機能をサポートしています。電話セキュリティプロファイルの構成詳細は次のとおりです。
-
エンドポイントは、デバイスセキュリティモードが [暗号化(Encrypted)] に設定され、OAuth 認証が有効になっている電話セキュリティプロファイルにリンクされているため、電話のセキュリティプロファイル名が Expressway-C 証明書のサブジェクト代替名(SAN)リストに含まれている必要はありません。
-
エンドポイントは、デバイスセキュリティモードが [暗号化(Encrypted)] に設定されているが、OAuth 認証が有効になっていない電話セキュリティプロファイルにリンクされている場合、電話のセキュリティプロファイル名が Expressway-C 証明書のサブジェクト代替名(SAN)リストに含まれている必要があります。
代替名としてセキュア電話プロファイルを持つことは、Unified CM がそのプロファイルを使用するデバイスからメッセージを転送する場合に、Expressway-C とトランスポートラインシグナリング(TLS)経由で通信できることを意味します。
-
-
IM and Presence チャット ノード エイリアス(フェデレーテッド グループ チャット):IM and Presence サーバで設定されるチャットノードエイリアス(たとえば chatroom1.example.com)。これらは、フェデレーテッド連絡先との TLS を介したグループ チャットをサポートするユニファイド コミュニケーション 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 とサービス検出にパブリック ドメイン名を使用する展開の場合、Expressway-E の証明書にパブリック ドメイン名を SAN として含める必要があります。Unified CM で使用するプライベート ドメイン名を含める必要はありません。エッジ ドメインのみを SAN としてリストする必要があります。
DNS 形式を選択し、必要な FQDN を手動で指定します。複数のドメインが必要な場合は FQDN をカンマで区切ります。代わりに CollabEdgeDNS 形式を選択すると、入力したドメインにプリフィックス collab-edge. が追加されます。この形式は、トップ レベル ドメインを SAN として含めたくない場合に推奨されます(次のスクリーンショットの例を参照してください)。
-
XMPP フェデレーション ドメイン:ポイントツーポイント XMPP フェデレーションに使用するドメイン。これらは、IM&P サーバで設定され、XMPP フェデレーション用のドメインとして Expressway-C でも設定する必要があります。
DNS 形式を選択し、必要な FQDN を手動で指定します。複数のドメインが必要な場合は FQDN をカンマで区切ります。
(注)
XMPPAddress 形式を使用しないでください。この形式は CA によってサポートされない可能性があり、Expressway ソフトウェアの将来のバージョンでは廃止される可能性があります。
-
IM and Presence チャット ノード エイリアス(フェデレーテッド グループ チャット):Expressway-C の証明書で入力されたものと同じチャットノードエイリアスのセット。フェデレーテッド連絡先との TLS を介したグループ チャットをサポートする音声とプレゼンスの導入にのみ必要です。
(注)
チャットノードエイリアスのリストは、Expressway-C 対応の「CSR の作成(Generate CSR)」ページからコピーできます。
詳細については、Expressway 構成ガイドページの『Cisco Expressway 証明書作成および使用導入ガイド』を参照してください。
MRA オンボードを使用する場合の mTLS 証明書
MRA 上でアクティベーション コード オンボードを有効にすると、相互 TLS に必要な CA 証明書が自動的に生成されます (相互 TLS はアクティベーション コード オンボードの必須要件です)。証明書は、信頼された CA 証明書のあるページからアクセスするための mTLS 用 CA 証明書ページで使用できます(
)。ドメイン証明書および Sever Name Indication の管理
Cisco Hosted Collaboration Solution(HCS)の一部であるマルチテナンシーにより、サービス プロバイダーは複数のテナント間で Expressway-E クラスタを共有できます。
TLS 内のサーバ名指定(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 ページの『マルチテナントおよび 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 接続を設定します。
-
クライアントは、SSL ClientHello リクエストに SNI 拡張子を付けて送信します。
-
DNS によって返されたホスト名がユーザのサービス ドメインと同じドメインを持つ場合、DNS ホスト名は SNI server_name(変更なし)で使用されます。
-
それ以外の場合、ドメインが一致しなければ、クライアントは SNI server_name を DNS ホスト名とサービス ドメインに設定します(たとえば、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 のドメイン証明書は、「ドメイン証明書(Domain certificates)」ページ(
)で管理します。これらの証明書は、マルチテナント環境で複数の顧客が TLS 暗号化と HTTPS 経由の Web ブラウザを使用してクライアントシステムと通信するために Expressway-E クラスタを共有している場合に、ドメインを識別するために使用されます。[ドメイン証明書(domain certificate)] ページを使用すると、次のことを実行できます。-
現在ロードされている証明書に関する詳細の表示
-
証明書署名要求(CSR)を生成します。
-
新しいドメイン証明書のアップロード
-
ACME(Automated Certificate Management Environment)サービスが自動的に CSR を ACME プロバイダーに送信して、生成された証明書を自動的に展開するように設定します。
(注) |
RSA キーに基づく証明書を使用することを強く推奨します。DSA キーに基づく証明書など他のタイプの証明書はテストされておらず、あらゆるシナリオで Expressway と連携するとは限りません。「信頼できる CA 証明書(Trusted CA certificate)」 ページを使用して、この Expressway で信頼されている認証局(CA)の証明書のリストを管理します。 |
現在アップロードされているドメイン証明書の表示
ドメインをクリックすると、ドメイン証明書データ セクションに、現在 Expressway にロードされている特定のドメイン証明書に関する情報が表示されます。
現在アップロードされているドメイン証明書ファイルを表示する場合、人間可読形式で表示するには [表示(復号化)(Show (decoded))] をクリック、または RAW 形式でファイルを表示するには [表示(PEM ファイル)(Show (PEM file))] をクリックします。
現在アップロードされているドメインを削除するには、[削除(Delete)] をクリックします。
(注) |
ドメイン証明書を期限切れにしないでください。期限が切れると他の外部システムが証明書を拒否し、Expressway がそれらのシステムに接続できなくなります。 |
新しいドメインの追加
手順
ステップ 1 |
に移動します。 |
ステップ 2 |
[新規(New)] をクリックします。 |
ステップ 3 |
[新しいローカルドメイン]で、追加するドメインの名前を入力します。 例:100.example-name.com などがあります。
|
ステップ 4 |
[ドメインの作成(Create domain)] をクリックします。 |
ステップ 5 |
新しいドメインが [ドメイン証明書(Domain certificates)] ページに追加され、ドメインの証明書のアップロードに進むことができます。 |
証明書署名要求の生成
Expressway はドメイン CSR を生成可能で、これにより証明書要求を生成および取得するために外部メカニズムを使用する必要がなくなります。
(注) |
|
手順
ステップ 1 |
に移動します。 |
||
ステップ 2 |
CSR を生成するドメインをクリックします。 |
||
ステップ 3 |
をクリックして [CSR の作成(Generate CSR)] ページに移動します。 |
||
ステップ 4 |
証明書に必要なプロパティを入力します。 Expressway がクラスタの一部である場合、145 ページの「ドメイン証明書とクラスタ化システム」を参照してください。 |
||
ステップ 5 |
[Generate CSR] をクリックします。システムが署名要求と関連する秘密キーを生成します。秘密キーは、Expressway に安全に保存され、表示またはダウンロードすることはできません。
|
||
ステップ 6 |
「ドメイン証明書(Domain certificate)」ページに戻ります。グローバル設定に関して実行できることは次のとおりです。
|
新しいドメイン証明書のアップロード
署名付きドメイン証明書が認証局から送り戻されたら、Expressway にアップロードする必要があります。[新規証明書のアップロード(Upload new certificate)] セクションを使用して、現在のドメイン証明書を新しい証明書に置き換えます。
手順
ステップ 1 |
に移動します。 |
ステップ 2 |
[新規証明書のアップロード(Upload new certificate)] セクションの ボタンを使用して、ドメイン証明書の PEM ファイルを選択し、アップロードします。 |
ステップ 3 |
外部システムを使用して CSR を生成する場合は、ドメイン証明書を暗号化するために使用した、サーバ秘密キー PEM ファイルもアップロードする必要があります。(Expressway を使用して、このドメイン証明書用の CSR が作成された場合、秘密キー ファイルは、前もって自動的に生成および保存されます)。
|
ステップ 4 |
[ドメイン証明書データのアップロード(Upload domain certificate data)] をクリックします。 |
自動証明書管理環境サービス
バージョン X12.5 から、Expressway-E の自動証明書管理環境(ACME)サービスは、(SNI で使用される)ドメイン証明書を要求して導入できます。
に移動すると、ドメインのリストの [ACME] 列に、各ドメインの ACME サービスのステータスが示されます。
ACME サービスを有効にするドメイン名の横にある
をクリックします。ドメイン証明書用に ACME サービスを設定するプロセスは、サーバ証明書用に設定する場合と同じで、Expressway-E インターフェイスで使用する場所が異なるだけです。
Expressway 構成ガイドページの『Cisco Expressway 証明書作成および使用導入ガイド』を参照してください。
ドメイン証明書とクラスタ化システム
CSR の生成時には、1 つの要求および秘密キーの組み合わせがそのピア専用に生成されます。
Expressway のクラスタがある場合は、各ピアで個別の署名要求を生成する必要があります。これらの要求はその後、認証局に送信し、返されたドメイン証明書を関連する各ピアにアップロードする必要があります。
(注) |
正しいドメイン証明書が適切なピアにアップロードされていることを確認する必要があります。そうでないと、各ピアに保存された秘密キーがアップロードされた証明書に対応しません。 |