Solucionar problemas de error de Finesse "SSLPeerUnverifyException" para gadgets alojados en servidores con firma CA

Introducción

Este documento describe los pasos para resolver problemas en el escenario en el que se carga una cadena de certificados firmada por la Autoridad de Certificación (CA) en Finesse para un servidor web externo que aloja un gadget pero el gadget no se carga cuando se inicia sesión en Finesse y se ve el error "SSLPeerUnverifyException".

Contribuido por Gino Schweinsberger, ingeniero del TAC de Cisco.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Certificados SSL
• Administración de Finesse
• administración de Windows Server
• Análisis de captura de paquetes con Wireshark

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software:

• Unified Contact Center Express (UCCX) 11.X
• Finesse 11.X

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.

Antecedentes

Estas son las condiciones para que se produzca el error:

• Suponga que la cadena de confianza del certificado se carga en Finesse
• Asegúrese de reiniciar los servidores/servicios correctos
• Suponga que el gadget se ha agregado al diseño Finesse con una URL HTTPS y que la URL es accesible

Este es el error observado cuando el agente inicia sesión en Finesse:

"Se han producido problemas al procesar este gadget. javax.net.ssl.SSLPeerUnverifyException: peer not authenticated"

Problemas

Escenario 1: El servidor de alojamiento negocia TLS inseguro

Cuando Finesse Server realiza una solicitud de conexión al servidor de alojamiento, Finesse Tomcat anuncia una lista de cifrados que admite.

Algunos códigos no se admiten debido a vulnerabilidades de seguridad,

Si el servidor de alojamiento selecciona cualquiera de estos códigos, se rechaza la conexión:

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Se sabe que estos cifrados utilizan claves Diffie-Hellman efímeras débiles cuando negocia la conexión, y la vulnerabilidad Logjam hace que estas sean una mala elección para las conexiones TLS.

Siga el proceso de intercambio de señales TLS en una captura de paquetes para ver qué cifrado se negocia.

1. Finesse presenta su lista de cifras admitidas en el paso Client Hello:

2. Para esta conexión, TLS_DHE_RSA_WITH_AES_256_CBC_SHA fue seleccionado por el servidor de alojamiento durante el paso Server Hello porque es superior en su lista de cifrados preferidos.

3. Finesse envía una alerta fatal y finaliza la conexión:

Solución

Para evitar el uso de estos cifrados, el servidor de alojamiento debe configurarse para darles una prioridad baja, o deben eliminarse completamente de la lista de cifrados disponibles. Esto se puede hacer en Windows Server con el editor de directivas de grupo de Windows (gpedit.msc).

Nota: Para obtener más detalles sobre los efectos de Logjam en Finesse y el uso de gpedit, consulte:

Escenario 2: El certificado tiene un algoritmo de firma no admitido

Las autoridades de certificados de Windows Server pueden utilizar estándares de firma más recientes para firmar certificados. Incluso ofrece mayor seguridad que SHA, la adopción de estos estándares fuera de los productos de Microsoft es escasa y es probable que los administradores se enfrenten a problemas de interoperabilidad.

Finesse Tomcat se basa en el proveedor de seguridad SunMSCAPI de Java para habilitar el soporte para los diversos algoritmos de firma y funciones criptográficas que utiliza Microsoft. Todas las versiones actuales de Java (1.7, 1.8 y 1.9) admiten sólo estos algoritmos de firma:

• MD5withRSA
• MD2withRSA
• NONEwithRSA
• SHA1withRSA
• SHA256withRSA
• SHA384withRSA
• SHA512withRSA

Es una buena idea verificar la versión de Java que se ejecuta en el servidor Finesse para confirmar qué algoritmos se soportan en esa versión. La versión se puede verificar desde el acceso raíz con este comando: versión de Java

Nota: Para obtener más detalles sobre el proveedor Java SunMSCAPI, consulte https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunMSCAPI

Si se proporciona un certificado con una firma distinta de las enumeradas anteriormente, Finesse no puede utilizar el certificado para crear una conexión TLS con el servidor de alojamiento. Esto incluye certificados firmados con un tipo de firma compatible pero emitidos por autoridades de certificados que tienen sus propios certificados intermedios y raíz firmados con otra cosa.

Si observa una captura de paquetes, Finesse cierra la conexión con una "alerta fatal: Error "Certificado desconocido", como se muestra en la imagen.

En este punto es necesario verificar los certificados presentados por el servidor de alojamiento y buscar algoritmos de firma no admitidos. Es común ver RSASSA-PSS como el algoritmo de firma problemático:

Si algún certificado de la cadena está firmado con RSASSA-PSS, la conexión falla. En este caso, la captura de paquetes muestra que la CA raíz utiliza RSASSA-PSS para su propio certificado: 

Solución

Para resolver este problema, se debe emitir un nuevo certificado de un proveedor de CA que sólo utilice uno de los tipos de firma SunMSCAPI admitidos enumerados en toda la cadena de certificados como se explicó anteriormente. 

Nota: Para obtener más detalles sobre el algoritmo de firma RSASSA-PSS, consulte https://pkisolutions.com/pkcs1v2-1rsassa-pss/

Nota: Este problema se rastrea en el defecto CSCve79330