この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、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 ベースの証明書の詳細については、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 証明書がクラスタの各ノードに自動的にレプリケートされます。 |
(注) | DirSync サービスをセキュア モードで実行する場合に必要となるディレクトリの信頼証明書は、tomcat-trust にアップロードすることができます。 |
サードパーティ認証局が発行するアプリケーション証明書を使用するには、署名付きのアプリケーション証明書と認証局ルート証明書の両方を認証局から取得するか、アプリケーション証明書と認証局証明書の両方が含まれている PKCS#7 証明書チェーン(Distinguished Encoding Rules [DER])から取得する必要があります。これらの証明書の取得に関する情報は、認証局から入手してください。証明書を取得するプロセスは、認証局によって異なります。署名アルゴリズムでは RSA 暗号化が使用されている必要があります。
Cisco Unified Communications オペレーティング システムでは、プライバシー強化メール(PEM)エンコード形式で CSR が作成されます。システムは、DER および PEM エンコード形式の証明書と、PEM 形式の PKCS#7 証明書チェーンを受け入れます。認証局プロキシ機能(CAPF)以外のすべての証明書タイプの場合、それぞれのノードについて認証局ルート証明書およびアプリケーション証明書を取得してアップロードする必要があります。
CAPF の場合、最初のノードについてのみ認証局ルート証明書およびアプリケーション証明書を取得してアップロードします。CAPF および Cisco Unified Communications Manager の CSR には、認証局へのアプリケーション証明書要求に含める必要のある拡張情報が含まれています。認証局が拡張要求メカニズムをサポートしていない場合は、次の手順に従って X.509 拡張を有効にする必要があります。
CAPF CSR では、次の拡張情報が使用されます。
X509v3 Extended Key Usage: TLS Web Server Authentication, IPSec End System X509v3 Key Usage: Digital Signature, Certificate Sign
Tomcat および Tomcat-ECDSA の CSR では、次の拡張情報が使用されます。
(注) | Tomcat または Tomcat-ECDSA は、キー アグリーメントや IPsec エンド システム キーを使用する必要はありません。 |
X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
IPsec の CSR では、次の拡張情報が使用されます。
X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
Cisco Unified Communications Manager の CSR では、次の拡張情報が使用されます。
X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
(注) | 使用する証明書に対して CSR を生成し、SHA256 署名を使用してサードパーティ認証局に署名させることもできます。この署名付き証明書を Cisco Unified Communications Manager に再度アップロードすることで、Tomcat および他の証明書が SHA256 をサポートできるようになります。 |
中間証明書をインストールするには、まずルート証明書をインストールして、署名付き証明書をアップロードする必要があります。この手順は、認証局から 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 クライアントを再実行します(設定している場合)。
|
証明書を再作成したら、システムのバックアップを実行して、最新のバックアップに再作成した証明書が含まれるようにします。バックアップに再作成した証明書が含まれていない状態でシステムの復元タスクを実行する場合は、システム内の各電話機のロックを手動で解除して、電話機を登録できるようにする必要があります。バックアップ タスク フローを参照してください。
関連サービス |
||
---|---|---|
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 |
コマンドライン インターフェイスを使用して暗号キーと署名キーの両方を再生成するには、この手順を使用します。Cisco Jabber が Cisco Unified Communications Manager による OAuth 認証に使用する暗号キーまたは署名キーが侵害された場合にのみ、この作業を実行します。署名キーは非対称で RSA ベースであるのに対し、暗号キーは対称キーです。
(注) |
|
すべての UC クラスタで新しいキーを再生成して同期する必要があります。
IM and Presence 中央クラスタ:IM and Presence 集中型展開の場合、IM and Presence ノードはテレフォニーとは別のクラスタ上で実行されています。この場合は、IM and Presence サービス中央クラスタの Cisco Unified Communications Manager のパブリッシャ ノードでこの手順を繰り返します。
Cisco Expressway または Cisco Unity Connection:これらのクラスタ上でもキーを再生成します。詳細については、Cisco Expressway および Cisco Unity Connection のマニュアルを参照してください。
ステップ 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 の信頼性(CallManager-trust)] を選択し、認証局署名済み CAPF ルート証明書を参照します。 |
ステップ 4 | [ファイルのアップロード(Upload File)] フィールドに証明書が表示されたら、[アップロード(Upload)] をクリックします。 |
クラスタ内の特定のノードで機能またはネットワーク サービスを再起動する必要がある場合は、次の手順に従います。
この手順を使用して、証明書の有効期限が近づいたときに、システムが自動的に電子メール メッセージをユーザに送信するように設定します。
ステップ 1 | 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 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 を再起動します。 |