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 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_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_256_CBC_SHA384*
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256*
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*
  

* For elliptic curve Diffie-Hellman ephemeral (ECDHE) key exchanges only secp384r1 (NIST/SECG curve over a 384-bit prime field) elliptical curves are supported.

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 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

Root CA certificates are available in two different file formats: DER and PEM. Both of these file formats contain the same data, but they differ in how they are encoded. Only download the file format that best suits your system.

• 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 
• 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.

The BYOC Cloud endpoints provide their own server certificate and all intermediate certificates in the certificate chain when acting as the server during the TLS handshake. The customer endpoints should only trust the DigiCert root certificate authority listed above.

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

The SIP URI is a mechanism that connects a VoIP endpoint. Each VoIP endpoint has a corresponding SIP URI to connect to the respective remote peer. The URI contains the remote address of the SIP device in the form of a DNS host name that includes the protocol, destination number, and remote host.

In addition to the host name, the URI can also contain attributes to control the connection. You apply attributes to the user portion and the host portion of the URI. For the URI to operate correctly, you must apply attributes to the appropriate portion of the 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)

The best practice is to use a TGRP configuration as it allows for trunk selection based on the attributes of the SIP URI. TGRP attributes control routing so the host name of the request URI is set to a value defined as the common name or subject alternate name of the X.509 certificate. This configuration allows the subject name validation to succeed.

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

DNIS routing may work with Secure BYOC Cloud trunks; however, subject name validation may limit the feasibility of this routing option. You typically use DNIS routing when the carrier limits control of the SIP URI and instead prefers an IP address. If calls are sent directly to an IP address rather than a supported host name, subject name validation of the X.509 certificates fails.

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.