内容

概要

背景説明

前提条件

要件

使用するコンポーネント

証明書を再生成するタイミング

証明書ストアによるサービスへの影響

DRS バックアップの作成

混合モードの決定

クラスタが混合モードの場合

クラスタのデフォルト セキュリティを確認する

Prepare Cluster for Rollback to pre 8.0機能の使用

特定の順序で証明書を再生成する

1種類の証明書を一度に再生成する

CUCM での証明書の削除と再生成

CLI での証明書の再生成

この処理による影響

CLI での証明書の削除

Web GUI での証明書の再生成

Web GUI での証明書の削除

証明書の再生成と削除の後

使用されなくなった証明書を識別する方法 – trust証明書

電話機の LSC のインストールと更新

他の証明書の更新プロセス

結論

概要

このドキュメントでは、Cisco Unified Communications Manager(CUCM)リリース8.x以降で使用される証明書を再生成する方法について説明します。

背景説明

このドキュメントでは、デフォルトのセキュリティ(SBD)機能に従って有効になるID信頼リスト(ITL)と、混合モード環境の証明書信頼リスト(CTL)についても説明し、望ましくない停止を回避します。たとえば、電話機の登録の問題や、設定の変更やファームウェアを受け入れない電話機を回避する方法を説明します。

注意：証明書の再生成は、常にメンテナンスウィンドウで実行することをお勧めします。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- CallManager

- CAPF（Certificate Authority Proxy Function）

- IPSec

- Tomcat

- TVS（信頼検証サービス）

- ITLRecovery（CUCM 10.X 以降のみ）

- phone-vpn-trust

- phone-sast-trust

- phone-trust

- phone-ctl-trust

- LSC（ローカルで有効な証明書）

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

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアのバージョンに基づいています。

- CUCMリリース9.1(2)SU2a、

- CUCMリリース8.x以降

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

証明書を再生成するタイミング

新規インストール後に CUCM で使用される証明書の多くは、デフォルトで 5 年間有効な自己署名証明書です。現在、5年間の時間範囲をCUCMの短い時間範囲に変更することはできません。ただし、認証局（CA）はほぼあらゆる時間範囲で証明書を発行することができます。

CUCMの証明書は、次の2つの役割に分類されます。

- サービス証明書：証明書を再生成することは可能で、-trustという言葉のラベルは付いていません。各ノードには独自のサービス証明書があります。これは、各pubとsubにCallManager、Tomcat、IPsec、TVS、およびCAPF証明書があることを意味します。

- 証明書を信頼する：証明書を再生成することはできず、「 – trust」というラベルが付きます。これらの証明書は、サービス証明書のコピー、デフォルトでインストールされる証明書、または他のサーバからの証明書です。

また、事前にロードされ、有効期間がより長い、信頼できる証明書もあります（CAPF-trust や CallManager-trust など）。たとえば、Cisco Manufacturing CA証明書は、特定の機能に対してCUCM信頼ストアで提供され、2029年まで期限切れになりません。

証明書は、期限切れになる前に再生成する必要があります。証明書の有効期限が近づくと、RTMT(Syslog Viewer)で警告が表示され、設定されている場合は通知が記載された電子メールが送信されます。

CUCM01.der証明書が5月19日（月）14:46に信頼ストアtomcat-trustのサーバCUCM02で期限切れになることを詳細に示す証明書期限切れ通知の例を次に示します。

At Fri Sep 05 02:00:56 CEST 2014 on node 192.168.1.2, the following

SyslogSeverityMatchFound events generated:

SeverityMatch : Critical

MatchedEvent : Sep 5 02:00:06 CUCM02 local7 2 : 864: CUCM02.localdomain:

Sep 05 2014 00:00:06.433 UTC : %UC_CERT-2-CertValidfor7days:

%[Message=Certificate expiration Notification. Certificate name:CUCM01.der

Unit:tomcat-trust Type:own-cert Expiration:Mon May 19 14:46:]

[AppID=Cisco Certificate Monitor][ClusterID=][NodeID=CUCM02]:

Alarm to indicate that Certificate has Expired or Expires in less than seven days

AppID : Cisco Syslog Agent

ClusterID :

NodeID : CUCM02

TimeStamp : Fri Sep 05 02:00:16 CEST 2014

クラスタの設定によっては、期限切れの証明書がCUCM機能に影響を与える可能性があることに注意してください。考慮事項については、次のセクションで説明します。

証明書ストアによるサービスへの影響

システムの優れた機能を実現するには、CUCMクラスタ全体ですべての証明書を更新することが重要です。証明書の期限が切れたり無効になったりすると、システムの通常の機能に大きな影響を与える可能性があります。特定の証明書のいずれかが無効または期限切れになった場合に発生する可能性のある問題のリストを次に示します。影響の違いは、システムの設定によって異なります。

CallManager.pem

- TFTP が信頼されません（電話機は署名付きのコンフィギュレーション ファイルや ITL ファイルを受け付けません）。

- 電話サービスが影響を受ける可能性があります。

- Secure Session Initiation Protocol(SIP)トランクまたはメディアリソース(会議ブリッジ、メディアターミネーションポイント(MTP)、Xcodersなど)が登録または機能しません。

- AXL 要求が失敗します。

Tomcat.pem

- 電話機が社内ディレクトリなどの CUCM ノードでホストされる HTTPS サービスにアクセスできません。

- クラスタ内の他のノードからサービス ページにアクセスできないなど、CUCM の Web GUI 問題が発生します。

- エクステンション モビリティおよびクラスタ間のエクステンション モビリティの問題が発生します。

- UCCX(Unified Contact Center Express)が統合されている場合、CCX 12.5からのセキュリティ変更のため、Finesseデスクトップログインに影響するため、UCCX tomcat-trustストアにCUCM Tomcat証明書（自己署名）またはTomcatルートおよび中間証明書（CA署名用）をアップロードする必要があります

CAPF.pem

- 電話機が、電話 VPN 802.1x または電話プロキシを認証しません。

- 電話機の LSC 証明書を発行できません。

- 暗号化されたコンフィギュレーション ファイルが機能しません。

IPSec.pem

- ディザスタリカバリシステム(DRS)/ディザスタリカバリフレームワーク(DRF)が正しく機能しません。

- 他の CUCM クラスタにつながるゲートウェイ（GW）への IPSec トンネルが動作しません。

Trust Verification Service(TVS)

電話機が HTTPS サービスを認証できません。電話機がコンフィギュレーション ファイルを認証できません（これは CUCM のほぼすべてに影響を与える可能性があります）。

phone-vpn-trust

VPNのHTTPS URLを認証できないため、電話VPNは機能しません。

注：これが存在しない場合は心配しないでください。これは、特定のコンフィギュレーションに限ります。

phone-sast-trust

以前のCTL/eTokenはCTLを更新または変更できません。

注：これが存在しない場合は心配しないでください。これは、特定のコンフィギュレーションに限ります。

phone-trust および phone-ctl-trust

UnityまたはUnity Connectionを使用したビジュアルボイスメールが機能しません。

注：これが存在しない場合は心配しないでください。これは、特定のコンフィギュレーションに限ります。

、

LSC または MIC

電話機が登録されない。電話機は、電話VPN、電話プロキシ、または802.1xに対して認証されません。

注:MICはほとんどの電話機モデルにデフォルトで搭載されています。LSC は CAPF によって署名され、デフォルトで 5 年間有効です。CIPC（Cisco IP Communicator）および Jabber などのソフトウェア クライアントは、MIC がインストールされていません。

DRS バックアップの作成

このような大きな変更を行う前に、DRS のバックアップを作成することを推奨します。CUCM DRFバックアップファイルは、クラスタ内のすべての証明書をバックアップします。すべてのDRSバックアップ/復元手順については、『Cisco Disaster Recovery System Administration Guide for Cisco Unified Communications Manager』を参照してください。

注意:Cisco Bug ID CSCtn50405、「CUCM DRFバックアップでは証明書がバックアップされない」に注意してください。

混合モードの決定

CTL/Secure/Mixed-Modeクラスタを実行しているかどうかを判別するには、[Cisco Unified CM Administration] > [System] > [Enterprise Parameters] > [Cluster Security Mode](0 == Non-Secure; 1 == Mixed Mode) を選択します。

クラスタが混合モードの場合

CUCM クラスタを混合モードで実行している場合、すべての証明書を変更した後で、CTL ファイルを更新する変更があることを意味します。この方法の手順は、『シスコ セキュリティ ガイド』に記載しています。ただし、混合モード機能の最初の開始時点から少なくとも1つのeTokenがあり、eTokenパスワードが既知であることを確認してください。

注:CTLの更新は自動的には行われません（ITLファイルの場合と同様）。これは、CTL クライアントまたは CLI コマンドを使用して、管理者が手動で実行する必要があります。

CUCM 10.X 以降では、次の 2 つの方法でクラスタを混合モードにすることができます。

- CLI コマンド：この方法を使用すると、CTL ファイルがパブリッシャ サーバの CallManager.pem 証明書によって署名されます。
admin:show ctl

The checksum value of the CTL file:

0c05655de63fe2a042cf252d96c6d609(MD5)

8c92d1a569f7263cf4485812366e66e3b503a2f5(SHA1)

Length of CTL file: 4947

The CTL File was last modified on Fri Mar 06 19:45:13 CET 2015

[...]

CTL Record #:1

----

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

1       RECORDLENGTH    2       1156

2       DNSNAME         16      cucm-1051-a-pub

3       SUBJECTNAME     62      CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;

ST=Malopolska;C=PL

4       FUNCTION        2       System Administrator Security Token

5       ISSUERNAME      62      CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;

ST=Malopolska;C=PL

6       SERIALNUMBER    16      70:CA:F6:4E:09:07:51:B9:DF:22:F4:9F:75:4F:C5:BB

7       PUBLICKEY       140

8       SIGNATURE       128

9       CERTIFICATE     694     E9 D4 33 64 5B C8 8C ED 51 4D 8F E5 EA 5B 6D 21

A5 A3 8C 9C (SHA1 Hash HEX)

10      IPADDRESS       4

This etoken was used to sign the CTL file.

- CTLクライアント：この方式を使用すると、CTLファイルはハードウェアeTokenのいずれかで署名されます。
admin:show ctl

The checksum value of the CTL file:

256a661f4630cd86ef460db5aad4e91c(MD5)

3d56cc01476000686f007aac6c278ed9059fc124(SHA1)

Length of CTL file: 5728

The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015

[...]

CTL Record #:5

----

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

1       RECORDLENGTH    2       1186

2       DNSNAME         1

3       SUBJECTNAME     56      cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems

4       FUNCTION        2       System Administrator Security Token

5       ISSUERNAME      42      cn=Cisco Manufacturing CA;o=Cisco Systems

6       SERIALNUMBER    10      83:E9:08:00:00:00:55:45:AF:31

7       PUBLICKEY       140

9       CERTIFICATE     902     85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93

3E 8B 3A 4F (SHA1 Hash HEX)

10      IPADDRESS       4

This etoken was used to sign the CTL file.

注：トークンレスCTLを使用するCUCM混合モードで使用する方式の間で移動できます。

クラスタのセキュリティを保護する方法に応じて、適切な CTL 更新手順を実行する必要があります。CTL クライアントを再実行するか、または CLI から utils ctl update CTLfile コマンドを入力します。

クラスタのデフォルト セキュリティを確認する

ITLの問題を回避することは重要です。ITLの問題によって多くの機能に障害が発生したり、電話機が設定の変更への対応を拒否したりする可能性があるためです。 ITL の問題は、次の 2 つの方法で回避できます。

Prepare Cluster for Rollback to pre 8.0機能の使用

この機能はITLファイル内のITLエントリを消去するため、電話機はすべてのTFTPサーバを信頼します。 このパラメータがTrueに設定されている場合、電話機との間で送受信されるすべてのHTTPS要求は失敗します。エクステンションモビリティ、社内ディレクトリなどの電話機能が制限されるため、この機能を有効にすることは推奨されません。 ただし、基本的な電話の発信と受信は可能です。

注：このパラメータはITLのみをクリアし、CTLエントリはクリアしないため、この機能は混合モードクラスタでは動作しません。

注：この機能はITLの問題を防止するだけですが、修正はしません。問題がすでに電話機にある場合は、ITLは削除されず、ITLの削除は手動で行う必要があります。

注：このパラメータを変更すると、すべての電話機がリセットされます。

この機能を設定した後は、（新しいITLを提供するために）すべてのTFTPサーバを再起動し、すべての電話をリセットして、新しい空のITLを要求する必要があります。証明書の変更が完了し、必要なすべてのサービスが再起動されたら、この機能をFalseに戻し、TFTPサービスを再起動し、電話機をリセットします（これにより、電話機は有効なITLファイルを取得できます）。すべての機能は以前と同じように動作し続けます。

特定の順序で証明書を再生成する

この手順は、使用可能な信頼できる TFTP サーバから得た有効な/更新された ITL ファイルを、TFTP サーバに提供します。

1. プライマリ TFTP サーバの TFTP サービスを停止します。

2. プライマリTFTPサーバの証明書を必要に応じて変更します。

3. （セカンダリTFTPサーバから新しいITLファイルを取得するために）電話機をリセットします。これは、再生成された証明書に応じて自動的に行われます。

4. 電話機が復帰したら、プライマリ TFTP サーバの TFTP サービスを開始します。

5. セカンダリ TFTP サーバの証明書を変更します。

6. 電話機をリセットします（新しい ITL ファイルをプライマリ TFTP サーバから取得するため）。

注意：両方のTFTPサーバで証明書を同時に編集しないでください。これを行うと、電話機で信頼できる TFTP サーバがなくなり、ローカル管理者は手動ですべての電話機から ITL を削除する必要があります。

1種類の証明書を一度に再生成する

これは最も使用される手順であり、電話の信頼性が失われるのを防ぐためにお勧めします。このプロセスについては、

『Certificate Regeneration Process For Cisco Unified Communications Manager (CUCM) Guide』

CUCM での証明書の削除と再生成

再生成できるのは、サービス証明書（ – trustのラベルが付いていない証明書ストア）だけです。信頼ストア（ – trustのラベルが付いた証明書ストア）内の証明書は再生成できないため、削除する必要があります。

注意:Cisco Bug ID CSCut58407（CAPF/CallManager/TVS-trustが削除されるとデバイスが再起動しない）に注意してください。

すべての証明書を変更したら、変更を反映するため、それぞれのサービスを再起動する必要があります。これについては「証明書の再生成と削除の後」セクションで説明します。

注意:Cisco Bug ID CSCto86463 - Deleted certificates reappear, unable to remove certificates from CUCMに注意してください。これは、削除された証明書が削除後も引き続き表示され続けるという問題です。問題の回避策を実行します。

CLI での証明書の再生成

注意：証明書を再生成すると、クラスタ内のITLファイルの自動更新がトリガーされます。これにより、電話機がローカルITLの更新をトリガーできるように、クラスタ全体のソフトフォンのリセットがトリガーされます。これは、CAPFおよびCallManager証明書の再生成に重点を置いていますが、TomcatなどのCUCM内の他の証明書ストアで発生する可能性があります。

CAPFの再生成：再生成すると、CAPF証明書は自動的にCAPF-trustおよびCallManager-trustにアップロードされます。また、CAPFには常に一意のサブジェクト名(FQDN)ヘッダーがあるため、以前に使用されたCAPF証明書が保持され、認証に使用されます。

set cert regen CAPF

注:CAPF証明書が期限切れになると、CUCMが証明書を拒否するため、LSCを使用する電話機はCUCMに登録できません。ただし、新しい CAPF 証明書のある電話機に新しい LSC を生成することはできます。電話機をリブートすると、電話機は設定をダウンロードし、LSCを更新するためにCAPFに接続します。LSCが更新されると、電話機は可能な限り登録されます。これは、新しい CAPF 証明書が ITL ファイルにあり、電話機が自分の署名した証明書（callmanager.pem）をダウンロードして信頼している場合に限り、機能します。

CallManagerの再生成：再生成すると、CallManagerは自動的にCallManager-trustにアップロードします。

set cert regen CallManager

IPsecの再生成：再生成すると、IPsec証明書は自動的にipsec-trustにアップロードされます。

set cert regen ipsec

Tomcatの再生成：Tomcat証明書が再生成されると、自動的にtomcat-trustにアップロードされます。

set cert regen tomcat

テレビの再生：

set cert regen TVS

この処理による影響

CLI で証明書を再生成すると、この変更の確認が求められます。yesと入力し、Enterを選択します。

admin:set cert regen CAPF

WARNING: This operation will overwrite any CA signed certificate previously imported

for CAPF

Proceed with regeneration (yes|no)? yes

Successfully Regenerated Certificate for CAPF.

You must restart services related to CAPF for the regenerated certificates to become active.

CLI での証明書の削除

CAPF-trust 証明書の削除

set cert delete CAPF <name of certificate>.pem

CallManager-trust 証明書の削除

set cert delete CallManager <name of certificate>.pem

ipsec-trust 証明書の削除

set cert delete ipsec <name of certificate>.pem

Tomcat-trust 証明書の削除

set cert delete tomcat <name of certificate>.pem

TVS-trust 証明書の削除

set cert delete TVS <name of certificate>.pem

Web GUI での証明書の再生成

CAPFの再生成：

CAPF 証明書が再生成されると、自動的に CAPF-trust と CallManager-trust にアップロードされます。また、CAPF 証明書には常に固有のサブジェクト名ヘッダーがありますので、以前に使用した CAPF 証明書がそのまま認証に使用されます。

OS Admin > Security > Certificate Management > Find > Click CAPF certificate > Regenerate

CallManagerの再生成：

CallManager証明書が再生成されると、自動的にCallManager-trustにアップロードされます。

OS Admin > Security > Certificate Management > Find > Click CallManager certificate > Regenerate

IPsecの再生成：

IPsec 証明書が再生成されると、自動的に ipsec-trust にアップロードされます。

OS Admin > Security > Certificate Management > Find > Click ipsec certificate > Regenerate

Tomcatの再生成：

Tomcat 証明書が再生成されると、自動的に tomcat-trust にアップロードされます。

OS Admin > Security > Certificate Management > Find > Click tomcat certificate > Regenerate

テレビの再生：

OS Admin > Security > Certificate Management > Find > Click TVS certificate > Regenerate

Web GUI での証明書の削除

OS Admin > Security > Certificate Management > Find > Click X certificate within the

'-trust' store > Remove/Delete

証明書の再生成と削除の後

証明書ストアから証明書を削除または再生成したら、変更を反映するため、それぞれのサービスを再起動する必要があります。

ストア

サービスの再起動

「Catalyst

Tomcat

Tomcat

CLI:utils service restart Cisco Tomcat

必要に応じて、CCX環境から必要な手順を実行します

https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/118855-configure-uccx-00.html#anc12

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_12_5/release/guide/uccx_b_uccx-solution-release-notes-125/uccx_b_uccx-solution-release-notes-125_chapter_01.html#reference_2D9122E01C43B6E0AA06AB2A3248B797

CallManager

CallManager、TFTP、CTIManager

Web Gui:[Cisco Unified Serviceability] > [Tools] > [Control Center - Feature Services] > （サーバの選択） に移動します。[Cisco CallManager] で、[Restart] をクリックします。

Web Gui:[Cisco Unified Serviceability] > [Tools] > [Control Center - Feature Services] > （サーバの選択） に移動します。[Cisco Tftp] で、[Restart] をクリックします。

Web Gui:[Cisco Unified Serviceability] > [Tools] > [Control Center - Feature Services] > （サーバの選択） に移動します。[Cisco CTIManager] で、[Restart] をクリックします。

CAPF

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

Web Gui:[Cisco Unified Serviceability] > [Tools] > [Control Center - Feature Services] > （サーバの選択）に移動します。 [Cisco Certificate Authority Proxy Function] で、[Restart] をクリックします。

TVS

信頼検証サービス（各サーバ上）

Web Gui:[Cisco Unified Serviceability] > [Tools] > [Control Center - Network Services] > (Select Server) に移動します。[Cisco Trust Verification Service] で、[Restart] をクリックします。

IPSec

Cisco DRFローカル（全ノード）、Cisco DRFプライマリ（パブリッシャ）

CLI:utils service restart Cisco DRF Local

CLI:utils service restart Cisco DRF Primary

使用されなくなった証明書を識別する方法 – trust証明書

信頼ストアで期限切れの証明書を削除する前に、使用されている証明書と使用されていない証明書を特定することが重要です。削除する必要がある証明書を選択するには、次の点に注意してください。

- -trust証明書のほとんどは、使用されたサービス証明書のコピーです。最初にすべてのノードで期限切れのすべてのサービス証明書を再生成し、CUCMが – trustコピーを自動的に更新することを推奨します。

- tomcat-trust VeriSign_Class_3_Secure_Server_CA_-_G3は使用されなくなりました。Smart Call Home機能を使用する場合は、次のガイドに従って新しい証明書をアップロードします。https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/smart-call-home/215210-troubleshooting-certficate-exipry-alert.html

- Manufacturing -trust証明書は、インストール時に任意のCUCMに事前にロードされ、CUCMがデフォルトで任意のCisco IP Phoneを信頼するために使用されます。次の証明書を削除することは推奨されません。

CAP-RTP-001

CAP-RTP-002

Cisco Root CA 2048

CiscoルートCA M2

ACT2_SUDI_CA

Cisco_Manufacturing_CA

Cisco_Manufacturing_CA_SHA2

- ドメインまたはホスト名が変更された場合、古いドメインまたはホスト名を持つ古い証明書は「信頼」としてリストされます。これらのホスト名とドメインが使用されなくなった場合、それらの証明書は使用されず、削除できます。

- 証明書の共通名が（CUCMクラスタではなく）別のサーバからのものである場合は、他のサーバからの証明書が有効であることを確認します。CUCMは証明書を再生成できないため、これは他のサーバで実行する必要があり、証明書を – trustとしてCUCMにインポートします。

電話機の LSC のインストールと更新

CAPF 証明書が再生成されたら、クラスタ内のすべての電話機の LSC 証明書を、新しい CAPF 証明書によって署名された LSC で更新する必要があります。

1. [CUCM Serviceability] > [Service Activation] に移動します。パブリッシャ サーバで Cisco CTL Provider および Cisco Certificate Authority Proxy Function をアクティブにします。

2. [CUCM CCMAdmin] で、[Device] > [Phone] に移動します。LSC をプロビジョニングする IP Phone を選択します。

3. [Device configuration]ページの[Certificate Operation] で、[Install / Upgrade] > [By Null String] に移動します。

4. CCMAdmin の電話機設定を保存し、[Apply Config] を選択します。

LSC のインストールに問題がある場合、電話機で次の操作を実行してください。

電話機がリセットされたら、物理的な電話機の下で[Settings] > (6) [Security Configuration] > (4) [LSC] > [**#] に移動します（この操作によりGUIがロック解除され、次の手順に進むことができます）。> [Update]（前の手順を実行するまで更新は表示されません）。ここで、[Submit] をクリックします。

無線電話（7921/25）でない限り、電話機に証明書を割り当てないでください。無線電話は自身を認証するためにサード パーティ認証局（CA）を使用します。

他の証明書の更新プロセス

Certificate Regeneration Process For Cisco Unified Communications Manager(CUCM)：このガイドでは、証明書をタイプ別に再生成するプロセスについて説明します。これは、最も使用されている推奨プロセスです。

CUCM 12.x以降でのITLRecoveryの証明書再生成プロセス：このガイドでは、12.x CUCMクラスタでITLRecovery証明書を再生成するプロセスについて説明します。

CUCM CA署名付き証明書の再生成：このガイドでは、CUCMでのCA署名付き証明書のプロセスと、証明書のアップロード時に表示される最も一般的なエラーについて説明します。

CA署名付きマルチサーバサブジェクト代替名を使用したユニファイドコミュニケーションクラスタのセットアップの設定例：このガイドでは、Tomcatマルチsan証明書の再生成の例を示します。

Regenerate Unified Communications Manager IM & Presence Service Self-Signed Certificates：このガイドでは、IM&Pノードを再起動するための再生成プロセスとサービスについて説明します。

UCCXソリューション証明書管理ガイド：このガイドでは、UCCXでの証明書の統合要件と、証明書を再生成するプロセスについて説明します。

Expressway CおよびEの再生成プロセスは、次のビデオで説明されています。

Expresswayへのサーバ証明書のインストール

MRA/クラスター化されたExpresswayのCSRを生成しています

Expressway-CとExpressway-Eの間の証明書信頼を設定する方法

結論

この手順で問題が発生したか、またはサポートが必要な場合、Cisco Technical Assistance Center（TAC）にお問い合わせください。この場合は、TACが他の方法でサービスを復元できない場合にサービスを復元するための最後の手段として使用されるため、DRFバックアップを使用可能な状態に保ちます。