¿Tiene una cuenta?
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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 tener acceso a la página de administración del sistema operativo (OS) para estas aplicaciones:
Un administrador también debe tener acceso al almacén de certificados en los PC del agente y del cliente supervisor.
Es necesario que todos los servidores de la configuración de UCCX se instalen con servidores DNS y nombres de dominio. También es necesario que los agentes, supervisores y administradores accedan a las aplicaciones de configuración de UCCX mediante el nombre de dominio completo (FQDN).
UCCX versión 10.0+ requiere que el nombre de dominio y los servidores DNS se rellenen tras la instalación. Los certificados generados por el instalador de la versión 10.0+ de UCCX contienen el FQDN, según corresponda. Agregue los servidores DNS y un dominio al clúster UCCX antes de actualizar a la versión 10.0+ de UCCX.
Si el dominio cambia o se rellena por primera vez, los certificados deben regenerarse. Después de agregar el nombre de dominio a la configuración del servidor, vuelva a generar todos los certificados Tomcat antes de instalarlos en las otras aplicaciones, en los exploradores del cliente o en la generación de 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:
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.
Con la introducción de Finesse y CUIC co-residentes, la integración entre UCCX y SocialMiner para el correo electrónico y el chat, y el uso de MediaSense para grabar, entender e instalar certificados a través de Finesse, la capacidad de resolver problemas de certificados es ahora de vital importancia.
Este documento describe el uso de certificados firmados y autofirmados en el entorno de configuración de UCCX que abarca:
Los certificados, ya sean firmados o autofirmados, deben instalarse tanto en las aplicaciones (servidores) de la configuración de UCCX como en los escritorios cliente de agente y supervisor.
En Unified Communications Operating System (UCOS) 10.5, se agregaron certificados de varios servidores para que se pudiera generar una CSR única para un clúster en lugar de tener que firmar un certificado individual para cada nodo del clúster. Este tipo de certificado no se admite explícitamente para UCCX, MediaSense y SocialMiner.
En esta sección se describe cómo configurar UCCX para el uso de certificados autofirmados y firmados.
Arquitectura de solución UCCX válida a partir de UCCX 11.0. Diagrama de comunicación HTTPS.
El método recomendado de administración de certificados para la configuración de UCCX es aprovechar los certificados firmados. Estos certificados pueden ser firmados por una Autoridad de Certificación interna (CA) o por una CA de terceros conocida.
En los exploradores principales, como Mozilla Firefox e Internet Explorer, los certificados raíz para las CA conocidas de terceros se instalan de forma predeterminada. Los certificados para las aplicaciones de configuración UCCX firmadas por estas CA son de confianza de forma predeterminada, ya que su cadena de certificados finaliza 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 a través de una directiva de grupo u otra configuración actual.
Puede elegir si desea que los certificados de aplicación de configuración de UCCX estén firmados por una CA de terceros conocida o por una CA interna basada en la disponibilidad y preinstalación del certificado raíz para las CA en el navegador cliente.
Complete estos pasos para cada nodo de las aplicaciones UCCX Publisher y Subscriber, SocialMiner y MediaSense Publisher y Subscriber Administration:
Envíe el nuevo CSR a la CA de terceros o firme con una CA interna, como se ha descrito anteriormente. Este proceso debe producir estos certificados firmados:
Nota: Deje el campo Distribution en el CSR como FQDN del servidor.
Nota: El certificado "Multi-Server (SAN)" es compatible con UCCX a partir de la versión 11.6. Sin embargo, la SAN debe incluir solamente el Nodo 1 y el Nodo 2 de UCCX. Otros servidores, como SocialMiner, no deben incluirse en la SAN de 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 intermedio en un editor (UCCX o MediaSense), se deben replicar automáticamente al suscriptor. No es necesario cargar los certificados raíz o intermedios en los otros servidores que no sean editores de la configuración si todos los certificados de aplicación se firman a través de la misma cadena de certificados.
Nota: Si una CA subordinada firma el certificado, cargue el certificado raíz de la CA subordinada como el certificado tomcat-trust en lugar del certificado raíz. Si se emite un certificado intermedio, cargue este certificado en el almacén tomcat-trust además del certificado de aplicación.
Nota: Cuando utiliza UCCX, MediaSense y SocialMiner 11.5 y posteriores, hay un nuevo certificado llamado tomcat-ECDSA. Cuando carga un certificado tomcat-ECDSA firmado en el servidor, carga el certificado de aplicación como certificado tomcat-ECDSA, no como certificado tomcat. Para obtener más información sobre ECDSA, consulte la Sección de Información Relacionada para ver el enlace para comprender y configurar los certificados ECDSA.
Todos los certificados que se utilizan en la configuración de 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 navegador cliente u otra aplicación de configuración. Aunque se recomienda firmar todos los certificados en la configuración de 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 política de grupo o un administrador de paquetes, o instálelos individualmente en el navegador de cada equipo agente.
Para Internet Explorer, instale los certificados autofirmados del cliente en el almacén Autoridades de certificación raíz de confianza.
Para Mozilla Firefox, complete estos pasos:
En el caso de que caduquen los certificados autofirmados, deberán regenerarse y los pasos de configuración de Instalación en Servidores Periféricos deberán realizarse de nuevo.
UCCX utiliza los servicios web MediaSense REST Application Programming Interface (API) para dos fines:
UCCX utiliza la API REST en los nodos de administración de MediaSense. Hay un máximo de dos en cualquier clúster de MediaSense. UCCX no se conecta a través de la API REST a los nodos de expansión MediaSense. Ambos nodos UCCX deben consumir la API REST de MediaSense, por lo que instale los dos certificados Tomcat de MediaSense en ambos nodos UCCX.
Cargue la cadena de certificados firmados o autofirmados de los servidores MediaSense en el almacén de claves tomcat-trust UCCX.
MediaSense utiliza la API REST de servicios web Finesse para autenticar agentes para el gadget MediaSense Search y Play en Finesse.
El servidor MediaSense configurado en el diseño XML de Finesse para el gadget Buscar y ejecutar debe utilizar la API REST de Finesse, de modo que instale los dos certificados Tomcat de UCCX en ese nodo MediaSense.
Cargue la cadena de certificados firmados o autofirmados de los servidores UCCX en el almacén de claves MediaSense tomcat-trust.
UCCX utiliza las API de notificación y REST 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 el servicio de notificación de SocialMiner debe notificarla, por lo que instale 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 tomcat-trust UCCX.
El certificado de cliente UCCX AppAdmin se utiliza para la administración del sistema UCCX. Para instalar el certificado AppAdmin de UCCX para los administradores de UCCX, en el equipo cliente, navegue a 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 exploradores de clientes. Para instalar el certificado de plataforma UCCX para agentes y supervisores UCCX, en el equipo cliente, navegue a 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 CCX para enviar información en tiempo real al escritorio del cliente a través de Extensible Messaging and Presence Protocol (XMPP). Esto se utiliza para la comunicación en tiempo real con Finesse, así como para CUIC Live Data.
Para instalar el certificado de cliente del servicio de notificación en el equipo de los agentes y supervisores o usuarios de informes que utilizan datos en directo, navegue hasta 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 Finesse Tomcat a efectos de la comunicación de la API REST entre el escritorio y el servidor Finesse coresidente.
Para instalar el certificado Finesse para agentes y supervisores, en el equipo cliente, navegue a 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 a 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 se debe instalar en el equipo cliente. Una vez que un agente acepta una solicitud de chat, el gadget Chat se redirige a una dirección URL que representa la sala de chat. Esta sala de chat está alojada en el servidor de SocialMiner y contiene el cliente o contacto de chat.
Para instalar el certificado de SocialMiner en el explorador, en el equipo cliente, navegue hasta https://<FQDN de SocialMiner>/ e instale el certificado a través de las indicaciones del explorador.
El certificado de Tomcat CUIC se debe instalar en el equipo cliente para agentes, supervisores y usuarios de informes que utilicen la interfaz web de CUIC para informes históricos o informes de datos en directo, bien en la página web de CUIC o en los gadgets del escritorio.
Para instalar el certificado de CUIC Tomcat en el navegador, en el equipo cliente, navegue a https://<UCCX FQDN>:844/ e instale el certificado a través de las indicaciones del navegador.
Certificado de datos en directo de CUIC (desde 11.x)
El CUIC utiliza el servicio Socket IO para los datos en directo del motor. Este certificado se debe instalar en el equipo cliente para los 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 en Finesse.
Para instalar el certificado Socket IO en el navegador, en el equipo cliente, navegue a https://<UCCX FQDN>:12015/ e instale el certificado a través de las indicaciones del navegador.
Si se diseña una secuencia de comandos UCCX para acceder a una ubicación segura en un servidor de terceros (por ejemplo, Get URL Document step to a HTTPS URL o Make Rest Call to a HTTPS REST URL), cargue la cadena de certificados firmada o autofirmada del servicio de terceros en el tomcat-trust UCCX. Para obtener este certificado, acceda a la página Administración del sistema operativo UCCX y elija Cargar certificado.
UCCX Engine se configura para buscar la plataforma Tomcat keystore para cadenas de certificados de terceros cuando las aplicaciones de terceros presentan estos certificados cuando acceden a ubicaciones seguras a través de pasos de script.
Toda la cadena de certificados se debe cargar en la plataforma Tomcat keystore, a la que se puede acceder a través de la página Administración del sistema operativo, ya que el almacén de claves Tomcat no contiene certificados raíz de forma predeterminada.
Después de completar estas acciones, reinicie Cisco UCCX Engine.
Para verificar que todos los certificados están instalados correctamente, puede probar las funciones descritas en esta sección. Si no aparecen errores de certificado y todas las funciones 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 el certificado SAN no coincide".
Es posible que la CA haya agregado otro dominio principal en el campo Nombres alternativos de asunto (SAN) del certificado. De forma predeterminada, el CSR tendrá estas SAN:
SubjectAltName [
example.com (dNSName)
hostname.ejemplo.com (dNSName)
]
Las CA podrían devolver un certificado con otra SAN agregada al certificado: www.hostname.example.com. El certificado tendrá una SAN adicional en este caso:
SubjectAltName [
example.com (dNSName)
hostname.ejemplo.com (dNSName)
www.hostname.example.com (dNSName)
]
Esto causa el error de discordancia SAN.
En la sección "Nombre alternativo del sujeto (SAN)" de la página "Generar solicitud de firma de certificado" de UCCX, genere la CSR con un campo de dominio principal vacío. De esta manera, la CSR no se genera con un atributo SAN, la CA puede formatear las SAN y no habrá una discordancia de atributo SAN cuando cargue el certificado en UCCX. Tenga en cuenta que el campo Dominio principal se asigna de forma predeterminada al dominio del servidor UCCX, por lo que el valor se debe quitar explícitamente mientras se configuran los parámetros de CSR.
Cuando accede a cualquier página web de UCCX, MediaSense o SocialMiner, recibe un mensaje de error.
"Su conexión no es privada.
Los atacantes podrían estar intentando robar su información de <Server_FQDN> (por ejemplo, contraseñas, mensajes o tarjetas de crédito). NET::ERR_CERT_COMMON_NAME_INVALID
Este servidor no pudo probar que es <Server_FQDN>; su certificado de seguridad es de [missing_subjectAltName]. Esto puede deberse a una configuración incorrecta o a un atacante que intercepte su conexión."
La versión 58 de Chrome introdujo una nueva función de seguridad en la que 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 SAN.
Consulte la sección "Eliminar compatibilidad para la coincidencia de nombre común en certificados" en Deprecations and Removals in Chrome 58.