El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo regenerar certificados utilizados en Cisco Unified Communications Manager (CUCM) Release 8.x y posteriores.
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.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en estas versiones de software:
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.
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:
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.
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
Tomcat.pem
CAPF.pem
IPSec.pem
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.
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.
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 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:
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.
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.
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.
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.
Este procedimiento brinda a un servidor TFTP un archivo de ITL válido/actualizado proveniente de un servidor TFTP confiable disponible.
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.
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).
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.
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
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 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 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
OS Admin > Security > Certificate Management > Find > Click X certificate within the
'-trust' store > Remove/Delete
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 |
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 |
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:
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 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.
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 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
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.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
3.0 |
10-Nov-2022 |
Actualizaciones realizadas para lenguaje sesgado, errores de título, errores de introducción, traducción automática, SEO, requisitos de estilo y formato. |
2.0 |
28-Oct-2021 |
En este artículo se incluyeron otros documentos de renovación de certificados. |
1.0 |
19-Oct-2015 |
Versión inicial |