Especificación del protocolo de transporte troncal TLS

Cuando selecciona TLS como protocolo de transporte de troncales para BYOC Premises o BYOC Cloud, puede crear troncales seguras. Más específicamente, los troncales seguros para BYOC permiten que los puntos finales VoIP remotos se comuniquen con Genesys Cloud de forma segura mediante SIP TLS (SIPS) y Secure RTP (SRTP). Las llamadas VoIP seguras protegen tanto el control (señalización) como los medios (audio) de la llamada.

Para más información, ver Elija un protocolo de transporte troncal.

Advertencia: Cuando elige un protocolo de transporte de troncales, es importante que configure ambos extremos de la troncal para usar el mismo protocolo. Si no utilizan el mismo protocolo, la troncal no funciona.

Cuando selecciona TLS como protocolo de transporte de troncales para BYOC Premises, establece troncales seguras 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 administra 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.

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 mediante TLS y SRTP. BYOC Cloud no es compatible con IPSEC para troncales seguros. La configuración de un tronco BYOC Cloud seguro es similar a un tronco no seguro con solo algunas configuraciones alternativas. Los baúles seguros lo hacen; sin embargo, existen 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.

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 solo admite puntos finales que utilizan el protocolo TLS versión 1.2.

Los cifrados TLS compatibles incluyen:

  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256*
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384*

* Para intercambios de claves efímeras Diffie-Hellman (ECDHE) de curva elíptica, solo se admiten curvas elípticas secp384r1 (curva NIST/SECG sobre un campo primario de 384 bits).

Los oyentes solo de TLS están disponibles en el puerto de host 5061.

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 específicamente, la autoridad de certificación raíz que firma los puntos finales de BYOC Cloud es DigiCert High Assurance EV Root CA. Puede descargar el certificado de clave pública raíz desde DigiCert

Nota: Genesys Cloud regenera o reemplaza 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 el certificado raíz cambie, aparecerán notificaciones de baja en Genesys Cloud. Notas de lanzamiento.

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:

  • Servicios de confianza de Amazon
  • Comodo / Sectigo
  • DigiCert / Symantec / QuoVadis / Verisign
  • Confiar
  • GlobalSign
  • GoDaddy / Starfield
  • Soluciones de red
  • Telia Sonera
  • Thawte

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 puntos finales de BYOC Cloud proporcionan su propio certificado de servidor y todos los certificados intermedios en la cadena de certificados cuando actúan como servidor durante el protocolo de enlace TLS. Los puntos finales de los clientes solo deben confiar en la autoridad de certificación raíz de DigiCert indicada 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.

Advertencia: Las conexiones que no pueden validar el nombre de destino corren el riesgo de falsificación y secuestro de 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.

Este de EE. UU. / Este de EE. UU.-1

Nombre común

lb01.byoc.us-east-1.mypurecloud.com

lb02.byoc.us-east-1.mypurecloud.com

lb03.byoc.us-east-1.mypurecloud.com

lb04.byoc.us-east-1.mypurecloud.com

EE.UU. Este / us-east-2

Nombre común

lb01.voice.use2.us-gov-pure.cloud

lb02.voice.use2.us-gov-pure.cloud

lb03.voice.use2.us-gov-pure.cloud

lb04.voice.use2.us-gov-pure.cloud

Oeste de EE. UU. / Oeste de EE. UU.-2

Nombre común

lb01.voice.usw2.pure.cloud

lb02.voice.usw2.pure.cloud

lb03.voice.usw2.pure.cloud

lb04.voice.usw2.pure.cloud

Canadá (Canadá central) / ca-central-1

Nombre común

lb01.voice.cac1.pure.cloud

lb02.voice.cac1.pure.cloud

lb03.voice.cac1.pure.cloud

lb04.voice.cac1.pure.cloud

UE (Irlanda) / eu-west-1

Nombre común

lb01.byoc.eu-west-1.mypurecloud.ie

lb02.byoc.eu-west-1.mypurecloud.ie

lb03.byoc.eu-west-1.mypurecloud.ie

lb04.byoc.eu-west-1.mypurecloud.ie

UE (Londres) / eu-west-2

Nombre común

lb01.voice.euw2.pure.cloud

lb02.voice.euw2.pure.cloud

lb03.voice.euw2.pure.cloud

lb04.voice.euw2.pure.cloud

UE (Fráncfort) / eu-central-1

Nombre común

lb01.byoc.eu-central-1.mypurecloud.de

lb02.byoc.eu-central-1.mypurecloud.de

lb03.byoc.eu-central-1.mypurecloud.de

lb04.byoc.eu-central-1.mypurecloud.de

Asia Pacífico (Tokio) / ap-noreste-1

Nombre común

lb01.byoc.ap-northeast-1.mypurecloud.jp

lb02.byoc.ap-northeast-1.mypurecloud.jp

lb03.byoc.ap-northeast-1.mypurecloud.jp

lb04.byoc.ap-northeast-1.mypurecloud.jp

Asia Pacífico (Seúl) / ap-noreste-2

Nombre común

lb01.voice.euw2.pure.cloud

lb02.voice.euw2.pure.cloud

lb03.voice.euw2.pure.cloud

lb04.voice.euw2.pure.cloud

Asia Pacífico (Sydney) / ap-sureste-2

Nombre común

lb01.byoc.ap-southeast-2.mypurecloud.com.au

lb02.byoc.ap-southeast-2.mypurecloud.com.au

lb03.byoc.ap-southeast-2.mypurecloud.com.au

lb04.byoc.ap-southeast-2.mypurecloud.com.au

Asia Pacífico (Mumbai) / ap-south-1

Nombre común

lb01.byoc.aps1.pure.cloud

lb02.byoc.aps1.pure.cloud

lb03.byoc.aps1.pure.cloud

lb04.byoc.aps1.pure.cloud

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 período de validez de la fecha y no más allá de la fecha de vencimiento.

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.

Advertencia: Las conexiones de red seguras fallan si el certificado activo ha caducado o aún no es válido.

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.

Advertencia: Si no configura correctamente el certificado de punto final del cliente, las llamadas salientes de Genesys Cloud pueden fallar.

URI de SIP

El SIP URI es un mecanismo que conecta un punto final de 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 un nombre de host DNS que incluye el protocolo, el número de destino y el host remoto.

Además del nombre de 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.

Atributo Ubicación del atributo Descripción Valores
Transporte Anfitrión Protocolo de transporte UDP | TCP | TLS
TGRP Usuario Etiqueta de grupo de troncales Identificador de terminación SIP entrante definido por el usuario
Contexto del tronco Usuario Espacio de nombres del grupo de troncales Espacio de nombres específico de la región

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 de TGRP, ya que permite la selección de troncales en función de los atributos del URI de SIP. Los atributos de TGRP controlan el enrutamiento, por lo que el nombre de host del URI de solicitud se establece en un valor definido como el nombre común o el nombre alternativo del sujeto del certificado X.509. Esta configuración permite que la validación del nombre del sujeto tenga éxito.

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

El enrutamiento DNIS puede funcionar con troncales Secure BYOC Cloud; 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, la validación del nombre de sujeto de los certificados X.509 falla.

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.