CSCwc69661/CSCwa25108によって導入されたMRAサービスのためのExpresswayトラフィックサーバ証明書検証のトラブルシューティング

概要

このドキュメントでは、Cisco Bug ID CSCwc69661またはCisco Bug ID CSCwa25108に関連するExpresswayバージョンX14.2.0以降での動作の変更について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Expresswayの基本設定
• MRA基本設定

使用するコンポーネント

このドキュメントの情報は、バージョンX14.2以降のCisco Expresswayに基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

この動作変更はCisco Bug ID CSCwc69661でマークされています。 またはCisco Bug ID CSCwa25108 は、Expresswayプラットフォーム上のトラフィックサーバが、Mobile and Remote Access(MRA)サービス用にCisco Unified Communication Manager(CUCM)、Cisco Unified Instant Messaging & Presence(IM&P)、およびUnityサーバノードの証明書検証を実行します。この変更により、Expresswayプラットフォームでのアップグレード後にMRAログイン障害が発生する可能性があります。  

Hypertext Transfer Protocol Secure(HTTPS)は、Transport Layer Security(TLS)を使用して通信を暗号化するセキュアな通信プロトコルです。このセキュアチャネルは、TLSハンドシェイクで交換されるTLS証明書を使用して作成されます。この方法では、認証（リモート側の接続先を知るため）とプライバシー（暗号化）の2つの目的が提供されます。認証は中間者攻撃から保護し、プライバシーは攻撃者が通信を傍受して改ざんするのを防ぎます。

TLS（証明書）検証は認証の観点で実行され、適切なリモートパーティに接続していることを確認できます。検証は、次の2つの個別の項目で構成されます。

1.信頼された認証局(CA)チェーン

2.サブジェクトの別名(SAN)または共通名(CN)

信頼されたCAチェーン

Expressway-CがCUCM/IM&P/Unityが送信する証明書を信頼するには、信頼するトップレベル（ルート）認証局(CA)へのリンクをその証明書から確立できる必要があります。このようなリンクは、エンティティ証明書をルートCA証明書にリンクする証明書の階層であり、信頼のチェーンと呼ばれます。このような信頼のチェーンを検証できるように、各証明書には、Issuer（または「Issued by」）とSubject（または「Issued To」）の2つのフィールドが含まれています。

CUCMがExpressway-Cに送信するサーバ証明書などのサーバ証明書の「Subject」フィールドには、通常、CNに完全修飾ドメイン名(FQDN)が含まれています。

        Issuer: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab

CUCM cucm.vngtp.labのサーバ証明書の例。SubjectフィールドのCN属性に、Country(C)、State(ST)、Location(L)、...などの他の属性と共にFQDNが含まれています。また、サーバ証明書がvngtp-ACTIVE-DIR-CAという名前のCAによって配布（発行）されることもわかります。

トップレベルCA（ルートCA）は、自身を識別する証明書を発行することもできます。このようなルートCA証明書では、IssuerとSubjectに同じ値(

        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA

これは、ルートCAが自身を識別するために配布する証明書です。

一般的な状況では、ルートCAはサーバ証明書を直接発行しません。代わりに、他のCAの証明書を発行します。このような他のCAは、中間CAと呼ばれます。中間CAは、サーバ証明書または他の中間CA用の証明書を直接発行できます。サーバ証明書が中間CA 1によって発行され、次に中間CA 2から証明書が取得されるという状況が発生する可能性があります。最終的に中間CAがルートCAから自身の証明書を直接取得するまで、次の手順を実行します。

Server certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1
        Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab
Intermediate CA 1 certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2 
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1 
Intermediate CA 2 certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-3 
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2 
...
Intermediate CA n certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-n 
Root CA certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-C

ここで、CUCMが送信するサーバ証明書をExpressway-Cで信頼するには、そのサーバ証明書からルートCA証明書までの信頼チェーンを構築できる必要があります。そのためには、ルートCA証明書およびすべての中間CA証明書（中間CA証明書が存在する場合。ルートCAがCUCMのサーバ証明書を直接発行する場合は該当しません）をExpressway-Cの信頼ストアにアップロードする必要があります。

注： IssuerフィールドとSubjectフィールドは、人間が読める方法で信頼のチェーンを構築するのは簡単ですが、CUCMはこれらのフィールドを証明書で使用しません。代わりに、「X509v3 Authority Key Identifier」フィールドと「X509v3 Subject Key Identifier」フィールドを使用して、信頼のチェーンを構築します。これらのキーには、Subject/Issuerフィールドを使用するより正確な証明書の識別子が含まれています。同じSubject/Issuerフィールドを持つ2つの証明書が存在する可能性がありますが、そのうちの1つは期限切れであり、1つはまだ有効です。両方とも異なるX509v3 Subject Key Identifier(PKC)を持つため、CUCMは正しい信頼チェーンを引き続き判別できます。

これはExpresswayには当てはまりません。Cisco Bug ID CSCwa12905によると、同じ共通名(CN)を持つ2つの異なる（自己署名された）証明書をExpresswayの信頼ストアにアップロードすることはできません。これを修正する方法は、CA署名付き証明書を使用するか、異なる共通名(CN)を使用するか、または常に同じ証明書を使用することを確認することです（CUCM 14の証明書再使用機能を通じて可能です）。

SANまたはCNの確認

ステップ1は信頼ストアをチェックアウトしますが、信頼ストア内のCAによって署名された証明書を持つユーザは誰でも有効です。これは明らかに十分ではありません。したがって、特に接続するサーバが実際に正しいものであることを検証する追加のチェックがあります。これは、要求が行われたアドレスに基づいて行われます。

ブラウザでも同様の操作が行われるので、例を挙げて見てみましょう。https://www.cisco.comを参照すると、入力したURLの横にロックアイコンが表示され、それが信頼できる接続であることを示します。これは、CA信頼チェーン（最初のセクションから）とSANまたはCNチェックの両方に基づいています。証明書を開くと（ブラウザのロックアイコンをクリックして）、共通名（「Issued to:」フィールドに表示）がwww.cisco.comに設定されており、接続先のアドレスに正確に対応していることがわかります。この方法で、正しいサーバに確実に接続できます（証明書に署名し、証明書を配布する前に検証を実行するCAを信頼するため）。

証明書、特にSANエントリの詳細を見ると、同じことが他のFQDNと同様に繰り返されていることがわかります。

つまり、たとえばhttps://www1.cisco.comへの接続を要求する場合、SANエントリに含まれているため、セキュアな接続として表示されます。

ただし、https://www.cisco.comをブラウズせず、IPアドレス(https://72.163.4.161)を直接参照する場合、署名したCAを信頼しますが、提示された証明書にはサーバへの接続に使用したアドレス(72.163.4.161)が含まれないため、セキュアな接続は表示されません。

ブラウザでは、これをバイパスできますが、バイパスが許可されていないTLS接続で有効にできる設定です。したがって、証明書には、リモート側が接続に使用する予定の正しいCNまたはSAN名が含まれていることが重要です。

動作の変更

MRAサービスは、CUCM/IM&P/UnityサーバへのExpressway経由の複数のHTTPS接続に大きく依存して、適切に認証し、ログインするクライアントに固有の適切な情報を収集します。この通信は通常、ポート8443および6972で発生します。

X14.2.0より前のバージョン

X14.2.0よりも前のバージョンでは、これらのセキュアHTTPS接続を処理するExpressway-Cのトラフィックサーバは、リモートエンドから提示された証明書を確認しませんでした。これにより、中間者攻撃が発生する可能性があります。MRAの設定では、Configuration > Unified Communications > Unified CM servers / IM and Presence Service nodes / Unity Connection serversでCUCM / IM&P / Unityサーバを追加する場合、「TLS Verify Mode」を「On」に設定してTLS証明書を検証するオプションがあります。設定オプションと関連する情報ボックスが例として示されています。この例では、証明書の有効性と、信頼できるCAによって署名されているかどうかだけでなく、SAN内のFQDNまたはIPも確認することを示しています。

このTLS証明書検証チェックは、CUCM/IM&P/Unityサーバの検出時にのみ実行され、MRAログイン時にさまざまなサーバが照会されることはありません。この設定の最初の欠点は、追加したパブリッシャアドレスに対してのみ検証が行われることです。サブスクライバノード上の証明書が正しく設定されているかどうかは検証されません。これは、サブスクライバノード情報（FQDNまたはIP）をパブリッシャノードのデータベースから取得するためです。この設定の2つ目の欠点は、接続情報としてMRAクライアントにアドバタイズされるものが、Expressway-C設定に設定されたパブリッシャアドレスとは異なる場合があることです。たとえば、CUCMのSystem > Serverで、IPアドレス（たとえば10.48.36.215）を使用してサーバをアドバタイズし、これがMRAクライアントによって（プロキシされたExpressway接続を介して）使用されますが、CUCM.steven.labのFQDNを使用してExpressway-CのCUCMに追加できます。CUCMのtomcat証明書にIPアドレスではなくSANエントリとしてcucm.steven.labが含まれていると、「TLS検証モード」が「オン」に設定された検出は成功しますが、MRAクライアントからの実際の通信は異なるFQDNまたはIPを対象とすることができるため、TLS検証は失敗します。

X14.2.0以降のバージョン

X14.2.0バージョン以降、Expresswayサーバは、トラフィックサーバを介して行われるすべてのHTTPS要求に対して、TLS証明書検証を実行します。つまり、CUCM/IM&P/Unityノードの検出中に「TLS Verify Mode」が「Off」に設定されている場合にも、これが実行されます。検証が成功しない場合、TLSハンドシェイクは完了せず、要求が失敗します。これにより、冗長性やフェールオーバーの問題などの機能が失われたり、ログインが完全に失敗したりする可能性があります。また、「TLS検証モード」を「オン」に設定しても、すべての接続が正常に動作するとは限りません。これについては、後の例で説明します。

ExpresswayがCUCM/IM&P/Unityノードに対してチェックする正確な証明書は、『MRAガイド』のセクションに示すとおりです。

TLS検証のデフォルト以外にも、X14.2で導入された変更があり、アップグレードパスに応じて異なる優先順位の暗号リストがアドバタイズされる可能性があります。アップグレード前にCUCM（またはECDSAアルゴリズム用の個別の証明書を持つその他の製品）からCisco TomcatまたはCisco CallManagerの証明書を要求した一方で、アップグレード後にECDSAバリアント（実際にはRSAよりも安全な暗号バリアント）を要求することが原因で、ソフトウェアアップグレード後に予期しないTLS接続が発生する可能性があります。Cisco Tomcat-ECDSAまたはCisco CallManager-ECDSA証明書は、別のCAによって署名することも、自己署名証明書だけで署名することもできます（デフォルト）。

この暗号の優先順位の変更は、Expressway X14.2.1のリリースノートに示されているアップグレードパスによって異なるため、常に関連しているとは限りません。つまり、各暗号リストのMaintenance > Security > Ciphersで、「ECDHE-RSA-AES256-GCM-SHA384:」を先頭に付加するかどうかを確認できます。そうでない場合は、RSA暗号よりも新しいECDSA暗号が優先されます。存在する場合は、以前と同様にRSAに対して動作が行われ、優先順位が高くなります。

このシナリオでTLS検証が失敗する可能性がある方法は2つあります。これについては後で詳しく説明します。

1.リモート証明書に署名したCAが信頼されていない

イ。自己署名証明書

b.不明なCAによって署名された証明書

2.接続アドレス（FQDNまたはIP）が証明書に含まれていない

シナリオのトラブルシューティング

次のシナリオは、ExpresswayをX14.0.7からX14.2にアップグレードした後にMRAログインが失敗したラボ環境で同様のシナリオを示しています。ログの内容は似ていますが、解決方法が異なります。ログは、MRAログインの前に開始され、MRAログインが失敗した後に停止された診断ログ(Maintenance > Diagnostics > Diagnostic logging)によって収集されます。追加のデバッグロギングは有効になっていません。

1.リモート証明書に署名したCAが信頼されていない

リモート証明書は、Expressway-Cの信頼ストアに含まれていないCAによって署名されているか、Expressway-Cサーバの信頼ストアに追加されていない自己署名証明書（本質的にはCA）である可能性があります。

次の例では、CUCMに送信される要求(10.48.36.215 - cucm.steven.lab)がポート8443（200 OK応答）で正しく処理され、ポート6972でTFTP接続に対してエラー（502応答）をスローすることを確認できます。

===Success connection on 8443===

2022-07-11T18:55:25.910+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,910" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Src-ip="127.0.0.1" Src-port="35764" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvODQ0Mw/cucm-uds/user/emusk/devices HTTP/1.1"

2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]:  Event="Request Allowed" Detail="Access allowed" Reason="In allow list" Username="emusk" Deployment="1" Method="GET" Request="https://cucm.steven.lab:8443/cucm-uds/user/emusk/devices" Rule="https://cucm.steven.lab:8443/cucm-uds/user/" Match="prefix" Type="Automatically generated rule for CUCM server" UTCTime="2022-07-11 16:55:25,916"
2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,916" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices HTTP/1.1"
2022-07-11T18:55:25.955+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Receive Response" Txn-id="189" TrackingID="" Src-ip="10.48.36.215" Src-port="8443" Msg="HTTP/1.1 200 "
2022-07-11T18:55:25.956+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="189" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35764" Msg="HTTP/1.1 200 "

===Failed connection on 6972===

2022-07-11T18:55:26.000+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,000" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Src-ip="127.0.0.1" Src-port="35766" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvNjk3Mg/CSFemusk.cnf.xml HTTP/1.1"

2022-07-11T18:55:26.006+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,006" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,016" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] WARNING: Core server certificate verification failed for (cucm.steven.lab). Action=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215) depth=0
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] ERROR: SSL connection failed for 'cucm.steven.lab': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2022-07-11T18:55:26.024+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,024" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="191" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35766" Msg="HTTP/1.1 502 connect failed"

「certificate verify failed」というエラーは、Expressway-CがTLSハンドシェイクを検証できなかったことを示しています。その理由は、自己署名証明書を示すため、警告行に表示されます。深さが0と表示されている場合は、自己署名証明書です。深さが0よりも大きい場合、証明書チェーンが存在し、不明なCAによって署名されていることを意味します（Expressway-Cから見た場合）。

テキストログから示されたタイムスタンプで収集されたpcapファイルを調べると、CUCMがCNがcucm-ms.steven.lab（およびSANがcucm.steven.lab）で、steven-DC-CAによって署名された証明書を、ポート8443のExpressway-Cに提示していることがわかります。

しかし、ポート6972で提示された証明書を検査すると、cucm-EC.steven.labとして設定されたCNを持つ自己署名証明書（発行者それ自体）であることがわかります。-EC拡張子は、これがCUCMで設定されたECDSA証明書であることを示します。

CUCMのCisco Unified OS Administrationで、次に示すように、Security > Certificate Managementの下に配置されている証明書を確認できます。tomcatとtomcat-ECDSA用の異なる証明書が表示されます。この証明書では、tomcatがCA署名されている（Expressway-Cによって信頼されている）のに対し、tomcat-ECDSA証明書は自己署名されており、Expressway-Cでは信頼されていません。

2.接続アドレス（FQDNまたはIP）が証明書に含まれていない

信頼ストアとは別に、トラフィックサーバはMRAクライアントが要求を行う接続アドレスも確認します。たとえば、CUCMでIPアドレス(10.48.36.215)を使用してSystem > Serverを設定した場合、Expressway-Cはそのようにクライアントにアドバタイズし、クライアントからの後続の要求（Expressway-C経由でプロキシされる）はこのアドレスに向けてターゲットになります。

サーバ証明書にその特定の接続アドレスが含まれていない場合、TLS検証も失敗し、502エラーがスローされます。このエラーは、たとえばMRAログインが失敗する原因となります。

2022-07-11T19:49:01.472+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,472" Module="network.http.trafficserver" Level="DEBUG": Detail="Receive Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Src-ip="127.0.0.1" Src-port="30044" Last-via-addr=""
HTTPMSG:
|GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw/cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...

2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1"
2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="DEBUG": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443"
HTTPMSG:
|GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...

2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] WARNING: SNI (10.48.36.215) not in certificate. Action=Terminate server=10.48.36.215(10.48.36.215)
2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] ERROR: SSL connection failed for '10.48.36.215': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mwは(base64 - https://www.base64decode.org/)をsteven.lab/https/10.48.36.215/8443に変換します。これは、接続アドレスとしてcucm.steven.labではなく10.48.36.215に接続する必要があることを示しています。パケットキャプチャに示されているように、CUCM tomcat証明書にはSANのIPアドレスが含まれていないため、エラーが発生します。

簡単に検証する方法

次の手順で、この動作が簡単に変更されるかどうかを検証できます。

1. Maintenance > Diagnostics > Diagnostic Logging（クラスタの場合はプライマリノードから開始すれば十分）から、Expressway-EおよびCサーバ（理想的にはTCPDumpsが有効な状態）の診断ログを開始します

2.アップグレード後にMRAログインを試行するか、中断された機能をテストします

3.障害が発生するまで待ってから、Expressway-EおよびCサーバの診断ログを停止します（クラスタの場合は、クラスタの各ノードから個別にログを収集してください）

4. Collaboration Solution Analyzerツールのログをアップロードして分析する

5.問題が発生した場合は、影響を受ける各サーバについて、この変更に関連する最新の警告ラインとエラーラインがピックアップされます

CA診断シグニチャ

SNI診断シグニチャ

解決方法

長期的な解決策は、TLS検証が正常に機能することを確認することです。実行するアクションは、表示される警告メッセージによって異なります。

WARNING: Core server certificate verification failed for (<server-FQDN-or-IP>)Action=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215) depth=xメッセージを受け取った場合は、それに応じてExpressway-Cサーバの信頼ストアを更新する必要があります。この証明書に署名したCAチェーン(depth > 0)を使用するか、Maintenance > Security > Trusted CA Certificateから自己署名証明書(depth = 0)を使用します。この操作は、クラスタ内のすべてのサーバで実行してください。別のオプションとして、Expressway-C信頼ストア上の既知のCAによってリモート証明書に署名する方法があります。

注： Expresswayでは、Cisco Bug ID CSCwa12905に従って、同じ共通名(CN)を持つ2つの異なる（たとえば自己署名された）証明書をExpresswayの信頼ストアにアップロードすることはできません。これを修正するには、CA署名付き証明書に移動するか、CUCMをバージョン14にアップグレードします。バージョン14では、TomcatとCallManagerに同じ（自己署名）証明書を再利用できます。

WARNING: SNI (<server-FQDN-or-IP>) not in certificateメッセージが表示された場合は、提示された証明書にこのサーバのFQDNまたはIPが含まれていないことを示しています。この情報を含めるように証明書を適合させるか、設定を変更して（CUCMのシステム>サーバのように、サーバ証明書に含まれるものに変更できます）、Expressway-Cサーバの設定を更新して、この設定を考慮に入れることができます。

短期的な解決策は、X14.2.0より前の動作にフォールバックするために、文書化されている回避策を適用することです。新しく導入されたコマンドを使用して、Expressway-Cサーバノード上のCLIを介してこれを実行できます。

xConfiguration EdgeConfigServer VerifyOriginServer: Off