この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
デフォルトのセキュリティとして、Cisco Unified IP Phone には次の自動化されたセキュリティ機能が用意されています。
Cisco Unified Communications Manager リリース 8.0 以降では、CTL クライアントが実行されているかどうかにかかわらず、これらのセキュリティ機能がデフォルトで提供されています。
信頼検証サービス(TVS)はデフォルト セキュリティの主要コンポーネントです。TVS を使用すると Cisco Unified IP Phoneは HTTPS 確立時に EM サービス、ディレクトリ、MIDlet などのアプリケーション サーバを認証できます。
柔軟性:信頼証明書の追加や削除はシステムに自動的に反映されます。
デフォルトのセキュリティ:非メディアおよびシグナリング セキュリティ機能はデフォルトのインストールに含まれており、ユーザの介入は必要ではありません。
(注) | セキュアなシグナリングおよびメディアを有効にすると、CTL ファイルを作成し、クラスタを混合モードに設定する必要があります。これらの変更には、CTL クライアントを使用するか、または CLI コマンドの utils ctl set-cluster non-secure-mode を使用して CTL ファイルを作成し、1 つの手順でセキュリティ モードを変更します。 |
TVS は Cisco Unified Communications Manager サーバ上で動作し、 Cisco Unified IP Phone の代わりに証明書を認証します。
信頼できる証明書をすべてダウンロードするのではなく、 Cisco Unified IP Phone では TVS を信頼するだけで済みます。
TVS 証明書およびいくつかのキー証明書が、初期信頼リスト ファイル(ITL)と呼ばれる新しいファイルにまとめられます。
ITL ファイルはユーザの介入なしで自動的に生成されます。
ITL ファイルは、 Cisco Unified IP Phone からダウンロードされ、そこから信頼情報がフローします。
次のタスクを実行するには、Cisco Unified IP Phone に初期信頼リスト(ITL)が必要です。
コンフィギュレーション ファイルの署名を認証する。
CAPF とセキュアに通話する。コンフィギュレーション ファイル暗号化サポートの前提条件です。
信頼検証サービス(TVS。他の機能の中で HTTPS 証明書を認証します)。
Cisco Unified IP Phone に CTL ファイルがまだ存在していない場合、最初の ITL ファイルが CTL ファイルと同様に信頼されます。後続の ITL ファイルは、TFTP サーバの CallManager 証明書に関連付けられたのと同じ秘密キーで署名されているか、または TVS が署名者に対応する証明書を返すことが可能であることが必要です。
すでに Cisco Unified IP Phone に CTL ファイルが存在する場合、ITL ファイルの署名の認証にその CTL ファイルが使用されます。
ITL ファイルには最初の信頼リストが含まれます。ITL ファイルは CTL ファイルと同じ形式を持ち、基本的には CTL ファイルを小さくスリムにしたものです。ITL ファイルには次の属性が適用されます。
TFTP サーバの CallManager 証明書。この証明書によって、ITL ファイルの署名および電話コンフィギュレーション ファイルの署名を認証できます。
クラスタ内のすべての TVS 証明書。これらの証明書によって、電話が TVS とセキュアに通話し、証明書の認証を要求することができます。
CAPF 証明書。これによって、コンフィギュレーション ファイル暗号化をサポートできます。CAPF 証明書は、必ずしも ITL ファイル内に存在する必要はありません(TVS で認証可能)が、これによって CAPF への接続が簡素化されます。
CTL ファイルと同様、ITL ファイルには証明書ごとに 1 つのレコードが含まれます。各レコードの内容は次のとおりです。
TFTP サーバの CallManager 証明書は、2 つの異なるロールを持つ次の 2 つの ITL レコード内に存在します。
Cisco Unified IP Phone は、クラスタ セキュリティ モードの判断(非セキュアまたは混合モード)で引き続き CTL ファイルに依存しています。CTL ファイルは、Cisco Unified Communications Manager レコード内の Cisco Unified Communications Manager 証明書を含めることで、クラスタのセキュリティ モードを追跡します。
ITLRecovery の有効期間が 5 年間から 20 年間に延長され、より長い期間にわたって同じ ITLRecovery 証明書が使用されるようになりました。
(注) | Cisco Unified Communications Manager をアップグレードした場合でも、ITLRecovery 証明書の有効期間は引き続き 5 年のままです。Cisco Unified Communications Manager をアップグレードするととき、後のリリースに証明書がコピーされます。ただし、ITLRecovery 証明書を再生成するか、Cisco Unified Communications Manager の新規インストールを実行すると、ITLRecovery の有効期間が 20 年に延長されます。 |
ITLRecovery 証明書を再生成する前に、警告メッセージが CLI と GUI の両方で表示されます。トークンレス CTL を使用しているか、および CallManager 証明書を再生成しているかを表示する警告メッセージが表示されたら、CTL ファイルに更新された CallManager 証明書があり、その証明書がエンドポイントに対して更新されていることを確認します。
Cisco Unified Communications Manager クラスタに 39 を超える証明書がある場合、Cisco Unified IP Phone 上の ITL ファイル サイズが 64 キロバイトを超えます。ITL ファイル サイズが増加すると、電話での ITL の正常なロードに影響し、Cisco Unified Communications Manager での電話登録が失敗することになります。
電話機にインストールされている ITL ファイルでデフォルトでセキュリティを使用する集中型 TFTP Cisco Unified CM リリース 8.0 は、TFTP 設定ファイルを検証しません。リモート クラスタから電話機を集中型 TFTP 構成に追加する前に、次の手順を完了する必要があります。
自動登録は、混合モードと非セキュア モードの両方でサポートされます。また、デフォルトの設定ファイルに対する署名も行われます。「デフォルトのセキュリティ」がサポートされていない Cisco Unified IP Phone には、署名されていないデフォルトの設定ファイルが提供されます。
Cisco Unified Reporting を使って、デフォルトのセキュリティをサポートする Cisco Unified IP Phone のリストを取得できます。Cisco Unified Reporting を使用するには、次の手順に従います。
Cisco Unified Reporting の詳細については、 『Cisco Unified Reporting Administration Guide』を参照してください。
Cisco Unified Communications Manager は、楕円曲線デジタル署名アルゴリズム(ECDSA)証明書をサポートします。これらの証明書は、RSA ベースの証明書よりも堅牢であり、コモン クライテリア(CC)認定のある製品に必要となります。米国政府の Commercial Solutions for Classified Systems(CSfC)プログラムは、CC 認定が必要なので、Cisco Unified Communications Manager にはこれが含まれています。
ECDSA 証明書は、証明書マネージャ、SIP、認証局プロキシ機能(CAPF)、Transport Layer Security(TLS)、トレース、エントロピー、HTTP、CTI Manager で既存の RSA 証明書とともに使用できます。
(注) | ECDSA は、Cisco Unified Communications Manager と Tomcat についてのみサポートされています。 |
Cisco Unified Communications Manager リリース 11.0 では、自己署名 ECDSA 証明書と ECDSA 証明書署名要求(CSR)の両方が、証明書マネージャによってサポートされています。これより前の Cisco Unified Communications Manager では、RSA 証明書のみがサポートされていました。しかし、Cisco Unified Communications Manager リリース 11.0 以降では、既存の RSA 証明書に加えて CallManager-ECDSA 証明書がサポートされます。
CallManager 証明書と CallManager-ECDSA 証明書の両方とも、共通の信頼ストアである CallManager-Trust を共有します。Cisco Unified Communications Manager によって、これらの証明書がこの信頼ストアにアップロードされます。
証明書マネージャでは、異なるキー長の値を持つ ECDSA の生成がサポートされています。
Cisco Unified Communications Manager をインストールすると、自己署名証明書が生成されます。Cisco Unified Communications Manager リリース 11.0 には常時 ECDSA 証明書が存在し、この証明書が SIP インターフェイスで使用されます。セキュアなコンピュータ テレフォニー インテグレーション(CTI)マネージャでも、ECDSA 証明書がサポートされます。CTI Manager と SIP サーバの両方で同じサーバ証明書が使用されるため、両方のインターフェイスが同期して動作します。
Cisco Unified Communications Manager リリース 11.0 は SIP 回線と SIP トランク インターフェイス向けの ECDSA サポートを含みます。Cisco Unified Communications Manager とエンドポイント電話またはビデオ デバイスとの間の接続は SIP 回線接続であるのに対し、2 つの Cisco Unified Communications Manager 間の接続は SIP トランク接続です。すべての SIP 接続が ECDSA 暗号方式をサポートし、ECDSA 証明書を使用します。
SIP が TLS サーバとして機能する場合: Cisco Unified Communications Manager が着信するセキュア SIP 接続用の TLS サーバとして機能する場合、SIP トランク インターフェイスは CallManager-ECDSA の証明書がディスクにあるかを判断します。証明書がディスクにあり、選択された暗号スイートが TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 または TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 である場合、SIP トランク インターフェイスは CallManager-ECDSA を使用します。SIP トランク インターフェイスは ECDSA 暗号化スイートをサポートしないクライアントからの接続には RSA TLS 暗号スイートを引き続きサポートします。[TLS 暗号方式(TLS Ciphers)] ドロップダウンリストには、 Cisco Unified Communications Manager が TLS サーバとして機能するときにサポートされている暗号スイートの構成を許可するオプションがあります。
SIP が TLS クライアントとして機能する場合:SIP トランク インターフェイスが TLS クライアントとして機能する場合、SIP トランク インターフェイスは Cisco Unified Communications Manager の [エンタープライズ パラメータ(Enterprise Parameters)] ウィンドウにある [TLS 暗号方式(TLS Ciphers)] フィールド([ECDSA 方式オプション(ECDSA ciphers option)]も含む)に基づいて要求された暗号化スイートのリストをサーバに送信します。 [TLS 暗号化(TLS Ciphers)]。この設定は優先順位の高い順に TLS クライアント暗号化スイートのリストと、サポートされている暗号スイートを決定します。
(注) | ECDSA クライアント証明書をサポートしていない Cisco Unified Communications Manager の以前のリリースとの TLS 接続の確立時には、RSA 暗号スイートを使用します。TLS 接続で送信されるクライアント証明書は選択した TLS 暗号である必要はありません。以前のリリースの Cisco Unified Communications Manager も TLS サーバが ECDSA クライアント証明書を受信して処理することをサポートしています。 |
Cisco Unified Communications Manager への接続に ECDSA 暗号化を使用するデバイスにはアイデンティティ信頼リスト(ITL ファイル)に CallManager-ECDSA 証明書が必要です。次に、デバイスは CallManager-ECDSA 証明書をローカル証明書ストアに組み込み、CallManager-ECDSA 証明書でセキュリティ保護された接続を信頼する必要があります。
認証局プロキシ機能(CAPF)は、シスコのエンドポイントと Cisco Unified Communications Manager との間で証明書を交換する、シスコ独自のメソッドです。CAPF を使用するのはシスコのエンドポイントだけです。コモン クライテリア要件を達成するため、CAPF は CAPF バージョン 3 に更新され、クライアントに ECDSA ローカルで有効な証明書(LSC)を提供できるようになりました。顧客は LSC をローカルに作成します。LSC はメーカーが作成する製造者インストール証明書(MIC)の代替です。
CAPF バージョン 3 を使うことで、Cisco Unified Communications Manager サーバから電話、CTI アプリケーション、Jabber クライアントに LSC で使用される EC キーの生成を指示できます。EC キーが生成されると、Cisco Unified Communications Manager は ECDSA LSC を生成して Cisco エンドポイントに送信するか、または ECDSA CSR を生成します。
エンドポイントで CAPR バージョン 3 がサポートされていない場合、Cisco Unified CM Administration からバックアップとして、必要な EC キー サイズと RSA キー サイズを設定して、[電話の設定(Phone Configuration)] ウィンドウにある [EC 優先、RSA バックアップ(EC Preferred, RSA Backup)] オプションを選択します。CAPF サーバが EC キー ペアにリクエスト送信を試行し、電話が EC キーをサポートしていないサーバと通信する場合、このバックアップ オプションが役立ちます。サーバは EC キー ペアの代わりに RSA キー ペアを生成するようリクエストを送信します。
(注) | 現在、CAPF バージョン 3 をサポートするシスコのエンドポイントはありません。したがって、[EC のみ(EC Only)] オプションは選択しないようにします。ただし、将来 ECDSA LSC のサポートを希望する管理者は、デバイスに [EC 優先、RSA バックアップ(EC Preferred, RSA Backup)] オプションを設定できます。エンドポイントで CAPF バージョン 3 の ECDSA LSC サポートが始まったときには、管理者が LSC を再インストールする必要があります。 |
強力な暗号化には、エントロピーの堅牢なソースが必要です。エントロピーはデータのランダム性の指標であり、コモン クライテリア要件の最小しきい値の決定に役立ちます。暗号化などのデータ変換方式の効率もエントロピーの優れたソースの有無に依存します。ECDSA のような強力な暗号化アルゴリズムであっても、エントロピーの弱いソースを使用すれば、暗号化が容易に破られてしまいます。
Cisco Unified Communications Manager リリース 11.0 では、Cisco Unified Communications Manager のエントロピー ソースが向上しました。エントロピー モニタリング デーモンは設定が不要な組み込み機能です。ただし、Cisco Unified Communications Manager CLI によってオフにすることができます。
Entropy Monitoring Daemon サービスの制御には、次の CLI コマンドを使用します。
CLI コマンド |
説明 |
---|---|
utils service start Entropy Monitoring Daemon |
エントロピー モニタリング デーモン サービスを開始します。 |
utils service stop Entropy Monitoring Daemon |
エントロピー モニタリング デーモン サービスを停止します。 |
utils service active Entropy Monitoring Daemon |
エントロピー モニタリング デーモン サービスをアクティベートします。さらにカーネル モジュールがロードされます。 |
utils service deactive Entropy Monitoring Daemon |
エントロピー モニタリング デーモン サービスを非アクティブ化します。さらにカーネル モジュールがアンロードされます。 |
セキュアなコンフィギュレーション ダウンロードのためCisco Unified Communications Manager リリース 11.0 では、以前のリリースでの HTTP および TFTP インターフェイスに加えて、HTTPS のサポートが強化されました。要求された場合、クライアントとサーバの両方が相互認証を使用します。ECDSA LSC および暗号化された TFTP コンフィギュレーションを使用して登録されたクライアントでは、LSC の提示が要求されます。
(注) | CallManager、CallManager ECDSA、Tomcat 証明書を更新する場合、TFTP サービスを無効化してから再び有効化する必要があります。CallManager 証明書と CallManager-ECDSA 証明書の認証にはポート 6971 が使用され、Tomcat 証明書の認証にはポート 6972 が使用されます。 |
コンピュータ テレフォニー インテグレーション(CTI)インターフェイスが、4 つの新しい暗号方式をサポートするよう強化されました。暗号スイートは TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、および TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 です。これらの暗号スイートのサポートによって、CTI Manager インターフェイスでは、Cisco Unified Communications Manager 内に存在する場合に、CallManager-ECDSA 証明書の保有が必要となりました。SIP インターフェイスと同様、CTI Manager セキュア インターフェイスでサポートされる TLS 暗号方式の設定には、Cisco Unified Communications Manager 内のエンタープライズ パラメータ [TLS Ciphers] オプションが使用されます。
Cisco Unified Communications Manager 証明書の 1 つを再作成した場合、このセクションの手順を実行します。
注意 | 証明書を再作成すると、システムの動作に影響する場合があります。証明書を再作成すると、サード パーティの署名付き証明書(アップロードされている場合)を含む既存の証明書が上書きされます。詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
(注) | CAPF 証明書がパブリッシャにある場合は、電話が各自の ITL ファイルを更新するために自動的に再起動することがあります。 |
ステップ 1 | CAPF 証明書を再生成します。
詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ステップ 2 | CTL ファイルがある場合は、CTL クライアントを終了し、再度実行する必要があります。
詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ステップ 3 | CAPF サービスを再起動します。
詳細については、『Cisco Unified Communications Manager Security Guide』の『Activating the Certificate Authority Proxy Function Service』のセクションを参照してください。 |
(注) | TVS および TFTP 両方の証明書を再生成する場合は、TVS 証明書を再生成し、電話で起こりうる複数回の再起動を待ってから TFTP 証明書を再生成します。 |
(注) | 複数の証明書を再生成する場合は、TFTP 証明書の再生成を最後にする必要があります。電話は複数回再起動する可能性があるので、これを待ってから TFTP 証明書を再生成します。この手順に従わないと、すべての Cisco Unified IP Phone の ITL ファイルを手動で削除する必要が生じることがあります。 |
ステップ 1 | TFTP 証明書を再生成します。
詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ステップ 2 | TFTP サービスを有効にしたら、すべての電話機が自動的に再起動するまで待ちます。 |
ステップ 3 | クラスタが混合モードである場合は、CTL クライアントを実行します。 |
ステップ 4 | クラスタが EMCC 導入の一部である場合は、証明書の一括プロビジョニングの手順を繰り返します。
詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ステップ 1 | Tomcat 証明書を再生成します。
詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ステップ 2 | Tomcat および TFTP サービスを再起動します。
詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ステップ 3 | クラスタが EMCC 導入に含まれる場合、証明書の一括プロビジョニングの手順を繰り返します。
詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ITL ファイルの信頼アンカーはソフトウェア エンティティ、つまり TFTP 秘密キーです。サーバがクラッシュすると、キーは失われ、電話機は新しい ITL ファイルを検証できません。
Cisco Unified Communications Manager リリース 8.0 では、TFTP 証明書と秘密キーの両方がディザスタ リカバリ システムによってバックアップされます。システムはバックアップ パッケージを暗号化して秘密鍵を保護します。サーバがクラッシュすると、以前の証明書およびキーが復元されます。
TFTP 証明書が再生成されるたびに、新しいシステムのバックアップを作成する必要があります。バックアップ手順については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。
クラスタをリリース 7.x から 8.6 以降にアップグレードするには、この手順に従ってください。
手順
ステップ 1 | クラスタをアップグレードするための通常の手順に従ってください。詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。
| ||
ステップ 2 | 次のリリースのいずれかを混合モードで実行している場合、CTL クライアントの実行が必要です。 | ||
ステップ 3 | Cisco Unified IP Phone が自動的に再起動し、Cisco Unified Communications Manager への登録が行われるよう、10 分間待機します。
| ||
ステップ 4 | ご使用のクラスタをバックアップします。
DRS を使用してクラスタをバックアップするには、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
アップグレード後にパブリッシャが起動したら、CAR の移行が完了するまで再起動しないでください。このフェーズでは、古いバージョンに切り替えたり、DRS バックアップを実行することは許可されません。
を開いて CAR 移行の状態を確認できます。クラスタを Cisco Unified Communications Manager の旧リリース(リリース 8.0 よりも前)にロールバックする場合は、その前に [クラスタの 8.0 以前へのロールバック準備(Prepare Cluster for Rollback to pre-8.0)] エンタープライズ パラメータを使用したロールバックの準備が必要です。
ステップ 1 | [Cisco Unified CM の管理(Cisco Unified Communications Manager Administration)] でで、 を選択します。
[エンタープライズ パラメータ設定(Enterprise Parameters Configuration)] ウィンドウが表示されます。 [クラスタの 8.0 以前へのロールバック準備(Prepare Cluster for Rollback to pre-8.0)] エンタープライズ パラメータを True に設定します。
| ||
ステップ 2 | Cisco Unified IP Phone が自動的に再起動し、Cisco Unified Communications Manager への登録が行われるよう、10 分間待機します。 | ||
ステップ 3 | クラスタの各サーバを以前のリリースに戻します。
クラスタを以前のバージョンに戻す方法の詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 | ||
ステップ 4 | クラスタが以前のバージョンに切り替わるまで待ちます。 | ||
ステップ 5 | 次のリリースのいずれかを混合モードで実行している場合、CTL クライアントの実行が必要です。 | ||
ステップ 6 | [クラスタの 8.0 以前へのロールバック準備(Prepare Cluster for Rollback to pre-8.0)] エンタープライズ パラメータが True に設定されている場合、社内ディレクトリが機能するために以下の変更が必要です。
で、サービス URL を 「Application:Cisco/CorporateDirectory」から「http://<ipaddr>:8080/ccmcip/xmldirectoryinput.jsp」へと変更します。 | ||
ステップ 7 | [クラスタの 8.0 以前へのロールバック準備(Prepare Cluster for Rollback to pre-8.0)] エンタープライズ パラメータが True に設定されている場合、パーソナル ディレクトリが機能するために以下の変更が必要です。
で、サービス URL を 「Application:Cisco/PersonalDirectory」から「http://<ipaddr>>:8080/ccmpd/pdCheckLogin.do?name=undefined」へと変更します。 |
クラスタをリリース 7.x に戻した後でリリース 8.6 以降のパーティションに再度切り替える場合は、次の手順を実行します。
ステップ 1 | クラスタを非アクティブのパーティションに再度切り替えるための手順に従います。詳細については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ステップ 2 | 次のいずれかのリリースを混合モードで使用していた場合は、CTL クライアントを実行する必要があります。 |
ステップ 3 | [Cisco Unified CM の管理(Cisco Unified Communications Manager Administration)] で、 を選択します。
[エンタープライズ パラメータ設定(Enterprise Parameters Configuration)] ウィンドウが表示されます。 Prepare Cluster for Rollback to pre-8.6 エンタープライズ パラメータを False に設定します。 |
ステップ 4 | Cisco Unified IP Phone が自動的に再起動され、Cisco Unified Communications Manager に登録されるまで、10 分間待ちます。 |
Cisco Unified Communications Manager 8.0(1) 以降では、新しい Security By Default 機能と初期信頼リスト(ITL)ファイルが導入されました。この新機能により、異なる Unified CM クラスタ間の電話の移行では、必ず正しい手順で移行できるよう注意します。
注意 | 正しい手順に従わないと、数千台の電話の ITL ファイルを手動で削除しなければならない状況が発生する可能性があります。 |
新しい ITL ファイルをサポートする Cisco Unified IP Phone では、Unified CM TFTP サーバからこの特別なファイルをダウンロードする必要があります。ITL ファイルが一旦電話にインストールされると、設定ファイルおよび ITL ファイルの以降の更新では、以下のいずれかによる署名が必要となります。
この新しいセキュリティ機能により、電話を別のクラスタに移動する場合に、次の 3 つの問題が発生する可能性があります。
新しいクラスタの ITL ファイルが現在の ITL ファイルの署名者による署名を受けていないため、電話が新しい ITL ファイルや設定ファイルを承認できない問題。
電話の既存の ITL にリストされている TVS サーバは、電話が新しいクラスタに移動すると接続できなくなる可能性があるという問題。
TVS サーバが証明書の検証のためにアクセス可能でも、古いクラスタ サーバに新しいサーバ証明書がない可能性があるという問題。
この 3 つの問題のうち 1 つ以上が発生した場合、考えられる解決策の 1 つは、クラスタ間を移動中のすべての電話から ITL ファイルを手作業で削除することです。ただし、この解決方法は電話の数が増えるにつれて大変な労力を必要とするため、望ましい解決策ではありません。
最も推奨されるオプションは、Cisco Unified CM エンタープライズ パラメータ Prepare Cluster for Rollback to pre-8.0 を使用することです。このパラメータを True に設定すると、電話は空の TVS および TFTP 証明書セクションを含む特殊な ITL ファイルをダウンロードします。
電話に空の ITL ファイルがあると、電話は署名のない設定ファイル(8.x 以前の Unified CM クラスタへの移行用)をすべて受け入れます。また、新しい ITL ファイル(他の Unified CM 8.x クラスタへの移行用)もすべて受け入れます。
空の ITL ファイルは、電話の をチェックすることで確認できます。古い TVS や TFTP サーバが指定されていた場所には、空のエントリが現れます。
新しい空の ITL ファイルをダウンロードできるまで、電話には古い Unified CM サーバへのアクセスが必要です。
古いクラスタをオンラインにしておく場合は、Security By Default を復元するよう、Prepare Cluster for Rollback to pre-8.0 エンタープライズ パラメータを無効にします。
新旧のクラスタが同時にオンラインになっている場合には証明書の一括移行による方法を使用できます。
Cisco Unified IP Phone は、ダウンロードしたファイルをすべて ITL ファイルまたは ITL ファイルに存在する TVS サーバと照合することに注意してください。電話を新しいクラスタに移動する必要がある場合、新しいクラスタが提示する ITL ファイルは、古いクラスタの TVS 証明書ストアの信頼を得る必要があります。
(注) | 証明書の一括エクスポートは、電話の移行中、両方のクラスタがネットワークに接続され、オンラインである場合のみ機能します。 |
(注) | 証明書一括インポート中、Cisco Extension Mobility Cross Cluster(EMCC)が動作を継続するには、訪問クラスタとホーム クラスタの両方において付加的な ITLRecovery 証明書をインポートすることが必要です。[証明書の一括管理(Bulk Certificate Management)] の [証明書タイプ(Certificate Type)] ドロップダウン リストに、ITL_Recovery 証明書をインポートするための新しいオプションが追加されています。 |
ステップ 1 | Cisco Unified Operating System Administration から、 を選択します。 |
ステップ 2 | 新しい宛先クラスタ(TFTP のみ)から中央の SFTP サーバに証明書をエクスポートします。 |
ステップ 3 | 証明書の一括インターフェイスを使用して、SFTP サーバの証明書(TFTP のみ)を統合します。 |
ステップ 4 | 元クラスタで証明書の一括機能を使用し、中央 SFTP サーバから TFTP 証明書をインポートします。 |
ステップ 5 | DHCP オプション 150 またはその他のメソッドを使用して、電話機を新規宛先クラスタにポイントします。 電話は新規宛先クラスタの ITL ファイルをダウンロードし、既存の ITL ファイルと照合することを試みます。証明書は既存の ITL ファイル内に存在しないため、電話は古い TVS サーバに新しい ITL ファイルの署名の確認を要求します。この要求を行うため、電話は古い元クラスタの TCP ポート 2445 に TVS クエリを送信します。 証明書のエクスポート、統合、インポートが正常に行われれば、TVS は成功を返し、電話のメモリにある ITL ファイルは新しくダウンロードされた ITL ファイルに置き換わります。 これで、電話は新しいクラスタから署名済みの設定ファイルをダウンロードおよび認証できるようになりました。 |
ステップ 1 | Cisco Unified OS の管理から、 を選択します。[証明書の一覧(Certificate List)] ウィンドウが表示されます。 |
ステップ 2 | 検索パラメータを入力して、証明書を検索して設定の詳細を表示します。 システムは [証明書リスト(Certificate List)] ウィンドウのすべての条件に一致するレコードを表示します。 |
ステップ 3 | 新しい自己署名証明書を生成するには、[自己署名証明書の生成(Generate Self-Signed Certificate)] をクリックします。 [新しい自己署名証明書の生成(Generate New Self-Signed Certificate)] ウィンドウが表示されます。 |
ステップ 4 | [証明書の用途(Certificate Purpose)] ドロップダウン ボックスから、CallManager-ECDSA などのシステム セキュリティ証明書を選択します。 |
ステップ 5 | [新しい自己署名証明書の生成(Generate New Self-Signed Certificate)] ウィンドウのフィールドを設定します。フィールドとその設定オプションの詳細については、関連項目のセクションを参照してください。 |
ステップ 6 | [生成(Generate)] をクリックします。 |
フィールド |
説明 |
||||
---|---|---|---|---|---|
証明書の用途(Certificate Purpose) |
ドロップダウン ボックスから値を選択します。 |
||||
配布(Distribution) |
Cisco Unified Communications Manager サーバを選択します。 |
||||
Common Name |
[配布(Distribution)] フィールドで選択した Cisco Unified Communications Manager アプリケーションの名前を示します。 |
||||
自動入力ドメイン(Auto-populated Domains) |
このフィールドはサブジェクト代替名(SANs)セクションに表示され、CallManager-ECDSA に対してのみ表示されます。[自動入力ドメイン(Auto-populated Domains)] フィールドは 1 つの証明書によって保護されるホスト名一覧を表示します。 通常、証明書の共通名はホスト名と同じです。ただし、CallManager-ECDSA 証明書にはホスト名と異なる共通名があります。[自動入力ドメイン(Auto-populated Domains)] フィールドは、CallManager-ECDSA 証明書用の完全修飾ドメイン名を表示します。 |
||||
キー タイプ |
このフィールドは秘密/公開キーのペアの暗号化と復号化に使用されるキー タイプを示します。 Cisco Unified Communications Manager は EC および RSA キー タイプをサポートしています。 |
||||
Key Length |
[キー長(Key Length)] ドロップダウン ボックスから、値を 1 つを選択します。 キー長によって、自己署名証明書の要求はハッシュ アルゴリズムの選択肢を限定します。ハッシュ アルゴリズムの選択に制限が加わることで、キー長の強度以上のハッシュ アルゴリズム強度が確保されます。たとえば、256 のキー長の場合、サポートされるハッシュ アルゴリズムは、SHA256、SHA384、SHA512 です。同様に、384 のキー長では、サポートされるハッシュ アルゴリズムは SHA384 または SHA512 です。
|
||||
ハッシュ アルゴリズム(Hash Algorithm) |
キー長以上の値を [ハッシュ アルゴリズム(Hash Algorithm)] ドロップダウン ボックスから選択します。
|
特定の証明書タイプについて、新しい証明書署名要求を生成すると、アプリケーションはその証明書タイプの既存の証明書署名要求を上書きします。
Cisco Unified オペレーティング システムの管理から CSR を生成し、CA に示すことで、CA 署名の証明書をアップロードすることができます。CSR を生成するたびに、CSR と一緒に新しい秘密キーが生成されます。
秘密キーは、CSR を生成するときに選択した、サーバとサービスに一意なファイルです。セキュリティ コンプライアンスのため、この秘密キーは誰とも共有しないでください。秘密キーを誰かに渡すと、証明書のセキュリティが損なわれます。また、古い CSR を使用して証明書を作成する場合は、同じサービス用の新しい CSR を再生成しないでください。Cisco Unified Communications Manager は古い CSR と秘密キーを削除し、それらの両方を新しいものに置き換えて、古い CSR を使用不能にします。
(注) | Cisco Unified Communications Manager リリース 11.0 以降で、TFTP またはすべての一括操作ユニットを選択した場合は、ECDSA 証明書は RSA 証明書に含まれるようになります。 |
ステップ 1 | Cisco Unified OS の管理から、 [証明書の一覧(Certificate List)] を選択します。 ウィンドウが表示されます。 |
ステップ 2 | [CSR の作成(Generate CSR)] をクリックします。 [証明書署名要求の作成(Generate Certificate Signing Request)] ウィンドウが表示されます。 |
ステップ 3 | 証明書を検索して設定の詳細を表示するため検索パラメータを入力します。 システムは [証明書リスト(Certificate List)] ウィンドウのすべての条件に一致するレコードを表示します。 |
ステップ 4 | [証明書の用途(Certificate Purpose)] ドロップダウン ボックスから、CallManager-ECDSA などのシステム セキュリティ証明書を選択します。 |
ステップ 5 | [証明書署名要求の作成(Generate Certificate Signing Request)] ウィンドウのフィールドを設定します。フィールドとその設定オプションの詳細については、関連項目のセクションを参照してください。 |
ステップ 6 | [生成(Generate)] をクリックします。 |
フィールド |
説明 |
||||
---|---|---|---|---|---|
証明書の用途(Certificate Purpose) |
ドロップダウン ボックスから値を選択します。 |
||||
配布(Distribution) |
Cisco Unified Communications Manager サーバを選択します。 Callmanager-ecdsa common name: <host-name>-EC-ms.<domain> Callmanager common name: <host-name>-ms.<domain> |
||||
Common Name |
デフォルトで [配布(Distribution)] フィールドで選択した Cisco Unified Communications Manager アプリケーションの名前を示します。 |
||||
自動入力ドメイン(Auto-populated Domains) |
このフィールドはサブジェクト代替名(SANs)セクションに表示されます。また、単一証明書によって保護されるべきホスト名をリストします。 |
||||
親ドメイン(Parent Domain) |
このフィールドはサブジェクト代替名(SANs)セクションに表示されます。デフォルト ドメイン名を表示します。必要に応じてドメイン名を変更できます。 |
||||
キー タイプ |
このフィールドは秘密/公開キーのペアの暗号化と復号化に使用されるキー タイプを特定します。 Cisco Unified Communications Manager は EC および RSA キー タイプをサポートしています。 |
||||
Key Length |
[キー長(Key Length)] ドロップダウン ボックスから、値を 1 つを選択します。 キーの長さによって、CSR 要求がハッシュ アルゴリズム選択を制限します。ハッシュ アルゴリズムの選択に制限が加わることで、キー長の強度以上のハッシュ アルゴリズム強度が確保されます。たとえば、256 のキー長の場合、サポートされるハッシュ アルゴリズムは、SHA256、SHA384、SHA512 です。同様に、384 のキー長では、サポートされるハッシュ アルゴリズムは SHA384 または SHA512 です。
|
||||
ハッシュ アルゴリズム(Hash Algorithm) |
楕円曲線のキー長と同じ強さのハッシュ アルゴリズムになるように、値を [ハッシュ アルゴリズム(Hash Algorithm)] ドロップダウン ボックスから選択します。 [ハッシュ アルゴリズム(Hash Algorithm)] ドロップダウン ボックスから、値を 1 つを選択します。
|
TLS_ECDHE_ECDSA_WITH_AES256_SHA384 および TLS_ECDHE_ECDSA_WITH_AES128_SHA256 をサポートしない SIP デバイスでも、TLS_ECDHE_RSA_WITH_AES_256_SHA384、TLS_ECDHE_RSA_WITH_AES_128_SHA256、または AES128_SHA1 によって接続できます。これらのオプションは、選択した TLS 暗号オプションによって異なります。[ECDSA のみ(ECDSA only)] オプションを選択すると、ECDSA 暗号化をサポートしないデバイスは SIP インターフェイスへの TLS 接続を作成できなくなります。[ECDSA のみ(ECDSA only)] オプションを選択すると、このパラメータの値は TLS_ECDHE_ECDSA_WITH_AES128_SHA256 および TLS_ECDHE_ECDSA_WITH_AES256_SHA384 になります。
CTI Manager のセキュア クライアントは、TLS_ECDHE_RSA_WITH_AES_128_SHA256、TLS_ECDHE_RSA_WITH_AES_256_SHA384、TLS_ECDHE_ECDSA_WITH_AES_128_SHA256、および TLS_ECDHE_ECDSA_WITH_AES_256_SHA384 をサポートしていません。ただし、AES128_SHA1 では接続できます。
Cisco Unified Communications Manager クラスタのデバイスがロックされて、信頼のステータスを失った場合は、CLI コマンド utils itl reset によりアイデンティティ信頼リスト(ITL)ファイルの一括リセットを行います。このコマンドにより、新しい ITL リカバリ ファイルが生成されます。
ヒント | Unified Communications Manager の新規インストールを実行した場合は、できるだけ早く ITL キーをエクスポートし、ディザスタ リカバリ システムによるバックアップを行います。 ITL リカバリ ペアをエクスポートする CLI コマンドは次のとおりです。 file get tftp ITLRecovery.p12(キーのエクスポート先となる)SFTP サーバとパスワードの入力を求めるプロンプトが表示されます。 |
この手順は必ず Cisco Unified Communications Manager パブリッシャで実行してください。
必要に応じて、パブリッシャからキーをエクスポートします。
ステップ 1 | 次のいずれかの手順を実行します。
| ||
ステップ 2 | リセットが正常に行われたことを確認するには show itl を実行します。 | ||
ステップ 3 | [Cisco Unified Communications Manager の管理(Cisco Unified Communications Manager Administration)] で、 を選択します。 | ||
ステップ 4 | [リセット(Reset)] を選択します。 デバイスが再起動されます。これで、ITLRecovery キーで署名された ITL ファイルをダウンロードし、設定ファイルを受け入れる準備が整いました。 | ||
ステップ 5 | TFTP サービスを再起動し、すべてのデバイスを再起動します。 デバイスは TFTP キーで署名されている ITL ファイルをダウンロードし、Unified Communications Manager に正しく再登録します。 |
Cisco Unified Communications Manager で連絡先検索の認証をセットアップするには、次のタスクを実行します。この機能が設定されている場合、ユーザはディレクトリで他のユーザを検索する前にユーザ自身を認証する必要があります。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | 連絡先検索の認証の電話サポートの確認 | 電話でこの機能がサポートされていることを確認します。Cisco Unified Reporting で [Unified CM 電話機能リスト(Unified CM Phone Feature List)] レポートを実行し、この機能をサポートしている電話モデルのリストを確認します。 |
ステップ 2 | 連絡先検索の認証の設定 | Cisco Unified Communications Manager で連絡先検索の認証を設定します。 |
ステップ 3 | 連絡先検索用のセキュアなディレクトリ サーバの設定 | 電話のユーザがディレクトリで他のユーザを検索したときに示される URL を Cisco Unified Communications Manager で設定するには、次の手順を実行します。 |
導入環境内の電話が連絡先検索の認証をサポートしていることを確認します。[電話機能リスト(Phone Feature List)] レポートを実行して、この機能をサポートしているすべての電話モデルのリストを取得します。
ステップ 1 | Cisco Unified Reporting から [システム レポート(System Reports)] をクリックします。 |
ステップ 2 | [Unified CM 電話機能(Unified CM Phone Feature)] を選択します。 |
ステップ 3 | [Unified CM 電話機能(Unified CM Phone Feature)] レポートをクリックします。 |
ステップ 4 | [製品(Product)] フィールドはデフォルト値のままにします。 |
ステップ 5 | [機能(Feature)] ドロップダウンから [認証済み連絡先検索(Authenticated Contact Search)] を選択します。 |
ステップ 6 | [送信(Submit)] をクリックします。 |
Cisco Unified Communications Manager でこの手順を使用し、電話ユーザの連絡先検索の認証を設定します。
UDS がユーザの検索リクエストを送信するディレクトリ サーバ URL を Cisco Unified Communications Manager に設定するには、次の手順を使用します。デフォルトの値は https://<cucm-fqdn-or-ip>:port/cucm-uds/users です。
(注) | デフォルトの UDS ポートは 8443 です。連絡先の検索の認証が有効になると、デフォルトの UDS ポートは 9443 に切り替わります。以降、連絡先検索の認証を無効にした場合は、UDS ポートを手動で 8443 に戻す必要があります。 |