Ejemplo de Configuración de Clúster de Unified Communication con Nombre Alternativo de Asunto de Varios Servidores Firmado por CA

Introducción

Este documento describe cómo configurar un clúster de Unified Communication con el uso de un nombre alternativo de asunto (SAN) de varios servidores firmado por la Autoridad de Certificación (CA).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cisco Unified Communications Manager (CUCM)
• Versión 10.5 de CUCM IM and Presence

Antes de intentar esta configuración, asegúrese de que estos servicios estén activos y sean funcionales:

• Servicio web administrativo de plataforma de Cisco
• Servicio Tomcat de Cisco

Para verificar estos servicios en una interfaz web, navegue hasta Cisco Unified Serviceability Page Services > Network Service > Select a server. Para verificarlos en la CLI, ingrese el comando utils service list.

Si SSO está habilitado en el clúster de CUCM, es necesario desactivarlo y volver a activarlo.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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. If your network is live, make sure that you understand the potential impact of any command.

Antecedentes

En CUCM versión 10.5 y posteriores, esta solicitud de solicitud de firma de certificado (CSR) de almacén de confianza puede incluir SAN y dominios alternativos.

1. Tomcat: CUCM e IM&P
2. Cisco CallManager - Solo CUCM
3. Cisco Unified Presence: protocolo extensible de mensajería y presencia (CUP-XMPP); solo IM&P
4. Servidor a servidor (S2S) CUP-XMPP: solo IM&P

Es más sencillo obtener un certificado firmado por CA en esta versión. Sólo se requiere una CSR firmada por CA en lugar de la necesidad de obtener una CSR de cada nodo de servidor y obtener un certificado firmado por CA para cada CSR y administrarlas individualmente.

Configurar

Paso 1.

Inicie sesión en Administración del sistema operativo (OS) de Publisher y navegue hasta Seguridad > Administración de certificados > Generar CSR.

Paso 2.
Seleccione Multi-Server SAN en Distribution.

Rellena automáticamente los dominios SAN y el dominio primario. 

Verifique que todos los nodos de su clúster aparezcan en Tomcat: todos los nodos CUCM y IM&P bs para CallManager: sólo se enumeran los nodos CUCM.

Paso 3.
Haga clic en Generar y, una vez que se genere la CSR, verifique que todos los nodos enumerados en la CSR también se muestren en la lista Exitosa de CSR exportada.

En Administración de Certificados, se genera la Solicitud SAN:

Paso 4.

Haga clic en Download CSR luego seleccione el propósito del certificado y haga clic en Download CSR.

Es posible utilizar la CA local o una CA externa como VeriSign para que se firme el CSR (archivo descargado en el paso anterior).

Este ejemplo muestra los pasos de configuración para una CA basada en Microsoft Windows Server. Si utiliza una CA diferente o una CA externa, vaya al paso 5.

Inicie sesión en https://<windowsserveripaddress>/certsrv/
Seleccione Request a Certificate > Advanced Certificate Request .
Copie el contenido del archivo CSR en el campo de solicitud de certificado codificado en base 64 y haga clic en Enviar.

Envíe la solicitud CSR como se muestra aquí.

Paso 5.

Nota: Antes de cargar un certificado Tomcat, verifique que el SSO esté inhabilitado. En caso de que esté habilitado, SSO se debe inhabilitar y volver a habilitar una vez que haya finalizado todo el proceso de regeneración de certificados Tomcat.

Con el certificado firmado, cargue los certificados de CA como tomcat-trust. Primero el certificado raíz y luego el certificado intermedio si existe.

Paso 6.

Ahora cargue el certificado firmado de CUCM como Tomcat y verifique que todos los nodos de su clúster aparezcan en la "Operación de carga de certificados exitosa", como se muestra en la imagen:

La SAN de varios servidores aparece en Administración de certificados, como se muestra en la imagen:

Paso 7.

Reinicie el servicio Tomcat en todos los nodos de la lista SAN (primero Publisher y después suscriptores) mediante CLI con el comando: utils service restart Cisco Tomcat.

Verificación

Inicie sesión en http://<fqdnofccm>:8443/ccmadmin para asegurarse de que se utiliza el nuevo certificado.

Certificado SAN de varios servidores de CallManager

Se puede seguir un procedimiento similar para el certificado de CallManager. En este caso, los dominios rellenados automáticamente son sólo nodos de CallManager. Si el servicio Cisco CallManager no se está ejecutando, puede optar por mantenerlo en la lista SAN o eliminarlo.

Antes del certificado SAN firmado por CA para CUCM, asegúrese de que:

• El teléfono IP puede confiar en el servicio de verificación de confianza (TVS). Esto se puede verificar con acceso a cualquier servicio HTTPS desde el teléfono. Por ejemplo, si el acceso al Directorio corporativo funciona, significa que el teléfono confía en el servicio TVS.
• Verifique si el clúster está en modo no seguro o en modo mixto. 

Para determinar si se trata de un clúster de modo mixto, elija Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non-Secure; 1 == Modo mixto).  

Advertencia: Si se encuentra en un Clúster de Modo Mixto antes de que se reinicie el servicio, el CTL debe actualizarse: Token o Tokenless.

Después de instalar el certificado emitido por la CA, se debe reiniciar la siguiente lista de servicios en los nodos que están habilitados:

• Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco TFTP
• Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco CallManager
• Cisco Unified Serviceability > Tools > Control Center - Feature Services > Cisco CTIManager
• Cisco Unified Serviceability > Tools > Control Center - Network Services > Cisco Trust Verification Service

Troubleshoot

Estos registros deben ayudar al Centro de asistencia técnica de Cisco a identificar cualquier problema relacionado con la generación de CSR SAN de varios servidores y la carga del certificado firmado por CA.

• API de la plataforma Cisco Unified OS
• Tomcat de Cisco
• Registros IPT Platform CertMgr

Advertencias conocidas

· CSCur97909: la carga de certificado multiservidor no elimina los certificados autofirmados en la base de datos
· CSCus47235 - CUCM 10.5.2 CN no duplicado en SAN para CSR
· CSCup28852: el teléfono se reinicia cada 7 minutos debido a la actualización de certificados cuando se utiliza la certificación de varios servidores

Si hay un certificado de varios servidores existente, la regeneración se recomienda en los siguientes escenarios:

• Cambio de nombre de host o dominio. Cuando se realiza un cambio de nombre de host o de dominio, los certificados se regeneran automáticamente como Autofirmado. Para cambiarlo a firmado por CA, se deben seguir los pasos anteriores.
• Si se agregó un nuevo nodo al clúster, se debe generar un nuevo CSR para incluir el nuevo nodo.
• Cuando se restaura un suscriptor y no se utiliza ninguna copia de seguridad, el nodo tendrá nuevos certificados con firma automática. Se necesitará un nuevo CSR para el clúster completo para incluir al suscriptor. (Hay una solicitud de mejora CSCuv75957 para agregar esta función.)