El conjunto de documentos para este producto aspira al uso de 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 de raza, identidad étnica, orientación sexual, nivel socioeconó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 configurar Cisco Unified Contact Center Express (UCCX) para el uso de certificados autofirmados y firmados.
Antes de continuar con los pasos de configuración descritos en este documento, asegúrese de que tiene acceso a la página de administración del sistema operativo (SO) para estas aplicaciones:
Un administrador también puede tener acceso al almacén de certificados en los equipos cliente agente y supervisor.
Es necesario que todos los servidores de la configuración UCCX se instalen con servidores DNS (Sistema de nombres de dominio) y nombres de dominio. También es necesario que los agentes, supervisores y administradores accedan a las aplicaciones de configuración UCCX mediante el nombre de dominio completo (FQDN).
Si el dominio cambia o se rellena por primera vez, los certificados se pueden volver a generar. Después de agregar el nombre de dominio a la configuración del servidor, regenere todos los certificados Tomcat antes de instalarlos en las otras aplicaciones, en los exploradores del cliente o tras generar la solicitud de firma de certificado (CSR) para la firma.
La información descrita en este documento se basa en estos componentes de hardware y software:
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Con la introducción de Finesse y CUIC, la integración entre UCCX y SocialMiner para el correo electrónico y el chat, y el uso de MediaSense para registrar, comprender e instalar certificados a través de Finesse, la capacidad de solucionar problemas de certificados es ahora de vital importancia.
Este documento describe el uso de certificados autofirmados y firmados en el entorno de configuración UCCX que cubre:
Los certificados, firmados o autofirmados, deben instalarse tanto en las aplicaciones (servidores) de la configuración UCCX como en los escritorios de los clientes agente y supervisor.
La compatibilidad con varias SAN se añadió en UCCX a partir de la versión 11.6.2.
Públicamente, se requieren certificados de CA firmados en SomicalMiner/CCP para que el chat externo funcione a través de Internet.
En esta sección se describe cómo configurar UCCX para el uso de certificados autofirmados y firmados.
El método recomendado de administración de certificados para la configuración UCCX es aprovechar los certificados firmados. Estos certificados pueden estar firmados por una autoridad de certificación (CA) interna o por una CA de terceros conocida.
En los exploradores principales, como Mozilla Firefox y Microsoft Edge, los certificados raíz para entidades emisoras de certificados de terceros conocidas se instalan de forma predeterminada. Los certificados de las aplicaciones de configuración UCCX firmados por estas CA son de confianza de forma predeterminada, ya que su cadena de certificados termina en un certificado raíz que ya está instalado en el explorador.
El certificado raíz de una CA interna también se puede preinstalar en el explorador cliente mediante una directiva de grupo u otra configuración actual.
Puede elegir si desea que los certificados de la aplicación de configuración UCCX estén firmados por una CA de terceros conocida o por una CA interna en función de la disponibilidad y la preinstalación del certificado raíz de las CA en el explorador cliente.
Complete estos pasos para cada nodo de las aplicaciones de administración de editor y suscriptor de UCCX, SocialMiner y editor y suscriptor de MediaSense:
Envíe la nueva CSR a la CA de terceros o fírmela con una CA interna, como se ha descrito anteriormente. Este proceso puede producir estos certificados firmados:
Nota: deje el campo Distribución en el CSR como FQDN del servidor.
Nota: el certificado de varios servidores (SAN) es compatible con UCCX a partir de la versión 11.6. Sin embargo, la SAN solo puede incluir el nodo 1 y el nodo 2 de UCCX. Otros servidores, como SocialMiner, no se pueden incluir en la SAN de UCCX. Consulte en la parte inferior de la página el ejemplo de SAN de CUCM, que también es válido para UCCX.
Nota: UCCX sólo admite longitudes de clave de certificado de 1024 y 2048 bits.
Complete estos pasos en cada servidor de aplicaciones para cargar el certificado raíz y el certificado de aplicación en los nodos:
Nota: Si carga los certificados raíz e intermedios en un editor (UCCX o MediaSense), se pueden replicar automáticamente en el suscriptor. No es necesario cargar los certificados raíz o intermedios en los otros servidores que no son editores de la configuración si todos los certificados de aplicación están firmados a través de la misma cadena de certificados.
Nota: si una entidad emisora de certificados subordinada firma el certificado, cargue el certificado raíz de la entidad emisora de certificados subordinada como certificado de confianza tomcat en lugar del certificado raíz. Si se emite un certificado intermedio, cargue este certificado en el almacén de confianza de tomcat además del certificado de aplicación.
Nota: cuando utiliza UCCX y SocialMiner 11.5, hay un nuevo certificado denominado tomcat-ECDSA. Al cargar un certificado firmado de tomcat-ECDSA en el servidor, cargue el certificado de aplicación como un certificado de tomcat-ECDSA, no como un certificado de tomcat. Para obtener más información sobre ECDSA, consulte la Sección Información Relacionada para obtener el enlace para comprender y configurar los certificados ECDSA. A partir de la versión 11.6, el uso de certificados ECDSA se ha eliminado por completo de la solución UCCX. Esto incluye UCCX, SM/CCP, CUIC y Finesse.
Todos los certificados que se utilizan en la configuración UCCX vienen preinstalados en las aplicaciones de configuración y se firman automáticamente. Estos certificados autofirmados no son de confianza implícita cuando se presentan a un explorador cliente u otra aplicación de configuración. Aunque se recomienda firmar todos los certificados de la configuración UCCX, puede utilizar los certificados autofirmados preinstalados.
Para cada relación de aplicación, debe descargar el certificado correspondiente y cargarlo en la aplicación. Complete estos pasos para obtener y cargar los certificados:
Para instalar certificados autofirmados en el equipo cliente, utilice una directiva de grupo o un administrador de paquetes, o instálelos individualmente en el explorador de cada equipo agente.
Para Microsoft Edge, instale los certificados autofirmados del lado del cliente en el almacén Trusted Root Certification Authorities.
Para Mozilla Firefox, siga estos pasos:
En caso de que caduquen los certificados autofirmados, es necesario volver a generarlos y realizar de nuevo los pasos de configuración de Instalación en servidores periféricos.
UCCX utiliza las API REST y Notification de SocialMiner para administrar los contactos de correo electrónico y la configuración. Ambos nodos UCCX deben consumir la API REST de SocialMiner y recibir una notificación del servicio de notificación de SocialMiner, por lo que debe instalar el certificado Tomcat de SocialMiner en ambos nodos UCCX.
Cargue la cadena de certificados firmados o autofirmados del servidor de SocialMiner en el almacén de claves UCCX tomcat-trust.
Cargue el certificado tomcat de UCCX desde los nodos de editor y suscriptor al servidor de SocialMiner como almacén de claves tomcat-trust.
El certificado de cliente de UCCX AppAdmin se utiliza para la administración del sistema UCCX. Para instalar el certificado de UCCX AppAdmin para administradores UCCX, en el equipo cliente, navegue hasta https://<UCCX FQDN>/appadmin/main para cada uno de los nodos UCCX e instale el certificado a través del navegador.
Los servicios web de UCCX se utilizan para la entrega de contactos de chat a los navegadores cliente. Para instalar el certificado de plataforma UCCX para agentes y supervisores UCCX, en el equipo cliente, navegue hasta https://<UCCX FQDN>/appadmin/main para cada uno de los nodos UCCX e instale el certificado a través del navegador.
Finesse, UCCX y CUIC utilizan el servicio de notificación de CCX para enviar información en tiempo real al escritorio del cliente a través del protocolo extensible de mensajería y presencia (XMPP). Se utiliza para la comunicación Finesse en tiempo real, así como para datos en directo de CUIC.
Para instalar el certificado de cliente del servicio de notificación en el equipo de los agentes y supervisores o de los usuarios de informes que utilizan datos en directo, vaya a https://<UCCX FQDN>:7443/ para cada uno de los nodos UCCX e instale el certificado a través del explorador.
Los escritorios Finesse utilizan el certificado de cliente Finesse para conectarse a la instancia de Tomcat Finesse con el fin de la comunicación API REST entre el escritorio y el servidor Finesse co-residente.
Para instalar el certificado Finesse para agentes y supervisores, en el equipo cliente, navegue hasta https://<UCCX FQDN>:8445/ para cada uno de los nodos UCCX e instale el certificado a través de las indicaciones del navegador.
Para instalar el certificado Finesse para los administradores de Finesse, en el equipo cliente, navegue hasta https://<UCCX FQDN>:8445/cfadmin para cada uno de los nodos UCCX e instale el certificado a través de las indicaciones del navegador.
El certificado Tomcat de SocialMiner debe estar instalado en el equipo cliente. Una vez que un agente acepta una solicitud de chat, el gadget Chat se redirige a una URL que representa la sala de chat. Esta sala de chat se aloja en el servidor de SocialMiner y contiene el cliente o el contacto de chat.
Para instalar el certificado de SocialMiner en el explorador, en el equipo cliente, vaya a https://<FQDN de SocialMiner>/ e instale el certificado a través de las indicaciones del explorador.
El certificado Tomcat de CUIC se puede instalar en el equipo cliente para agentes, supervisores y usuarios de informes que utilizan la interfaz web de CUIC para informes históricos o informes de datos en directo, ya sea en la página web de CUIC o en los gadgets del escritorio.
Para instalar el certificado Tomcat de CUIC en el explorador, en el equipo cliente, navegue hasta https://<UCCX FQDN>:8444/ e instale el certificado a través de las indicaciones del explorador.
Certificado de datos en directo de CUIC (desde 11.x)
CUIC utiliza el servicio E/S de socket para los datos activos del servidor. Este certificado se puede instalar en el equipo cliente para agentes, supervisores y usuarios de informes que utilizan la interfaz web de CUIC para datos en directo o que utilizan los gadgets de datos en directo de Finesse.
Para instalar el certificado de E/S de socket en el explorador, en el equipo cliente, navegue hasta https://<UCCX FQDN>:12015/ e instale el certificado a través de las indicaciones del explorador.
Si un script UCCX está diseñado para acceder a una ubicación segura en un servidor de terceros (por ejemplo, el paso Obtener documento URL a una URL HTTPS o Realizar una llamada de descanso a una URL HTTPS REST), cargue la cadena de certificados firmada o autofirmada del servicio de terceros en el almacén de claves UCCX tomcat-trust. Para obtener este certificado, acceda a la página UCCX OS Administration y elija Upload Certificate.
El motor UCCX se configura para buscar en el almacén de claves de Tomcat de la plataforma cadenas de certificados de terceros cuando las aplicaciones de terceros les presentan estos certificados cuando acceden a ubicaciones seguras mediante pasos de secuencia de comandos.
La cadena de certificados completa debe cargarse en el almacén de claves de Tomcat de la plataforma, al que se puede acceder a través de la página Administración del SO, ya que el almacén de claves de Tomcat no contiene certificados raíz de forma predeterminada.
Una vez completadas estas acciones, reinicie el motor Cisco UCCX.
Para comprobar que todos los certificados están instalados correctamente, puede probar las características descritas en esta sección. Si no aparecen errores de certificado y todas las características funcionan correctamente, los certificados se instalan correctamente.
Los agentes de UCCX Finesse no pueden iniciar sesión con el error "ID de usuario/contraseña no válidos".
Unified CCX produce una excepción "SSLHandshakeException" y no puede establecer una conexión con Unified CM.
La carga de un certificado firmado por CA muestra el error "CSR SAN y Certificate SAN no coinciden".
La CA puede haber agregado otro dominio primario en el campo de nombres alternativos de asunto (SAN) del certificado. De forma predeterminada, CSR puede tener estas SAN:
SubjectAltName [
example.com (dNSName)
hostname.example.com (dNSName)
]
Las CA pueden devolver un certificado con otra SAN agregada al certificado: Ejemplo de nombre de host. El certificado puede tener una SAN adicional en este caso:
SubjectAltName [
example.com (dNSName)
hostname.example.com (dNSName)
www.hostname.example.com (dNSName)
]
Esto provoca el error de discordancia de SAN.
En la sección Nombre alternativo del sujeto (SAN) de la página UCCX Generate Certificate Signing Request (UCCX Generar solicitud de firma de certificado), genere el CSR con un campo Parent Domain (Dominio principal) vacío. De esta manera, la CSR no se genera con un atributo SAN, la CA puede formatear las SAN y no puede haber una discordancia de atributos SAN cuando se carga el certificado en UCCX. Observe que el campo Dominio principal toma de forma predeterminada el dominio del servidor UCCX, por lo que el valor debe eliminarse explícitamente mientras se configuran los valores para CSR.
Al acceder a cualquier página web de UCCX, MediaSense o SocialMiner, recibirá un mensaje de error.
"Su conexión no es privada. Los atacantes pueden estar intentando robar su información de <FQDN_servidor> (por ejemplo, contraseñas, mensajes o tarjetas de crédito). NET::ERR_CERT_COMMON_NAME_INVALID. Este servidor no pudo probar que es <FQDN_servidor>; su certificado de seguridad es de [missing_subjectAltName]. Esto puede deberse a un error de configuración o a que un atacante intercepte su conexión".
Chrome versión 58 introdujo una nueva función de seguridad donde se informa de que el certificado de un sitio web no es seguro si su nombre común (CN) no se incluye también como una SAN.
Vea la sección Quitar compatibilidad con coincidencia de commonName en certificados en Obsoletos y eliminaciones en Chrome 58.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
3.0 |
19-Sep-2024 |
Traducción automática y formato actualizados. |
2.0 |
20-Oct-2023 |
Texto alternativo agregado.
Título actualizado, Introducción, PII, SEO, Renuncia legal, Traducción automática, Requisitos de estilo y formato. |
1.0 |
24-Mar-2015 |
Versión inicial |