Regenere el certificado de CUCM

Introducción

Este documento describe cómo regenerar certificados utilizados en Cisco Unified Communications Manager (CUCM) Release 8.x y posteriores.

Antecedentes

La Lista de confianza de identidad (ITL) habilitada por la función Security by Default (SBD) y la Lista de confianza de certificados (CTL) para entornos de modo mixto también se tratan en este documento para evitar interrupciones no deseadas. Por ejemplo, cómo evitar problemas de registro del teléfono o teléfonos que no aceptan cambios de configuración o firmware.

Precaución: siempre se recomienda completar la regeneración de certificados en una ventana de mantenimiento.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• CallManager
• Función de proxy de autoridad de certificación (CAPF, Certificate Authority Proxy Function)
• IPsec
• Tomcat
• TVS (Trust Verification Service)
• ITLRecovery (solo para CUCM 10.X y versiones posteriores)
• phone-vpn-trust
• phone-sast-trust
• phone-trust
• phone-ctl-trust
• Certificados de significación local (LSC, Locally Significant Certificates)
• Certificados instalados por el fabricante (MIC, Manufacturer Installed Certificates)

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software:

• CUCM versión 9.1(2)SU2a,
• CUCM versión 8.x y posterior

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Cuándo regenerar certificados

La mayoría de los certificados utilizados en CUCM tras una instalación nueva son certificados autofirmados emitidos, de forma predeterminada, por cinco años. Tenga en cuenta que el intervalo de tiempo de cinco años actualmente no se puede modificar para que sea más corto en CUCM. Sin embargo, una autoridad certificadora (CA, Certificate Authority) puede emitir certificados por casi cualquier plazo.

Los certificados de CUCM se clasifican en dos funciones:

• Certificados de servicio: Es posible regenerarlos y NO se etiquetan con la palabra -trust. Cada nodo tiene sus propios certificados de servicio, esto significa que cada pub y sub tiene un certificado de CallManager, Tomcat, IPsec, TVS y CAPF.

• Certificados de confianza: NO es posible regenerarlos y se etiquetan con la palabra -trust. Estos certificados pueden ser copias de certificados de servicio, certificados instalados de forma predeterminada o certificados de otros servidores.

También hay algunos certificados confiables (como CAPF-trust y CallManager-trust) que vienen precargados y tienen un período de validez superior. Por ejemplo, el certificado de CA de Cisco Manufacturing se proporciona en los almacenes de confianza de CUCM para funciones específicas y no caduca hasta el año 2029.

Los certificados deben regenerarse antes de que caduquen. Cuando los certificados están a punto de caducar, recibirá advertencias en RTMT (Syslog Viewer) y, si está configurado, se enviará un correo electrónico con la notificación.

Aquí se muestra un ejemplo de una notificación de expiración de certificado que detalla que el certificado CUCM01.der caduca el lunes 19 de mayo a las 14:46 en el servidor CUCM02 en el almacén de confianza tomcat-trust:

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

Tenga en cuenta que los certificados caducados pueden afectar a la funcionalidad de CUCM, en función de la configuración del clúster. En las siguientes secciones se efectúan algunas consideraciones.

Impacto del almacén de certificados sobre los servicios

Es fundamental para la buena funcionalidad del sistema tener todos los certificados actualizados en el clúster de CUCM. Si los certificados han caducado o no son válidos, pueden afectar considerablemente al funcionamiento normal del sistema. Aquí se muestra una lista de posibles problemas que puede tener cuando alguno de los certificados específicos no es válido o ha caducado. La diferencia de impacto puede depender de la configuración del sistema.

CallManager.pem

• No se confía en el protocolo TFTP (los teléfonos no aceptan archivos de ITL ni archivos de configuración firmados).
• Los servicios telefónicos pueden verse afectados.
• Los enlaces troncales del protocolo de inicio de sesión seguro (SIP) o los recursos multimedia (puentes de conferencia, punto de terminación de medios (MTP), codificadores X, etc.) no se registran ni funcionan.
• Falla la solicitud de AXL.

Tomcat.pem

• Los teléfonos no pueden acceder a servicios HTTPs alojados en el nodo de CUCM, como Directorio corporativo.
• Problemas con la GUI web de CUCM, como la imposibilidad de acceder a páginas de servicios desde otros nodos del clúster.
• Problemas con la movilidad de la extensión o con la movilidad de la extensión entre clústeres.
• Si se integra UCCX (Unified Contact Center Express), debido al cambio de seguridad de CCX 12.5, es necesario tener cargado el certificado Tomcat de CUCM (autofirmado) o el certificado raíz e intermedio Tomcat (para CA firmada) en el almacén de confianza Tomcat de UCCX, ya que afecta a los inicios de sesión de escritorio de Finesse

CAPF.pem

• Los teléfonos no se autentican para VPN de teléfono, 802.1x o proxy de teléfono. 
• No se puede emitir certificados LSC para los teléfonos.
• Los archivos de configuración cifrados no funcionan.

IPSec.pem

• El Sistema de recuperación ante desastres (DRS)/Marco de recuperación ante desastres (DRF) no puede funcionar correctamente. 
• No funcionan los túneles IPsec a gateway (GW) a otros clústeres de CUCM.

Servicio de verificación de confianza (TVS)

El teléfono no puede autenticar el servicio HTTPS. El teléfono no puede autenticar archivos de configuración (esto puede afectar casi todo en CUCM).

phone-vpn-trust

La VPN del teléfono no funciona porque la URL HTTPS de la VPN no se puede autenticar.

Nota: Si esto no existe, no se preocupe. Es solo para configuraciones específicas.

phone-sast-trust

Los CTL/eTokens anteriores no pueden actualizar o modificar CTL.

Nota: Si esto no existe, no se preocupe. Es solo para configuraciones específicas.

phone-trust y phone-ctl-trust

El correo de voz visual con Unity o Unity Connection no funciona.

Nota: Si esto no existe, no se preocupe. Es solo para configuraciones específicas.

,

LSC y MIC

Los teléfonos no se registran. El teléfono no se autentica en VPN de teléfono, Proxy de teléfono o 802.1x. 

Nota: Los MIC se encuentran en la mayoría de los modelos de teléfono de forma predeterminada. Los LSC llevan la firma de CAPF y tienen una duración predeterminada de cinco años. Los clientes de software como CIPC (Cisco IP Communicator) y Jabber no tienen instalado ningún MIC.

Cree una copia de respaldo con el DRS

Se recomienda crear una copia de respaldo con el DRS antes de hacer cambios importantes como este. El archivo de copia de seguridad DRF de CUCM realiza una copia de seguridad de todos los certificados del clúster. Todos los procedimientos de copia de seguridad/restauración de DRS se pueden encontrar en la Guía de administración de Cisco Disaster Recovery System para Cisco Unified Communications Manager.

Precaución: Tenga en cuenta el Id. de error de Cisco CSCtn50405, CUCM DRF Backup no realiza una copia de seguridad de los certificados.

Determinación del modo mixto 

Para determinar si ejecuta un clúster de CTL/Secure/Mixed-Mode, elija Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non-Secure; 1 == Mixed Mode).

Si el clúster se encuentra en modo mixto

Si ejecuta un clúster de CUCM en modo mixto, el archivo CTL debe actualizarse tras todos los cambios de certificados. El procedimiento para hacer eso lo hallará en la documentación de la Guía de seguridad de Cisco. Sin embargo, asegúrese de que tiene al menos un eToken de la iniciación original de la función Mixed-Mode y que se conoce la contraseña del eToken.

Nota: Una actualización de la CTL no se realiza automáticamente (como ocurre en el caso del archivo ITL). Debe actualizarlo manualmente el administrador con el cliente CTL o el comando CLI.

En CUCM 10.X y versiones posteriores, puede colocar el clúster en modo mixto de dos maneras:

• Comando CLI: Si se emplea este método, el archivo CTL está firmado con el certificado CallManager.pem del servidor de editores.

  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.

• Cliente CTL: si se utiliza este método, el archivo CTL se firma con uno de los eTokens de hardware.

  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.

Nota: Puede cambiar entre el método utilizado con el modo mixto de CUCM con CTL sin tokens.

Según el método empleado para proteger el clúster, deberá utilizarse un procedimiento adecuado de actualización del CTL. Vuelva a ejecutar el cliente CTL o introduzca el comando utils ctl update CTLfile desde la CLI.

Verifique la seguridad predeterminada en el clúster

Evitar los problemas del DIT es importante porque puede hacer que muchas funciones fallen o que el teléfono se niegue a cumplir los cambios de configuración. Los problemas con ITL pueden evitarse de estas dos maneras.

Utilice la función Preparar clúster para revertir a versión anterior a 8.0

Esta función oculta las entradas de ITL en el archivo ITL, por lo que los teléfonos confían en cualquier servidor TFTP. Cualquier solicitud HTTPS de/a teléfonos falla mientras que este parámetro se establece en True. No se recomienda tenerlo activado, ya que limita las funciones del teléfono como Extension Mobility, Corporate Directory, etc. Sin embargo, puede realizar y recibir llamadas telefónicas básicas.

Nota: Esta función no funciona para los clusters de modo mixto, ya que este parámetro sólo borra ITL, no entradas CTL.

Nota: Esta función sólo evita, pero no soluciona, los problemas de ITL. Si el problema ya está en el teléfono, no elimina el DIT y la eliminación del DIT debe ser manual.

Nota: Si se cambia este parámetro, TODOS LOS TELÉFONOS SE RESTABLECERÁN.

Una vez establecida esta función, todos los servidores TFTP deben reiniciarse (para suministrar el nuevo ITL) y todos los teléfonos deben reiniciarse para obligarlos a solicitar el nuevo ITL en blanco. Una vez que se completan los cambios del certificado y se han reiniciado todos los servicios necesarios, esta función se puede volver a establecer en False, se reinicia el servicio TFTP y se reinicia el teléfono (para que el teléfono pueda obtener el archivo ITL válido). A continuación, todas las funciones seguirán funcionando como antes.

Regenere certificados en un orden específico

Este procedimiento brinda a un servidor TFTP un archivo de ITL válido/actualizado proveniente de un servidor TFTP confiable disponible.

1. Interrumpa el servicio TFTP en el servidor TFTP principal.
2. Realice cambios en los certificados del servidor TFTP principal (según sea necesario).
3. Reinicie los teléfonos (para obtener un nuevo archivo ITL del servidor TFTP secundario); esto puede ocurrir automáticamente, dependiendo de los certificados que se regeneren.
4. Una vez recuperados los teléfonos, inicie el servicio TFTP del servidor TFTP principal.
5. Haga cambios en los certificados del servidor TFTP secundario.
6. Restablezca los teléfonos (para obtener un nuevo archivo de ITL del servidor TFTP principal).

Precaución: NO edite certificados en ambos servidores TFTP al mismo tiempo. Esto deja a los teléfonos sin servidor TFTP confiable y exige que el administrador local elimine manualmente la ITL de todos los teléfonos.

Regenere un tipo de certificado a la vez

Este es el procedimiento más utilizado y el recomendado, ya que evita que los teléfonos pierdan confianza. El proceso se describe en la

Guía del proceso de regeneración de certificados para Cisco Unified Communications Manager (CUCM).

Elimine y regenere certificados en CUCM

Sólo se pueden regenerar certificados de servicio (almacenes de certificados que no están etiquetados con -trust). Los certificados de los almacenes de confianza (almacenes de certificados etiquetados con -trust) deben eliminarse, ya que no se pueden volver a generar.

Precaución: tenga en cuenta el Id. de error de Cisco CSCut58407: los dispositivos no se pueden reiniciar cuando se elimina CAPF / CallManager / TVS-trust.

Tras todas las modificaciones de certificados, el servicio respectivo debe reiniciarse para que se apliquen los cambios. Esto se trata en la sección Tras la regeneración/eliminación de certificados.

  

Precaución: tenga en cuenta el Id. de error de Cisco CSCto86463: los certificados eliminados reaparecen, no se pueden quitar certificados de CUCM. Este problema consiste en que los certificados eliminados siguen apareciendo. Emplee la solución alternativa para el defecto.

Regenere certificados mediante la CLI

Precaución: las regeneraciones de certificados activan una actualización automática de los archivos de ITL del clúster, que activa un restablecimiento de software telefónico en todo el clúster para permitir que los teléfonos activen una actualización de su ITL local. Esto se centra en las regeneraciones de certificados de CAPF y CallManager, pero puede ocurrir con otros almacenes de certificados dentro de CUCM, como Tomcat.

Regenerar CAPF: Al regenerar, el certificado CAPF se carga automáticamente en CAPF-trust y CallManager-trust. Además, CAPF siempre tiene un encabezado de nombre de sujeto único, por lo que los certificados CAPF utilizados anteriormente se conservan y se utilizan para la autenticación.

set cert regen CAPF

Nota: si caduca un certificado CAPF, los teléfonos que utilizan LSC no podrán registrarse en CUCM porque CUCM rechaza su certificado. Sin embargo, de todas formas podrá generar un nuevo LSC para el teléfono con el nuevo certificado CAPF. Cuando reinicia el teléfono, descarga la configuración y luego se pone en contacto con CAPF para actualizar LSC. Después de actualizar el LSC, el teléfono se registra como puede. Esto funciona siempre y cuando haya un certificado CAPF nuevo en el archivo de ITL, y el teléfono haya descargado el certificado que lo firmó (callmanager.pem) y haya confiado en él.

Regenerar CallManager: Tras la regeneración, CallManager se carga automáticamente en CallManager-trust.

set cert regen CallManager

Regenerar IPsec: tras la regeneración, el certificado IPsec se carga automáticamente en ipsec-trust.

set cert regen ipsec

Regenerar Tomcat: tras la regeneración, el certificado Tomcat se carga automáticamente en tomcat-trust.

set cert regen tomcat

Regenere TVS:

set cert regen TVS

Qué esperar

Al regenerar certificados mediante la CLI, se le solicita que verifique este cambio. Ingrese yes y luego elija 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.

Elimine certificados mediante la CLI

Elimine certificados de CAPF-trust

set cert delete CAPF <name of certificate>.pem

Elimine certificados de CallManager-trust

set cert delete CallManager <name of certificate>.pem

Elimine certificados de ipsec-trust

set cert delete ipsec <name of certificate>.pem

Elimine certificados de Tomcat-trust

set cert delete tomcat <name of certificate>.pem

Elimine certificados de TVS-trust

set cert delete TVS <name of certificate>.pem

Regenere certificados mediante la GUI web

Regenere CAPF:

Tras la regeneración, el certificado CAPF se carga automáticamente en CAPF-trust y CallManager-trust. Además, el certificado CAPF siempre tiene un encabezado exclusivo de nombre de sujeto, por lo cual los certificados CAPF utilizados previamente se conservan y se emplean para la autenticación.

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

Regenere CallManager:

Tras la regeneración, el certificado de CallManager se carga automáticamente en CallManager-trust.

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

Regenere IPsec: 

Tras la regeneración, el certificado IPsec se carga automáticamente en ipsec-trust.

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

Regenere Tomcat:

Tras la regeneración, el certificado Tomcat se carga automáticamente en tomcat-trust.

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

Regenere TVS:

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

Elimine certificados mediante la GUI web

OS Admin > Security > Certificate Management > Find > Click X certificate within the
 '-trust' store > Remove/Delete

Tras la regeneración/eliminación de certificados

Tras eliminar o regenerar un certificado de un almacén de certificados, el servicio respectivo debe reiniciarse para que se apliquen los cambios.

Almacén	Servicio por reiniciar	Cómo
Tomcat	Tomcat	CLI: utils service restart Cisco Tomcat Siga los pasos necesarios del entorno CCX, si procede 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	Gui Web: Vaya a Serviciabilidad de Cisco Unified > Herramientas > Centro de control - Servicios de funciones > (Seleccionar servidor). En Cisco CallManager, haga clic en Reiniciar. Gui Web: Vaya a Serviciabilidad de Cisco Unified > Herramientas > Centro de control - Servicios de funciones > (Seleccionar servidor). En Cisco Tftp, haga clic en Reiniciar. Gui Web: Vaya a Serviciabilidad de Cisco Unified > Herramientas > Centro de control - Servicios de funciones > (Seleccionar servidor). En Cisco CTIManager, haga clic en Reiniciar.
CAPF	CAPF (solo en el servidor de editores)	Gui Web: Vaya a Serviciabilidad de Cisco Unified > Herramientas > Centro de control - Servicios de funciones > (Seleccione Servidor). En Función de proxy de Cisco Certificate Authority, haga clic en Reiniciar.
TVS	Servicio de verificación de confianza (en el servidor correspondiente)	Gui Web: Vaya a Serviciabilidad de Cisco Unified > Herramientas > Centro de control - Servicios de red > (Seleccione Servidor). En Servicio de verificación de confianza de Cisco, haga clic en Reiniciar.
ipsec	Cisco DRF Local (en todos los nodos); Cisco DRF Primary (en Publisher)	CLI: servicio utils reinicio Cisco DRF Local CLI: servicio utils reinicio Cisco DRF principal

Cómo identificar certificados de confianza que ya no se utilizan

Antes de eliminar certificados caducados en el almacén de confianza, es importante identificar los que se utilizan y los que no. Tenga en cuenta los siguientes puntos para seleccionar los certificados que se deben eliminar:

• La mayoría de los certificados de confianza son copias de certificados de servicio usados. Se recomienda volver a generar primero todos los certificados de servicio caducados en todos los nodos y CUCM actualiza automáticamente la copia de confianza.

• Ya no se utiliza la clase VeriSign_Class_3_Secure_Server_CA_-_G3 de tomcat-trust. Si se utiliza la función Smart Call Home, siga la siguiente guía para cargar el nuevo certificado: https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/smart-call-home/215210-troubleshooting-certficate-exipry-alert.html

• Los certificados de confianza de fabricación se cargan previamente en cualquier CUCM durante la instalación y se utilizan para que CUCM confíe en cualquier teléfono IP de Cisco de forma predeterminada. No se recomienda quitar estos certificados:

CAP-RTP-001

CAP-RTP-002

CA raíz de Cisco 2048

CA raíz M2 de Cisco

ACT2_SUDI_CA

Cisco_Manufacturing_CA

Cisco_Manufacturing_CA_SHA2

• Si se ha cambiado el dominio o el nombre de host, los certificados antiguos con un dominio o nombre de host antiguo se muestran como "trust" (confianza). Si esos nombres de host y dominios ya no se utilizan, esos certificados no se utilizan y pueden eliminarse.

• Si el nombre común del certificado procede de un servidor diferente (no de un clúster de CUCM), compruebe que el certificado del otro servidor es válido. Como CUCM no puede regenerar el certificado, debe hacerlo en el otro servidor y, a continuación, importar el certificado como -trust a CUCM.

Instale/Actualice el LSC en el teléfono

Si se regeneró el certificado CAPF, los certificados LSC de todos los teléfonos del clúster deben actualizarse con LSC firmados por el nuevo certificado CAPF.

1. Vaya a CUCM Serviceability > Service Activation. Active en el servidor de editores Cisco CTL Provider (Proveedor de CTL de Cisco) y Cisco Certificate Authority Proxy Function (Función de proxy de autoridad de certificación de Cisco).
   
   
2. En CUCM CCMAdmin, navegue hasta Device > Phone. Seleccione el teléfono IP al que desee asignar un LSC.
   
   
3. En la página Configuración del dispositivo, en Operación de certificado, navegue hasta Instalar / Actualizar > Por cadena nula.
   
   
4. Guarde la configuración del teléfono en CCMAdmin y elija Apply Config (Aplicar configuración).

Si el teléfono tiene problemas con la instalación del LSC, haga lo siguiente en el teléfono:

Cuando se reinicie el teléfono, en el teléfono físico y navegue hasta Settings > (6) Security Configuration > (4) LSC > **# (esta operación desbloquea la GUI y nos permite continuar con el siguiente paso) > Update (la actualización no es visible hasta que realice el paso anterior). Ahora, haga clic en Submit.

No asigne certificados al teléfono a menos que se trate de un teléfono inalámbrico (7921/25). Los teléfonos inalámbricos emplean otras autoridades certificadoras (CA) para autenticarse.

Proceso de renovación de otros certificados

Proceso de regeneración de certificados para Cisco Unified Communications Manager (CUCM): la guía describe el proceso para regenerar los certificados por tipo, que es el más utilizado y el proceso recomendado.

Proceso de regeneración de certificados para ITLRecrecovery en CUCM 12.x y versiones posteriores: la guía describe el proceso para regenerar el certificado ITLRecrecovery en un clúster de CUCM 12.x. 

Regeneración de certificados firmados por CA de CUCM: la guía describe el proceso para los certificados firmados por CA en CUCM y los errores más comunes que se muestran al cargar un certificado.

Ejemplo de configuración de Unified Communication Cluster Setup with CA-Signed Multi-Server Subject Alternate Name: la guía proporciona un ejemplo para la regeneración de certificados de Tomcat Multi-san.

Regenere los certificados autofirmados del servicio de mensajería instantánea y presencia de Unified Communications Manager: la guía proporciona el proceso de regeneración y los servicios que se deben reiniciar para los nodos de IM&P.

Guía de administración de certificados de la solución UCCX: la guía proporciona los requisitos de integración para certificados en UCCX y el proceso para regenerarlos.

El proceso de regeneración de Expressway C y E se describe en estos vídeos:

Instalación de un certificado de servidor en Expressway

Cómo configurar la confianza de certificados entre Expressway-C y Expressway-E

Conclusión

Si surge un problema o necesita asistencia con este procedimiento, comuníquese con Cisco Technical Assistance Center (TAC). En este caso, mantenga su copia de respaldo DRF disponible ya que se utiliza como último recurso para restaurar el servicio si TAC no puede hacerlo a través de otros métodos.