¿Tiene una cuenta?
Para la documentación de este producto, se ha apuntado a utilizar 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 étnica, orientación sexual, nivel socio-econó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 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.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en estas versiones de software:
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.
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:
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.
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
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 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.
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.
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 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:
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 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.
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.
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.
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 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.
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 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.
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
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 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:
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
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 desde el 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 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 |
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 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 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
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.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
28-Oct-2021 |
En este artículo se incluyeron otros documentos de renovación de certificados. |
1.0 |
21-Apr-2016 |
Versión inicial |