Proceso de regeneración/renovación de certificados de CUCM

Introducción

Este documento describe cómo regenerar certificados usados en Cisco Unified Communications Manager (CUCM) versión 8.x y posteriores. La Lista de confianza de identidad (ITL) habilitada por la función Seguridad por defecto (SBD) y la Lista de confianza de certificados (CTL) para entornos en 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: Se recomienda siempre 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 posteriores

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. 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 un intervalo de tiempo 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, lo que significa que cada pub y subdivisiones tienen un CallManager, Tomcat, IPsec, TVS y certificado CAPF.

• Certificados de confianza: NO es posible regenerarlos y están etiquetados 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 CA de fabricación de Cisco se proporciona en los almacenes de confianza de CUCM a 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 un correo electrónico con la notificación se enviará si está configurado.

Aquí se muestra un ejemplo de una notificación de vencimiento del certificado que detalla el certificado CUCM01.der vence el lunes 19 de mayo 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

Recuerde que los certificados caducados pueden afectar el funcionamiento de CUCM, según 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 que todos los certificados se actualicen en el clúster de CUCM. Si sus certificados caducan o no son válidos, pueden afectar significativamente al funcionamiento normal del sistema. Aquí se muestra una lista de los 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 o los recursos multimedia del protocolo de inicio de sesión seguro (SIP) (puentes de conferencia, Media Termination Point (MTP), Xcoders, 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 UCCX (Unified Contact Center Express) está integrado, debido al cambio de seguridad de CCX 12.5, es necesario que se cargue el certificado Tomcat de CUCM (autofirmado) o el certificado raíz e intermedio de Tomcat (para CA firmada) en el almacén de tomcat-trust de UCCX, ya que se producen los inicios de sesión de escritorio 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

• Quizás no funcione bien el sistema de recuperación tras desastres (DRS, Disaster Recovery System) o el marco de trabajo de recuperación tras desastres (DRF, Disaster Recovery Framework). 
• 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 ni modificar CTL.

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

phone-trust y phone-ctl-trust

Visual Voicemail 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 Phone VPN, Phone Proxy o 802.1x. 

Nota: Los MIC están de forma predeterminada en la mayoría de los modelos de teléfono. 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 de DRF de CUCM realiza una copia de seguridad de todos los certificados del clúster. Todos los procedimientos de respaldo/restauración de DRS se pueden encontrar en la Guía de Administración del Sistema de Recuperación ante Desastres de Cisco para Cisco Unified Communications Manager.

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

Determinar el modo mixto 

Para determinar si usted ejecuta un clúster en modo CTL/seguro/mixto, elija Cisco Unified CM Administration > System (Sistema) > Enterprise Parameters (Parámetros empresariales) > Cluster Security Mode (Modo de seguridad de clúster) (0 == Non-Secure [No seguro]; 1 == Mixed Mode [Modo mixto]).

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 tener al menos un eToken desde el inicio original de la función Mixed-Mode y de que se conozca la contraseña eToken.

Nota: La 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 emplea este método, el archivo CTL está firmado 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 CUCM con CTL sin Tokenless.

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 de ITL es importante porque puede provocar que muchas funciones fallen o el teléfono se niega a acatar cualquier cambio en las configuraciones. Los problemas con ITL pueden evitarse de estas dos maneras.

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

Esta función vacía las entradas 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 este parámetro se establece en True. No se recomienda activarlo, 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 clústeres de modo mixto, ya que este parámetro sólo borra las entradas ITL, no las entradas CTL.

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

Nota: Un cambio en este parámetro hace que TODOS LOS TELÉFONOS SE REINICIEN.

Una vez que se configura 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 reinició el servicio TFTP y se restableció el teléfono (de modo que el teléfono pueda obtener el archivo ITL válido). A continuación, todas las funciones siguen funcionando como lo hacían anteriormente.

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 primario (según sea necesario).
3. Restablezca los teléfonos (para obtener un nuevo archivo de ITL del servidor TFTP secundario); según qué certificados se regeneren, esto podría suceder automáticamente.
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 los dos 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 los 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 regenerar.

Precaución: Tenga en cuenta el error de ID CSCut58407 de Cisco, por el cual los dispositivos no deberían reiniciarse al eliminar 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 eliminar 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 desencadenan una actualización automática de los archivos ITL dentro del clúster, lo que activa un reinicio del teléfono basado en software 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.

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

set cert regen CAPF

Nota: Si un certificado CAPF caduca, los teléfonos que utilizan LSC no pueden 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. El teléfono, al reiniciarse, descarga la configuración y luego se comunica con CAPF para actualizar el LSC. Tras actualizar el LSC, el teléfono se registra como corresponde. 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.

Regenere 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

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

set cert regen tomcat

Regenere la televisión:

set cert regen TVS

¿Qué se puede esperar?

Al regenerar certificados mediante la CLI, se le solicita que verifique este cambio. Introduzca yes (sí) y, a continuación, seleccione Enter (Introducir).

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:

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

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

Regenerar 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 la televisión:

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 desde el 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 Restart. Gui web: Vaya a Serviciabilidad de Cisco Unified > Herramientas > Centro de control - Servicios de funciones > (Seleccionar servidor). En Cisco Tftp, haga clic en Restart. Gui web: Vaya a Serviciabilidad de Cisco Unified > Herramientas > Centro de control - Servicios de funciones > (Seleccionar servidor). En Cisco CTIManager, haga clic en Restart.
CAPF	CAPF (solo en el servidor de editores)	Gui web: Vaya a Serviciabilidad de Cisco Unified > Herramientas > Centro de control - Servicios de funciones > (Seleccionar servidor). En Función Proxy de la Autoridad de Certificación de Cisco, 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 > (Seleccionar servidor). En Servicio de verificación de confianza de Cisco, haga clic en Reiniciar.
ipsec	Cisco DRF Local (en todos los nodos); Cisco DRF Master (en el servidor de editores)	CLI: utils service restart Cisco DRF Local CLI: utils service restart Cisco DRF Master

¿Cómo se identifican los 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 los certificados de servicio usados. Se recomienda regenerar primero todos los certificados de servicio caducados en todos los nodos y CUCM actualiza la copia -trust automáticamente.

• Ya no se utiliza el tomcat-trust VeriSign_Class_3_Secure_Server_CA_-_G3. 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 eliminar 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 cambió el dominio o nombre de host, los certificados antiguos con un dominio o nombre de host antiguo se enumeran como "trust". Si esos nombres de host y dominios ya no se utilizan, esos certificados no se utilizan y se pueden eliminar.

• Si el nombre común del certificado proviene de un servidor diferente (no del clúster de CUCM), verifique que el certificado del otro servidor sea válido. Como CUCM no puede regenerar el certificado, debe hacerse en el otro servidor y después 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 Serviciabilidad de CUCM > Activación de servicio. 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, vaya a 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 el teléfono se reinicie, en el teléfono físico y navegue hasta Configuración > (6) Configuración de seguridad > (4) LSC > **# (esta operación desbloquea la GUI y nos permite continuar con el siguiente paso) > Actualizar (la actualización no es visible hasta que realice el paso anterior). Ahora haga clic en Enviar.

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, es el proceso más utilizado y recomendado.

Proceso de Regeneración de Certificados para ITLRecrecovery en CUCM 12.x y 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 CUCM CA: 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 Clúster de Unified Communication con Nombre Alternativo de Asunto de Varios Servidores Firmado por CA: la guía proporciona un ejemplo para la regeneración de certificados Tomcat Multi-san.

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

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

El proceso de regeneración de Expressway C y E se describe en los siguientes 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 respaldo DRF disponible como último recurso para restaurar el servicio si el TAC no puede hacerlo a través de otros métodos.