この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
システムでは、自己署名証明書とサードパーティの署名付き証明書が使用されます。送信元から宛先までのデータ整合性を確保するために、デバイスのセキュア認証、データの暗号化、データのハッシュを行う際に、システム内のデバイス間で証明書を使用します。証明書を使用することにより、帯域幅、通信、操作のセキュアな転送が可能になります。
証明書を使用する際、意図した Web サイト、電話、FTP サーバなどのエンティティとの間でデータがどのように暗号化され共有されているかを理解し、それを定義することが最も重要な部分です。
システムが証明書を信頼するということは、システムにプレインストールされている証明書によって、適切な接続先と情報を共有していることが完全に確信されているということです。そうでない場合、システムはこれらのポイント間の通信を終了します。
証明書を信頼するには、サードパーティ認証局(CA)によって信頼がすでに確立されている必要があります。
まずデバイスが CA 証明書と中間証明書の両方を信頼できると認識していることが必要であり、そうであるならデバイスは Secure Socket Layer(SSL)ハンドシェイクというメッセージの交換によって提供されるサーバ証明書を信頼することができます。
(注) | Tomcat 用の EC ベースの証明書がサポートされています。この新しい証明書を tomcat-ECDSA といいます。詳細については、『Configuration and Administration of IM and Presence Service on Cisco Unified Communications Manager』の「Enhanced TLS Encryption on IM and Presence Service」の章を参照してください。 Tomcat インターフェイスの EC 暗号はデフォルトで無効になっています。Cisco Unified Communications Manager または IM and Presence Service で [HTTPS 暗号(HTTPS Ciphers)] のエンタープライズ パラメータを使用して、これらを有効にできます。このパラメータを変更すると、すべてのノードで Cisco Tomcat サービスを再起動する必要があります。 EC ベースの証明書の詳細については、『Release Notes for Cisco Unified Communications Manager and IM and Presence Service』の「ECDSA Support for Common Criteria for Certified Solutions」を参照してください。 |
アプリケーション証明書を署名した認証局の認証局ルート証明書をアップロードします。下位認証局がアプリケーション証明書に署名した場合は、下位認証局の認証局ルート証明書をアップロードする必要があります。すべての認証局証明書の PKCS#7 形式の証明書チェーンもアップロードできます。
認証局ルート証明書およびアプリケーション証明書は、同じ [証明書のアップロード(Upload Certificate)] ダイアログボックスを使用してアップロードできます。認証局ルート証明書または認証局証明書だけがある証明書チェーンをアップロードする場合は、certificate type-trust 形式の証明書名を選択します。アプリケーション証明書またはアプリケーション証明書と認証局証明書がある証明書チェーンをアップロードする場合は、証明書タイプだけが含まれている証明書名を選択します。
たとえば、Tomcat 認証局証明書または認証局証明書チェーンをアップロードする場合は tomcat-trust を選択します。Tomcat アプリケーション証明書またはアプリケーション証明書と認証局証明書がある証明書チェーンをアップロードする場合は、tomcat または tomcat-ECDSA を選択します。
CAPF 認証局ルート証明書をアップロードすると、CallManager の信頼ストアにコピーされるため、認証局ルート証明書を個別に CallManager にアップロードする必要はありません。
(注) | サード パーティの認証局署名付き証明書が正常にアップロードされると、署名付き証明書を取得するために使用された、最近生成した CSR が削除され、サード パーティの署名付き証明書(アップロードされている場合)を含む既存の証明書が上書きされます。 |
(注) | tomcat-trust、CallManager-trust、および Phone-SAST-trust 証明書がクラスタの各ノードに自動的にレプリケートされます。 |
(注) | ディレクトリの信頼証明書を tomcat-trust にアップロードすることができます。それは、DirSync サービスがセキュア モードで動作するために必要となります。 |
サードパーティの認証局が発行するアプリケーション証明書を使用するには、署名付きのアプリケーション証明書と認証局ルート証明書の両方を、認証局から、または PKCS#7 証明書チェーン(Distinguished Encoding Rules(DER))から取得する必要があります。それには、アプリケーション証明書と認証局証明書の両方が含まれています。これらの証明書の取得に関する情報は、認証局から入手してください。そのプロセスは、認証局ごとに異なります。署名アルゴリズムでは、RSA 暗号化を使用する必要があります。
Cisco Unified Communications オペレーティング システムでは、プライバシー拡張メール(PEM)エンコード形式で CSR が作成されます。システムは、DER および PEM エンコード形式の証明書と、PEM 形式の PKCS#7 証明書チェーンを受け入れます。認証局プロキシ機能(CAPF)以外の証明書タイプの場合、それぞれのノードについて認証局ルート証明書およびアプリケーション証明書を取得してアップロードする必要があります。
CAPF の場合、1 つ目のノードについてのみ認証局ルート証明書およびアプリケーション証明書を取得してアップロードします。CAPF および Cisco Unified Communications Manager の CSR には、認証局へのアプリケーション証明書要求に含める必要のある拡張情報が含まれています。認証局が拡張要求メカニズムをサポートしていない場合は、次の手順に従って X.509 拡張をイネーブルにする必要があります。
CAPF CSR では、次の拡張情報が使用されます。
X509v3 拡張キーの使用: TLS Web サーバ認証、IPSec エンド システム X509v3 キーの使用: デジタル署名、証明書署名
Tomcat および Tomcat-ECDSA の CSR では、次の拡張情報を使用します。
(注) | Tomcat または Tomcat-ECDSA では、キー同意も IPsec エンド システム キー使用も不要です。 |
X509v3 拡張キー使用: TLS Web サーバ認証、TLS Web クライアント認証、IPSec エンド システム X509v3 キー使用: デジタル署名、キー暗号化、データ暗号化、キー同意
IPSec の CSR では、次の拡張情報を使用します。
X509v3 拡張キー使用: TLS Web サーバ認証、TLS Web クライアント認証、IPSec エンド システム X509v3 キー使用: デジタル署名、キー暗号化、データ暗号化、キー同意
Cisco Unified Communications Manager の CSR では、次の拡張情報を使用します。
X509v3 拡張キー使用: TLS Web サーバ認証、TLS Web クライアント認証 X509v3 キー使用: デジタル署名、キー暗号化、データ暗号化、キー同意
(注) | 自分の証明書に対して CSR を生成し、SHA256 署名によってサードパーティの認証局で署名することもできます。Tomcat および他の証明書が SHA256 をサポートできるように、この署名付き証明書を Cisco Unified Communications Manager に再度アップロードすることができます。 |
中間証明書をインストールするには、まずルート証明書をインストールして、署名付き証明書をアップロードする必要があります。この手順は、認証局から 1 つの署名付き証明書と複数の証明書が証明書チェーンで提供されている場合にのみ必要です。
ヒント | ルート証明書の名前は、ルート証明書がアップロードされたときに生成された .pem ファイル名です。 |
削除できる証明書は、信頼できる証明書だけです。システムで生成される自己署名証明書は削除できません。
注意 | 証明書を削除すると、システムの動作に影響する場合があります。証明書が既存のチェーンの一部である場合、証明書を削除すると証明書チェーンが壊れることがあります。この関係は、[証明書の一覧(Certificate List)] ウィンドウ内の関連する証明書のユーザ名とサブジェクト名から確認できます。この操作は取り消すことができません。 |
ステップ 1 | [Cisco Unified OS の管理(Cisco Unified OS Administration)] から を選択します。 | ||
ステップ 2 | 証明書の一覧をフィルタするには、[検索(Find)] コントロールを使用します。 | ||
ステップ 3 | 証明書のファイル名を選択します。 | ||
ステップ 4 | [削除(Delete)] をクリックします。 | ||
ステップ 5 | [OK] をクリックします。
|
証明書が期限切れの場合は、再作成します。電話機を再起動してサービスを再起動する必要があるため、営業時間後にこの手順を実行します。Cisco Unified OS の管理に "cert" タイプとしてリストされている証明書のみ再作成できます。
注意 | 証明書を再作成すると、システムの動作に影響する場合があります。証明書を再作成すると、サード パーティの署名付き証明書(アップロードされている場合)を含む既存の証明書が上書きされます。 |
ステップ 1 | [Cisco Unified OS の管理(Cisco Unified OS Administration)] から を選択します。 | ||
ステップ 2 | [自己署名証明書の新規作成(Generate New Self-Signed Certificate)] ウィンドウのフィールドを設定します。フィールドとその設定オプションの詳細については、オンライン ヘルプを参照してください。 | ||
ステップ 3 | [生成(Generate)] をクリックします。 | ||
ステップ 4 | 再作成された証明書の影響を受けるサービスをすべて再起動します。証明書名と説明の詳細については、関連項目のセクションを参照してください。 | ||
ステップ 5 | CAPF 証明書または CallManager 証明書の再作成後に CTL クライアントを再実行します(設定している場合)。
|
証明書を再作成したら、システムのバックアップを実行して、最新のバックアップに再作成した証明書が含まれるようにします。バックアップに再作成した証明書が含まれていない状態でシステムの復元タスクを実行する場合は、システム内の各電話機のロックを手動で解除して、電話機を登録できるようにする必要があります。バックアップ タスク フローを参照してください。
関連サービス(Related Services) |
||
---|---|---|
tomcat-ECDSA |
Tomcat と TFTP |
|
この自己署名ルート証明書は、MGCP ゲートウェイおよび H.323 ゲートウェイとの IPsec 接続のインストール中に生成されます。 |
Cisco Disaster Recovery System(DRS)Local と Cisco DRF Master |
|
この自己署名ルート証明書は、Cisco Unified Communications Manager のインストール時に自動的にインストールされます。この証明書は、ノード名およびグローバル固有識別子(GUID)など、ノードの ID を提供します。 |
CallManager、CAPF、および CTI |
|
このルート証明書は、Cisco クライアント設定を完了すると、現在のノードまたはクラスタ内のすべてのノードにコピーされます。 |
CallManager と CAPF |
|
TVS |
ステップ 1 | Cisco Unified OS の管理から、 を選択します。 | ||
ステップ 2 | [証明書/証明書チェーンのアップロード(Upload Certificate/Certificate chain)] をクリックします。 | ||
ステップ 3 | [証明書の用途(Certificate Purpose)] ドロップダウン リストから証明書の名前を選択します。 | ||
ステップ 4 | 次のいずれかの手順を実行して、アップロードするファイルを選択します。 | ||
ステップ 5 | ファイルをサーバにアップロードするには、[ファイルのアップロード(Upload File)] をクリックします。
|
このタスク フローでは、サード パーティの証明書プロセスの概要を順序に従って説明します。システムでは、サード パーティの認証局が PKCS # 10 証明書署名要求(CSR)によって発行した証明書がサポートされています。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | 証明書署名要求の生成 |
証明書署名要求(CSR)を生成します。これは、公開キー、組織名、共通名、地域、および国などの証明書申請情報を含む暗号化されたテキストのブロックです。認証局はこの CSR を使用して、ご使用のシステムの信頼できる証明書を生成します。 |
ステップ 2 | 証明書署名要求のダウンロード | |
ステップ 3 | 認証局のドキュメントを参照してください。 |
認証局からアプリケーション証明書を取得します。 |
ステップ 4 | 認証局のドキュメントを参照してください。 |
認証局からルート証明書を取得します。 |
ステップ 5 | 信頼ストアへの認証局署名付き CAPF ルート証明書の追加 | ルート証明書を信頼ストアに追加します。認証局の署名付き CAPF 証明書を使用している場合は、この手順を実行します。 |
ステップ 6 | 証明書または証明書チェーンのアップロード | |
ステップ 7 | CAPF または Cisco Unified Communications Manager の証明書を更新した場合は、新しい CTL ファイルを生成します。 |
『Cisco Unified Communications Manager Security Guide』(http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html)を参照してください。 サードパーティの署名付き CAPF または CallManager 証明書をアップロードしたら、CTL クライアント(設定している場合)を再実行します。 |
ステップ 8 | サービスの再起動 |
新しい証明書の影響を受けるサービスを再起動します。すべての証明書タイプで、対応するサービスを再起動します(たとえば、Tomcat または Tomcat-ECDSA 証明書を更新した場合は Cisco Tomcat サービスを再起動します)。 |
証明書署名要求(CSR)を生成します。これは、公開キー、組織名、共通名、地域、および国などの証明書申請情報を含む暗号化されたテキストのブロックです。認証局はこの CSR を使用して、ご使用のシステムの信頼できる証明書を生成します。
(注) | 新しい CSR を生成すると、既存の CSR は上書きされます。 |
コンピュータに CSR をダウンロードして、認証局に証明書を送信できるようにします。
認証局の署名付き CAPF 証明書を使用する場合は、次の手順に従ってルート証明書を CallManager 信頼ストアに追加します。
ステップ 1 | Cisco Unified OS の管理から、 を選択します。 |
ステップ 2 | [証明書/証明書チェーンのアップロード(Upload Certificate/Certificate chain)] をクリックします。 |
ステップ 3 | [証明書/証明書チェーンのアップロード(Upload Certificate/Certificate chain)] ポップアップ ウィンドウの [証明書の目的(Certificate Purpose)] ドロップダウンリストから [CallManager-trust] を選択し、認証局の署名付き CAPF ルート証明書を参照します。 |
ステップ 4 | [ファイルのアップロード(Upload File)] フィールドに証明書が表示されたら、[アップロード(Upload)] をクリックします。 |
クラスタ内の特定のノードで機能またはネットワーク サービスを再起動する必要がある場合は、次の手順に従います。
証明書の有効期限日が近づいたときに、電子メール メッセージをユーザに自動的に送信するようにシステムを設定するには、次の手順に従います。
ステップ 1 | [Cisco Unified OS の管理(Cisco Unified OS Administration)] から、 を選択します。 |
ステップ 2 | [通知開始時期(Notification Start Time)] に数値を入力します。この値は、電子メールでの通知が送信されるまでの日数です。 |
ステップ 3 | [通知の頻度(Notification Frequency)] に数値を入力し、[日数(Days)] または [時間数(Hours)] を選択します。 |
ステップ 4 | (任意) [電子メール通知を有効にする(Enable email notification)] をオンにし、[電子メール ID(email IDs)] フィールドに電子メール アドレスを入力します。 |
ステップ 5 | [保存(Save)] をクリックします。 |
Online Certificate Status Protocol(OCSP)を使用して、証明書の失効ステータスを取得します。
(注) | 証明書失効ステータス チェックは、証明書または証明書チェーンのアップロード時にのみ実行されます。証明書が失効している場合、該当するアラームが表示されます。 |
OSCP を有効にする前に、OCSP レスポンダ証明書を tomcat-trust にアップロードする必要があります。
注意
ステップ 1 | [Cisco Unified OS の管理(Cisco Unified OS Administration)] から、 を選択します。 | ||
ステップ 2 | [OCSP の有効化(Enable OCSP)] チェック ボックスをオンにし、次のいずれかのタスクを実行します。 | ||
ステップ 3 | [失効チェックの有効化(Enable Revocation Check)] チェック ボックスをオンにして、失効チェックを実行します。
| ||
ステップ 4 | [チェック間隔(Check Every)] の値を入力して、証明書の失効ステータス チェックの実行頻度を設定します。 | ||
ステップ 5 | [保存(Save)] をクリックします。 |
ステップ 1 | [Cisco Unified OS の管理(Cisco Unified OS Administration)] の で、必要な tomcat-trust 証明書が存在することを確認します。。 必要な証明書がない場合は、再度確認するまで 30 分間待ちます。 |
ステップ 2 | 証明書を選択して情報を表示します。証明書の内容が、リモート ノード上の対応する証明書の内容と一致することを確認します。 |
ステップ 3 | CLI から、utils service restart Cisco Intercluster Sync Agent を実行して Cisco Intercluster Sync Agent サービスを再起動します。 |
ステップ 4 | Cisco Intercluster Sync Agent サービスが再起動したら、utils service restart Cisco Tomcat を実行して Cisco Tomcat サービスを再起動します。 |
ステップ 5 | 30 分間待機します。前の手順で証明書のエラーが対処されず、tomcat-trust 証明書が存在する場合は、証明書を削除します。証明書を削除したら、ノードごとに Tomcat および Tomcat-ECDSA 証明書をダウンロードし、tomcat-trust 証明書としてピアにアップロードすることで、証明書を手動で交換する必要があります。 |
ステップ 6 | 証明書の交換が完了したら、utils service restart Cisco Tomcat を実行して、影響を受ける各サーバで Cisco Tomcat を再起動します。 |