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

Introducción

En este documento, se presenta paso a paso un procedimiento recomendado para regenerar certificados empleados en Cisco Unified Communications Manager (CUCM) 8.x y versiones posteriores. También se tratan la función de seguridad predeterminada (ITL) y el modo mixto (CTL), para prevenir interrupciones no deseadas. Por ejemplo, cómo evitar problemas con el registro telefónico o con teléfonos que no aceptan firmware o cambios de configuración.

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

Información general

En este documento se trata el proceso de regeneración de certificados para los siguientes servicios:

• CallManager
• Función de proxy de autoridad de certificación (CAPF, Certificate Authority Proxy Function)
• IPsec
• Tomcat
• Servicio de verificación de confianza (TVS, Trust Verification Service)
• ITLRecovery (solo para CUCM 10.X y versiones posteriores)
• phone-vpn-trust
• phone-sast-trust
• phone-trust
• phone-ctl-trust

Además de estos certificados telefónicos:

• Certificados de significación local (LSC, Locally Significant Certificates)
• Certificados instalados por el fabricante (MIC, Manufacturer Installed Certificates)

Componentes Utilizados

Todos los resultados y las capturas de pantallas presentados en este documento se basan en CUCM 9.1(2)SU2a, aunque el procedimiento puede emplearse con CUCM 8.x y versiones posteriores. Las diferencias entre versiones se mencionan en las secciones correspondientes.

La información incluida en este documento se basa en dispositivos de un entorno de laboratorio que comenzaron con una configuración aprobada (predeterminada). Si su red está activada, asegúrese de comprender el impacto potencial de todos los comandos y las acciones.

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 plazo de cinco años por el momento no puede acortarse en CUCM. Sin embargo, una autoridad certificadora (CA, Certificate Authority) puede emitir certificados por casi cualquier plazo.

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 "Cisco Manufacturing CA" se ofrece en almacenes de trusts de CUCM para funciones específicas y no caduca hasta el año 2029.

Los certificados deberían regenerarse antes de que caduquen. Cuando los certificados estén por caducar, recibirá advertencias en RTMT (visor de Syslog) y se le enviará una notificación por correo electrónico si tiene configurada esta opción.

Aquí hay un ejemplo de una notificación de caducidad de certificado donde se detalla que el certificado "CUCM01.der" caducará el lunes 19 de mayo a las 14:46 en el servidor CUCM02 del almacén de trusts "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

Si los certificados de servicios (almacenes de certificados sin la denominación "-trust") ya caducaron, aún se pueden regenerar. 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 el buen funcionamiento del sistema que todos los certificados estén actualizados en todo el clúster de CUCM. Si caducaron o no son válidos, pueden afectar significativamente el funcionamiento normal del sistema. Aquí se presenta una lista de problemas que podría hallar si alguno de estos certificados específicos caducó o no es válido. El impacto puede variar según 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.
• No se registran o no funcionan los enlaces troncales seguros del protocolo de inicio de sesión (SIP, Session Initiation Protocol) o los recursos multimedia (puentes de conferencias, puntos de terminación de medios, Xcoders, etc.).
• 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.

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.

TVS (Trust Verification Service)

• 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 funcionará, porque no se puede autenticar la URL HTTPS de la VPN.

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

phone-sast-trust

• Los CTL/eTokens anteriores no podrán actualizar ni modificar CTL.

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

phone-trust y phone-ctl-trust

• No funcionará el correo de voz visual con Unity o Unity Connection.

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

LSC y MIC

• Los teléfonos no se registran y el teléfono no se autentica en VPN de teléfono, proxy de teléfono 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. Las copias de respaldo del DRF de CUCM incluyen todos los certificados del clúster. Todos los procedimientos de creación/restauración de copias de respaldo del DRS se encuentran en la "Guía de administración del sistema de recuperación tras desastres para Cisco Unified Communications Manager".

Precaución: Tenga en cuenta el error de ID CSCtn50405 de Cisco, por el cual el DRF de CUCM no crea copias de respaldo de los certificados.

Determine si el clúster se encuentra en 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. No obstante, asegúrese de tener al menos un eToken del inicio original de la función de modo mixto y conocer la contraseña del eToken.

Nota: El CTL no se actualiza automáticamente (como sí sucede en el caso del archivo de 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 de método mediante CUCM Mixed Mode with Tokenless CTL (Modo mixto de CUCM con CTL sin token).

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

Es importante evitar los problemas con ITL, ya que pueden hacer que muchas funciones fallen o que el teléfono no aplique los cambios en las configuraciones. Los problemas con ITL pueden evitarse de estas dos maneras.

Utilice la función "Prepare Cluster for Rollback to pre 8.0 (Preparar clúster para reversión a antes de 8.0)"

Esta función "vacía" su ITL en todos los servidores, para que los teléfonos confíen en cualquier servidor TFTP. Los servicios telefónicos (por ejemplo, la movilidad de la extensión) NO funcionan cuando este parámetro se configura como True (Verdadero). No obstante, los usuarios podrán seguir haciendo y recibiendo llamadas telefónicas básicas.

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

Una vez configurada esta función, todos los servidores TFTP deben reiniciarse (para suministrar la nueva ITL) y todos los teléfonos deben restablecerse para obligarlos a solicitar la nueva ITL "vacía". Una vez completados los cambios de certificados y reiniciados todos los servicios necesarios, se puede regresar esta función a "False (Falso)", reiniciar el servicio TFTP y restablecer el teléfono (para que el teléfono pueda obtener el archivo de ITL válido). Luego 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. Haga los cambios que necesite en los certificados del servidor TFTP principal.
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.

Elimine y regenere certificados en CUCM

Solo se puede regenerar certificados de servicios (almacenes de certificados sin la denominación "-trust"). Los certificados de almacenes de trusts (almacenes de certificados con la denominación "-trust") deben eliminarse, ya que no pueden regenerarse.

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 error de ID CSCto86463 de Cisco, por el cual los certificados eliminados reaparecen y no se pueden eliminar 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: La regeneración de certificados activa una actualización automática de los archivos de ITL dentro del clúster, lo cual activa un restablecimiento de software de los teléfonos de todo el clúster para que los teléfonos puedan activar una actualización de su ITL local. Esto se concentra en la regeneración de los certificados CAPF y CallManager, pero puede suceder 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 exclusivo de nombre de sujeto, por lo cual los certificados CAPF utilizados previamente se conservan y se emplean para la autenticación.

set cert regen CAPF

Nota: Si un certificado CAPF caduca, los teléfonos que emplean LSC no podrán registrarse en CUCM porque CUCM rechazará el 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

Regenere 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 TVS

set cert regen TVS

Qué esperar

Al regenerar certificados mediante la CLI, se le solicita que verifique este cambio. Escriba yes (sí) y presione Intro.

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 CAPF 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
CallManager	CallManager; TFTP; CTIManager	GUI de la red:  Cisco Unified Serviceability > Tools (Herramientas) > Control Center (Centro de control) - Feature Services (Servicios de funciones) > (Select Server [Seleccionar servidor]) > seleccione "Cisco CallManager" > Restart (Reiniciar) GUI de la red:  Cisco Unified Serviceability > Tools (Herramientas) > Control Center (Centro de control) - Feature Services (Servicios de funciones) > (Select Server [Seleccionar servidor]) > seleccione "Cisco Tftp" > Restart (Reiniciar) GUI de la red:  Cisco unificó la utilidad > el Tools (Herramientas) > Control Center (Centro de control) - La característica mantiene > (servidor selecto) > “Cisco selecto CTIManager” > reinicio
CAPF	CAPF (solo en el servidor de editores)	GUI de la red:  Cisco Unified Serviceability > Tools (Herramientas) > Control Center (Centro de control) - Feature Services (Servicios de funciones) > (Select Server [Seleccionar servidor]) > seleccione "Cisco Certificate Authority Proxy Function" > Restart (Reiniciar)
TVS	Trust Verification Service (en el servidor respectivo)	GUI de la red: Cisco Unified Serviceability > Tools (Herramientas) > Control Center (Centro de control) - Network Services (Servicios de redes) > (Select Server [Seleccionar servidor]) > seleccione "Cisco Trust Verification Service" > Restart (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

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. Elija CUCM Serviceability > Service Activation (Activación de servicios). 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, elija Device (Dispositivo) > Phone (Teléfono). Seleccione el teléfono IP al que desee asignar un LSC.
3. En la página de configuración del dispositivo, en Certificate Operation (Operación de certificados), elija Install / Upgrade (Instalar/Actualizar) > By Null String (Con 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:

Tras restablecer el teléfono, vaya al teléfono físico y elija Settings (Configuración) > (6) Security Configuration (Configuración de seguridad) > (4) LSC > **# (esto desbloquea la GUI y nos permite avanzar con el siguiente paso) > Update (Actualizar) (esta opción no aparece hasta completar el paso anterior) > Submit (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.

Conclusión

Si surge un problema o necesita asistencia con este procedimiento, comuníquese con Cisco Technical Assistance Center (TAC). En este caso, tenga a disposición su copia de respaldo del DRF, ya que se usará como último recurso para restaurar el servicio si en TAC no logran hacerlo con otros métodos.