この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、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)が必要です。
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 証明書があり、その証明書がエンドポイントに対して更新されていることを確認することが指示されます。
電話にインストールされている 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 リリース 11.0 は、楕円曲線デジタル署名アルゴリズム(ECDSA)証明書をサポートします。これらの証明書は、RSA ベースの証明書よりも堅牢であり、コモン クライテリア(CC)認定のある製品に必要となります。米国政府の Commercial Solutions for Classified Systems(CSfC)プログラムは、CC 認定が必要なので、Cisco Unified Communications Manager リリース 11.0 にはこれが含まれています。
ECDSA 証明書は、証明書マネージャ、SIP、Certificate Authority Proxy Function(CAPF)、Transport Layer Security(TLS)、トレース、エントロピー、HTTP、CTI Manager で既存の RSA 証明書とともに使用できます。
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 Ciphers] ドロップダウンリストには、Cisco Unified Communications Manager が TLS サーバとして機能するときにサポートされている暗号スイートの設定を許可するオプションがあります。
SIP が TLS クライアントとして機能する場合:SIP トランク インターフェイスが TLS クライアントとして機能する場合、SIP トランク インターフェイスは Cisco Unified Communications Manager の [Enterprise Parameters] ウィンドウにある [TLS Ciphers] フィールド([ECDSA ciphers] オプションも含む)に基づいて、要求された暗号化スイートのリストをサーバに送信します。[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 証明書でセキュリティ保護された接続を信頼する必要があります。
Certificate Authority Proxy Function(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 を生成します。
エンドポイントで CAPF バージョン 3 がサポートされていない場合、[Cisco Unified CM Administration] からバックアップとして、必要な EC キー サイズと RSA キー サイズを設定して、[Phone Configuration] ウィンドウにある [EC Preferred, RSA Backup] オプションを選択できます。CAPF サーバが EC キー ペアに要求の送信を試行し、電話が EC キーをサポートしていないサーバと通信する場合、このバックアップ オプションが役立ちます。サーバは EC キー ペアの代わりに RSA キー ペアを生成するよう要求を送信します。
(注) | 現在、CAPF バージョン 3 をサポートするシスコのエンドポイントはありません。したがって、[EC Only] オプションは選択しないようにしてください。ただし、後で ECDSA LSC をサポートする必要がある管理者は、デバイスに [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 によってオフにすることができます。
エントロピー モニタリング デーモン サービスの制御には、次の 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 つを再生成した場合、この項で説明する手順を実行する必要があります。
注意 | 証明書を再生成すると、システムの動作に影響する場合があります。証明書を再生成すると、サード パーティの署名付き証明書(アップロードされている場合)を含む既存の証明書が上書きされます。詳細については、『System Configuration Guide for Cisco Unified Communications Manager』を参照してください。 |
(注) | CAPF 証明書がパブリッシャにある場合は、電話が各自の ITL ファイルを更新するために自動的に再起動することがあります。 |
(注) | TVS および TFTP 両方の証明書を再生成する場合は、TVS 証明書を再生成し、電話が再起動する場合は再起動が完了するまで待ってから、TFTP 証明書を再生成します。 |
(注) | 複数の証明書を再生成する場合は、TFTP 証明書の再生成を最後に行う必要があります。電話が再起動する場合は再起動が完了するまで待ってから、TFTP 証明書を再生成します。この手順に従わないと、すべての Cisco Unified IP Phone から ITL ファイルを手動で削除する必要が生じることがあります。 |
ITL ファイルのトラスト アンカーはソフトウェア エンティティ、つまり TFTP 秘密キーです。サーバがクラッシュすると、キーは失われ、電話は新しい ITL ファイルを検証できなくなります。
Cisco Unified Communications Manager リリース 8.0 では、TFTP 証明書と秘密キーの両方がディザスタ リカバリ システムによってバックアップされます。システムはバックアップ パッケージを暗号化して秘密キーを保護します。サーバがクラッシュすると、以前の証明書およびキーが復元されます。
TFTP 証明書が再生成されるたびに、新しいシステムのバックアップを作成する必要があります。バックアップ手順については、『Administration Guide for Cisco Unified Communications Manager』を参照してください。
クラスタをリリース 7.x から 8.6 以降にアップグレードするには、この手順に従ってください。
手順
アップグレード後にパブリッシャが起動したら、CAR の移行が完了するまで再起動しないでください。このフェーズでは、古いバージョンに切り替えたり、DRS バックアップを実行することは許可されません。
を開いて CAR 移行の状態をモニタできます。クラスタを Cisco Unified Communications Manager の旧リリース(リリース 8.0 よりも前)にロールバックする場合は、その前に [Prepare Cluster for Rollback to pre-8.0] エンタープライズ パラメータを使用したロールバックの準備が必要です。
ステップ 1 | [Cisco Unified Communications Manager Administration] で、 を選択します。
[Enterprise Parameters Configuration] ウィンドウが表示されます。 [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 | [Prepare Cluster for Rollback to pre-8.0] エンタープライズ パラメータが [True] に設定されている場合、社内ディレクトリが機能するために以下の変更が必要です。
で、サービス URL を 「Application:Cisco/CorporateDirectory」から「http://<ipaddr>:8080/ccmcip/xmldirectoryinput.jsp」へと変更します。 | ||
ステップ 7 | [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 | クラスタを非アクティブのパーティションに再度切り替えるための手順に従います。詳細については、『System Configuration Guide for Cisco Unified Communications Manager』を参照してください。 |
ステップ 2 | 次のいずれかのリリースを混合モードで使用していた場合は、CTL クライアントを実行する必要があります。 |
ステップ 3 | [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) 以降では、新しいデフォルトのセキュリティ機能と初期信頼リスト(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 クラスタへの移行の場合)電話は署名のない設定ファイルをすべて受け入れます。また、(異なる Unified CM 8.x クラスタへの移行の場合)新しい ITL ファイルをすべて受け入れます。
空の ITL ファイルは、電話の をチェックすることで確認できます。古い TVS や TFTP サーバが指定されていた場所には、空のエントリが表示されます。
新しい空の ITL ファイルをダウンロードできるまで、電話には古い Unified CM サーバにアクセスできる必要があります。
古いクラスタをオンラインにしておく場合は、デフォルトのセキュリティを復元するため、[Prepare Cluster for Rollback to pre-8.0] エンタープライズ パラメータを無効にします。
新旧のクラスタが同時にオンラインになっている場合には証明書の一括移行による方法を使用できます。
Cisco Unified IP Phone は、ダウンロードしたすべてのファイルを、ITL ファイルまたは ITL ファイルに指定されている TVS サーバと照合することに注意してください。電話を新しいクラスタに移動する必要がある場合、新しいクラスタが提示する ITL ファイルは、古いクラスタの TVS 証明書ストアの信頼を得る必要があります。
(注) | 証明書の一括エクスポートは、電話の移行中、両方のクラスタがネットワークに接続され、オンラインである場合のみ機能します。 |
ステップ 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 Administration] から [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] |
このフィールドは [Subject Alternate Names(SANs)] セクションに表示され、CallManager-ECDSA に対してのみ表示されます。[Auto-populated Domains] フィールドには、1 つの証明書によって保護されるホスト名一覧が表示されます。通常、証明書の共通名はホスト名と同じです。ただし、CallManager-ECDSA 証明書にはホスト名と異なる共通名があります。[Auto-populated Domains] フィールドは、CallManager-ECDSA 証明書用の完全修飾ドメイン名を表示します。 |
||||
[Key Type] |
このフィールドは秘密/公開キーのペアの暗号化と復号化に使用されるキー タイプを示します。 Cisco Unified Communications Manager は EC および RSA キー タイプをサポートしています。 |
||||
[Key Length] |
[Key Length] ドロップダウン ボックスから、値を 1 つ選択します。 キー長に応じて、自己署名証明書の要求によりハッシュ アルゴリズムの選択肢が限定されます。ハッシュ アルゴリズムの選択に制限が加わることで、キー長の強度以上のハッシュ アルゴリズム強度が確保されます。たとえばキー長が 256 の場合、サポートされるハッシュ アルゴリズムは、SHA256、SHA384、SHA512 です。同様にキー長が 384 の場合、サポートされるハッシュ アルゴリズムは SHA384 または SHA512 です。
|
||||
[Hash Algorithm] |
キー長以上の値を [Hash Algorithm] ドロップダウン ボックスから選択します。
|
特定の証明書タイプに対する新しい証明書署名要求を生成すると、アプリケーションはその証明書タイプの既存の証明書署名要求を上書きします。
(注) | Cisco Unified Communications Manager リリース 11.0 以降では、TFTP またはすべての一括操作ユニットを選択した場合は、ECDSA 証明書は RSA 証明書に含まれるようになります。 |
ステップ 1 | [Cisco Unified OS Administration] から [Certificate List] を選択します。 ウィンドウが表示されます。 |
ステップ 2 | [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] |
このフィールドは [Subject Alternate Names(SANs)] セクションに表示されます。1 つの証明書によって保護されるホストの名前をリストします。 |
||||
[Parent Domain] |
このフィールドは [Subject Alternate Names(SANs)] セクションに表示されます。デフォルト ドメイン名を表示します。必要に応じてドメイン名を変更できます。 |
||||
[Key Type] |
このフィールドは秘密/公開キーのペアの暗号化と復号化に使用されるキー タイプを示します。 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 only] オプションを選択すると、ECDSA 暗号化をサポートしないデバイスは SIP インターフェイスへの TLS 接続を確立できません。[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 | 次のいずれかの手順を実行します。
utils itl reset localkey では、ローカルキーはパブリッシャ側にあります。この手順により、システムの既存のファイルの署名をリカバリ キー署名に置き換えた新しい ITL ファイルが生成されます。その後、キーはクラスタの TFTP サーバにコピーされます。 |
ステップ 2 | リセットが正常に行われたことを確認するには show itl を実行します。 |
ステップ 3 | [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 Phone Feature List] レポートを実行し、この機能をサポートしている電話モデルのリストを確認します。 |
ステップ 2 | 連絡先検索の認証の設定 | Cisco Unified Communications Manager で連絡先検索の認証を設定します。 |
ステップ 3 | 連絡先検索用のセキュアなディレクトリ サーバの設定 | 電話のユーザがディレクトリで他のユーザを検索したときに示される URL を Cisco Unified Communications Manager で設定するには、次の手順を実行します。 |
導入環境内の電話が連絡先検索の認証をサポートしていることを確認します。[Phone Feature List] レポートを実行して、この機能をサポートしているすべての電話モデルのリストを取得します。
電話ユーザの連絡先検索の認証を設定するには、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 に戻す必要があります。 |