The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the procedure to regenerate certificates in Cisco Unified Communications Manager (CUCM) release 8.X and later.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
This document describes the step-by-step procedure on how to regenerate certificates in Cisco Unified Communications Manager (CUCM) release 8.X and newer. However, this does not reflect the changes post 12.0 to ITL recovery.
Tip: The regeneration process of some certificates can impact endpoint. Consider an action plan after regular business hours due to the requirement to restart services and reboot phones. Verify phone registration via RTMT is highly recommended.
Warning: Endpoints with current ITL mismatch can have registration issues after this process. The deletion of the ITL on the endpoint is a typical best practice solution after the regeneration process is completed and all other phones have registered.
It is critical for successful system functionality to have all certificates updated across the CUCM cluster. If certificates are expired or invalid they can significantly affect normal functionality of the system. The impact can differ dependent upon your system setup. A list of services for the specific certificates that are invalid or expired is shown here:
Trust Verification Service (TVS) is the main component of Security by Default. TVS enables Cisco Unified IP Phones to authenticate application servers, such as EM services, directory, and MIDlet, when HTTPS is established.
TVS provides these features:
Note: All the endpoints need to be powered on and registered before the certificates regeneration. Otherwise, the not connected phones require the removal of the ITL.
Identify if third party certificates are in use:
5. These steps are needed from the CCX enviroment if applicable:
Additional References:
Note: CUCM/Instant Messaging and Presence (IM&P) before version10.X the DRF Master Agent runs on both CUCM Publisher and IM&P Publisher. DRF Local service runs on the subscribers respectively. Versions 10.X and higher, DRF Master Agent runs on the CUCM Publisher only and DRF Local service on CUCM Subscribers and IM&P Publisher and Subscribers.
Note: The Disaster Recovery System uses an Secure Socket Layer (SSL) based communication between the Master Agent and the Local Agent for authentication and encryption of data between the CUCM cluster nodes. DRS makes use of the IPSec certificates for its Public/Private Key encryption. Be aware that if you delete the IPSEC truststore (hostname.pem) file from the Certificate Management page, then DRS do not work as expected. If you delete the IPSEC-trust file manually, then you must ensure that you upload the IPSEC certificate to the IPSEC trust-store. For more details, refer to the certificate management help page in the Cisco Unified Communications Manager Security Guides.
The IPSEC.pem certificate in the publisher must be valid and must be present in all subscribers as IPSEC truststores. The subscribers IPSEC.pem certificate not be present in the publisher as IPSEC truststore in a standard deployment. In order to verify the validity compare the serial numbers in the IPSEC.pem certificate from the PUB with the IPSEC-trust in the SUBs. They must match.
Warning: Ensure you have identified if your Cluster is in Mixed-Mode before you proceed. Refer to section Identify if your cluster is in Mix-Mode or Non-secure Mode.
The phones now reset. Monitor their actions via RTMT tool to ensure the reset was successful and that devices register back to CUCM. Wait for the phone registration to complete before you proceed to next certificate. This process of phones registration can take some time. Be advised, devices that had bad ITLs prior to regeneration process do not register back to the cluster until it is remove.
Warning: Ensure you have identified if your Cluster is in Mixed-Mode before you proceed. Refer to section Identify if your cluster is in Mix-Mode or Non-secure Mode.
Warning: Do not regenerate CallManager.PEM and TVS.PEM certificates at the same time. This cause an unrecoverable mismatch to the installed ITL on endpoints which require the removal the ITL from ALL endpoints in the cluster. Finish the entire process for CallManager.PEM and once the phones are registered back, start the process for the TVS.PEM.
The phones now reset. Monitor their actions via RTMT tool to ensure the reset was successful and that devices register back to CUCM. Wait for the phone registration to complete before you proceed to next certificate. This process of phones registration can take some time. Be advised, devices that had bad ITLs prior to regeneration process do not register back to the cluster until ITL is remove.
Warning: Do not regenerate CallManager.PEM and TVS.PEM certificates at the same time. This cause an unrecoverable mismatch to the installed ITL on endpoints which require the removal the ITL from ALL endpoints in the cluster.
Note: TVS authenticates certificates on behalf of Call Manager. Regenerate this certificate last.
Navigate to each server in your cluster (in separate tabs of your web browser) begin with the publisher, then each subscriber. Navigate to Cisco Unified OS Administration > Security > Certificate Management > Find:
The phones now reset. Monitor their actions via RTMT tool to ensure the reset was successful and that devices register back to CUCM. Wait for the phone registration to complete before you proceed to next certificate. This process of phones registration can take some time. Be advised, devices that had bad ITLs prior to regeneration process do not register back to the cluster until ITL is remove.
Note: The ITLRecovery Certificate is used when devices lose their trusted status. The certificate appears in both the ITL and CTL (when CTL provider is active).
If devices lose their trust status, you can use the command utils itl reset localkey for non-secure clusters and the command utils ctl reset localkey for mix-mode clusters. Read the security guide for your Call Manager version to become familiar with how the ITLRecovery certificate is used and the process required to recover trusted status.
If the cluster has been upgraded to a version that supports a key length of 2048 and the clusters server certificates have been regenerated to 2048 and the ITLRecovery has not been regenerated and is currently 1024 key length, the ITL recovery command fails and the ITLRecovery method is not used.
Note: Identify the trust certificates that need to be deleted, no longer required, or have expired. Do not delete the five base certificates which include the CallManager.pem, tomcat.pem, ipsec.pem, CAPF.pem and TVS.pem. Trust certificates can be deleted when appropriate. The next service that restarts is designed to clear information of legacy certificates within those services.
Verification procedure are not available for this configuration.
Troubleshoot procedures are not available for this configuration.