Especificación del protocolo de transporte troncal TLS

Requisitos

Para configurar una troncal segura para BYOC Cloud, su operador o proveedor de telefonía también debe admitir conexiones VoIP seguras con SIP utilizando TLS sobre TCP y SRTP. BYOC Cloud no es compatible con IPSEC para troncales seguros. La configuración de un troncal seguro BYOC Cloud es similar a la de un troncal no seguro, con sólo unos pocos ajustes alternativos. Sin embargo, las troncales seguras tienen otros requisitos para que la conexión se realice correctamente.

Conexiones

El dispositivo de origen de la llamada inicia las conexiones VoIP. Sin embargo, ambos puntos finales de VoIP actúan como servidores y clientes. Configure una conexión TLS segura para ambos puntos finales tanto para las llamadas originarias (entrantes) como para las terminadas (salientes). Ambos extremos de VoIP deben tener un certificado X.509 firmado por una autoridad de certificación pública y cada extremo de cliente debe confiar en la autoridad de certificación que firmó el servidor.Ambas conexiones utilizan TLS unidireccional o del lado del servidor, pero no se admite TLS mutuo (MTLS).

Las troncales seguras para BYOC Cloud se conectan a los mismos puntos finales de VoIP que las contrapartes no seguras. Para obtener más información sobre estas direcciones de conexión, consulte Direcciones IP SIP públicas de BYOC Cloud.

Puertos y versiones de protocolo

BYOC Cloud sólo admite terminales que utilicen el protocolo TLS versión 1.2. Las escuchas sólo TLS están disponibles en el puerto 5061 del host. 

Los cifrados TLS compatibles incluyen:

• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA*
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256*
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*

Los siguientes cifradores TLS siguen siendo compatibles, pero se prevé que queden obsoletos en una futura versión.

• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384*

* Para los intercambios de claves efímeras Diffie-Hellman de curva elíptica (ECDHE) sólo se admiten las curvas elípticas secp384r1 (curva NIST/SECG sobre un campo primo de 384 bits).

Certificado de confianza

Cuando el cliente crea una conexión segura a un servidor, verifica la validez del certificado. El certificado autoriza la legitimidad de la clave contenida. Un certificado válido se adhiere a lo siguiente:

Autoridad certificada

Una autoridad certificadora acreditada debe emitir el certificado para que sea válido.

Los puntos finales del cliente deben confiar en los puntos finales BYOC Cloud. Genesys Cloud firma los puntos finales de BYOC Cloud con certificados X.509 emitidos por DigiCert, una autoridad de certificación pública. Más concretamente, la autoridad de certificación raíz que firma los puntos finales de BYOC Cloud está separada por regiones y utiliza certificados autorizados por DigiCert High Assurance EV Root CA o DigiCert Global Root G2/DigiCert Global Root G3. Puede descargar el certificado de clave pública raíz adecuado para su región desde DigiCert.

Certificados raíz

Genesys Cloud regenera o sustituye los certificados de punto final de BYOC Cloud cuando cambia la clave privada. Es importante no confiar en el certificado del servidor en sí, ya que podría cambiar sin previo aviso. Configure los puntos finales del cliente para que confíen en el certificado raíz para evitar problemas. En caso de que cambie el certificado raíz, aparecerán notificaciones de caducidad en las notas de la versión de Genesys Cloud .

Formatos de archivos de certificado

Los certificados de CA raíz están disponibles en dos formatos de archivo diferentes: DER y PEM. Ambos formatos de archivo contienen los mismos datos, pero difieren en la forma de codificarlos. Descargue únicamente el formato de archivo que mejor se adapte a su sistema.

• Un certificado DER se codifica utilizando el método Distinguished Encoding Rules (DER), que es un formato binario. Los certificados DER están pensados para su uso en sistemas basados en Java.
• Un certificado PEM se codifica utilizando el método de correo de privacidad mejorada (PEM), que es un formato codificado en base64. Los certificados PEM están pensados para su uso en sistemas basados en Unix.

Autoridades de certificación por región

Los puntos finales de BYOC Cloud también deben confiar en los puntos finales del cliente. Para que los puntos finales de BYOC Cloud confíen en los puntos finales del cliente, una de estas autoridades de certificación pública debe firmar los puntos finales del cliente:

• Actalis
• Servicios de confianza de Amazon
• Certum
• Deutsche Telekom / T-TelSec
• DigiCert / QuoVadis / Symantec / Thawte / Verisign 
• Entrust / SSL.com
• GlobalSign
• Go Daddy / Starfield 
• Harica
• IdenTrust
• Grupo de Investigación sobre Seguridad en Internet
• Soluciones de red
• Sectigo / AddTrust / Comodo / UserTrust
• SwissSign
• Telia / TeliaSonera 
• Trustwave / Confianza Segura / Viking Cloud

Todos los puntos finales remotos que reciban conexiones seguras SIP TLS de los servidores SIP de BYOC Cloud deben estar configurados con un certificado. Este certificado está firmado por él mismo o, lo que es más habitual, por una autoridad de certificación intermedia emitida por una de las autoridades de certificación raíz en las que confían los servidores SIP BYOC Cloud de Genesys Cloud. Si el certificado no está firmado, la conexión fallará. El punto final remoto debe presentar su certificado de entidad final, así como todas las autoridades de certificación intermedias en el protocolo TLS.

Apretón de manos TLS con confianza intermedia

TLS utiliza un protocolo de enlace para negociar la conexión segura entre los dos puntos finales. El protocolo de enlace comparte tanto los certificados públicos como los requisitos específicos de la conexión. El cliente inicia el protocolo de enlace y solicita una conexión segura del servidor. El servidor debe proporcionar tanto su propio certificado firmado como todos los certificados intermedios en la cadena de certificados.

Los extremos de BYOC Cloud proporcionan su propio certificado de servidor y todos los certificados intermedios de la cadena de certificados cuando actúan como servidor durante el protocolo TLS. Los puntos finales del cliente sólo deben confiar en la autoridad de certificación raíz DigiCert mencionada anteriormente.

Los puntos finales de BYOC Cloud solo confían en los certificados de la autoridad de certificación raíz de los proveedores enumerados anteriormente. Los puntos finales del cliente deben proporcionar tanto su propio certificado de servidor como todos los certificados de autoridad de certificación intermedios en la cadena de certificados cuando actúan como el servidor durante el protocolo de enlace de TLS.

Validación del nombre del sujeto

Un certificado válido debe contener el nombre del sujeto de la ubicación a la que se conectó el cliente (URI).

Un cliente de una conexión segura utiliza la validación del nombre del sujeto para asegurarse de que el punto final remoto se identifica a sí mismo como el objetivo esperado. Si un certificado de servidor no contiene el nombre al que está conectado el cliente como el nombre común o el nombre alternativo del sujeto, entonces el cliente debe rechazar esa conexión.

Para garantizar que la validación del nombre del sujeto se realice correctamente, las conexiones a BYOC Cloud utilizan la siguiente tabla como una lista de posibles puntos finales.

• Américas
• EMEA
• Asia Pacífico

Las autoridades de certificación públicas deben firmar los certificados X.509 del punto final del cliente con el nombre común o el nombre alternativo del sujeto utilizado como valor de servidores SIP o Proxies de la troncal. El punto final BYOC valida la conexión por el nombre de host; una dirección IP no es aceptable. Para obtener más información sobre los troncales BYOC Cloud, consulte Crear un tronco BYOC Cloud.

Validación de fecha

Un certificado válido debe estar dentro del periodo de validez de la fecha y no haber sobrepasado la fecha de caducidad.

Los certificados X.509 tienen un período de validez, que es un rango de fechas que especifica cuándo el certificado es aceptable. En una fecha cercana o en la fecha de vencimiento, Genesys Cloud renueva el certificado del endpoint con un nuevo certificado que incluye un período de validación extendido.

Certificado lista de revocación

Un certificado válido debe ser un certificado emitido activamente y no estar incluido en la lista de revocación de las autoridades.

Cuando una autoridad de certificación pública firma certificados X.509, incluye una dirección de una lista de revocación de certificados. La autoridad de certificación pública puede revocar un certificado antes del período de vencimiento agregándolo a una lista de revocación. El cliente seguro comprueba la lista de revocación cuando establece una conexión y confirma que el certificado es válido. Una autoridad de certificación pública normalmente revoca un certificado público de punto final si la seguridad del par de claves se ve comprometida.

URI de SIP

El URI SIP es un mecanismo que conecta un punto final VoIP. Cada extremo de VoIP tiene un URI de SIP correspondiente para conectarse al par remoto respectivo. El URI contiene la dirección remota del dispositivo SIP en forma de nombre de host DNS que incluye el protocolo, el número de destino y el host remoto.

Además del nombre del host, el URI también puede contener atributos para controlar la conexión. Aplica atributos a la parte del usuario y la parte del host del URI. Para que el URI funcione correctamente, debe aplicar atributos a la parte correspondiente del URI.  

Los atributos primarios especifican la selección de troncales y el protocolo de transporte. En conexiones seguras, el atributo de transporte especifica el protocolo de transporte TLS.

Para obtener más información, consulte la sección Inbound de Configurar el enrutamiento SIP para un tronco BYOC Cloud.

Enrutamiento SIP entrante

Cuando usa SIP seguro para BYOC Cloud usando TLS, Genesys Cloud recomienda que use un conjunto de URI distintos para cada proxy que usa el TGRP para el enrutamiento SIP entrante. Sin embargo, hay algunas otras opciones que debe considerar al seleccionar un método de enrutamiento entrante:

TGRP (Protocolo de enrutamiento de grupo de troncales)

La mejor práctica es utilizar una configuración TGRP ya que permite la selección de troncales basada en los atributos del SIP URI. Los atributos TGRP controlan el enrutamiento, de modo que el nombre de host del URI de la solicitud se establece en un valor definido como el nombre común o el nombre alternativo del asunto del certificado X.509. Esta configuración permite que la validación del nombre del asunto se realice correctamente.

DNIS (Servicio de identificación de número marcado)

El enrutamiento DNIS puede funcionar con troncales BYOC Cloud seguras; sin embargo, la validación del nombre del sujeto puede limitar la viabilidad de esta opción de enrutamiento. Por lo general, usa el enrutamiento DNIS cuando el operador limita el control del URI SIP y, en su lugar, prefiere una dirección IP. Si las llamadas se envían directamente a una dirección IP en lugar de a un nombre de host compatible, falla la validación del nombre de asunto de los certificados X.509.

FQDN (nombre de dominio completo)

FQDN puede funcionar con troncales Secure BYOC Cloud; sin embargo, no se espera que se apruebe la validación del nombre de sujeto del certificado X.509 porque los FQDN son definidos por el usuario. Los certificados comodín pueden admitir los nombres definidos por el usuario, pero no se utilizan debido a la falta de compatibilidad con algunos dispositivos SIP.

Los registros SRV para TLS están disponibles y los certificados de proxy contienen el nombre de dominio SRV y el nombre del registro SRV. Sin embargo, las autoridades de certificación públicas no permiten el uso de caracteres de subrayado en nombres comunes y nombres alternativos de sujeto que se utilizan en los registros SRV para los nombres de servicio y transporte. Si el dispositivo SIP remoto valida el nombre común del certificado, solo valida el nombre de dominio. No valida el nombre completo del registro de recursos, que incluye el servicio y el transporte.

Para obtener más información, consulte la sección Inbound de Configurar el enrutamiento SIP para un tronco BYOC Cloud.

Ejemplos de

Para ayudarlo a configurar correctamente su URI de SIP, el siguiente ejemplo es para una conexión usando TGRP. Este ejemplo muestra todas las entradas de host requeridas actualmente que se utilizan para distribuir llamadas entre cada uno de los servidores proxy BYOC SIP. También muestra el nombre de host FQDN de cada proxy que se utiliza para pasar la validación del nombre de sujeto del certificado X.509. El protocolo se proporciona para garantizar que el punto final remoto inicie una conexión segura.

Cuando selecciona TLS como protocolo de transporte troncal para BYOC Premises, establece troncales seguras utilizando TLS sobre TCP directamente entre el punto final del cliente y Genesys Cloud Edge. Una autoridad de certificación específica de la organización emite un certificado de servidor que firma cada punto final de Genesys Cloud Edge TLS. La autoridad de certificación raíz de su organización es el certificado válido que gestiona el servicio SIP.

Puede obtener el certificado de clave pública para su organización desde Genesys Cloud. Para más información, ver Configurar autoridades de certificación.

Puede ajustar la configuración de seguridad de medios y transporte en la configuración de troncal externa. Para más información, ver Configuración de tronco externo.