# Unified CM certificate renewal Canonical: https://warmtransfer.net/knowledge/cucm-certificate-renewal Last verified: 2026-09-25 Renewing certificates in Cisco Unified Communications Manager involves updating core identity certificates while preserving endpoint and inter-service trust relationships[^18][^17]. Because endpoint trust lists rely on specific certificate roles, distinct sequencing and service restart procedures apply across certificate types[^15][^47]. ## Certificate management and renewal rules When cleaning up expired certificates, only expired trust certificates are deleted, 1 node at a time[^17]. The base identity certificates (CallManager, Tomcat, IPsec, CAPF, TVS) are never deleted[^17]. Regenerating a certificate overwrites the existing certificate, including any third-party CA-signed certificate that was uploaded[^42]. The Release 15 regeneration procedure ends with a system backup so the backup includes the regenerated certificates[^4]. For CA-signed certificate renewals, only 1 CSR can exist per server and certificate type; generating a new CSR replaces the previous one[^36]. When uploading a CA-signed certificate chain, the root CA certificate is uploaded to the matching -trust store first, then any intermediate certificate to -trust, followed by the CA-signed identity certificate[^7]. Multi-server SAN CA-signed certificates apply to cluster nodes only when uploaded to the publisher, and they cannot be uploaded through the CLI; administrators must always use the OS Admin GUI[^33][^31]. From Release 14, Tomcat, Tomcat-ECDSA, CallManager, and CallManager-ECDSA certificates can be multi-server SAN self-signed certificates, whereas multi-server SAN was previously supported only for CA-signed certificates[^32]. The TVS certificate can also be a multi-server SAN certificate, self-signed or CA-signed, allowing 1 TVS certificate to cover the whole cluster[^55]. WarmTransfer's reading of the sources is that on Release 14 and later, using multi-server SAN certificates for Tomcat, CallManager, and TVS turns a per-node renewal into roughly 1 renewal per certificate type per cluster[^30]. In Unified CM 10.0(1), a hold timer was added that prevents regenerating another certificate on the same node within 5 minutes of the previous regeneration[^40]. In the Release 15 security guide, the default validity of self-signed certificates is 5 years[^44]. When generating a self-signed certificate in Release 15, administrators can select a validity of 1, 2, 5, 10, or 20 years[^58]. Release 15SU3 added 1-year and 2-year validity options for newly generated self-signed certificates alongside the existing options, changed the CA flag on all self-signed certificates except CAPF from CA:TRUE to CA:FALSE, and introduced full-chain certificate validation as a configurable option over default leaf-only validation on publisher and subscriber nodes[^1][^2][^3]. Certificate expiry monitoring runs once every 24 hours by default and shifts to every 1 hour once a certificate has expired or will expire within 1 day[^12]. Expiry monitoring can be configured with a notification start time and frequency, can send email notifications to a semicolon-separated list of addresses, and can optionally include LSCs[^11]. ## ITL trust and endpoint impact Cisco's certificate regeneration technote specifies that all endpoints should be powered on and registered before certificates are regenerated[^18]. Devices that already had a bad ITL before regeneration do not register back to the cluster until their ITL is removed[^5]. See also [Cisco IP phone registration and TFTP and ITL and CTL](https://warmtransfer.net/knowledge/cisco-phone-registration). The ITL file contains the ITLRecovery certificate, the CallManager certificate of the TFTP server, every TVS certificate in the cluster, and the CAPF certificate, but it does not list Tomcat[^21]. The Trust Verification Service runs on Unified CM and authenticates certificates on behalf of the IP phone so phone resources do not limit how many certificates can be trusted[^56]. Technotes warn against regenerating CallManager and TVS certificates at the same time in versions 8.x through 11.5, and the CA-signed renewal technote for 14.x and 15.x warns that renewing both at the same time causes an unrecoverable mismatch with endpoint ITL files[^14][^15]. Cisco technotes explain that phones use TVS as a secondary way to authenticate files whichever certificate is regenerated first, making single certificate updates recoverable[^57]. WarmTransfer's reading of the sources is that because an endpoint falls back to TVS when encountering an unfamiliar ITL signer, regenerating TVS in the same window leaves the phone with no trusted path[^59]. Technotes instruct administrators to reboot phones after each phone-trust certificate regeneration and wait until RTMT shows registration is complete before regenerating the next certificate[^38]. Phones reset automatically to download the updated ITL file after CallManager, CAPF, or TVS certificates are regenerated or renewed[^39]. Release 14 added the enterprise parameter Phone Interaction on Certificate Update under Security Parameters, defaulting to automatic reset, which controls whether phones reset manually or automatically after TVS, CAPF, or TFTP certificate updates[^37]. WarmTransfer's reading of the sources is that on Release 14 and later under default settings, CallManager, CAPF, or TVS certificate renewals reset cluster phones and belong in a maintenance window unless this parameter is changed to manual[^6]. Cluster security mode is checked via the Cluster Security Mode enterprise parameter under Security Parameters, where 1 indicates mixed mode and 0 indicates non-secure[^13]. In mixed-mode clusters, regenerating CAPF, CallManager, or ITLRecovery requires running `utils ctl update CTLFile` on the publisher[^29]. ## ITLRecovery and recovery procedures From Release 12.0 onward, the ITL file is signed by the ITLRecovery certificate[^25]. The ITL Recovery key was introduced in Unified CM 10.0(1) and is designed not to change when hostname, DNS, or similar changes occur[^22]. The ITLRecovery certificate signs both the ITL and CTL files, is used to sign SAML SSO assertions, and its service restarts automatically upon regeneration[^28]. Cisco advises against regenerating ITLRecovery frequently because it maintains long validity with phones and also contains the CallManager certificate[^27]. ITLRecovery certificate validity was extended from 5 years to 20 years, with selectable values of 5, 10, 15, or 20 years[^26]. When phones no longer trust the ITL signer, `utils itl reset localkey` re-signs the ITL with the ITLRecovery key, allowing phones to download the ITL and register following a TFTP restart and device reset[^23]. The `utils itl reset localkey` command uses the ITLRecovery.p12 file stored on the publisher, while `utils itl reset remotekey` retrieves the key from an external SFTP server[^24]. ## Service-specific renewal procedures The Release 15 security guide states that no specific service restart is needed when TVS, CAPF, or ITLRecovery certificates are regenerated[^35]. From Release 14, CAPF certificates are generated only on the publisher and are present as CallManager-trust certificates on both publisher and subscribers[^9]. The CAPF service restarts automatically when its certificate is regenerated or uploaded to CAPF-trust[^8]. After regenerating the Tomcat certificate, administrators must restart Tomcat across every node with `utils service restart Cisco Tomcat`, publisher first and then subscribers[^47]. When SSO or OAuth is configured, Cisco SSOSP Tomcat must also be restarted[^53]. From Release 14, the CallManager service does not require a restart when OAuth is enabled and Tomcat is regenerated[^46]. According to the Release 15 admin guide, regenerating Tomcat or Tomcat-ECDSA requires restarting Cisco Tomcat, Intercluster Lookup Service, Location Bandwidth Manager, DRS Local and Master, Extension Mobility, and AXL Tomcat[^48]. When Unified CM integrates with Unified CCX, regenerated Unified CM Tomcat certificates must be uploaded to the CCX tomcat-trust store[^10]. From Release 14.0.1.13900-155, a multi-SAN Tomcat certificate (self-signed or CA-signed) can be reused for CallManager via Security > Certificate Management > Reuse Certificate[^49]. SSO must be disabled before uploading the Tomcat certificate for CallManager reuse and re-enabled afterward[^52]. Enabling Tomcat reuse requires restarting Cisco HAProxy on all nodes, running `utils ctl update CTLFile` in mixed mode, and resetting all phones[^50]. From 14SU4, the CallManager certificate is hidden in the GUI when Tomcat reuse is active, whereas it was visible in SU2 and SU3[^51]. DRS uses the IPsec certificate for public and private key encryption[^20]. After regenerating IPsec, administrators restart Cisco DRF Master on the publisher followed by Cisco DRF Local on every node[^20]. See also [Unified CM backup and upgrade](https://warmtransfer.net/knowledge/cucm-backup-upgrade). ## Applicability Applies to: Cisco Unified Communications Manager. Deployments: on-premises. Sources checked 2026-09-25. Specific applicability facts stated in the evidence include coverage of Unified CM versions 8.x through 11.5, 10.0(1), 12.0, 14, 14.x, 14SU2, 14SU3, 14SU4, 14.0.1.13900-155, 15, 15.x, 15SU3, and 15SU3a[^14][^22][^25][^9][^51][^49][^2][^15][^58]. ## What remains uncertain Whether CA/Browser Forum reductions in public TLS certificate lifetime affect CA-signed Tomcat renewal cadence is not covered by the sources below. Whether CallManager, CTIManager, TVS, and TFTP restarts are still required after CallManager regeneration on 14 and 15 is not covered by the sources below. Expressway-C, Jabber, and CUBE trust-store impact after Tomcat or CallManager renewal is not covered by the sources below. Whether multi-server SAN certificates cover IM and Presence and Unity Connection nodes is not covered by the sources below. Whether phones reset when ITLRecovery is regenerated on 14 and 15 is not covered by the sources below. The scope of the regenerate-TVS-last instruction relative to ITLRecovery is not covered by the sources below. SAML SSO re-enablement and IdP metadata impact after Tomcat or ITLRecovery renewal is not covered by the sources below. The scope of the TLS certificate lifetime in release 14 enhanced security compliance is not covered by the sources below. ## Sources [^1]: Release 15SU3 added one-year and two-year validity options for newly generated self-signed certificates, alongside the existing options. Source: [Release Notes for Cisco Unified Communications Manager Release 15SU3a and the IM and Presence Service Release 15SU3](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/15/SU3/cucm_b_release-notes-for-cucm-imp-15su3.html), New and changed features, certificate management / self-signed certificate validity period. Checked 2026-09-25. [^2]: Release 15SU3 changed the CA flag on all self-signed certificates except CAPF from CA:TRUE to CA:FALSE. Source: [Release Notes for Cisco Unified Communications Manager Release 15SU3a and the IM and Presence Service Release 15SU3](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/15/SU3/cucm_b_release-notes-for-cucm-imp-15su3.html), New and changed features, certificate management / CA flag. Checked 2026-09-25. [^3]: Release 15SU3 lets administrators enable full-chain certificate validation instead of the default leaf-only validation, on both publisher and subscriber nodes. Source: [Release Notes for Cisco Unified Communications Manager Release 15SU3a and the IM and Presence Service Release 15SU3](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/15/SU3/cucm_b_release-notes-for-cucm-imp-15su3.html), New and changed features, certificate management / full-chain validation. Checked 2026-09-25. [^4]: The Release 15 regeneration procedure ends with a system backup so the backup includes the regenerated certificates. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Manage Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_01111.html), Manage Certificates chapter, Regenerate a Certificate procedure, final step. Checked 2026-09-25. [^5]: Devices that already had a bad ITL before regeneration do not register back to the cluster until their ITL is removed. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), Background / prerequisites notes before the Tomcat certificate section. Checked 2026-09-25. [^6]: On Release 14 and later with default settings, renewing the CallManager, CAPF or TVS certificate will reset phones across the cluster, so these renewals belong in a maintenance window unless Phone Interaction on Certificate Update is set to manual (inferred). Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_certificates.html), Certificates chapter, certificate regeneration notes (phone auto-reset) combined with Release 14 parameter default. Checked 2026-09-25. [^7]: For a CA-signed renewal, the root CA certificate is uploaded to the matching -trust store first, then any intermediate to -trust, then the CA-signed identity certificate. Source: [Create New Certificates from Signed CA Certificates](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/217138-regeneration-of-cucm-ca-signed-certifica.html), Upload process section. Checked 2026-09-25. [^8]: From Release 14, the CAPF service restarts automatically when the CAPF certificate is regenerated or a new certificate is uploaded to CAPF-trust. Source: [Release Notes for Cisco Unified Communications Manager and the IM and Presence Service, Release 14 - New and Changed Features](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/14_0_1/cucm_b_release-notes-for-cucm-imp-14_0_1/cucm_m_new-and-changed-features.html), Certificate Regeneration without Service Restarts feature entry. Checked 2026-09-25. [^9]: From Release 14, the CAPF certificate is generated only on the publisher. It is present as a CallManager-trust certificate on both the publisher and the subscribers. Source: [Security Guide for Cisco Unified Communications Manager Release 14 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/14SU2/cucm_b_security-guide-14su2/cucm_m_certificates.html), Certificates chapter, multi-server SAN / CAPF generation paragraph. Checked 2026-09-25. [^10]: When Unified CM integrates with Unified CCX, the regenerated Unified CM Tomcat certificates must be uploaded to the CCX tomcat-trust store. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), Tomcat certificate section, CCX note. Checked 2026-09-25. [^11]: Certificate expiry monitoring can be set with a notification start time and frequency, can send email notifications to a semicolon-separated list of addresses, and can optionally include LSCs. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Manage Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_01111.html), Manage Certificates chapter, certificate monitoring / expiry notification configuration. Checked 2026-09-25. [^12]: The certificate monitor service runs once every 24 hours by default. It runs every hour once a certificate has expired or will expire within one day. Source: [Security Guide for Cisco Unified Communications Manager Release 14 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/14SU2/cucm_b_security-guide-14su2/cucm_m_certificates.html), Certificates chapter, certificate monitoring / expiry section. Checked 2026-09-25. [^13]: Whether the cluster is mixed mode is read from the Cluster Security Mode enterprise parameter under Security Parameters, where 1 means mixed mode and 0 means non-secure. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), Section describing how to check cluster security mode before CAPF and CallManager regeneration. Checked 2026-09-25. [^14]: The TAC technote warns against regenerating the CallManager and TVS certificates at the same time in versions 8.x through 11.5. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), CallManager and TVS certificate sections, warning notes. Checked 2026-09-25. [^15]: The CA-signed renewal technote for 14.x and 15.x warns that regenerating the CallManager and TVS certificates at the same time causes an unrecoverable mismatch with the ITL installed on endpoints. Source: [Create New Certificates from Signed CA Certificates](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/217138-regeneration-of-cucm-ca-signed-certifica.html), Warning note in the CallManager / TVS certificate steps. Checked 2026-09-25. [^16]: The CTL file has entries for the CallManager, TFTP, CAPF, ITLRecovery and SAST roles but not for TVS. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), ITL and CTL background section. Checked 2026-09-25. [^17]: When cleaning up expired certificates, only expired trust certificates are deleted, one node at a time. The base identity certificates (CallManager, Tomcat, IPsec, CAPF, TVS) are never deleted. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), Delete expired trust certificates section. Checked 2026-09-25. [^18]: Cisco's certificate regeneration technote says all endpoints should be powered on and registered before certificates are regenerated. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), Background / prerequisites notes before the Tomcat certificate section. Checked 2026-09-25. [^19]: The Release 15 admin guide's restart table lists only the HAProxy service after CallManager or CallManager-ECDSA regeneration, plus a CTL file update if the cluster is secure (disputed). Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Manage Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_01111.html), Manage Certificates chapter, services-to-restart table after certificate regeneration. Checked 2026-09-25. [^20]: DRS uses the IPsec certificate for its public and private key encryption, so after regenerating IPsec the technote restarts Cisco DRF Master on the publisher and then Cisco DRF Local on every node. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), IPSec certificate section. Checked 2026-09-25. [^21]: The ITL file contains the ITLRecovery certificate, the CallManager certificate of the TFTP server, every TVS certificate in the cluster and the CAPF certificate. It does not list Tomcat. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Default Security](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_default-security-setup_su2_reorg.html), Default Security chapter, Initial Trust List section. Checked 2026-09-25. [^22]: The ITL Recovery key was introduced in Unified CM 10.0(1). It is designed not to change when hostname, DNS or similar changes occur. Source: [Unified Communications Manager ITL Enhancements in Version 10.0(1)](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/117598-technote-itl-00.html), ITL Recovery key section. Checked 2026-09-25. [^23]: When phones no longer trust the ITL signer, utils itl reset localkey re-signs the ITL with the ITLRecovery key. After a TFTP restart and a device reset, phones download that ITL and register correctly. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Default Security](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_default-security-setup_su2_reorg.html), Default Security chapter, bulk reset of the ITL file. Checked 2026-09-25. [^24]: utils itl reset localkey uses the ITLRecovery.p12 file stored on the publisher. utils itl reset remotekey retrieves the key from an external SFTP server. Source: [Unified Communications Manager ITL Enhancements in Version 10.0(1)](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/117598-technote-itl-00.html), Bulk reset of the ITL file / utils itl reset section. Checked 2026-09-25. [^25]: From Release 12.0 onward, the ITL file is signed by the ITLRecovery certificate. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), ITL and CTL background section. Checked 2026-09-25. [^26]: The ITLRecovery certificate validity was extended from 5 years to 20 years so that it stays the same for longer. Selectable values are 5, 10, 15 or 20 years. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Default Security](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_default-security-setup_su2_reorg.html), Default Security chapter, ITLRecovery certificate section. Checked 2026-09-25. [^27]: Cisco advises against regenerating the ITLRecovery certificate frequently, because it has a long validity with phones and also contains the CallManager certificate. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_certificates.html), Certificates chapter, ITLRecovery regeneration note. Checked 2026-09-25. [^28]: The ITLRecovery certificate signs both the ITL and CTL files and is also used to sign SAML SSO assertions. Its service restarts automatically when it is regenerated. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Manage Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_01111.html), Manage Certificates chapter, certificate types description (ITLRecovery). Checked 2026-09-25. [^29]: In a mixed-mode cluster, after the CAPF, CallManager or ITLRecovery certificate is regenerated the CTL file must be updated with utils ctl update CTLFile on the publisher. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), CAPF, CallManager and ITLRecovery certificate sections. Checked 2026-09-25. [^30]: On Release 14 and later, using multi-server SAN certificates for Tomcat, CallManager and TVS turns a per-node renewal into roughly one renewal per certificate type per cluster (inferred). Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_certificates.html), Certificates chapter, multi-server SAN example (10-node cluster reduced to cluster-based certificates). Checked 2026-09-25. [^31]: Multi-server SAN certificates cannot be uploaded through the CLI and must always be uploaded through the OS Admin GUI. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Manage Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_01111.html), Manage Certificates chapter, multi-server SAN upload note. Checked 2026-09-25. [^32]: From Release 14, the Tomcat, Tomcat-ECDSA, CallManager and CallManager-ECDSA certificates can be multi-server SAN self-signed certificates. Before that, multi-server SAN was supported only for CA-signed certificates. Source: [Security Guide for Cisco Unified Communications Manager Release 14 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/14SU2/cucm_b_security-guide-14su2/cucm_m_certificates.html), Certificates chapter, multi-server SAN self-signed certificates paragraph. Checked 2026-09-25. [^33]: A multi-server SAN CA-signed certificate applies to the cluster nodes only when it is uploaded to the publisher. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_certificates.html), Certificates chapter, multi-server (SAN) CSR / Distribution field note. Checked 2026-09-25. [^34]: The Release 14 notes say a manual restart of the CallManager and CTIManager services is no longer required when the CallManager certificate is regenerated (disputed). Source: [Release Notes for Cisco Unified Communications Manager and the IM and Presence Service, Release 14 - New and Changed Features](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/14_0_1/cucm_b_release-notes-for-cucm-imp-14_0_1/cucm_m_new-and-changed-features.html), Certificate Regeneration without Service Restarts (certificate management feature entry). Checked 2026-09-25. [^35]: The Release 15 security guide says no specific service restart is needed when the TVS, CAPF or ITLRecovery certificate is regenerated. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_certificates.html), Certificates chapter, services to restart after regeneration. Checked 2026-09-25. [^36]: Only one CSR can exist per server and certificate type. Generating a new CSR replaces the previous one. Source: [Create New Certificates from Signed CA Certificates](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/217138-regeneration-of-cucm-ca-signed-certifica.html), CSR generation section. Checked 2026-09-25. [^37]: Release 14 added the enterprise parameter Phone Interaction on Certificate Update, under Security Parameters, which resets phones manually or automatically when a TVS, CAPF or TFTP certificate is updated. Its default is automatic reset. Source: [Release Notes for Cisco Unified Communications Manager and the IM and Presence Service, Release 14 - New and Changed Features](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/14_0_1/cucm_b_release-notes-for-cucm-imp-14_0_1/cucm_m_new-and-changed-features.html), Certificate Regeneration without Service Restarts feature entry. Checked 2026-09-25. [^38]: The technote says to reboot the phones after each phone-trust certificate is regenerated and to wait until RTMT shows registration is complete before regenerating the next certificate. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), CAPF, CallManager and TVS certificate sections, final steps. Checked 2026-09-25. [^39]: Phones reset automatically to download the updated ITL file after the CallManager, CAPF or TVS certificate is regenerated or renewed. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_certificates.html), Certificates chapter, certificate regeneration notes. Checked 2026-09-25. [^40]: In 10.0(1), Unified CM added a hold timer that prevents regenerating another certificate on the same node within five minutes of the previous regeneration. Source: [Unified Communications Manager ITL Enhancements in Version 10.0(1)](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/117598-technote-itl-00.html), Certificate regeneration safeguards / hold timer paragraph. Checked 2026-09-25. [^41]: According to the admin guide summary, the Release 15 regenerate dialog offers a 3072-bit or 4096-bit key length for self-signed certificates. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Manage Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_01111.html), Manage Certificates chapter, Regenerate a Certificate procedure, key length step. Checked 2026-09-25. [^42]: Regenerating a certificate overwrites the existing certificate, including any third-party CA-signed certificate that was uploaded. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Manage Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_01111.html), Manage Certificates chapter, Regenerate a Certificate caution. Checked 2026-09-25. [^43]: Under an Enhanced Security Compliances heading, the Release 14 notes give TLS server certificates a three-year lifetime, signing certificates a five-year default and ITLRecovery certificates twenty years (disputed). Source: [Release Notes for Cisco Unified Communications Manager and the IM and Presence Service, Release 14 - New and Changed Features](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/14_0_1/cucm_b_release-notes-for-cucm-imp-14_0_1/cucm_m_new-and-changed-features.html), Enhanced Security Compliances / Certificate Validity feature entry. Checked 2026-09-25. [^44]: In the Release 15 security guide, the default validity of self-signed certificates is five years. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_certificates.html), Certificates chapter, self-signed certificate validity paragraph. Checked 2026-09-25. [^45]: The TAC technote (rev 7.0, scoped to 15.0 and later) tells administrators to restart Cisco CallManager, CTIManager, Trust Verification Service and TFTP, publisher first, after regenerating the CallManager certificate, and then to reboot the phones (disputed). Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), CallManager certificate section, service restart steps. Checked 2026-09-25. [^46]: From Release 14, the CallManager service does not need a restart when OAuth is enabled and the Tomcat certificate is regenerated. Source: [Release Notes for Cisco Unified Communications Manager and the IM and Presence Service, Release 14 - New and Changed Features](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/14_0_1/cucm_b_release-notes-for-cucm-imp-14_0_1/cucm_m_new-and-changed-features.html), Certificate Regeneration without Service Restarts feature entry. Checked 2026-09-25. [^47]: The TAC technote tells administrators to restart Tomcat on every node with utils service restart Cisco Tomcat after regenerating the Tomcat certificate, publisher first and then subscribers. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), Tomcat certificate section. Checked 2026-09-25. [^48]: The Release 15 admin guide says that after Tomcat or Tomcat-ECDSA is regenerated, Cisco Tomcat, Intercluster Lookup Service, Location Bandwidth Manager, DRS Local and Master, Extension Mobility and AXL Tomcat should be restarted. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Manage Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_01111.html), Manage Certificates chapter, services-to-restart table. Checked 2026-09-25. [^49]: From 14.0.1.13900-155, a multi-SAN Tomcat certificate (self-signed or CA-signed) can be reused for the CallManager service through Security > Certificate Management > Reuse Certificate. Source: [Configure Tomcat Certificate Reuse for CallManager in CUCM 14](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/221070-configure-tomcat-certificate-reuse-for-c.html), Configure section, reuse certificate steps. Checked 2026-09-25. [^50]: After enabling Tomcat reuse for CallManager, Cisco HAProxy is restarted on all nodes. In mixed mode, utils ctl update CTLFile is run and all phones are reset. Source: [Configure Tomcat Certificate Reuse for CallManager in CUCM 14](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/221070-configure-tomcat-certificate-reuse-for-c.html), Configure section, final steps and mixed-mode note. Checked 2026-09-25. [^51]: From 14SU4, the CallManager certificate is hidden in the GUI when Tomcat reuse is enabled. In SU2 and SU3 it was still visible. Source: [Configure Tomcat Certificate Reuse for CallManager in CUCM 14](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/221070-configure-tomcat-certificate-reuse-for-c.html), Verify / caveats section. Checked 2026-09-25. [^52]: SSO must be disabled before uploading the Tomcat certificate for CallManager reuse and re-enabled afterwards. Source: [Configure Tomcat Certificate Reuse for CallManager in CUCM 14](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/221070-configure-tomcat-certificate-reuse-for-c.html), Prerequisites and caveats sections. Checked 2026-09-25. [^53]: When SSO or OAuth is configured, the technote also requires restarting Cisco SSOSP Tomcat after the Tomcat certificate is regenerated. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), Tomcat certificate section. Checked 2026-09-25. [^54]: In its sequence of phone-trust certificates (CAPF, CallManager, TVS), the TAC technote tells administrators to regenerate the TVS certificate last, and it documents ITLRecovery separately as a publisher-only certificate. Source: [Regenerate Certificates In Unified Communications Manager](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html), TVS certificate section, ordering note. Checked 2026-09-25. [^55]: The TVS certificate can be a multi-server SAN certificate, self-signed or CA-signed, so one TVS certificate can cover the whole cluster. Source: [Security Guide for Cisco Unified Communications Manager Release 14 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/14SU2/cucm_b_security-guide-14su2/cucm_m_certificates.html), Certificates chapter, TVS multi-server SAN paragraph. Checked 2026-09-25. [^56]: The Trust Verification Service runs on Unified CM and authenticates certificates on behalf of the IP phone, so phone resources do not limit how many certificates can be trusted. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Default Security](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_default-security-setup_su2_reorg.html), Default Security chapter, Trust Verification Service section. Checked 2026-09-25. [^57]: The 10.0(1) technote says phones have TVS as a secondary way to authenticate files, whichever certificate is regenerated first. This is why changing one ITL-relevant certificate at a time is recoverable. Source: [Unified Communications Manager ITL Enhancements in Version 10.0(1)](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/117598-technote-itl-00.html), Trust validation / TVS discussion. Checked 2026-09-25. [^58]: When generating a self-signed certificate in Release 15, an administrator can choose a validity of 1, 2, 5, 10 or 20 years. Source: [Security Guide for Cisco Unified Communications Manager, Release 15 and SUs - Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/15_0/cucm_b_security-guide-release-15/cucm_m_certificates.html), Certificates chapter, self-signed certificate validity paragraph. Checked 2026-09-25. [^59]: The rule against changing CallManager and TVS together follows from the ITL trust model. A phone that sees an unfamiliar ITL signer falls back to TVS, so if the TVS certificate changes in the same window the phone has no trusted path left (inferred). Source: [Unified Communications Manager ITL Enhancements in Version 10.0(1)](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/117598-technote-itl-00.html), Trust validation / TVS discussion, read with 217138 warning. Checked 2026-09-25.