この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Cisco Unified Communications Manager(CUCM)で認証局(CA)によって署名された証明書を再生成する方法について説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
注:自己署名証明書の再生成については、『証明書の再生成ガイド』を参照してください。CA署名付きマルチSAN証明書の再生成については、『マルチSAN証明書の再生成ガイド』を参照してください。
各証明書とその再生成の影響については、『自己署名再生成ガイド』を参照してください。
証明書署名要求(CSR)タイプごとに異なるキー使用法があり、それらは署名付き証明書に必要です。セキュリティガイドには、証明書の各タイプに必要なキー使用法が記載されたテーブルが含まれています。
サブジェクト設定(地域、州、組織単位など)を変更するには、次のコマンドを実行します。
set web-security orgunit orgname locality state [country] [alternatehostname]
Tomcat証明書は、 set web-security
コマンドが表示されない場合もあります。Tomcatサービスを再起動しない限り、新しい自己署名証明書は適用されません。このコマンドの詳細については、次のガイドを参照してください。
CAによって署名されたCUCMクラスタ内の単一ノード証明書を再生成する手順は、証明書のタイプごとにリストされています。クラスタ内のすべての証明書が期限切れになっていない場合は、再生成する必要はありません。
注意:クラスタでSSOが無効になっていることを確認します(CM Administration > System > SAML Single Sign-On
)。 SSOを有効にする場合は、SSOを無効にして、Tomcat証明書の再生成プロセスが完了したら有効にする必要があります。
クラスタのすべてのノード(CallManagerおよびIM&P)で、次の操作を実行します。
ステップ1:に移動します。 Cisco Unified OS Administration > Security > Certificate Management > Find
Tomcat証明書の有効期限を確認します。
ステップ2: Generate CSR >
.証明書の設定を選択し、 Certificate Purpose: tomcat
Generate
.成功メッセージが表示されるまで待ち、 Close
.
ステップ3:CSRをダウンロードします。クリック Download CSR
、選択 Certificate Purpose: tomcat
,
をクリックし、 Download
.
ステップ4:CSRを認証局に送信します。
ステップ5:認証局は、署名付き証明書チェーン用に2つ以上のファイルを返します。証明書を次の順序でアップロードします。
Certificate Management > Upload certificate > Certificate Purpose: tomcat-trust.
証明書の説明を設定し、ルート証明書ファイルを参照します。Certificate Management > Upload certificate > Certificate Purpose: tomcat-trust
.証明書の説明を設定し、中間証明書ファイルを参照します。注:一部のCAは中間証明書を提供しません。ルート証明書のみが提供されている場合、この手順は省略できます。
Certificate Management > Upload certificate > Certificate Purpose: tomcat
。証明書の説明を設定し、現在のCUCMノードのCA署名付き証明書ファイルを参照します。注:この時点で、CUCMはCSRとアップロードされたCA署名付き証明書を比較します。情報が一致すると、CSRが消去され、新しいCA署名付き証明書がアップロードされます。証明書のアップロード後にエラーメッセージが表示される場合は、 Upload Certificate Common Error Messages
。
ステップ6:新しい証明書をサーバに適用するには、CLIを使用してCisco Tomcatサービスを再起動する必要があります(パブリッシャから開始し、サブスクライバを1つずつ開始する)。次のコマンドを使用します utils service restart Cisco Tomcat
.
Tomcat証明書がCUCMで使用されていることを確認します。ノードのWebページに移動し、 Site Information
(ロックアイコン)をクリックし、 certificate
を選択し、新しい証明書の日付を確認します。
注意:CallManager証明書とTVS証明書を同時に再生成しないでください。これにより、エンドポイントにインストールされているITLと回復不能な不一致が発生し、クラスタ内のすべてのエンドポイントからITLを削除する必要があります。CallManagerのプロセス全体を終了し、電話機が再登録されたら、TVSのプロセスを開始します。
注:クラスタが混合モードであるかどうかを確認するには、[Cisco Unified CM Administration] > [System] > [Enterprise Parameters] > [Cluster Security Mode (0 == Non-Secure;1 == 混合モード)。
クラスタのすべてのCallManagerノードについて、次の手順を実行します。
ステップ1:に移動します。
CallManager証明書の有効期限を確認します。Cisco Unified OS Administration > Security > Certificate Management > Find
ステップ2: Generate CSR > Certificate Purpose: CallManager
.証明書の設定を選択し、 Generate
.成功メッセージが表示されるまで待ち、 Close
.
ステップ3:CSRをダウンロードします。クリック Download CSR. Select Certificate Purpose: CallManager and click Download
.
ステップ4:CSRを Certificate Authority
.
ステップ5:認証局は、署名付き証明書チェーン用に2つ以上のファイルを返します。証明書を次の順序でアップロードします。
Certificate Management > Upload certificate > Certificate Purpose: CallManager-trust
.証明書の説明を設定し、ルート証明書ファイルを参照します。Certificate Management > Upload certificate > Certificate Purpose: CallManager-trust
.証明書の説明を設定し、中間証明書ファイルを参照します。注:一部のCAは中間証明書を提供しません。ルート証明書のみが提供されている場合、この手順は省略できます。
Certificate Management > Upload certificate > Certificate Purpose: CallManager
.証明書の説明を設定し、現在のCUCMノードのCA署名付き証明書ファイルを参照します。注:この時点で、CUCMはCSRとアップロードされたCA署名付き証明書を比較します。情報が一致すると、CSRが消去され、新しいCA署名付き証明書がアップロードされます。証明書のアップロード後にエラーメッセージが表示される場合は、「証明書のアップロードに関する一般的なエラーメッセージ」セクションを参照してください。
ステップ6:クラスタが混合モードの場合、サービスを再起動する前にCTLを更新します。TokenまたはTokenless。クラスタが非セキュアモードの場合は、この手順を省略してサービスの再起動に進みます。
ステップ7:新しい証明書をサーバに適用するには、必要なサービスを再起動する必要があります(サービスが実行され、アクティブな場合のみ)。 次のとおりに移動します。
Cisco Unified Serviceability > Tools > Control Center - Network Services > Cisco Trust Verification Service
Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco TFTP
Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco CallManager
Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco CTIManager
ステップ8:すべての電話をリセットします。
Cisco Unified CM Administration > System > Enterprise Parameters > Reset
.ポップアップウィンドウに「You are about to reset all devices in the system.この操作は元に戻せません。Continue?選択 OK
次に、 Reset
.注:RTMTを使用してデバイス登録を監視します。すべての電話機が登録し直されたら、次の証明書タイプに進むことができます。
注意:IPSec証明書が再生成される場合、バックアップタスクまたは復元タスクはアクティブであってはなりません。
クラスタのすべてのノード(CallManagerおよびIM&P)について、次の手順を実行します。
ステップ1:に移動します。 Cisco Unified OS Administration > Security > Certificate Management > Find
ipsec証明書の有効期限を確認します。
ステップ2:[Generate CSR] > [Certificate Purpose:IPSec.証明書に必要な設定を選択し、[Generate] をクリックします。成功メッセージが表示されるまで待ってから、Closeをクリックします。
ステップ3:CSRをダウンロードします。[Download CSR] をクリックします。Certificate Purpose ipsecを選択し、Downloadをクリックします。
ステップ4:CSRを認証局に送信します。
ステップ5:認証局は、署名付き証明書チェーン用に2つ以上のファイルを返します。証明書を次の順序でアップロードします。
注:一部のCAは中間証明書を提供しません。ルート証明書のみが提供されている場合、この手順は省略できます。
注:この時点で、CUCMはCSRとアップロードされたCA署名付き証明書を比較します。情報が一致すると、CSRが消去され、新しいCA署名付き証明書がアップロードされます。証明書のアップロード後にエラーメッセージが表示される場合は、「証明書のアップロードに関する一般的なエラーメッセージ」< /strong>セクションを参照してください。
ステップ6:新しい証明書をサーバに適用するには、必要なサービスを再起動する必要があります(サービスが実行され、アクティブな場合のみ)。 次のとおりに移動します。
Master
(パブリッシャ)注:クラスタが混合モードであるかどうかを確認するには、[Cisco Unified CM Administration] > [System] > [Enterprise Parameters] > [Cluster Security Mode](0 == Non-Secure;1 == 混合モード)。
注:CAPFサービスはパブリッシャでのみ動作し、これが使用される唯一の証明書です。サブスクライバノードは使用されないため、CAによって署名されたサブスクライバノードを取得する必要はありません。サブスクライバで証明書が期限切れになり、期限切れの証明書のアラートを回避する場合は、サブスクライバCAPF証明書を自己署名として再生成できます。詳細については、「自己署名としてのCAPF証明書」を参照してください。
[Publisher:
ステップ1:[Cisco Unified OS Administration] > [Security] > [Certificate Management] > [Find] に移動し、CAPF証明書の有効期限を確認します。
ステップ2:[Generate CSR] > [Certificate Purpose:CAPF.証明書に必要な設定を選択し、Generateをクリックします。成功メッセージが表示されるまで待ち、[Close] をクリックします。
ステップ3:CSRをダウンロードします。[Download CSR] をクリックします。Certificate Purpose CAPFを選択し、Downloadをクリックします。
ステップ4:CSRを認証局に送信します。
ステップ5:認証局は、署名付き証明書チェーン用に2つ以上のファイルを返します。証明書を次の順序でアップロードします。
注:一部のCAは中間証明書を提供しません。ルート証明書のみが提供されている場合、この手順は省略できます。
注:この時点で、CUCMはCSRとアップロードされたCA署名付き証明書を比較します。情報が一致すると、CSRが消去され、新しいCA署名付き証明書がアップロードされます。証明書のアップロード後にエラーメッセージが表示される場合は、「証明書のアップロードに関する一般的なエラーメッセージ」セクションを参照してください。
ステップ6:クラスタが混合モードの場合、サービスを再起動する前にCTLを更新します。TokenまたはTokenless。クラスタが非セキュアモードの場合は、この手順を省略してサービスの再起動に進みます。
ステップ7:新しい証明書をサーバに適用するには、必要なサービスを再起動する必要があります(サービスが実行され、アクティブな場合のみ)。 次のとおりに移動します。
ステップ8:すべての電話をリセットします。
注:RTMTを使用してデバイス登録を監視します。すべての電話機が登録し直されたら、次の証明書タイプに進むことができます。
注意:CallManager証明書とTVS証明書を同時に再生成しないでください。これにより、エンドポイントにインストールされているITLと回復不能な不一致が発生し、クラスタ内のすべてのエンドポイントからITLを削除する必要があります。CallManagerのプロセス全体を終了し、電話機が再登録されたら、TVSのプロセスを開始します。
クラスタのすべてのTVSノードについて、次の手順を実行します。
ステップ1:[Cisco Unified OS Administration] > [Security] > [Certificate Management] > [Find] に移動し、TVS証明書の有効期限を確認します。
ステップ2:[Generate CSR] > [Certificate Purpose:TVS.証明書に必要な設定を選択し、Generateをクリックします。成功メッセージが表示されるまで待ち、[Close] をクリックします。
ステップ3:CSRをダウンロードします。[Download CSR] をクリックします。Certificate Purpose TVSを選択し、Downloadをクリックします。
ステップ4:CSRを認証局に送信します。
ステップ5:認証局は、署名付き証明書チェーン用に2つ以上のファイルを返します。証明書を次の順序でアップロードします。
注:一部のCAは中間証明書を提供しません。ルート証明書のみが提供されている場合、この手順は省略できます。
注:この時点で、CUCMはCSRとアップロードされたCA署名付き証明書を比較します。情報が一致すると、CSRが消去され、新しいCA署名付き証明書がアップロードされます。証明書のアップロード後にエラーメッセージが表示される場合は、「証明書のアップロードに関する一般的なエラーメッセージ」セクションを参照してください。
ステップ6:新しい証明書をサーバに適用するには、必要なサービスを再起動する必要があります(サービスが実行され、アクティブな場合のみ)。 次のとおりに移動します。
ステップ7:すべての電話をリセットします。
注:RTMTを使用してデバイス登録を監視します。すべての電話機が登録し直されたら、次の証明書タイプに進むことができます。
このセクションでは、CA署名付き証明書のアップロード時に表示される最も一般的なエラーメッセージの一部を示します。
このエラーは、ルートまたは中間証明書がCUCMにアップロードされなかったことを意味します。サービス証明書をアップロードする前に、これら2つの証明書が信頼ストアとしてアップロードされたことを確認します。
このエラーは、証明書(tomcat、callmanager、ipsec、capf、tvs)のCSRが存在しない場合に表示されます。 CSRが以前に作成され、証明書がそのCSRに基づいて作成されたことを確認します。留意すべき重要なポイント:
このエラーは、CAによって提供された証明書に、CSRファイルで送信された公開キーと異なる公開キーがある場合に表示されます。考えられる原因は次のとおりです。
CSRと証明書の公開キーの一致を確認するには、SSLなどの複数のツールをオンラインで使用します。
同じ問題に関する別のエラーとして、「The file /usr/local/platform/upload/certs//tomcat.der could not be uploaded」が考えられます。 これは、CUCMのバージョンによって異なります。
CSRと証明書の間のSANは同じである必要があります。これにより、許可されていないドメインの認証が防止されます。SANの不一致を確認するには、次の手順に従います。
1. CSRと証明書をデコードします(ベース64)。 Decoderなど、さまざまなデコーダをオンラインで使用できます。
2. SANエントリを比較し、すべてが一致することを確認します。順序は重要ではありませんが、CSRのすべてのエントリが証明書と同じである必要があります。
たとえば、CA署名付き証明書には、証明書の共通名と追加のIPアドレスの2つの追加SANエントリが追加されています。
3. SANが一致しないことを確認した場合、これを修正する2つのオプションがあります。
CUCMによって作成されたCSRを変更するには、次の手順を実行します。
3. CUCMによって自動補完されたものとは別に代替名を追加するには、次の手順に従います。
b.証明書がシングルノードの場合は、 set web-security
コマンドが表示されない場合もあります。このコマンドは、マルチSAN証明書にも適用されます。(任意の種類のドメインを追加でき、IPアドレスも許可されます)。
詳細については、『コマンドラインリファレンスガイド』を参照してください。
CUCMは、同じ共通名と証明書タイプを持つ証明書を1つだけ保存するように設計されています。つまり、tomcat-trustである証明書がデータベースにすでに存在し、同じCNを持つ最新の証明書に置き換える必要がある場合、CUCMは古い証明書を削除して、新しい証明書に置き換えます。
CUCMが古い証明書を置き換えない場合があります。
改定 | 発行日 | コメント |
---|---|---|
3.0 |
14-Sep-2022 |
再認定 |
1.0 |
17-May-2021 |
初版 |