Configurar y solucionar problemas de certificados de Collaboration Edge (MRA)
Contenido
Introducción
Este documento describe los certificados con respecto a las implementaciones de acceso remoto móvil (MRA).
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Antecedentes
Autoridad de certificación (CA) pública o privada
Hay un número de opciones para firmar certificados en los servidores de Expressway-C y E. Puede optar por obtener la firma para la solicitud de firma de certificado (CSR) de una autoridad de certificación pública como GoDaddy, Verisign u otra, o puede obtener la firma internamente mediante su propia autoridad de certificación (CA) (puede autofirmarla con openSSL o con una CA empresarial interna como un servidor de Microsoft Windows). Para obtener más información sobre cómo crear y firmar las CSR con cualquiera de estos métodos, consulte la Guía de creación de certificados del servidor de comunicación de video (VCS).
El único servidor que realmente necesita la firma de una CA pública es Expressway-E. Este es el único servidor en el que los clientes verán el certificado cuando inicien sesión mediante MRA, por tanto, con una CA pública, se asegurarán de que los usuarios no tengan que aceptar el certificado manualmente. Se puede usar una CA interna para firmar en Expressway-E, pero los usuarios primerizos deberán aceptar el certificado que no es de confianza. El registro de MRA de los teléfonos de las series 7800 y 8800 tampoco funcionará con certificados internos porque no se puede modificar la lista de confianza de certificados. Por motivos de simplicidad, se recomienda que los certificados de Expressway-C y Expressway-E estén firmados por la misma CA; sin embargo, esto no es un requisito siempre que haya configurado correctamente las listas de CA de confianza en ambos servidores.
Cómo funcionan las cadenas de certificados
Los certificados se vinculan entre sí en una cadena de dos o más para verificar la fuente de la firma del certificado de los servidores. Hay tres tipos de certificados en una cadena, el certificado del cliente/servidor, los certificados intermedios (en algunos casos) y el certificado raíz (también conocido como la CA raíz, ya que se trata de la autoridad de nivel más alto que firmó el certificado).
Los certificados contienen dos campos principales que crean la cadena: el asunto y el emisor. El asunto es el nombre del servidor o la autoridad que representa este certificado. En el caso de los dispositivos Expressway-C o Expressway-E (u otros dispositivos de Unified Communications [UC]), esto se genera a partir del nombre de dominio totalmente calificado (FQDN). El emisor es la autoridad que validó el certificado específico. Dado que cualquiera puede firmar un certificado (incluido el servidor que creó el certificado en primer lugar, algo conocido como certificados autofirmados), los clientes y servidores tienen una lista de emisores o CA de confianza que se consideran auténticos.
Una cadena de certificado siempre termina con un certificado autofirmado de nivel superior o certificado raíz. Mientras se desplaza por la jerarquía de certificados donde cada certificado tiene un emisor diferente en relación con el asunto, finalmente encontrará la CA de raíz donde el sujeto coincidirá con el emisor, lo que indica que este es el certificado de nivel superior y, por lo tanto, el que debe recibir la confianza de la lista de CA de confianza del cliente o los servidores.
Resumen del intercambio de señales de SSL
Puede ver este diagrama de flujo para conocer el flujo de señalización detallado del proceso de intercambio de señales de SSL, incluido el intercambio y la generación de claves, lo que puede ser de utilidad al observar capturas de paquetes. En el caso de la zona transversal, Expressway-C siempre actuará como el cliente, mientras que Expressway-E siempre será el servidor. El intercambio simplificado funciona como se indica a continuación:
Expressway-C Expressway-E
—Cliente Hello—>
<—Server Hello—
<—Certificado de servidor—
<—Solicitud de certificado—
—Certificado de cliente—>
La clave aquí está en el intercambio; puesto que Expressway-C siempre inicia la conexión y, por lo tanto, es siempre el cliente, Expressway-E es el primero en enviar su certificado. Si Expressway-C no puede validar este certificado, eliminará el intercambio de señales y no enviará su certificado a Expressway-E.
Otro aspecto importante que vale notar son los atributos de autenticación de cliente web de seguridad de capa de transporte (TLS) y los atributos de autenticación de servidor web de TLS. Estos atributos se determinan en la CA que está firmando la CSR (si usa una CA de Windows, esto lo determina la plantilla seleccionada) e indican si el certificado es válido en la función de cliente o servidor (o ambas). Debido a que para un VCS o Expressway se pueden usar ambos según la situación (siempre es el mismo para una zona transversal), el certificado debe tener los atributos de autenticación de cliente y servidor. Expressway-C y Expressway-E emitirán un error al cargar un certificado de servidor nuevo si no tiene ambos aplicados.
Si no está seguro de si un certificado presenta estos atributos, puede abrir los detalles del certificado en un navegador o en su sistema operativo y consultar la sección de uso de clave extendida (consulte la captura de pantalla). El formato puede variar y depende de cómo se visualice el certificado. Ejemplo:
Configurar
Zona transversal y de confianza de Expressway-C y Expressway-E
Generar y firmar CSR
Como se describe anteriormente, los certificados de Expressway-E y Expressway-C deben estar firmados por una CA interna o externa, o usar openSSL para el autofirmado. No se puede usar el certificado temporal que se incluye en el servidor de Expressway. Tampoco se permite el uso de certificados comodín en los que una CA firma un certificado cuya línea de asunto no está definida específicamente.
El primer paso es generar el CSR y que lo firme el tipo de CA preferida. Este proceso se detalla específicamente en la guía de creación de certificado. Al crear el CSR es importante tener en cuenta los nombres alternativos de asunto (SAN) que deben incluirse en los certificados. Esto también se detalla en la guía de certificados y la guía de implementación de acceso remoto móvil. Consulte las versiones más recientes de la guía, ya que se pueden agregar más a medida que se presentan nuevas funciones. Lista de SAN comunes que deben incluirse en función de las funciones que se utilizan:
Expressway-C
- Cualquier dominio (interno o externo) agregado a la lista de dominios.
- Cualquier alias de nodo de chat persistente si se usan las federaciones XMPP.
- Nombres de perfil de dispositivo seguro en CUCM si usa perfiles de dispositivo seguros.
Expressway-E
- Cualquier dominio configurado en Expressway-C.
- Cualquier alias de nodo de chat persistente si se usan las federaciones XMPP.
- Cualquier dominio publicitado para federaciones XMPP.
Configuración de confianza mutua entre Expressway-C y Expressway-E
Para que la zona transversal de Unified Communications pueda establecer una conexión, Expressway-C y Expressway-E deben confiar en los certificados mútuamente. En este ejemplo, se supone que el certificado de Expressway-E recibió la firma de CA pública mediante la siguiente jerarquía.
Certificado 3
Emisor: CA de raíz de GoDaddy
Asunto: CA de raíz de GoDaddy
Certificado 2
Emisor: CA de raíz de GoDaddy
Asunto: Autoridad intermedia de GoDaddy
Certificado 1
Emisor: Autoridad intermedia de GoDaddy
Asunto: Expressway-E.lab.com
Expressway-C debe configurarse con el certificado de confianza 1 anterior. En la mayoría de los casos, en función de los certificados de confianza que se aplican al servidor que envía realmente su certificado, ese servidor solo enviará su certificado de servidor de nivel más bajo. Esto significa que, para que Expressway-C confíe en el certificado 1, debe cargar ambos certificados 2 y 3 a la lista de CA de confianza de Expressway-C (Mantenimiento > Seguridad > Lista de CA de confianza). Si omite el certificado intermedio 2, cuando Expressway-C reciba el certificado de Expressway-E, no tendrá manera de asociarlo con la CA de raíz de confianza de GoDaddy, por lo que se rechazará.
Certificado 3
Emisor: CA de raíz de GoDaddy
Asunto: CA de raíz de GoDaddy
Certificado 1
Emisor: Autoridad intermedia de GoDaddy: no es de confianza
Asunto: Expressway-E.lab.com
Además, si carga solo el certificado intermedio sin la raíz a la lista de CA de confianza de Expressway-C, se verá que la autoridad intermedia de GoDaddy es de confianza, pero como está firmado por una autoridad superior, CA de raíz de GoDaddy, que no es de confianza, producirá un error.
Certificado 2
Emisor: CA de raíz de GoDaddy: no es de confianza
Asunto: Autoridad intermedia de GoDaddy
Certificado 1
Emisor: Autoridad intermedia de GoDaddy
Asunto: Expressway-E.lab.com
Una vez que se agregaron todas las autoridades intermedias y la raíz a la lista de CA de confianza, se puede comprobar el certificado...
Certificado 3
Emisor: CA de raíz de GoDaddy: el certificado autofirmado de nivel superior es de confianza y la cadena está completa.
Asunto: CA de raíz de GoDaddy
Certificado 2
Emisor: CA de raíz de GoDaddy
Asunto: Autoridad intermedia de GoDaddy
Certificado 1
Emisor: Autoridad intermedia de GoDaddy
Asunto: Expressway-E.lab.com
Si no está seguro de cómo es la cadena de certificados, puede comprobar su navegador cuando inicie sesión en la interfaz web del Expressway específico. El proceso varía ligeramente en función del navegador, pero en Firefox, puede hacer clic en el icono de candado en el extremo izquierdo de la barra de direcciones. A continuación, en el menú emergente, haga clic en Más información > Ver certificado > Detalles. Suponiendo que el navegador puede reunir la cadena completa, verá la cadena de inicio a fin. Si el asunto y el emisor del certificado de nivel superior no coinciden, sabrá que no está viendo la cadena completa. También puede exportar cada certificado de la cadena por separado haciendo clic en Exportar con el certificado que desee seleccionado. Esto resulta útil si no está 100 % seguro de haber cargado los certificados correctos a la lista de confianza de CA.
A continuación, ahora que Expressway-C confía en el certificado de Expressway-E, asegúrese de que esto sea así en el sentido contrario. Si el certificado de Expressway-C está firmado por la misma CA que firmó el de Expressway-E, el proceso es sencillo, solo tiene que cargar los mismos certificados a la lista de CA de confianza en Expressway-E como ya lo hizo en Expressway-C. Si el certificado de Expressway-C está firmado por otra CA diferente, deberá seguir el mismo proceso que antes, pero con la cadena con la firma del certificado de Expressway-C.
Protección de las comunicaciones entre Cisco Unified Communications Manager (CUCM) y Expressway-C
Overview
A diferencia de la zona transversal entre Expressway-C y Expressway-E, NO se necesitan señales seguras entre Expressway-C y CUCM. A menos que las políticas de seguridad internas no lo permitan, siempre debe configurar MRA para que funcione con perfiles de dispositivo no seguros en CUCM primero para confirmar que el resto de la implementación sea correcta antes de seguir con este paso.
Hay dos funciones principales de seguridad que se pueden habilitar entre CUCM y Expressway-C, la comprobación de TLS y los registros de dispositivos seguros. Hay una diferencia importante entre estos dos porque usan dos certificados diferentes en el lado de CUCM en el intercambio de señales de SSL.
Comprobación de TLS: certificado Tomcat
Registros seguros en SIP: certificado de CallManager
Configuración de confianza entre CUCM y Expressway-C
El concepto en este caso es exactamente el mismo que entre Expressway-C y Expressway-E. CUCM en primer lugar debe confiar en el certificado del servidor de Expressway-C. Esto significa que en el CUCM, el certificado de raíz y los certificados intermedios de Expressway-C deben cargarse como un certificado de confianza de Tomcat para la función de comprobación de TLS y como certificados de confianza de CallManager para los registros de dispositivos seguros. Para esto, vaya a Cisco Unified OS Administrationen la esquina superior derecha de la GUI web de CUCM y, a continuación, haga clic en Seguridad > Administración de certificados. Aquí puede hacer clic en Cargar certificado/cadena de certificado y seleccionar el formato correcto de confianza o hacer clic en Buscar para ver la lista de certificados cargados actualmente.
También deberá asegurarse de que Expressway-C confíe en la CA que firmó los certificados de CUCM al agregarla a la lista de CA de confianza. En casi todos los casos, si firmó los certificados de CUCM con una CA, los certificados de Tomcat y CallManager deben estar firmados por la misma CA. Si son diferentes, deberá confiar en ambos si usa la comprobación de TLS y los registros seguros.
Para los registros seguros en SIP también debe asegurarse de que el nombre de perfil de dispositivo seguro en el CUCM que se aplica al dispositivo figure como una SAN en el certificado de Expressway-C. Si esto falta, se producirá un error de mensajes de registro seguro con un "403" de CUCM que indica un error de TLS.
Servidores CUCM con certificados autofirmados
De forma predeterminada, un servidor de CUCM viene con certificados autofirmados. Si estos están en su lugar, no se puede usar la comprobación de TLS y los registros de dispositivos seguros al mismo tiempo. Ambas funciones pueden usarse por separado, pero dado que los certificados son autofirmados, los certificados autofirmados de Tomcat y CallManager deben cargarse a la lista de CA de confianza en Expressway-C. Cuando Expressway-C busca en su lista de confianza para validar un certificado, se detendrá una vez que encuentre uno con un asunto que coincida. Por este motivo, se usará la función que esté más alta en la lista de confianza (Tomcat o CallManager). La función que esté más baja fallará como si no estuviera presente. La solución a esto es firmar los certificados de CUCM con una CA (pública o privada) y confiar solo en esa CA.
Consideraciones sobre clústeres de Expressway-C y Expressway-E
Certificados de clúster
Se recomienda encarecidamente que, si dispone de un clúster de servidores Expressway-C o Expressway-E para obtener redundancia, genere una CSR independiente para cada servidor y que la haga firmar por una CA. En el escenario anterior, el nombre común (CN) de cada certificado de peers sería el mismo nombre de dominio completamente calificado (FQDN) del clúster y las SAN serían el FQDN del clúster y el FQDN de los pares respectivos como se muestra a continuación:
Es posible que utilice el FQDN del clúster como CN y cada FQDN del mismo nivel y el FQDN del clúster en la SAN para utilizar el mismo certificado para todos los nodos del clúster, evitando así el costo de varios certificados firmados por una CA pública.
Si es absolutamente necesario, esto puede hacerse con el siguiente proceso o con OpenSSL para generar la clave privada y la CSR manualmente:
Paso 1. Genere un CSR en el maestro del clúster y configúrelo para enumerar el alias del clúster como CN. Agregue todos los pares del clúster como nombres alternativos, junto con todas las demás SAN necesarias.
Paso 2. Firme este CSR y cárguelo en el par maestro.
Paso 3. Inicie sesión en el maestro como root y descargue la clave privada ubicada en /tandberg/persistent/certs.
Paso 4. Cargue el certificado firmado y la clave privada coincidente entre sí en el clúster.
Listas de autoridades de certificación de confianza
A diferencia de los suscriptores de CUCM en un clúster, la lista de autoridades de certificación de confianza NO se replica de un par a otro en un clúster de VCS o Expressway. Esto significa que si dispone de un clúster, deberá cargar manualmente los certificados de confianza en la lista de CA de cada par.
Verificación
Use esta sección para confirmar que su configuración funciona correctamente.
Comprobación de información del certificado existente
Hay varias maneras de comprobar la información de un certificado existente. La primera opción es mediante el explorador web con el método que se muestra en la sección anterior, que también puede usarse para exportar un certificado específico de la cadena. Si necesita verificar SAN u otros atributos agregados al certificado de servidor de Expressway, puede hacerlo directamente a través de la interfaz gráfica de usuario (GUI) web en Mantenimiento > Certificados de seguridad> Certificado de servidor y haciendo clic en Mostrar decodificación.
Aquí puede ver todos los detalles específicos del certificado sin la necesidad de descargarlo. También puede hacer lo mismo para una CSR activa si aún no se ha cargado el certificado firmado asociado.
Lectura/exportación de certificado en Wireshark
Si dispone de una captura de Wireshark del intercambio de señales de SSL, incluido el intercambio de certificados, Wireshark descodificará el certificado y podrá exportar todos los certificados de la cadena (suponiendo que se intercambia la cadena completa) desde adentro. Puede filtrar la captura de paquetes para el puerto específico del intercambio de certificados (generalmente 7001 en el caso de la zona transversal). A continuación, si no ve los paquetes de saludo del cliente y el servidor junto con el intercambio de señales de SSL, haga clic con el botón secundario del mouse en uno de los paquetes de la secuencia de TCP y seleccione Decodificar como, SSL y haga clic en aplicar. Ahora, si ha capturado el tráfico correcto, verá el intercambio de certificados. Busque el paquete del servidor correcto que contiene los certificados en la carga útil. Expanda la sección SSL en el panel inferior hasta que vea la lista de certificados como se muestra a continuación.
Aquí se puede ampliar cualquiera de los certificados para ver todos los detalles. Si desea exportar el certificado, haga clic con el botón secundario del mouse en el certificado que desee de la cadena (si hay varios) y seleccione Exportar bytes de paquete seleccionado. Introduzca un nombre para el certificado y haga clic en guardar. Ahora debería poder abrir el certificado en el Visor de certificados de Windows (si le asigna una extensión .cer) o cargarlo en cualquier otra herramienta para su análisis.
Troubleshoot
En esta sección encontrará información que puede utilizar para solucionar problemas de configuración.
Comprobación de un certificado para determinar si es de confianza en Expressway
El mejor método consiste en comprobar manualmente la cadena de certificados para asegurarse de que todos los miembros figuren en la lista de CA de confianza de Expressway, pero puede hacer una comprobación rápida para garantizar que Expressway confiará en el certificado de un cliente específico usando la prueba de certificado de cliente en Mantenimiento > Certificados de seguridaden la GUI web. Con los ajustes predeterminados, seleccione Cargar archivo de prueba (formato pem) en el menú desplegable y seleccione el certificado de cliente que desee comprobar. Si el certificado no es de confianza, se producirá un error como el siguiente que explica el motivo del rechazo. Debajo del error también podrá ver la información decodificada del certificado cargado a modo de referencia.
Si aparece un error que indica que Expressway no puede obtener el CRL del certificado, pero Expressway no está usando la comprobación de CRL, esto significa que el certificado es de confianza y ha pasado todos los demás controles de verificación.
Terminales de Synergy Light (teléfonos de las series 7800 y 8800)
Estos nuevos dispositivos cuentan con una lista de certificados de confianza ya completa que incluye un gran número de CA públicas muy conocidas. Esta lista de confianza no se puede modificar, lo que significa que el certificado de Expressway-E DEBE estar firmado por una de estas CA públicas para funcionar con estos dispositivos. Si el certificado está firmado por una CA interna o una CA pública diferente, la conexión fallará. No hay ninguna opción para que el usuario pueda aceptar manualmente el certificado como con los clientes de Jabber.
Comentarios