Expresswayにおける DNS及び証明書の ベストプラクティス CTU - Collaboration Expresswayにおける DNS及び証明書の ベストプラクティス シスコシステムズ合同会社 コラボレーションアーキテクチャ事業 コラボレーションシステムズエンジニアリング部 シニアシステムズエンジニア 高山 貴行 2016年7月21日

はじめに 本セッションではExpresswayを用いた接続を構築するために証明書及びそれに関連するDNSの ベストプラクティスについてお伝えします。 対象はExpresswayを構築する予定がある、またはしたことがあるエンジニアを想定しています。 本セッション終了後のゴールは以下の通りです。 Expresswayで用いられるDNS名とサーバ証明書、SSL/TLSの関係を理解し適切な設計、構築 を行うことができる。 DNSサーバ Expressway-C Expressway-E 認証局

アジェンダ ExpresswayにおけるSSL証明書 TLS概要 Expressway 上での証明書チェック 相互TLS（Mutual TLS：MTLS） 各シナリオにおける証明書 B2B, 複数DNSドメイン,複数ドメイン, MRA まとめ

アジェンダ ExpresswayにおけるSSL証明書 TLS概要 Expressway 上での証明書チェック 相互TLS（Mutual TLS：MTLS） 各シナリオにおける証明書 B2B, 複数DNSドメイン,複数ドメイン, MRA まとめ

証明書発行の流れ Certificate Signing Request（CSR), 認証局 CA（Certificate Authority) 認証局 サーバFQDN / DNSドメイン Alternative Names キー長, ダイジェストアルゴリズム 場所情報（国、地域） 組織情報 公開鍵 確認 CSR CA 署名済み証明書 CAは証明書中に記載する内容を選択することが可能。なので、証 明書にCSRに含まれているすべての情報が含まれるとは限らない。 5

SSL証明書の種類 SSL証明書は認証の厳格さ、コストにあわせて3種類存在する ドメイン証明書 企業証明書 EV（Extended Validation）証明書 ドメイン使用権の認証 ○ 企業の実在証明 企業の住所情報などの証明 コスト 低 中 高 その他特徴 ブラウザ側で対応していれば、アドレスバーに企業情報が緑バーで表示される（下図参照）

Cisco UCで使用する証明書 標準的な証明書は単一のホストまたはドメインを認証する。 オプション 証明書タイプ ドメイン認証 企業認証 EV認証 単一ホスト・ドメイン Yes UCC/Multiple SAN/cert (最大Xホスト・ドメイン) 複数サブドメイン：ワイルドカード証明書 No Cisco UCでサポート Cisco UCで 未サポート 標準的な証明書は単一のホストまたはドメインを認証する。 複数のホストが同一ドメインやサブドメインで共有して利用する場合、認証局はワイルドカードを利用し た証明書を提供する。ただし、シスコUCではワイルドカードは未サポート。 複数のホスト、ドメイン、サブドメインなどを利用する場合、複数SANの記載された証明書は利用可能。 UCC＝Unified Communication Cirtificate マルチドメイン（UCC）SSL証明書

証明書の選択 MRAは複数SANに対応した証明書が必要 B2B, Spark HS, CMR Cloud/CMR Hybridでは複数のSANが 必要な場合があるが、基本的には単一SANで動作可能。

証明書とドメインタイプ ドメインタイプと機能 サービスドメイン (DNS SRV): あるコラボレーションサービスを利用するホスト情報を提供するた めに使用 DNS ドメイン: ホスト名の右部分 FQDN=ホスト名+ DNS ドメイン 例: host name=www, DNS domain=cisco.com SIP ドメイン: UCM ディレクトリ URI ドメイン プレゼンスドメイン: JID（Jabber ID）で指定されるドメイン MRAを除いて、TLSのハンドシェークはDNSドメイン証明を証明書を用いて行います。

アジェンダ ExpresswayにおけるSSL証明書 TLS概要 Expressway 上での証明書チェック 相互TLS（Mutual TLS：MTLS） 各シナリオにおける証明書 B2B, 複数DNSドメイン,複数ドメイン, MRA まとめ

TLSの目的 2つのアプリケーション間においてプライバシーとデータ整合性を提供するのが目的。 TCPなどの信頼できるトランスポート上で利用する。 上位のプロトコルをカプセル化用に利用（TLSレコードプロトコル）。 TLSハンドシェイクにより、上位アプリケーションがやりとりを開始する前に認証を行 い、暗号化アルゴリズムや暗号鍵を交渉する。

TLS ハンドシェイク動作概要 共通鍵は直接交換は行わない 。 マスターシックレットからセッションキーが生成される。 クライアントハロー 能力値とクライント指 定ランダム値 クライアントによるチェック - 証明書の電子署名 - 証明書チェーン - 執行日時 - 証明書の執行状況 - ホスト名とCA/SANとの比較 <公開鍵> サーバハロー 証明書の送付 クライアントはプリマスターシークレットを生成しサーバに送る。その際の暗号化はサーバの公 開鍵を利用する. 共通鍵は直接交換は行わない 。 マスターシックレットからセッションキーが生成される。 クライアントとサーバは公開鍵を利用して通信を開始し、その後共通鍵を利用して通信を 行う。 クライアント側の証明書は不要。 How SSL and TLS provide authentication For server authentication, the client uses the server's public key to encrypt the data that is used to compute the secret key. The server can generate the secret key only if it can decrypt that data with the correct private key. For client authentication, the server uses the public key in the client certificate to decrypt the data the client sends during step 5 of the handshake. The exchange of finished messages that are encrypted with the secret key (steps 7 and 8 in the overview) confirms that authentication is complete. If any of the authentication steps fail, the handshake fails and the session terminates. The exchange of digital certificates during the SSLor TLS handshake is part of the authentication process. For more information about how certificates provide protection against impersonation, refer to the related information. The certificates required are as follows, where CA X issues the certificate to the SSL or TLS client, and CA Y issues the certificate to the SSL or TLS server: For server authentication only, the SSL or TLS server needs: The personal certificate issued to the server by CA Y The server's private key and the SSL or TLS client needs: The CA certificate for CA Y If the SSL or TLS server requires client authentication, the server verifies the client's identity by verifying the client's digital certificate with the public key for the CA that issued the personal certificate to the client, in this case CA X. For both server and client authentication, the server needs: The CA certificate for CA X and the client needs: The personal certificate issued to the client by CA X The client's private key Both the SSL or TLS server and client might need other CA certificates to form a certificate chain to the root CA certificate. For more information about certificate chains, refer to the related information. What happens during certificate verification As noted in steps 3 and 6 of the overview, the SSL or TLS client verifies the server's certificate, and the SSL or TLS server verifies the client's certificate. There are four aspects to this verification: The digital signature is checked (see Digital signatures in SSL and TLS). The certificate chain is checked you should have intermediate CA certificates (see How certificate chains work). The expiry and activation dates and the validity period are checked. The revocation status of the certificate is checked (see Working with revoked certificates). Secret key reset During an SSL or TLS handshake a secret key is generated to encrypt data between the SSL or TLS client and server. The secret key is used in a mathematical formula that is applied to the data to transform plaintext into unreadable ciphertext, and ciphertext into plaintext. The secret key is generated from the random text sent as part of the handshake and is used to encrypt plaintext into ciphertext. The secret key is also used in the MAC (Message Authentication Code) algorithm, which is used to determine whether a message has been altered. See Message digests and digital signatures for more information. If the secret key is discovered, the plaintext of a message could be deciphered from the ciphertext, or the message digest could be calculated, allowing messages to be altered without detection. Even for a complex algorithm, the plaintext can eventually be discovered by applying every possible mathematical transformation to the ciphertext. To minimize the amount of data that can be deciphered or altered if the secret key is broken, the secret key can be renegotiated periodically. When the secret key has been renegotiated, the previous secret key can no longer be used to decrypt data encrypted with the new secret key. How SSL and TLS provide confidentiality SSL and TLS use a combination of symmetric and asymmetric encryption to ensure message privacy. During the SSL or TLS handshake, the SSL or TLS client and server agree an encryption algorithm and a shared secret key to be used for one session only. All messages transmitted between the SSL or TLS client and server are encrypted using that algorithm and key, ensuring that the message remains private even if it is intercepted. SSL supports a wide range of cryptographic algorithms. Because SSL and TLS use asymmetric encryption when transporting the shared secret key, there is no key distribution problem. For more information about encryption techniques, refer to Cryptography. How SSL and TLS provide integrity SSL and TLS provide data integrity by calculating a message digest. For more information, see Data integrity of messages. Use of SSL or TLS does ensure data integrity, provided that the CipherSpec in your channel definition uses a hash algorithm as described in the table in Specifying CipherSpecs. In particular, if data integrity is a concern, you should avoid choosing a CipherSpec whose hash algorithm is listed as "None". Use of MD5 is also strongly discouraged as this is now very old and no longer secure for most practical purposes.

TLSネゴシエーション中の証明書チェック ユーザ入力: www.wonderfulwebsite.com or wonderfulwebsite.com www.wonderfulwebsite.com wonderfulwebsite.com 1 CN=www.wonderfulwebsite.com SAN=wonderfulwebsite.com Signed by: PublicCA.example.com <Public Key> 2 クライアントは証明書の有効性をチェック(電子署名、証 明書チェーン、失効日時、失効状況)。 クライアントはホスト名がCNまたはSANとマッチするか どうかをチェックする。 TLSの検証はFQDNベースで実施 クライアントは信頼する認証局から証明書が署名されて いるかを確認。 サーバ証明書に署名しているCAの証明書はクライアント側の信頼リストに入っている必要がある。

例 ホスト名とCN/SANがマッチ ホスト名とCN/SANがマッ チしない www.google.com (IPアドレス 172.217.16.99) https://172.217.16.99/ ホスト名とCN/SANがマッチ ホスト名とCN/SANがマッ チしない

アジェンダ ExpresswayにおけるSSL証明書 TLS概要 Expressway 上での証明書チェック 相互TLS（Mutual TLS：MTLS） 各シナリオにおける証明書 B2B, 複数DNSドメイン,複数ドメイン, MRA まとめ

証明書チェックの違い ブラウザはホスト名をSAN/CNとマッチするかをチェックする。証明書は公的な認証局 によって署名されている必要がある。 ExpresswayではTLSのチェックはオプションであり、設定（TLS verify mode）を有効 にする。 TLS verify mode はTLSを利用するかどうかとは別の設定項目。 結果として、TLS確認を実施しない場合、自己証明書を利用したTLSが利用可能。

TLS verify 設定を“Off” Peer1 certifcate SAN: X509v3 Subject Alternative Name: DNS:example.com, DNS:expe.example.com TLS verify mode 設定が “Off”の場合、Expresswayはホスト名がただしく証明書に署 名してあるかをチェックしない。 IPアドレスが利用可能。 IPアドレスは対向ExpresswayのSANに含まれていないことに注意。

TLS verification設定を”on” DNSゾーンでの例 DNS Zone (outbound) 1 クライアントハロー TLS verify 設定を“On”にすると、 verify subject name とCN/SANが マッチするか、署名している認証局 はどこかをチェックする。 expe.example.com host.mypreferredpartner.com 3 証明書チェック <Public Key> ExpE Cert host.mypreferredpartner.co m Third-party Edge 2 サーバハロー

信頼済み CA PCやその他のクライアントは多くのCA証明書を初期から入れているケースが多い。 Expressway-C/EはCA証明書を持っていない。これは管理者側いれる必要がある。 プライベートルートCA 公的ルートCA (subject==Issuer： 証明対象と発行者が同一) 中間CA (subject <> Issuer： 証明対象と発行者が違う)

中間証明書 クライアントの多くはルートCAの証明書をもつが、中間CAの証明書は持っていない。 サーバはルートCA、中間CAを含めた証明書チェーンを送る必要がある。これによりクライアントはルー トCAが最終的にサーバを認証していることをチェックすることができる。 例1): MRAの場合、Expressway-Eがサーバであり8800シリーズIP Phoneがクライアント。Expressway-E の証明書が中間CAによって認証されている場合、中間CAの証明書はExpressway-Eの信頼済みCAリスト に入れておく必要がある。 例外: Expressway-C 及びExpressway-E でトラバーサル接続をする場合、中間CA証明書をクライア ント、サーバ共に信頼リスト中に上げておく必要がある。

アジェンダ ExpresswayにおけるSSL証明書 TLS概要 Expressway 上での証明書チェック 相互TLS（Mutual TLS：MTLS） 各シナリオにおける証明書 B2B, 複数DNSドメイン,複数ドメイン, MRA まとめ

相互TLS（Mutual TLS） TLS の仕様には相互TLSの内容が含まれている TLS 相互TLS クライアントはサーバ証明書をチェックする (TLS verify 設定が“on”)。 クライアントはホスト名をCN/SANと比較し、認証局情報もあわせてチェックする(TLS verify設定が “on”)。 クライアントはCA/SAN情報とTLS Verify Subject Name”もしくは“Peer Address”を比較する (TLS verify 設定が“on”)。 相互TLS サーバはクライアント側の証明書を要求し、証明書チェックを行う。

Expressway上での相互TLS トラバーサルゾーンではExpressway-Cがクライアントとして動作。 デフォルトゾーンではExpressway-Eがサーバとして動作。 DNSゾーンでは: Expressway-Eが外部へのコール時はクライアント、内部 へのコールの場合はサーバとして動作。 Spark DNS Zone TLS verify subject name がSANまたはCNにマッチした場合、DNSゾーンに着信させることができる。

Expressway-Cでの相互TLS（トラバーサルクライアント） クライアントがサーバを認証する Traversal Client Zone 1 expe.example.com クライアントハロー Expressway-C: トラバーサルクライアントはTLS verify 設定が “On”にしても相互TLSを有効化 しない。 Expressway-EnのCNまたはSANが Peerアドレスとマッチする必要がある。 証明書は信頼済み証明局に署名され ている必要がある。 expc.example.com 3 証明書チェック <Public Key> ExpE Cert expe.example.com 2 サーバハロー

Expressway-Eでの相互TLS（トラバーサルクライアント） サーバがクライアントを認証する Traversal Server Zone Expressway-E: Expressway-EにてTLS verify 設定を “On” にすることでMTLSが有効化される。 クライアント側が証明書を送付する。 Expressway-CのCNまたはSANが Expressway-Eの “TLS verify subject name”設定とマッチする。 3 <Public Key> Exp_E_Cert expc.example.com 証明書チェック クライアント証明書 2 expc.example.com expe.example.com クライアント証明書の要求 1

Expressway-C から Expressway-E Expressway-E から Expressway-C TCP, TLS または 相互TLS 利用ケース UCM から Expressway-C Expressway-C から Expressway-E Expressway-E から TCP or 相互TLS TCP, TLS or 相互TLS 1.CMR Cloud 2.CMR Hybrid 相互TLS 3.Spark Hybrid Services Expressway-C から UCM Expressway-E から Expressway-C Cloud to Expressway-E TCP, TLS or 相互TLS 1.CMR Cloud 2.CMR Hybrid N.A. 3.Spark Hybrid Services 相互TLS CMRコールバック

アジェンダ ExpresswayにおけるSSL証明書 TLS概要 Expressway 上での証明書チェック 相互TLS（Mutual TLS：MTLS） 各シナリオにおける証明書 B2B, 複数DNSドメイン,複数ドメイン, MRA まとめ

証明書と信頼リスト 一般的なシナリオ 管理者はプライベート認証局を設置し、UCMと-Expressway-Cに証明書を設定。 Cisco Collaboration Cloud 証明書と信頼リスト 一般的なシナリオ 証明書を認証したCA 信頼リスト PublicCA1 … PublicCAn TLS Cisco Unified CM Expressway-C Expressway-E TLS TLS 証明書を認証したCA 信頼リスト InternalCA 証明書を認証したCA 信頼リスト InternalCA PublicCA1 証明書を認証したCA 信頼リスト PublicCA1 InternalCA …. PublicCAn OtherCA Third-party TLS 証明書を認証したCA 信頼リスト OtherCA PublicCA1 管理者はプライベート認証局を設置し、UCMと-Expressway-Cに証明書を設定。 接続先側で信頼しているCA情報のなかから選択して証明書を要求。 Expressway-Eの信頼リスト上に追加。

B2B：Expressway-E CSRの生成 CN及びSANは FQDN=“ホスト名＋ドメイン名”を利用 ドメイン認証された証明書が必要

複数DNSドメイン： Expressway-E上内部、外部で異なるFQDNを持つケース expe.example.com 内部DNS FQDN 外部DNS FQDN expe.examplexternal.com CN=expe.example.local SAN=expe.examplexternal.com <Public Key> DNS SRV レコードで解決可能　expe.examplexternal.com Expressway-E 証明書にはexpe.examplexternal.com を含む 必要がある 複数SANをサポートしたドメイン認証証明書が必要

内部ドメインが外部からRoutableで無い場合 Expressway-EのDNSホスト名: expe.internal.local 外部からinternal.local がroutableでは無い場合、CAが証明書に署名しない場合が ある。 ただし、Expressway上でCSRを生成する場合、ホスト名expe.internal.localは常に含 まれる。 回避策としては下記の2つ。 ホスト名を expe.example.com といった外部から解決できる形式に変更する。 CSRをカスタマイズできるような外部ツールを利用する。

複数ドメインシナリオ： ドメインの種類 DNS ドメイン SIP ドメイン プレゼンスドメイン ディスカバリードメイン それぞれ別で設定が可能

ハイブリッドサービスの例: 3種類のドメインを利用する場合 SIP URI (SIP ドメイン含む): bob@exampledomain.com Spark Cloud bob DNS SRV record (includes discovery domain): _sips._tcp.discoverydomain.com CUCM expe.example.com 2 expe.example.com Exp-C FQDN: expc.internal.local 相互TLS 3 4 INVITE: bob@exampledomain.com alice がBobにコール 1 Sparkクラウドからexpe.example.com が 証明書中のCN/SANにマッチするかを チェックする。 alice

Mobile and Remote Access ドメイン MRA ドメインの一般的なオプション: ディスカバリードメイン=プレゼンスドメイン=DNS ドメイン（推奨） ディスカバリードメイン=プレゼンスドメイン<>DNS ドメイン ディスカバリードメイン<>プレゼンスドメイン<> DNS ドメイン

証明書でのSANの記載 利用する機能に応じて証明書のSANに入れるようにCSRを生成する必要がある。 追加するべきSAN 目的 MRA Login XMPP Federation Unified CM登録ドメイン （Expressway-Cで設定したドメイン。DNSまたはCollabEdgeDNS形式をCSRで利用） Expressway-Eで必要 XMPPフェデレーションドメイン IM &Pチャットノードエイリアス （フェデレートされた連絡先とのグループチャット） Expressway-C/Eで必要 Unified CM 電話セキリティプロファイル Expressway-Cで必要 ※TLSを利用するためSRVから解決されるAレコードとマッチするExpressway-Eのホスト名もSANに必要

MRA を利用した証明書及びSANの例 Expressway-E 証明書 最大3つの SANが単一IM&P向けに必要 FQDN Jabber login: luca@example.com FQDN expe.example.com DNS SRV レコード Aレコード _collab-edge._tls.example.com expe.example.com Expressway-E 証明書 XMPP及びログイン用 CN=expe.example.com SAN=expe.example.com SAN=example.com SAN=chat node alias expc.internal.local フェデレートされた連絡先とのグループチャットで利用 Jabber ID: lpellegr@example.com Directory URI: lpellegr@example.com 最大3つの SANが単一IM&P向けに必要 cucm.internal.local imp.domaininternal2.com

ログイン用のドメインをSANに入れる理由 DNS キャッシュポイズニングは比較的簡単な攻撃。 ドメイン認証した証明書は比較的入手しやすく、また追跡しづらいケースがある。 ハッカーがhackerhere.com というサイトのドメイン証明書を入手。 ハッカーはDNSキャッシュポイズニングを行い、_collabo-edge レコードへの応答を sip.hackerhere.com (Aレコード）にポイントすることが可能。これにより、Jabberからみて適切な証明書 が提供されることでログインが出来てしまう可能性がある。 ユーザがハッカーが用意したサーバに接続し、パスワードを入手されてしまう。 Jabber は証明書をチェックするだけでは無く、ログインドメイン（example.com）が証明書に含まれてい るかも確認する。example.comはハッカーが取得しているものでは無いので、認証局が認証を行って いない。これによりJabberのログインが失敗する。

アジェンダ ExpresswayにおけるSSL証明書 TLS概要 Expressway 上での証明書チェック 相互TLS（Mutual TLS：MTLS） 各シナリオにおける証明書 B2B, 複数DNSドメイン,複数ドメイン, MRA まとめ

まとめ 本セッションでは、Expressway上で利用する証明書やDNSのベストプラク ティスについて述べた。 証明書は3種類のどれでも利用可能。ただしワイルドカード利用した複数ド メインサポートはできない。 Expressway上ではルート証明書、中間証明書を含めて準備が必要。 TLSはクライアントがサーバを認証、相互TLSはサーバクライアント間で相 互認証。 使用するシナリオによって各ドメインを考慮したうえで複数SANをサポート した証明書を各Expressway-C/Eで利用する必要がある。

参考資料 Cisco Expressway Certificate Creation and Use Deployment Guide (X8.8) http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-8/Cisco-Expressway-Certificate-Creation-and-Use-Deployment-Guide-X8-8.pdf Mobile and Remote Access via Cisco Expressway Deployment Guide (X8.8) http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-8/Mobile-Remote-Access-via-Expressway-Deployment-Guide-X8-8.pdf Configuration Example: Mobile and Remote Access through Expressway/VCS in a multi-domain deployment http://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/117811-configure-vcs-00.html Cisco Expressway の証明書の設定方法 https://supportforums.cisco.com/ja/document/12559246

TLS と SRTP TLS はSIPの制御信号中のセキリティとして使われる SRTP は別の鍵情報を使用する。 SRTPのマスターキーはSDPの中に含まれTLSで暗号化した上で交換される。 セッションキーはマスターキーから生成され、端末間で交換は行われない。 TLS はHop-by-Hopで、SRTPはEnd-to-Endで使用する (B2BUA として利用 される場合は終端が異なる場合がある)

TLS/SRTP 動作概要 3 SIP Node 3 SIP Node 2 SIP Node 1 5 1 TLS TLS TLS 6 2 4 <Public Key> SIP Node 2 3 <Public Key> SIP Node 3 SIP Node 3 <Public Key> SIP Node 1 5 SIP Node 2 SIP Node 1 1 TLS TLS TLS 6 4 2 マスターキーはSDP で交換される TLS マスターキーはSDP で交換される SRTP はマスターキーから生成されたセッションキーを利用する マスターキーはSDP上で交換する。信号はTLSで暗号化される

クイズ1: CMR Cloud Cisco Unified CM Expressway-C Expressway-E WebEx Q: CMRクラウドに発信し、TLS/SRTPを利用する場合、Expressway-E上に証明書は必要でしょうか？ A: 不要。Expressway-Eはクライアントなので。

クイズ2: CMR Cloud コールバック Cisco Unified CM Expressway-C Expressway-E WebEx Q: CMRクラウドからコールバックを利用、TLS/SRTPを使う場合Expressway-E上に証明書は必要か？ A: 必要。Expressway-Eはサーバなので。

クイズ3: Spark Hybrid Services Architecture Expressway-C Connector Host Q: Spark クラウドにHTTPSを利用したセキュアな通ウィンを行う場合、Expressway-CもしくはDirectory Connectorに証明書は必要ですか？ A: 不要。Expressway-C及びDirectory ConnectorはTLSクライアント Management Connector Calendar Connector Call Connector Active Directory Directory Connector Internet HTTPS connections Expressway-C Expressway-E DMZ FW Cisco Unified CM Internal FW Spark Cloud

クイズ4: Spark Hybrid Services Architecture Q: Spark クラウドへ発信してセキュアなビデオ接続をする場合、Expressway-Eは証明書が必要ですか？ A: 必要。相互TLSではクライアントでも証明書が必要。Expresswayはサーバにもクライアントにもなる。 Expressway-C with Connectors Management Connector Calendar Connector Call Connector Active Directory Directory Connector Q: Spark クラウドからセキュアなビデオを着信した場合、Expresswayは証明書が必要ですか? A: 必要。サーバなので。 Internet Expressway-C Expressway-E SIP signaling and media DMZ FW Cisco Unified CM Internal FW