コメントありがとうございます。
フィードバックがある場合2026年10月のeMudhra認証局（CA）のセキュリティインシデントを受けて、Webex Calling 4つのルートCAへの信頼が失われました。 証明書ベースのローカルゲートウェイトランクがこれらの機関のいずれかに依存している場合は、影響を受ける証明書またはチェーンを交換して、安全なTLS接続を維持してください。 影響を受けるトランクがオフライン、インバウンド、アウトバウンドのPSTNコールと、それに依存するオンプレミスの統合が利用できない可能性があります。
影響を受けるルート証明書は次のとおりです。
-
M サインルート TLS CA-3G
-
ECCのルートCAをデザインします-3G
-
メサインルート SC CA-3G
-
AAA証明書サービス（コモドAAAサービスルート）
AAA証明書サービスは侵害されませんでした。 ただし、影響を受けるeMudhraの中間CAにクロス署名し、侵害された証明書への代替トラストパスを提供しました。
証明書チェーンがこれらの機関に依存している証明書ベースのローカルゲートウェイ（LGW）トランクを使用しているお客様が影響を受けます。 これには、UserTrustを通じてAAA証明書サービスにチェーンされるSectigoが発行した証明書が含まれます。
Webex Callingこれで、影響を受けるローカルゲートウェイからの TLS 接続を拒否します。 インバウンドとアウトバウンドのPSTN通話、およびこれらのゲートウェイに依存するオンプレミス通話の統合は失敗します。
ゲートウェイのSIP TLSポートにアクセスできる認証済みのコンピューターから、該当するコマンドを実行します。 lgw.example.comと5061をゲートウェイのホスト名とTLSポートに置き換えてください。 外部アクセスが制限されている場合は、権限のある内部管理ホストからコマンドを実行してください。
リナックスまたはマックOS:
openssl s_client -connect lgw.example.com:5061 -showcerts </dev/nullウィンドウズ・コマンド・プロンプト：
openssl s_client -connect lgw.example.com:5061 -showcerts <NUL始める前に
- 組織のトランクを閲覧するには、コントロールハブへのアクセス許可が必要です。
- 各プライマリゲートウェイ、冗長ゲートウェイ、およびバックアップゲートウェイのゲートウェイホスト名とSIP TLSポート。
- 各ゲートウェイエンドポイントに到達できる、OpenSSLを備えた認証済みコンピューターへのアクセス。
| 1 |
ローカルゲートウェイのトランクを特定してください。
| ||||||||||
| 2 |
各ゲートウェイの証明書チェーンを調べてください。
| ||||||||||
| 3 |
証明書の件名と発行者を確認してください。
| ||||||||||
| 4 |
検査結果を解釈してください。
リストされているルートがどれも表示されず、Control Hubでトランクがオンラインになっている場合にのみ、ゲートウェイが影響を受けていないことが確認されます。 | ||||||||||
| 5 |
影響を受ける証明書チェーンを交換してください。
| ||||||||||
| 6 |
ローカルゲートウェイの接続を確認してください。
|
次にすべきこと
チェーンは正しいように見えても、トランクがオフライン、障害がある、または不明なままの場合：
- 証明書が有効で、正しくインストールされていることを確認してください。
- 中間のCAチェーン全体と、予想される証明書の同一性を確認してください。
- ゲートウェイのTLS接続と証明書検証エラーを確認してください。
- 問題が解決しない場合は、証明書プロバイダー、シスコパートナー、または Cisco Technical Assistance Center (TAC) に連絡してください。 問い合わせるときはCisco Technical Assistance Center、組織ID、影響を受けるトランクの詳細、ゲートウェイのホスト名、証明書チェーン情報、および関連するTLSエラーメッセージを教えてください。
関連情報:
