証明書

証明書の管理

証明書管理機能では、さまざまな証明書タイプ、証明書の管理に関連するタスク、および証明書の監視と失効の方法の概要を提供します。

証明書の概要

証明書は展開で安全な接続を確立するために重要です。 ネットワーク上の個人、コンピュータ、その他のサービスを認証します。 証明書管理を実装することで、複雑さを軽減しながら、優れたレベルの保護を提供できます。

証明書は証明書の所有者のアイデンティティを証明するファイルで、次の情報が含まれています。

  • 証明書所有者名

  • [パブリックキー(Public Key)]

  • 証明書を発行した認証局のデジタル署名

Unified Communications Manager は、公開鍵基盤 (PKI) の証明書を使用して暗号化を有効にし、サーバとクライアントのアイデンティティを検証します。 適切な信頼ストアに一致する証明書がない限り、他のシステムを信頼せず、アクセスを拒否します。

ルート証明書は、デバイスとアプリケーション ユーザを含む、ユーザとホストの間の接続を保護します。 証明書はクライアントとサーバのアイデンティティを保護し、ルート トラスト ストアに追加します。

管理者は、サーバ証明書の指紋の表示、自己署名証明書の再生成、および Unified Communications Manager インターフェイスからの信頼できる証明書の削除を行うことができます。 また、CLI を使用して自己署名証明書を再生成して表示することもできます。

Unified Communications Manager 信頼ストアの更新および証明書の管理についての詳細は、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。


（注）  

Unified Communications Manager は、PEM (.pem) および DER (.der) 形式の証明書のみをサポートします。 DER または PEM でサポートされる証明書の最大サイズは 4096 ビットです。


（注）  

Unified Communications Manager は、ワイルドカード エントリを含む証明書をサポートしていません。 たとえば、"*.cisco.com"。


（注）  

Unified Communications Manager トラストストアに期限切れの証明書がある場合、これらの証明書はリリース 12.5(1)SU6 および 14SU2 以降へのアップグレード中にインポートされません。

2 つの証明書をアップロードする場合、名前と有効期間が同じであることを確認し、シリアル番号と署名アルゴリズムが異なることを確認してください。

例:

ルート CA 27:20:41:0c:5b:08:69:80:42:62:4f:13:bd:16:06:6a シリアル番号および SHA-1 アルゴリズムは Unified Communications Manager tomcat-trust に存在します。

7b:35:33:71:0b:7c:08:b2:47:b3:aa:f9:5c:0d:ca:e4 シリアル番号および SHA-256 アルゴリズムの証明書をアップロードしようとすると、証明書の管理:

  • 受け取った証明書の有効性を確認します

  • Tomcat trust フォルダから同じ名前の証明書を検索します

  • Tomcat trust フォルダーにある証明書のシリアル番号と、アップロードしている受信した証明書を比較します

シリアル番号が異なる場合、両方の証明書の有効開始日を確認します。 新しい受信証明書の開始タイムスタンプが最新の場合、既存の証明書を置換し、それ以外の場合はアップロードされません。

SHA-1 および SHA-256 アルゴリズムには同じサブジェクト名または共通名があります。これは、同じエンティティに属していることを意味します。 Unified Communications Manager フレームワークは、Unified Communications Manager のサーバー上でこれら両方のアルゴリズムを同時にサポートすることはできません。 署名アルゴリズムに関係なく、特定の信頼フォルダー内のエンティティに属する 1 つの証明書のみをサポートします。

証明書の種類

このセクションでは、さまざまなタイプの証明書と証明書署名要求のキー使用拡張機能の概要について説明します。

電話の証明書タイプ

電話証明書は、電話を認証する一意の識別子です。 これは IP 攻撃に対するセキュリティにとって非常に重要です。

電話証明書は次のとおりです。

表 1.

電話証明書

説明

製造元でインストールされる証明書（MIC）

MIC は Cisco マニュファクチャリング CA によって署名されており、サポートされている [適切な用語を挿入] Cisco Unified IP 電話にはこの証明書が自動的にインストールされます。

MIC は、ローカルで有効な証明書 (LSC) のインストールのために Cisco認証局プロキシ 機能 (CAPF) で認証するか、暗号化された構成ファイルをダウンロードします。 管理者は証明書を変更、削除、失効させることができないため、有効期限が切れた後は [適切な主語を挿入]を使用できません。

ローカルで有効な証明書 (LSC)

Cisco Unified IP 電話は、セキュアモードで動作するためにLSCが必要であり、認証と暗号化に使用されます。 CAPF オンラインまたはオフライン CA によって署名され、MIC より優先されます。

CAPF に関連する必要なタスクを実行した後、この証明書はサポートされている電話にインストールされます。 認証または暗号化にデバイスセキュリティモードを設定すると、LSC により Unified Communications Manager と電話間の接続が保護されます。


ヒント

LSC のインストールには、MICのみを使用することをお勧めします。 TLS 接続を認証するために LSC をサポートしています Unified Communications Manager。 電話設定が TLS 認証またはその他の目的で MIC を使用する場合、MIC ルート証明書は簡単に危険にさらされるため、当社は責任を負いません。

Cisco Unified IP 電話の 6900、7900、8900、9900 シリーズをアップグレードして TLS 接続に LSC を使用するように Unified Communications Manager。 互換性の問題を避けるため、 Unified Communications Manager 信頼ストアから MIC ルート証明書を削除してください。


（注）  

MIC を使って Unified Communications Manager への TLS 接続を行う電話モデルでは、登録ができない場合があります。

管理者は次の MIC ルート証明書を Unified Communications Manager 信頼ストアから削除する必要があります:

  • CAP-RTP-001

  • CAP-RTP-002

  • Cisco_Manufacturing_CA

  • Cisco_Root_CA_2048

  • Cisco_Manufacturing_CA_SHA2

  • Cisco_Root_CA_M2

  • ACT2_SUDI_CA

CAPF 信頼ストアに残る MIC ルート証明書は、証明書のアップグレードに使用されます。 Unified Communications Manager 信頼ストアの更新と証明書の管理については、 Cisco Unified Communications Manager アドミニストレーション ガイド を参照してください。


（注）  

CAP-RTP-001 および CAP-RTP-002 証明書は Unified Communications Manager から削除されます。

（注）  
Unified Communications Manager リリース 12.5.1SU2 以前では、CallManager-trust ストアから Cisco 製造元の証明書を削除すると、セキュアオンボーディング機能が機能しません。これは、電話機から製造時にインストールされた証明書 (MIC) を検証できないためです。 ただし、この機能は Unified Communications Manager リリース 12.5.1SU3 以降で動作します。電話からの MIC を検証するために CAPF 信頼ストアを使用するためです。

サーバ証明書の種類

サーバ証明書は基本的にサーバを識別するためのものです。 サーバ証明書は、コンテンツの暗号化と復号化の目的としています。

Unified Communications Manager サーバ内の自己署名 (自分の) 証明書のタイプは次の通りです:

Unified Communications Manager は次の証明書タイプを Unified Communications Manager トラストストアにインポートします:

表 2. 証明書のタイプと説明

証明書タイプ

説明

Cisco Unity サーバまたは Cisco Unity Connection 証明書

Cisco Unity および Cisco Unity Connection この自己署名ルート証明書を使用して、 Cisco Unity SCCP および Cisco Unity Connection SCCP デバイス証明書を署名します。 Cisco Unity の場合、Cisco Unity テレフォニー統合マネージャ（UTIM）がこの証明書を管理します。 Cisco Unity Connection について、 この証明書は Cisco Unity Connection Administration が管理します。

Cisco Unity および Cisco Unity Connection SCCP デバイス証明書

Cisco Unity および Cisco Unity Connection SCCP デバイスは、この署名付き証明書を使用して、 Unified Communications Manager との TLS 接続を確立します。

SIP プロキシ サーバ証明書

SIP トランク経由で接続する SIP ユーザ エージェントは、 Unified Communications Manager CallManager の信頼ストアに SIP ユーザエージェント証明書が含まれていて、かつ SIP ユーザ エージェントの信頼ストアに Unified Communications Manager 証明書が含まれている場合に認証を行います。


（注）  

証明書名は、ボイスメール サーバ名に基づく、証明書のサブジェクト名のハッシュを表します。すべてのデバイス (またはポート) には、ルート証明書をルートとする証明書が発行されます。

以下の追加のトラストストアが存在します。

  • Tomcat およびウェブアプリケーションの共通トラストストア

  • IPSec-trust

  • CAPF 信頼

  • ユーザライセンスの信頼性

  • TVSの信頼性

  • 電話とSAST間の信頼性

  • 電話とCTL間の信頼性

Cisco Unity Connection の CA 信頼証明書の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。 これらの信頼証明書は、メール、カレンダー情報、または連絡先を取得するための Exchange または Meeting Place Express への接続を保護します。

サードパーティ CA 署名証明書

CA 署名付き証明書は、デジタル証明書に署名して発行する、信頼できるサードパーティの証明書です。

デフォルトでは、 Unified Communications Manager はすべての接続に自己署名証明書を使用します。 しかし、証明書に署名するようにサードパーティ CA を設定することで、セキュリティを追加することができます。 サードパーティ CA を使用するには、Cisco Unified Communications Manager Administration に CA ルート証明書チェーンをインストールします。

CA が署名した証明書を発行するには、CSR を送信して、CA が証明書を発行して署名できるようにします。 証明書をアップロード、ダウンロード、表示する方法の詳細は、 自己署名証明書 のセクションを参照してください。

設定

Unified Communications Managerに接続する別のシステムから CA 署名付き証明書を使用する場合は、 Cisco Unified Communications Manager Administration で次の操作を行います:

  • 証明書に署名した CA のルート証明書チェーンをアップロードします。

  • 他のシステムから CA 署名付き証明書をアップロードします。

Unified Communications Managerで CA 署名付き証明書を使用する場合:

  • CSR を完成させ、 Cisco Unified Communications Manager Administrationで CA 署名付き証明書を要求します。

  • CA ルート証明書チェーンと CA 署名付き証明書の両方をダウンロードしてください Cisco Unified Communications Manager Administration

  • CA ルート証明書チェーンと CA 署名付き証明書の両方をアップロードします。

CA のルート証明書を取得および設定する方法の詳細については、Certificate Authorityのドキュメントを参照してください。

外部 CA からの証明書のサポート

Unified Communications Manager は、 Unified Communications Manager GUI からアクセス可能な PKCS#10 証明書署名リクエスト (CSR) メカニズムを使用することで、サードパーティの認証局 (CA) との統合をサポートしています。

現在サードパーティ CA を使用している顧客は、以下の証明書を発行するために CSR メカニズムを使用すべきです。

  • Unified Communications Manager

  • CAPF

  • IPSec

  • Tomcat

  • TVS


（注）  
マルチサーバ (SAN) の CA 署名付き証明書は、証明書がパブリッシャーにアップロードされると、クラスター内のノードに適用されますのみ。 新しいマルチサーバ証明書を生成します。 新しいノードを追加するか、再構築するたびに、マルチサーバ証明書をクラスターにアップロードします。

システムを混合モードで実行している場合、一部のエンドポイントでは 4096 以上のキーサイズでは CA 証明書を受け付けない場合があります。 混在モードで CA 証明書を使用するには、以下のいずれかのオプションを選択します。

  • 証明書キーサイズが4096未満の証明書を使用してください。

  • 自己署名証明書の場合：


（注）  

Cisco の CTL クライアントは Release 14 からサポートされなくなりました。Cisco CTL プラグインの代わりに、CLI コマンドを使用して Unified Communications Manager サーバを混合モードに切り替えることを推奨します。

CTL クライアントを実行した後、更新のために適切なサービスを再起動してください。

次に例を示します。

  • Unified Communications Manager 証明書を更新したときには、TFTP サービスと Unified Communications Manager サービスを再起動します。

  • CAPF 証明書を更新したら CAPF を再起動します。

Unified Communications Manager または CAPF 証明書をアップロードした後、電話が ITL ファイルを更新するために自動的にリセットされるのを確認できます。

プラットフォームでの証明書署名リクエスト CSR の生成については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

証明書署名要求のキー用途拡張

次の表に、Unified Communications Manager と IM and Presence Service の CA 証明書の両方に対する証明書署名要求（CSR）の主な使用法の拡張を示します。

表 3. Cisco Unified Communications Manager CSR キー鍵用途拡張

マルチサーバー

拡張キーの使用状況

キーの使用法

サーバ認証

(1.3.6.1.5.5.7.3.1)

クライアント認証

(1.3.6.1.5.5.7.3.2)

IP セキュリティ末端システム

(1.3.6.1.5.5.7.3.5)

デジタル署名

鍵の暗号化

データの暗号化

鍵証明書サイン

鍵共有

CallManager

CallManager-ECDSA

Y

Y

Y

Y

N

Y

CAPF（パブリッシャーのみ）

N

Y

Y

Y

N

Y

ipsec

N

Y

Y

Y

Y

Y

Y

tomcat

tomcat-ECDSA

Y

Y

Y

Y

N

Y

TVS

N

Y

Y

Y

Y

Y
表 4. IM and Presence Service の CSR キーの用途の拡張

マルチサーバー

拡張キーの使用状況

キーの使用法

サーバ認証

(1.3.6.1.5.5.7.3.1)

クライアント認証

(1.3.6.1.5.5.7.3.2)

IP セキュリティ末端システム

(1.3.6.1.5.5.7.3.5)

デジタル署名

鍵の暗号化

データの暗号化

鍵証明書サイン

鍵共有

cup

cup-ECDSA

N

Y

Y

Y

Y

Y

Y

cup-xmpp

cup-xmpp-ECDSA

Y

Y

Y

Y

Y

Y

Y

cup-xmpp-s2s

cup-xmpp-s2s-ECDSA

Y

Y

Y

Y

Y

Y

Y

ipsec

N

Y

Y

Y

Y

Y

Y

tomcat

tomcat-ECDSA

Y

Y

Y

Y

Y

Y

（注）  

「データの暗号化」ビットは、CA 署名証明書の処理中に変更も削除もされません。

証明書のタスク

このセクションでは、証明書を管理するためのすべての手順が記載されています。

証明書の一括エクスポート

古いクラスターと新しいクラスターが同時にオンラインの場合、証明書の一括移行方法を使用できます。

Cisco Unified IP Phone は、ITL ファイルに対して、または ITL ファイルに存在する TVS サーバに対して、ダウンロードされたすべてのファイルを検証することに注意してください。 電話を新しいクラスタに移動する必要がある場合、新しいクラスタが提供する ITL ファイルは、古いクラスタ TVS 証明書ストアによって信頼されている必要があります。


（注）  

一括証明書のエクスポート方法は、電話が移行されている間に両方のクラスターがネットワーク接続でオンラインの場合にのみ機能します。

（注）  

証明書の一括インポート中、Cisco Extension Mobility Cross Cluster (EMCC) が機能し続けるためには、訪問先クラスタとホーム クラスタの両方で追加の ITLRecovery 証明書をインポートする必要があります。 ITL_Recovery 証明書をインポートするための新しいオプションが [一括証明書管理] の 証明書タイプ ドロップダウンリストに追加されました。

証明書の一括エクスポートを使用するには、以下の手順を実行します。

手順

ステップ 1

[Cisco Unifiedオペレーティングシステムの管理(Cisco Unified Operating System Administration)] で、[セキュリティ(Security)] > [証明書の管理] の順に選択します。

ステップ 2

新しい宛先クラスタ (TFTP のみ) から中央の SFTP サーバに証明書をエクスポートします。

ステップ 3

一括証明書インターフェイスを使用して、SFTP サーバー上の証明書を統合する（TFTP のみ）。

ステップ 4

元のクラスターで一括証明書機能を使用して、中央の SFTP サーバから TFTP 証明書をインポートします。

ステップ 5

DHCP オプション 150 または他の方法を使用して、電話を新しい宛先クラスタにポイントします。

電話は新しい宛先クラスタ ITL ファイルをダウンロードし、既存の ITL ファイルに対して確認しようとします。 証明書が既存の ITL ファイルにないため、電話は古い TVS サーバに新しい ITL ファイルの署名を確認するよう要求します。 電話は、このリクエストを行うために、TCP ポート 2445 で TVS クエリを古い元のクラスターに送信します。

証明書のエクスポート/統合/インポートのプロセスが正しく機能する場合、TVS は成功を返し、電話はメモリ内の ITL ファイルを新しくダウンロードされた ITL ファイルで置き換えます。

電話は新しいクラスタから署名された構成ファイルをダウンロードし、確認できます。

証明書の表示

[証明書リスト] ページのフィルタ オプションを使用して、共通名、有効期限日付、キー タイプ、および使用方法に基づいて証明書のリストを並べ替えて表示できます。 このため、フィルタ オプションを使用すると、データの並べ替え、表示、およびデータの効率的な管理を行えます。

Unified Communications Manager リリース 14 から、使用オプションを選択して、ID または信頼証明書のリストを並べ替え、表示できます。

手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）][証明書の管理（Certificate Management）] を選択します。

[Certificate List] ページが表示されます。

ステップ 2

[証明書リストの検索場所] ドロップダウン リストから、必要なフィルタ オプションを選択し、[検索] フィールドに検索項目を入力して [検索] ボタンをクリックします。

たとえば、アイデンティティ証明書だけを表示するには、[証明書の一覧の検索条件（Find Certificate List where）] ドロップダウンリストから [使用法（Usage）] を選択し、[検索（Find）] フィールドにアイデンティティを入力して、[検索（Find）] ボタンをクリックします。

BCFIPS プロバイダーの証明書表示データは、リリース 14SU2 以降で変更されました。

14SU1 までのタグ名

14SU2 からのタグ名

発行者名

IssuerDN（発行者 DN）

有効期限

開始日　

移行後

最終日

サブジェクト名

SubjectDN（サブジェクト DN）

キー

[パブリックキー(Public Key)]

キー値

モジュラス

（注）  

 

x509 拡張機能は、実際のキー使用法名ではなく OID 名で表示されます。

証明書のダウンロード

CSR リクエストを送信する際、ダウンロード証明書タスクを使用して証明書のコピーを作成するか、証明書をアップロードします。

手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] を選択します。

ステップ 2

検索情報を指定し、[検索（Find）] をクリックします。

ステップ 3

必要なファイル名を選択し、[ダウンロード] をクリックします。

中間証明書のインストール

中間証明書をインストールするには、まずルート証明書をインストールしてから、署名付き証明書をアップロードする必要があります。 この手順は、認証局から 1 つの署名付き証明書と複数の証明書が証明書チェーンで提供されている場合にのみ必要です。

手順

ステップ 1

[Cisco Unified OS の管理（Cisco Unified OS Administration）] から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] をクリックします。

ステップ 2

[証明書/証明書チェーンのアップロード] をクリックします。

ステップ 3

[証明書の用途] ドロップダウンリストで適切な信頼ストアを選択して、ルート証明書をインストールします。

ステップ 4

選択した証明書の説明を入力します。

ステップ 5

次のいずれかの手順を実行して、アップロードするファイルを選択します。

  • [ファイルのアップロード（Upload File）]テキスト ボックスに、ファイルへのパスを入力します。
  • [参照（Browse）]をクリックしてファイルに移動し、[開く（Open）]をクリックします。

ステップ 6

[アップロード（Upload）]をクリックします。

ステップ 7

顧客証明書をインストールしたら、FQDN を使用して Cisco Unified Intelligence Center の URL にアクセスします。 IP アドレスを使用して Cisco Unified Intelligence Center にアクセスすると、カスタム証明書を正常にインストールした後でも"ここをクリックしてログインを継続します（Click here to continue）"のメッセージが表示されます。

（注）  

 

  • TFTP Tomcat 証明書をアップロードするときは、TFTP サービスを再起動する必要があります。 それ以外の場合は、TFTP は古いキャッシュの自己署名された tomcat 証明書を提供し続けます。

  • 電話機のエッジ信頼から証明書をアップロードするには、発行元から行う必要があります。

信頼証明書の削除

削除できる証明書は、信頼できる証明書だけです。 システムで生成される自己署名証明書は削除できません。


注意    

証明書を削除すると、システムの動作に影響する場合があります。 また、証明書が既存のチェーンの一部である場合、証明書チェーンが壊れることがあります。 この関係は、[証明書の一覧（Certificate List）] ウィンドウ内の関連する証明書のユーザ名とサブジェクト名から確認します。 この操作は取り消すことができません。

手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] を選択します。

ステップ 2

証明書の一覧をフィルタするには、[検索（Find）] コントロールを使用します。

ステップ 3

証明書のファイル名を選択します。

ステップ 4

[削除（Delete）]をクリックします。

ステップ 5

OKをクリックします。

（注）  

 

  • 削除する証明書が "CAPF-trust"、"tomcat-trust"、"CallManager-trust"、または "Phone-SAST-trust" 証明書タイプの場合、証明書はクラスタ内のすべてのサーバで削除されます。

  • 電話機のエッジトラストからの証明書の削除は、発行元から行う必要があります。

  • 証明書を CAPF-trust にインポートする場合、それはその特定のノードでのみ有効になり、クラスタ全体で複製されることはありません。

証明書署名要求の生成

証明書署名要求（CSR）を生成します。これは、公開キー、組織名、共通名、地域、および国などの証明書申請情報を含む暗号化されたテキストのブロックです。 認証局はこの CSR を使用して、ご使用のシステムの信頼できる証明書を生成します。


（注）  

新しい CSR を生成すると、既存の CSR は上書きされます。

手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] を選択します。

ステップ 2

[CSR の作成（Generate CSR）]をクリックします。

ステップ 3

[証明書署名要求の作成] ウィンドウのフィールドを設定します。 フィールドとその設定オプションの詳細については、オンライン ヘルプを参照してください。

ステップ 4

[Generate]をクリックします。

証明書署名リクエストのフィールド
表 5. 証明書署名リクエストのフィールド

フィールド

説明

証明書の用途

ドロップダウンメニューから次の値を選択します。

  • CallManager

  • CallManager-ECDSA

配布

Unified Communications Manager サーバを選択します。

ECDSA のマルチサーバーにこのフィールドを選択するには、次の構文を使用します。 
Callmanager-ecdsa common name: <host-name>-EC-ms.<domain>
RSA のマルチサーバーにこのフィールドを選択するには、次の構文を使用します。 
Callmanager common name: <host-name>-ms.<domain>

共通名/共通Name_SerialNumber

重要

 

リリース 14SU1 以降でサポートされます。

共通名または共通名に証明書のシリアル番号を付加したものが表示されます。 共通名または共通Name_SerialNumber は証明書のファイル名です。

配信 フィールドでデフォルトで選択した Unified Communications Manager アプリケーションの名前を表示します。

CSR に OU を含める

重要

 

リリース 14SU1 以降でサポートされます。

デフォルトでは、[組織単位（Organization Unit）] フィールドは証明書署名リクエストに含まれません。 このオプションを選択すると、証明書署名リクエストに [組織単位（Organization Unit）] フィールドが追加されます。

（注）  

 

証明書署名リクエストに組織ユニットがあり、署名付き CA 証明書には含まれない場合、署名付き CA 証明書を Unified Communications Manager にアップロードできます。

自動入力ドメイン

このフィールドは、[サブジェクト代替名(SAN)（Subject Alternate Names (SANs)）] セクションに表示されます。 1 つの証明書で保護されるホスト名が一覧で表示されます。

親ドメイン

このフィールドは、[サブジェクト代替名(SAN)（Subject Alternate Names (SANs)）] セクションに表示されます。 デフォルトドメイン名が表示されます。必要に応じて、ドメイン名を変更できます。

キータイプ

このフィールドで、公開秘密キーペアの暗号化および復号化に使用するキーのタイプを識別します。

Unified Communications Manager は、 EC および RSA 鍵タイプをサポートしています。

キーの長さ

[キー長（Key Length）] ドロップダウンメニューから、いずれかの値を選択します。

キー長に応じて、CSR リクエストのハッシュアルゴリズムの選択肢が制限されます。 ここでハッシュアルゴリズムの選択肢が制限されることで、キー長と同じかそれ以上の強度を持つハッシュアルゴリズムを使用できます。 たとえば、キー長が 256 の場合は、SHA256、SHA384、SHA512 からハッシュアルゴリズムを選択できます。 同様に、キー長が 384 の場合は、SHA384 または SHA512 からハッシュアルゴリズムを選択できます。

（注）  

 

RSA 証明書については、[Key Length] の値が 3072 または 4096 の証明書のみを選択できます。 これらのオプションは、ECDSA 証明書では使用できません。

（注）  

 

CallManager [証明書の目的（Certificate Purpose）] で選択された RSA キーの長さが 2048 を超えると、電話機の機種によっては登録に失敗することがあります。Cisco Unified Reporting Tool（CURT）の Unified CM 電話機能リストレポートから、3072/4096 RSA キーサイズサポート機能でサポートされている電話モデルのリストを確認できます。

ハッシュ アルゴリズム（Hash Algorithm）

[Hash Algorithm（ハッシュアルゴリズム）] ドロップダウンメニューから値を選択して、ハッシュアルゴリズムの強度を楕円曲線のキー長よりも強くします。 [Hash Algorithm（ハッシュアルゴリズム）] ドロップダウンメニューから、いずれかの値を選択します。

（注）  

 

  • [Hash Algorithm（ハッシュアルゴリズム）] の値が、[キー長（Key Length）] フィールドで選択した値に応じて変わります。

  • システムが FIPS モードで稼働している場合は、ハッシュアルゴリズムに必ず SHA256 を選択してください。
証明書署名要求のダウンロード

CSR を作成後、ダウンロードして、認証局に証明書を送信できるようにします。

手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] を選択します。

ステップ 2

[CSR のダウンロード（Download CSR）]をクリックします。

ステップ 3

[証明書の用途（Certificate Purpose）]ドロップダウン リストで、証明書名を選択します。

ステップ 4

[CSR のダウンロード（Download CSR）]をクリックします。

ステップ 5

（任意） プロンプトが表示されたら、[保存（Save）]をクリックします。

自己署名証明書の生成

手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] を選択します。

[証明書の一覧（Certificate List）]ウィンドウが表示されます。

ステップ 2

検索パラメータを入力して、証明書を検索して設定の詳細を表示します。

すべての条件に一致したレコードが [Certificate List] ウィンドウに表示されます。

ステップ 3

[ 自己署名証明書の生成 ] をクリックして新しい自己署名証明書を生成します。

[ 新しい自己署名証明書の生成 ] ウィンドウが表示されます。

ステップ 4

証明書の目的 ドロップダウンボックスから、システムセキュリティ証明書を選択します (例: CallManager-ECDSA)。

ステップ 5

[ 新しい自己署名証明書 ] ウィンドウのフィールドを設定します。 フィールドとその設定オプションの詳細については、「関連項目」の項を参照してください。

ステップ 6

[Generate]をクリックします。

自己署名証明書のフィールド
表 6. 自己署名証明書のフィールド

フィールド

説明

証明書の用途

ドロップダウンメニューから、必要なオプションを選択します。

次のいずれかのオプションを選択すると、[キータイプ（Key Type）] フィールドが自動的に [RSA] に設定されます。

  • Cisco Tomcat

  • ipsec

  • ITL リカバリ

  • CallManager

  • CAPF

  • TVS

次のいずれかのオプションを選択すると、[キータイプ（Key Type）] フィールドが自動的に [EC]（楕円曲線）に設定されます。

  • tomcat-ECDSA

  • CallManager-ECDSA

配布

ドロップダウン メニューから Unified Communications Manager サーバを選択します。

共通名/共通Name_SerialNumber

共通名または共通名に証明書のシリアル番号を付加したものが表示されます。 共通名または共通Name_SerialNumber は証明書のファイル名です。

CSR に OU を含める

デフォルトでは、[組織単位（Organization Unit）] フィールドは証明書署名リクエストに含まれません。 このオプションを選択すると、証明書署名リクエストに [組織単位（Organization Unit）] フィールドが追加されます。

（注）  

 

証明書署名リクエストに組織ユニットがあり、署名付き CA 証明書には含まれない場合、署名付き CA 証明書を Unified Communications Manager にアップロードできます。

自動入力ドメイン

[証明書の用途（Certificate Purpose）] ドロップダウンメニューで次のいずれかのオプションを選択した場合にのみ表示されます。

  • tomcat

  • tomcat-ECDSA

  • CallManager

  • CallManager-ECDSA

  • TVS

このフィールドには、単一の証明書で保護されるホストの名前が一覧で表示されます。 証明書の共通名はホスト名と同じです。 CallManager-ECDSA と tomcat-ECDSA の両方の証明書に、ホスト名とは異なる共通名が付けられます。

このフィールドには、 CallManager-ECDSA 証明書の完全修飾ドメイン名が表示されます。

キータイプ

このフィールドには、公開秘密キーペアの暗号化および復号化に使用するキーのタイプが一覧で表示されます。

Unified Communications Manager は、 EC および RSA 鍵タイプをサポートしています。

キーの長さ

次のいずれかの値をドロップダウンメニューから選択します。

  • 1024

  • 2048

  • 3072

  • 4096

キー長に応じて、自己署名証明書リクエストのハッシュアルゴリズムの選択肢が制限されます。 ハッシュアルゴリズムの選択肢が制限されることで、キー長と同じかそれ以上の強度を持つハッシュアルゴリズムを使用できます。

  • キー長の値が 256 の場合、SHA256、SHA384、SHA512 からハッシュアルゴリズムを選択できます。

  • キー長の値が 384 の場合は、SHA384 または SHA512 からハッシュアルゴリズムを選択できます。

（注）  

 

[キー長（[Key Length）] の値に 3072 または 4096 を選択する証明書は RSA 証明書のみです。 これらのオプションは、ECDSA 証明書については使用できません。

（注）  

 

CallManager の [証明書の用途（Certificate Purpose）] で選択された RSA の [キー長（key length）] が 2048 を超えると、電話機のモデルによっては登録に失敗することがあります。

詳細については、Cisco Unified Reporting Tool（CURT）の Unified CM 電話機能リストレポートから、33072/4096 RSA キーサイズサポート機能でサポートされている電話モデルのリストをチェックしてください。

ハッシュ アルゴリズム（Hash Algorithm）

ドロップダウンメニューから、キー長と同じかそれ以上の値を選択します。

（注）  

 

  • [ハッシュアルゴリズム（Hash Algorithm）] ドロップダウンリストの値は、[キー長（Key Length）] フィールドで選択した値に応じて変わります。

  • システムが FIPS モードで稼働している場合は、ハッシュアルゴリズムに必ず SHA256 を選択してください。
有効期限（年） ドロップダウンリストから 5、10、20 などのオプションのいずれかを選択して、自己署名証明書の有効期間を設定します。

（注）  

 

デフォルトでは、すべての自己署名証明書の有効期間は 5 年です。

証明書の有効期間を変更しても、既存の証明書には影響しません。 新しい証明書のみが影響を受けます。

証明書の再作成

有効期限が切れる前に証明書を再生成することをお勧めします。 RTMT（Syslog Viewer）で警告が発行され、証明書の期限が近くなると電子メールで通知が送信されます。

ただし、期限切れの証明書を再生成することもできます。 電話機を再起動してサービスを再起動する必要があるため、営業時間後にこのタスクを実行します。 Cisco Unified OS の管理に「cert」タイプとしてリストされている証明書のみ再作成できます。


注意    

証明書を再生成すると、システムの動作に影響する場合があります。 証明書を再作成すると、サード パーティの署名付き証明書（アップロードされている場合）を含む既存の証明書が上書きされます。

手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] を選択します。

検索パラメータを入力して、証明書を検索して設定の詳細を表示します。 すべての条件に一致したレコードが [Certificate List] ウィンドウに表示されます。

証明書の詳細ページで [再生成（Regenerate）] ボタンをクリックすると、同じキー長を持つ自己署名証明書が再生成されます。

（注）  

 

証明書を再生成した場合、[再生成（Regeneration）] ウィンドウを閉じて、新しく生成された証明書を開くまで、[証明書の説明（Certificate Description）] フィールドは更新されません。

3072 または 4096 の新しいキー長の自己署名証明書を再生成するには、[自己署名証明書の生成（Generate Self-Signed Certificate）] をクリックします。

ステップ 2

[自己署名証明書の新規作成（Generate New Self-Signed Certificate）] ウィンドウのフィールドを設定します。 フィールドおよびその設定オプションの詳細については、オンライン ヘルプを参照してください。

ステップ 3

[Generate]をクリックします。

ステップ 4

再作成された証明書の影響を受けるサービスをすべて再起動します。 詳細については、証明書の名前と説明を参照してください。

ステップ 5

CAPF、ITLRecovery 証明書または CallManager 証明書の再生成後に CTL ファイルを更新します（設定している場合）。

（注）  

 

証明書を再作成したら、システムのバックアップを実行して、最新のバックアップに再作成した証明書が含まれるようにします。 バックアップに再作成した証明書が含まれていない状態でシステムの復元タスクを実行する場合は、システム内の各電話機のロックを手動で解除して、電話機を登録できるようにする必要があります。

重要

 
CallManager、CAPF、および TVS 証明書が再生成または更新されると、電話機は自動的にリセットされ、更新された ITL ファイルを受信します。
証明書の名前と説明

次の表に、再作成可能なシステムのセキュリティ証明書と、再起動する必要がある関連サービスを示します。 TFTP 証明書の再作成の詳細については、http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html の『Cisco Unified Communications Manager セキュリティガイド』を参照してください。

表 7. 証明書の名前と説明

名前

説明

再起動が必要なサービス

tomcat

この証明書は、SIP Oauth モードが有効になっているときに Web サービス、Cisco DRF サービス、および Cisco CallManager サービスで使用されます。

（注）  

 

これ以降の上記のサービスの再起動は、リリース 14 以降に適用されます。

Cisco Tomcat サービス、Cisco Disaster Recovery System（DRS）ローカルサービスおよびマスターサービス、Cisco UDS Tomcat、および Cisco AXL Tomcat Web サービス。

SAML SSO が Tomcat 証明書で有効になっている場合は、IDP で SP メタデータを再プロビジョニングする必要があります。

tomcat-ECDSA

この証明書は、SIP Oauth モードが有効になっているときに Web サービス、Cisco DRF サービス、および Cisco CallManager サービスで使用されます。

（注）  

 

これ以降の上記のサービスの再起動は、リリース 14 以降に適用されます。

Cisco Tomcat サービス、Cisco Disaster Recovery System（DRS）ローカルサービスおよびマスターサービス、Cisco UDS Tomcat、および Cisco AXL Tomcat Web サービス。

ipsec

この自己署名ルート証明書は、Unified Communications Manager、MGCP、H.323、IM and Presence Service との IPsec 接続のインストール中に生成されます。

CLI から utils ipsec restart コマンドを使用して IPSec サービスを再起動できます。

CallManager

CallManager-ECDSA

これは SIP、SIP トランク、SCCP、TFTP などに使用されます。

重要

 

リリース 14 では、次のサービスを再起動します。

  • Cisco Call Manager Service およびその他の関連サービス（Cisco CTI Manager、HAProxy Service など）- サーバーがセキュアモードの場合、CTL ファイルを更新します。

重要

 

この後の上記のサービスの再起動は、リリース 14 SU1 以降に適用されます。

  • CallManager：HAProxy サービス - サーバーがセキュアモードの場合、CTL ファイルを更新します。

  • CallManager-ECDSA：Cisco CallManager サービスおよび HAProxy サービス。

CAPF

Unified Communications Manager Publisher ノードで実行されている CAPF サービスによって使用されます。 この証明書は、エンドポイントに LSC を発行するために使用されます (オンラインおよびオフライン CAPF モードを除く)。

クラスタ ノードで SIP OAuth が有効になっている場合は、Cisco HAProxy を再起動します。

TVS

これは Trust 検証サービスで使用されます。これは、サーバ証明書が変更された場合に電話機のセカンダリ信頼検証メカニズムとして機能します。

該当なし

ITL リカバリ

この証明書は、ITL ファイルと CTL ファイルの両方に署名します。 SAML SSO アサーションの署名にも使用されます。

証明書が再生成されるたびに、サービスは自動的に再起動されます。

Tomcat 証明書で SAML SSO が有効になっている場合は、IDP で SP メタデータを再プロビジョニングする必要があります。

（注）  

  • TVS、CAPF、または TFTP 証明書のいずれかを更新した場合に、手動または自動で電話機をリセットするには、証明書の更新に関する新しいエンタープライズパラメータの電話機の相互操作を導入します。 このパラメータは、デフォルトで電話機を自動的にリセットするために設定されています。

  • 証明書の再生成、削除、更新後、「再起動するサービス」列に記載されている適切なサービスを必ず再起動してください。

  • 証明書が再生成されるたびに、TVS、CAPF、および ITLRecovery サービスを再起動する必要はありません。


重要
この注意事項は、リリース 14SU2 にのみ適用されます。

リリース 14SU2 では、tomcat-ECDSA 証明書の再生成またはアップロードの後に Cisco DRF サービスを再起動する必要があります。 tomcat RSA 証明書の処理後に再起動する必要はありません。

重要

この注意事項は、リリース 14SU2 以降に適用されます。

CLI 経由の複数 SAN 証明書のアップロードはサポートしていません。 これらの証明書は常に OS 管理 GUI 経由でアップロードする必要があります。
CAPF 証明書の再生成

CAPF 証明書を再生成するには、以下の手順を実行します。


（注）  

CAPF 証明書がパブリッシャにある場合、電話が ITL ファイルを更新するために自動的に再起動するのを確認できます。 この動作は、証明書更新時の電話によるやり取りパラメータが自動的にリセットされた場合に適用されます。
手順

ステップ 1

CAPF 証明書を再生成します。

ステップ 2

CTL ファイルがある場合は、CTL ファイルを更新する必要があります。

詳細については、証明書の再作成 を参照してください。

ステップ 3

CAPF 証明書が再生成されると、CAPF サービスが自動的に再起動されます。

『Cisco Unified Communications Manager セキュリティガイド』にある"「認証局プロキシ機能サービスを有効にする」"の項を参照してください。

TVS 証明書の再生成

（注）  

TVS および TFTP 証明書の再生成を計画している場合、TVS 証明書を再生成し、電話の再起動が完了するのを待ってから、TFTP 証明書を再生成します。 これは、[証明書更新時の電話との対話] パラメーターが自動的にリセットされる場合に適用されます。
手順

TVS 証明書を再生成します。

詳細については、『Cisco Unified Communications Manager セキュリティ ガイド』の「 証明書の再生成」セクションを参照してください。

CTL ファイルには TVS 証明書が含まれていません。 したがって、TVS 証明書が再生成される場合は、CTL ファイルを更新する必要はありません。

TVS 証明書が再生成されると、TVS サービスは自動的に再起動されます。
CallManager 証明書の再生成

CallManager 証明書を再生成するには、次の手順に従います。


（注）  

複数の証明書を再生成する予定の場合は、最後に TFTP 証明書を再生成する必要があります。 電話の再起動が完了するのを待ってから、TFTP 証明書を再生成してください。 この手順を実施しない場合、すべての Cisco IP 電話から ITL ファイルを手動で削除する必要があります。 このルールは、Phone interaction on Certificate Update パラメータが自動的にリセットされる場合に適用されます。

手順

ステップ 1

CallManager 証明書を再生成します。

詳細については、『Cisco Unified Communications Manager 管理ガイド』 を参照してください 。

ステップ 2

TFTP サービスが有効になっている場合は、すべての電話が自動的に再起動するまで待ちます。

ステップ 3

クラスターが混合モードの場合、CTL ファイルを更新します。

ステップ 4

クラスターが EMCC 展開の一部である場合、一括証明書プロビジョニングの手順を繰り返します。

詳細については、『Cisco Unified Communications Manager 管理ガイド』 を参照してください 。

TFTP 証明書の再生成後のシステムバックアップ手順

ITL ファイルのトラスト アンカーはソフトウェア エンティティである TFTP 秘密鍵です。 サーバがクラッシュした場合、キーが失われ、電話は新しい ITL ファイルを検証できなくなります。

Unified Communications Manager リリース 10.0 では、TFTP 証明書と秘密鍵の両方が災害復旧システムによりバックアップされます。 システムはバックアップパッケージを暗号化して、秘密鍵を秘密に保つ。 サーバがクラッシュした場合、以前の証明書とキーが復元されます。

TFTP 証明書が再生成されるたびに、新しいシステムバックアップを作成する必要があります。 バックアップ手順については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

ITLRecovery 証明書の再生成

警告

ITLRecovery 証明書は頻繁に再生成しないでください。この証明書には電話で長い有効期間があり、CallManager 証明書が含まれているためです。
非セキュア クラスタの ITLRecovery 証明書を再生成する

  1. ITL ファイルが有効かどうか、およびクラスタ内のすべての電話が現在の ITL ファイルを信頼していることを確認してください。

  2. ITLRecovery 証明書を再生成します。

    各クラスタのパブリッシャに移動して、ITLRecovery 証明書を再生成します。

    1. [Cisco Unified OS Administration] から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] を選択します。

    2. [検索（Find）] をクリックします。

      [証明書の一覧（Certificate List）] ウィンドウが表示されます。

    3. 表示される証明書のリストから、[ITLRecovery.pem Certificate] リンクをクリックします。

    4. [ 再生成] をクリックして、ITLRecovery 証明書を再生成します。

    5. 確認メッセージのポップアップで、[ OK] をクリックします。

  3. ITLファイルに署名するために utils itl reset localkey をCallManager証明書で使用し、新しい ITL ファイルを受け入れます。

  4. クラスタ内のすべての電話をバッチでリセットします。


    （注）  

    クラスタ内のすべての電話が登録されていることを確認してください。

  5. 新しい ITLRecovery 証明書で ITL ファイルに再署名するために、TFTP サービスを再起動します。

    電話がリセットされると、新しい ITLRecovery 証明書が電話にアップロードします。

  6. 新しい ITL ファイルを取得するために、クラスタ内のすべての電話を 2 回目にバッチでリセットします。

  7. 電話機はリセット後に新しい ITLRecovery 証明書で更新されます。

セキュア クラスタの ITLRecovery 証明書を再生成する

トークン ベースの ITL ファイルからトークンレス ITL ファイルに移行する場合は、セキュリティ ガイドの移行セクションを参照してください。

  1. ITL ファイルが有効かどうか、およびクラスタ内のすべての電話が現在の ITL ファイルを信頼していることを確認してください。

  2. show ctl コマンドを使用して CTL ファイルを確認してください。

  3. ITLRecovery 証明書を再生成してください。

    各クラスタのパブリッシャに移動して、ITLRecovery 証明書を再生成してください。

    1. [Cisco Unified OS Administration] から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] > [検索（Find）] を選択します。

    2. 証明書の一覧を検索するには、[ 検索 ] をクリックします。

      [証明書の一覧（Certificate List）] ウィンドウが表示されます。

    3. 表示される証明書のリストから、[ITLRecovery.pem 証明書] リンクをクリックします。

    4. [ 再生成] をクリックして、ITLRecovery 証明書を再生成します。

    5. 確認メッセージのポップアップで、[ OK] をクリックします。

  4. CallManager 証明書で utils ctl reset localkey を使用して CTLFile に署名します。 これにより、新しい ITLRecovery 証明書で CTLFile も更新されます。

  5. クラスター内のすべての電話をバッチでリセットして、新しい ITLRecovery 証明書を持つ新しい CTLFile を選択します。


    （注）  

    • クラスタ内のすべての電話が登録されていることを確認してください。

    • システム全体の証明書が有効化に使用される場合、ITLRecovery の再生成はクラスタの SAML SSO ログインに影響を与えます。

  6. 新しい ITLRecovery Certificate で再署名するために CTLFile を更新します utils ctl update CTLFile。

  7. クラスター内のすべての電話を再度バッチでリセットし、新しい ITLRecovery 証明書によって署名された新しい CTLFile をピックアップします。

  8. 電話機はリセット後に新しい ITLRecovery 証明書で更新されます。

Tomcat 証明書の再生成

（注）  
リリース 14 以降、SIP OAuth が有効な場合、Tomcat の再起動後に SIP OAuth を使用するように設定された電話を手動でリセットする必要があります。

Tomcat 証明書を再生成するには、以下の手順を実行します。

手順

ステップ 1

Tomcat 証明書を再生成します。

詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

ステップ 2

Tomcat サービスの再起動

詳細については、 Cisco Unified Communications 管理者ガイドを参照してください。

ステップ 3

クラスターが EMCC 展開の一部である場合、一括証明書プロビジョニングの手順を繰り返してください。

詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

OAuth 更新ログイン用のキーの再生成

コマンドライン インターフェイスを使用して暗号キーと署名キーの両方を再生成するには、この手順を使用します。 Cisco Jabber が Unified Communications Manager との OAuth 認証に使用する暗号キーまたは署名キーが侵害された場合にのみ、この作業を実行します。 署名キーは非対称で RSA ベースであるのに対し、暗号キーは対称キーです。

このタスクを完了すると、これらのキーを使用する現在のアクセス トークンと更新トークンは無効になります。

エンド ユーザへの影響を最小限に抑えるために、このタスクは営業時間外に完了することを推奨します。

暗号キーは、以下の CLI を使用してのみ再生成できますが、発行元の Cisco Unified OS の管理 GUI を使用して署名キーを再生成することもできます。 [セキュリティ] > [証明書の管理] を選択し、AUTHZ 証明書を選択して、[再作成] をクリックします。

手順

ステップ 1

Unified Communications Manager発行元ノードでコマンドライン インターフェイスにログインします。

ステップ 2

暗号キーを再生成するには、次の手順を実行します。

  1. set key regen authz encryption コマンドを実行します。

  2. 「yes」と入力します。

ステップ 3

署名キーを再生成するには、次の手順を実行します。

  1. set key regen authz signing コマンドを実行します。

  2. 「yes」と入力します。

    Unified Communications Manager パブリッシャ ノードがキーを再生成し、IM and Presence Service のローカルノードを含めたすべての Unified Communications Manager クラスタノードに新しいキーを複製します。
すべての UC クラスタで新しいキーを再生成して同期する必要があります。

  • IM and Presence 中央クラスタ：IM and Presence 集中型展開の場合、IM and Presence ノードはテレフォニーとは別のクラスタ上で実行されています。 この場合、IM and Presence Service の中央クラスタの Unified Communications Manager パブリッシャ ノードで、この手順を繰り返します。

  • Cisco Expressway または Cisco Unity Connection：これらのクラスタ上でもキーを再生成します。 詳細については、Cisco Expressway および Cisco Unity Connection のマニュアルを参照してください。

（注）  

 

次のシナリオでは、Cisco XCP 認証サービスを再起動する必要があります。

  • 認定証明書を再作成する場合

  • IM and Presence 管理者コンソールで中央集中型導入に新しくエントリを作成する場合

信頼ストアへの認証局署名済み CAPF ルート証明書の追加

認証局が署名した CAPF 証明書を使用する場合は、ルート証明書をUnified Communications Manager信頼ストアに追加します。

手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）] > [証明書の管理（Certificate Management）] を選択します。

ステップ 2

[証明書/証明書チェーンのアップロード] をクリックします。

ステップ 3

[証明書/証明書チェーンのアップロード] ポップアップ ウィンドウで、[証明書の用途] ドロップダウン リストから [CallManager の信頼性] を選択し、認証局署名済み CAPF ルート証明書を参照します。

ステップ 4

[ファイルのアップロード] フィールドに証明書が表示されたら、[アップロード] をクリックします。

CTL ファイルの更新

この手順を使用して、CLI コマンド経由で CTL ファイルを更新します。 混合モードが有効になっている場合、新しい証明書をアップロードするたびに CTL ファイルを更新する必要があります。

手順

ステップ 1

Unified Communications Manager パブリッシャノードから、 コマンドラインインターフェースにログインします。

ステップ 2

utils ctl update CTLFile コマンドを実行します。 CTL ファイルが再生成されると、ファイルは TFTP サーバにアップロードされ、電話に自動的に送信されます。

連携動作と制限事項

  • 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_SHAで接続することができます。 これらのオプションは、選択した TLS 暗号オプションによって異なります。 [ ECDSA のみ ] オプションを選択すると、ECDSA 暗号をサポートしない端末は SIP インターフェイスへの TLS 接続を確立できなくなります。 [ECDSA のみ（ECDSA only）] オプションを選択した場合、このパラメータの値は TLS_ECDHE_ECDSA_WITH_AES128_SHA256 および TLS_ECDHE_ECDSA_WITH_AES256_SHA384です。

  • CTI マネージャセキュアクライアントは 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_SHA での接続は可能です。

  • Unified Communications Manager は、同じ SubjectDN を持つ複数の証明書が同じ信頼ストアにアップロードされることをサポートしていません。 サーバーで新規と既存の証明書を区別するため、ユーザーには、異なる名前の新しい CN を使用するか、SubjectDN-issue-CA-G2 または SubjectDN-issue-CA-2023 のような文字をサフィックスとして使用することを推奨します。 それに対してハッシュリンクが作成されます。

証明書の監視と失効

このセクションでは、更新が必要な証明書を監視し、期限切れの証明書を失効させることができます。

証明書の監視の概要

Unified Communications Manager および IM and Presence Service サービスに自動システムが含まれるとき、管理者は証明書を追跡して更新できる必要があります。 証明書の監視は、管理者が継続的に証明書の状況を把握し、証明書の有効期限が近づいたらメールで通知するのに役立ちます。

証明書モニタの設定(Certificate Monitor Configuration)

[Cisco Certificate Expiry Monitor] ネットワーク サービスを実行している必要があります。 デフォルトでこのサービスは有効化されていますが、[ツール（Tools）] > [コントロール センター - ネットワーク サービス（Control Center - Network Services）] を選択し、[Cisco Certificate Expiry Monitor サービス（Cisco Certificate Expiry Monitor Service）] の状態が [実行中（Running）] であることを検証して Cisco Unified Serviceability でサービスが実行中であることを確認できます。

手順

ステップ 1

Cisco Unified OS 管理で セキュリティ > Certificate Monitor を選択します

ステップ 2

構成の詳細を入力または選択します。

ステップ 3

[Save]をクリックして、設定を保存します。

（注）  

 

既定では、証明書監視サービスは 24 時間に 1 回実行されます。 証明書モニタ サービスを再起動すると、サービスが開始され、24 時間後に実行する次のスケジュールが計算されます。 証明書の有効期限日の 7 日間が近づいている場合でも、間隔は変更されません。 証明書の有効期限が切れた場合、または 1 日後に期限切れになる場合に、1 時間ごとに実行されます。

証明書失効の概要

この項では、証明書の失効について理解することができます。 Cisco UCM は、証明書失効を監視するための Online Certificate Status Protocol (OCSP) をプロビジョニングします。 証明書がアップロードされ、定期的なタイミングで、システムはステータスをチェックして有効性を確認します。

共通基準モードが有効な FIPS 展開の場合、OCSP はシステムが共通基準要件に準拠するように支援します。

証明書失効の設定

Unified Communications Manager 証明書のステータスをチェックし、有効性を確認します。

証明書の検証手順は以下の通りです。

  • Unified Communications Manager Delegated Trust Model (DTM) を使用し、ルート CA または中間 CA の OCSP 署名属性を確認します。 ルート CA または中間 CA は、ステータスを確認するために OCSP 証明書に署名する必要があります。

  • 委任された信頼モデルが失敗した場合、信頼レスポンダーモデル (TRP) にフォールバックします。 Unified Communications Manager は、OCSP サーバからの指定 OCSP 応答署名証明書を使用して、証明書を検証します。


（注）  

証明書の失効ステータスを確認するために、OCSP レスポンダが実行されている必要があります。

システムが期限切れの証明書を自動的に失効させるように、OCSP を設定します。 証明書失効ウィンドウで OCSP オプションを有効にして、証明書失効をリアルタイムで安全に確認する手段を提供します。 証明書の OCSP URI を使用するか、構成された OCSP URI を使用するかオプションから選択します。


（注）  

syslog、FileBeat、SIP、ILS、LBM などの TLS クライアントは、OCSP からリアルタイムで失効応答を受信します。

システムに OCSP チェックに必要な証明書があることを確認してください。 OCSP 応答属性で設定されたルートまたは中間 CA 証明書、または tomcat-trust にアップロードされた指定された OCSP 署名証明書を使用できます。


重要

このセクションは、リリース 14SU3 以降に適用されます。

証明書の失効は、無効で信頼されていない証明書を、有効な信頼された証明書から区別するプロセスです。 CAが1つまたは複数のデジタル証明書が信頼できなくなったことを知らせ、有効期限が切れる前に証明書を本質的に無効にします。

証明書失効リスト (CRL) は、実際の有効期限日または指定された有効期限日より前に発行した認証局によって失効させられたデジタル証明書のリストです。 証明書失効リストは、公開鍵基盤 (PKI) とウェブ セキュリティに不可欠です。 すべての CA には独自の CRL リストがあります。

この機能は主に、CA 発行の CAPF 署名付き電話 LSC 向けに設計されています。 CA からダウンロードした最新の CRL ファイルと以前にダウンロードした CRL ファイルに差異がある場合は、 CRLChanged アラームが生成され、Syslog サーバのメッセージとともに RTMT に表示されます。 CRLChanged アラームの詳細については、「Cisco Unified Real-Time Monitoring Tool」を参照してください。

管理者は、有効な証明書チェーンを更新および置換することでアラームに対処し、Call Manager で影響を受けるサービスを再起動して、失効した証明書を使用していた新しい TLS 既存の接続を終了する必要があります。 その後、接続は有効な新しい証明書で確立されます。

手順

ステップ 1

Cisco Unified OS Administration で、[セキュリティ（Security）] > [証明書失効（Certificate Revocation）] を選択します。

ステップ 2

[OCSP 有効化] チェックボックスをオンにします。

ステップ 3

証明書が OCSP レスポンダ URI で設定されている場合、[ 証明書の OCSP URI を使用 ] オプションをクリックします。

または

ステップ 4

OCSP チェックに OCSP レスポンダを指定する場合は、[ 設定済みの OCSP URI を使用] オプションをクリックします。

ステップ 5

レスポンダの OCSP 設定済み URI を入力します。

ステップ 6

[ 失効確認を有効にする ] チェックボックスにチェックを入れ、失効確認を有効にします。

ステップ 7

失効ステータスを確認する 頻度 を入力して、[時間] または [日] から[ ]の間隔をクリックします。

ステップ 8

[CRL 有効化] チェックボックスをオンにします。

ステップ 9

CRL ファイルをダウンロードする CRL 配布ポイント URI を入力します。

重要

 

リリース 15SU3 以降では、複数の CRL ファイルのダウンロード（Certificate Authority ごとに 1 つ）をサポートするために、最大 5 つの配布ポイント URI 設定を構成できます。

ステップ 10

[保存（Save）] をクリックします。

（注）  

 

ポップアップが表示され、Cisco サービスのリストを再起動してリアルタイム OCSP を有効にするように警告されます。 このポップアップは、[ OCSP を有効にする ] にチェックを入れるか、その後の変更を保存した場合にのみ表示されます。

OCSP レスポンダは、検証と Common Criteria モードがオンの場合に、次のいずれかのステータスを返します。

  • 正常 は、OCSP レスポンダーが状況の問い合わせに対して肯定的な応答を送信したことを示します。 証明書が失効していないということは、証明書が発行されたことや応答時間が証明書の有効期間内であることを必ずしも意味しません。 応答の拡張機能は、発行、有効性など、証明書のステータスに関して応答側によって提出されたより多くの主張を伝えます。

  • 失効 証明書が永久的または一時的に失効 (保留中) の状況であることを示します。

  • 不明 は、OCSP レスポンダーが要求された証明書を知らないことを示します。

    警告

     

    共通基準モードを有効にすると、 失効 および 不明 の場合に接続が失敗します。 コモンクライテリアモードを無効にすると、( 不明なケース )接続に成功します。

ステップ 11

（任意） CTI、IPsec または LDAP リンクがある場合は、これらの長期性接続の OCSP 失効サポートを有効にするために、上記の手順に加えて次の手順も行う必要があります。

  1. Cisco Unified CM Administrationから、[システム] > [企業パラメータ] を選択します。

  2. [ 証明書の失効と期限切れ ] ペインに移動します。

  3. パラメータ 証明書の有効性チェックを 有効に設定してください。

  4. パラメータ 有効性チェック頻度 に値を入力してください。

    （注）  

     

    [証明書失効] ウィンドウの [失効チェックを有効にする（Enable Revocation Check）] パラメータの間隔値は、[有効チェック頻度（Validity Check Frequency）] エンタープライズパラメータの値よりも優先されます。

  5. [保存（Save）] をクリックします。

シンプルな証明書管理

管理が必要な証明書の数を大幅に減らす更新の集まりにより、証明書の要件を満たすことがより簡単になりました。 Unified Communications Manager には 8 つの ID 証明書があります。 これらは、CallManager、CallManager-ECDSA、Tomcat、Tomcat-ECDSA、IPsec、CAPF、TVS、各ノードの ITL Recovery です。 これらの証明書は、有効期間に基づいて定期的に更新する必要があります。 そのため、マルチクラスタ展開のシナリオでは、これらの証明書を管理することは困難です。

簡素化された証明書管理の概要

証明書を効率的に管理するために、証明書の数を減らして再利用するオプションが追加されました。

  • TVS がマルチサーバー SAN 証明書をサポート：TVS は自己署名と CA 署名の両方のオプションでマルチサーバー SAN 証明書をサポートするようになりました。これにより、クラスタに単一の証明書を導入できます。 これらの証明書はクラスターベースです。 各クラスターには、ITL ファイル サイズと管理オーバーヘッドを削減する TVS 証明書を 1 つだけ持つオプションがあります。 たとえば、21 ノードがある場合でも、今では各クラスターに必要な証明書は 1 つだけです。

  • パブリッシャノードから生成された CAPF 証明書—CAPF 証明書はパブリッシャノードからのみ生成されるようになりました。クラスタに単一の証明書を展開することができます。 ただし、CAPF 証明書は、エンドポイント登録のパブリッシャとサブスクライバの両方のノードで、信頼証明書 (Callmanager-trust) として使用できます。

  • マルチサーバ SAN 自己署名証明書のサポート - Tomcat、Tomcat-ECDSA、CallManager、CallManager-ECDSA 証明書がマルチサーバ SAN 自己署名証明書をサポートするようになりました。 以前は、マルチサーバ SAN 証明書は CA 署名付き証明書に対してのみサポートされていました。 マルチサーバ SAN 自己署名証明書を使用することで、サードパーティの認証局からの CA を管理するコストを回避できるようになりました。

  • CallManager のマルチサーバ Tomcat 証明書の再利用:CallManager 証明書用のマルチサーバ Tomcat 証明書を再利用できるようになりました。証明書ごとに別の証明書を生成する必要がないためです。 CallManager 証明書でマルチサーバ Tomcat 証明書を再利用する方法の詳細については、 CallManager 用のマルチサーバ Tomcat 証明書の再使用を参照してください。

  • 自己署名証明書の有効期間—自己署名証明書のデフォルトの有効期間が短縮されました。 有効期間を減らすことで、キーは短期間に定期的に更新され、古い証明書が削除されます。 証明書の有効期間が長ければ長いほど、秘密鍵が危険にさらされる可能性が高くなります。 すべての自己署名証明書のデフォルトの有効期間は 5 年です。

    [ 有効期間 ] フィールドで自己署名証明書の有効期間を設定することもできます。 詳細については、 新しい自己署名証明書を生成するセクションを参照してください。

表 8. Cisco Unified Communications Manager CSR キー鍵用途拡張

Unified CM Release 14 以前

Unified CM Release 14 以降

証明書

マルチサーバ SAN 自己署名をサポート

マルチサーバ SAN CA 署名をサポート

10 ノード クラスターで管理する証明書の数

ノード/クラスター ベース

マルチサーバ SAN 自己署名をサポート

複数サーバー CA 署名対応

10 ノード クラスターで管理する証明書の数

ノード/クラスター ベース

Tomcat

N

Y

1

自己署名の場合はノードベース

Y

Y

1

クラスターベース

Tomcat-ECDSA

N

Y

1

自己署名の場合はノードベース

Y

Y

1

クラスターベース

CallManager

N

Y

1

自己署名の場合はノードベース

Y

Y

0

クラスターベース

CallManager-ECDSA

N

Y

1

自己署名の場合はノードベース

Y

Y

0

クラスターベース

TVS

N

N

10

ノードベース

Y

Y

1

クラスターベース

CAPF

N

N

10

ノードベース

Y

N

1

パブリッシャーのみ

IPsec

N

N

10

ノードベース

N

N

0

ノードベース

ITL リカバリ

N

N

1

ノードベース

N

N

1

クラスターベース

簡素化された証明書管理のユーザ インターフェイスの更新

以下のユーザ インターフェイスの更新が導入されました。

  • 証明書の再使用—[証明書管理] ウィンドウには、Tomcat マルチサーバ証明書を CallManager アプリケーションで共有するためのこの新しいオプションが含まれています。 これにより ITL ファイルのサイズが減り、オーバーヘッドが減ります。

  • 証明書を表示（Show Certificates）：Cisco Unified OS 管理インターフェイスの Certificate Management ウィンドウには、アイデンティティと信頼証明書のリストを表示するための新しいフィルタリングオプションが含まれています。

CallManager 用のマルチサーバ Tomcat 証明書の再使用

CallManager アプリケーションに対して、Tomcat マルチサーバ証明書を再利用できるようになりました。 CA から 1 つの証明書を入手し、それを複数のアプリケーションで再利用することができます。 これにより、管理オーバーヘッドを減らし、コストを最適化できます。

（注）  

Tomcat 証明書を再利用する前に、それがマルチサーバ SAN サポート証明書であることを確認してください。
手順

ステップ 1

Cisco Unified OS の管理から、[セキュリティ（Security）][証明書の管理（Certificate Management）] を選択します。

[証明書の一覧（Certificate List）]ウィンドウが表示されます。

ステップ 2

[ 証明書の再利用] をクリックします。

[ 他のサービスで Tomcat 証明書を使用する ] ページが表示されます。

ステップ 3

[Tomcat タイプを選択（Choose Tomcat type）] ドロップダウンリストから、[tomcat] または [tomcat-ECDSA] を選択します。

ステップ 4

[ 次の目的のための証明書を置換 ] ペインで、 CallManager または CallManager-ECDSA チェックボックスを選択します。

（注）  

 

[ 次の目的で証明書を置換 ] ボタンをクリックする前に、Tomcat アイデンティティ証明書に署名した CA 証明書チェーンを手動で CallManager トラストストアにアップロードしてください。 証明書の名前と説明 のセクションを参照して、Tomcat 証明書チェーンを CallManager トラストにアップロードする際に再起動する必要があるサービスを確認してください。

ステップ 5

Finish をクリックして、CallManager 証明書を Tomcat マルチサーバ SAN 証明書と置換します。

（注）  

 

  • 証明書タイプとして Tomcat を選択する場合、CallManager が代替として有効になります。

  • tomcat-ECDSA を証明書タイプとして選択する場合、CallManager-ECDSA が代替として有効になります。

  • 証明書を再使用する場合、CallManager 証明書は GUI に表示されません。