TLS jonction spécification du protocole de transport

Configuration requise

Pour mettre en place une liaison sécurisée pour BYOC Cloud, votre opérateur ou votre fournisseur de téléphonie doit également prendre en charge les connexions VoIP sécurisées avec SIP en utilisant TLS sur TCP et SRTP. BYOC Cloud ne prend pas en charge IPSEC pour les lignes de réseau sécurisées. La configuration d'un trunk BYOC Cloud sécurisé est similaire à celle d'un trunk non sécurisé, avec seulement quelques paramètres différents. Les liaisons sécurisées ont cependant d'autres exigences pour que la connexion réussisse.

Connexions

L’appareil d’origine de l’appel initie les connexions VoIP. Cependant, les deux points de terminaison VoIP agissent à la fois comme serveurs et clients. Vous configurez une connexion TLS sécurisée pour les deux extrémités des appels d’origine (entrants) et d’arrivée (sortants) Les deux points de terminaison VoIP doivent avoir un certificat X,509 signé par une autorité de certification publique et chaque client point de terminaison doit faire confiance à l’autorité de certification qui a signé le serveur.Les deux connexions utilisent TLS à sens unique ou côté serveur, mais TLS mutuel (MTLS) n'est pas pris en charge.

Les liaisons sécurisées pour BYOC Cloud se connectent aux mêmes points de terminaison VoIP que les homologues non sécurisés. Pour plus d’informations sur ces adresses de connexion, voir Adresses IP SIP publiques BYOC Cloud.

Versions de ports et de protocoles

BYOC Cloud ne prend en charge que les terminaux utilisant le protocole TLS version 1.2.

Les chiffrements TLS pris en charge incluent :

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

Les écouteurs TLS uniquement sont disponibles sur le port hôte 5061.

Certificat de confiance

Lorsque le client crée une connexion sécurisée à un serveur, il vérifie la validité du certificat. Le certificat autorise la légitimité de la clé contenue. Un certificat valide est conforme à ce qui suit :

Autorité de certification

Une autorité de certification réputée doit émettre le certificat pour qu’il soit valide.

Les points de terminaison client doivent faire confiance aux points de terminaison BYOC Cloud. Genesys Cloud signe les points de terminaison BYOC Cloud avec des certificats X.509 émis par DigiCert, une autorité de certification publique. Plus précisément, l'autorité de certification racine qui signe les terminaux BYOC Cloud est séparée par région et utilise des certificats autorisés par DigiCert High Assurance EV Root CA ou DigiCert Global Root G2/DigiCert Global Root G3. Vous pouvez télécharger le certificat de clé publique racine approprié pour votre région auprès de DigiCert.

Certificats racine

Genesys Cloud régénère ou remplace les certificats des points d'extrémité BYOC Cloud lorsque la clé privée change. Il est important de ne pas faire confiance au certificat de serveur lui-même car il pourrait changer sans préavis. Vous configurez les points de terminaison client pour faire confiance au certificat racine afin d’éviter tout problème. En cas de changement du certificat racine, des notifications de dépréciation apparaissent dans les notes de mise à jour de Genesys Cloud .

Formats des fichiers de certificats

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 certificat DER est encodé à l'aide de la méthode DER (Distinguished Encoding Rules), qui est un format binaire. Les certificats DER sont destinés à être utilisés dans des systèmes basés sur Java.
• Un certificat PEM est encodé à l'aide de la méthode Privacy-Enhanced Mail (PEM), qui est un format encodé en base64. Les certificats PEM sont destinés à être utilisés dans les systèmes basés sur Unix.

Autorités de certification par région

Les points de terminaison BYOC Cloud doivent également faire confiance aux points de terminaison du client. Pour que les points de terminaison BYOC Cloud fassent confiance aux points de terminaison client, l’une des autorités de certification publiques suivantes doit signer les points de terminaison client :

• Actalis
• Services Amazon Trust
• Certum
• Deutsche Telekom / T-TelSec
• DigiCert / QuoVadis / Symantec / Thawte / Verisign 
• Entrust / SSL.com
• GlobalSign
• Go Daddy / Starfield 
• Groupe de recherche sur la sécurité Internet
• Solutions réseau
• Sectigo / AddTrust / Comodo / UserTrust
• SwissSign
• Telia / TeliaSonera 
• Trustwave / Secure Trust / Viking Cloud

Tous les terminaux distants recevant des connexions SIP TLS sécurisées des serveurs SIP du BYOC Cloud doivent être configurés avec un certificat. Ce certificat est soit lui-même signé, soit, le plus souvent, signé par une autorité de certification intermédiaire émise par l'une des autorités de certification racine auxquelles les serveurs SIP du nuage BYOC de Genesys font confiance. Si le certificat n'est pas signé, la connexion échouera. Le point d'accès distant doit présenter son certificat d'entité finale ainsi que toutes les autorités de certification intermédiaires dans le cadre de la poignée de main TLS.

Prise de contact TLS avec confiance intermédiaire

TLS utilise une prise de contact pour négocier la connexion sécurisée entre les deux points de terminaison. L’établissement de liaison partage à la fois les certificats publics et les exigences spécifiques à la connexion. Le client lance la négociation et demande une connexion sécurisée au serveur. Le serveur doit fournir à la fois son propre certificat signé ainsi que tous les certificats intermédiaires de la chaîne de certificats.

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.

Les points de terminaison BYOC Cloud font confiance uniquement aux certificats d’autorité de certification racine des fournisseurs répertoriés ci-dessus. Les points de terminaison du client doivent fournir à la fois son propre certificat de serveur et tous les certificats d’autorité de certification intermédiaires dans la chaîne de certificats lorsqu’ils agissent en tant que serveur pendant l’établissement de liaison TLS.

Validation du nom du sujet

Un certificat valide doit contenir le nom de sujet de l’emplacement auquel le client s’est connecté (URI).

Un client d’une connexion sécurisée utilise la validation du nom de sujet pour s’assurer que l’point de terminaison distant s’identifie comme étant l’cible attendu. Si un certificat de serveur ne contient pas le nom auquel le client est connecté en tant que nom commun ou nom alternatif du sujet, le client doit alors refuser cette connexion.

Pour vous assurer que la validation du nom de sujet réussit, les connexions à BYOC Cloud utilisent le tableau suivant en tant que liste de points de terminaison potentiels.

• Amériques
• EMEA
• Asie-Pacifique

Les autorités de certification publiques doivent signer les certificats point de terminaison X.509 du client avec le nom commun ou le nom alternatif du sujet utilisé comme valeur SIP Servers ou Proxies de jonction. BYOC point de terminaison valide la connexion par le nom d’hôte - une adresse IP n’est pas acceptable. Pour plus d’informations sur les lignes réseau BYOC Cloud, voir Créer un nuage BYOC jonction.

Validation de la date

Un certificat valide doit être dans la période de validité de la date et ne pas dépasser la date d'expiration.

Les certificats X.509 ont une période de validité, qui correspond à une plage de dates spécifiant à quel moment le certificat est acceptable. À une date proche ou à la date d’expiration, Genesys Cloud renouvelle le certificat du point de terminaison par un nouveau certificat qui inclut une période de validation prolongée.

Certificat liste de révocation

Un certificat valide doit être un certificat émis activement et ne pas figurer sur la liste de révocation d’autorités.

Lorsqu’une autorité de certification publique signe des certificats X.509, elle inclut l’adresse d’une liste de révocation de certificats. L’autorité de certification publique peut révoquer un certificat avant la période d’expiration en l’ajoutant à une liste de révocation. Le client sécurisé vérifie la liste de révocation lorsqu’il établit une connexion et confirme la validité du certificat. Une autorité de certification publique révoque généralement un certificat public point de terminaison si la sécurité de la paire de clés est compromise.

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

Les attributs principaux spécifient la sélection jonction et le protocole de transport. Dans le cas d’une connexion sécurisée, le transport attribut spécifie le protocole de transport TLS.

Pour plus d’informations, voir la section Entrant de Configurer le routage SIP pour un cloud BYOC jonction.

Routage SIP entrant

Lorsque vous utilisez un SIP sécurisé pour BYOC Cloud à l’aide de TLS, Genesys Cloud recommande d’utiliser un ensemble d’URI distincts pour chaque proxy utilisant le TGRP pour le routage SIP entrant. Cependant, il existe quelques autres options à prendre en compte lors de la sélection d’une méthode de routage entrant :

TGRP (protocole de routage de groupe de lignes réseau)

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 (Service d’identification du numéro composé)

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 (nom de domaine complet)

Le nom de domaine complet peut fonctionner avec les lignes réseau Secure BYOC Cloud ; Toutefois, la validation du nom de sujet du certificat X.509 ne devrait pas réussir car les noms de domaine complets sont définis par Utilisateur. Les certificats génériques peuvent prendre en charge les noms définis par d’utilisateur mais ne sont pas utilisés en raison d’un manque de prise en charge sur certains périphériques SIP.

Les enregistrements SRV pour TLS sont disponibles et les certificats de proxy contiennent le nom de l’enregistrement SRV. Cependant, les autorités de certification publiques n'autorisent pas l'utilisation de caractères de soulignement dans les noms communs et les noms alternatifs de sujet qui sont utilisés dans les enregistrements SRV pour les noms de service et de transport. Si le périphérique SIP distant valide le nom commun du certificat, il valide uniquement le nom de domaine. Il ne valide pas le nom complet de l'enregistrement de ressource, qui inclut le service et le transport.

Pour plus d’informations, voir la section Entrant de Configurer le routage SIP pour un cloud BYOC jonction.

Exemples

Pour vous aider à configurer correctement votre URI SIP, voici un exemple de connexion à l’aide de TGRP. Cet exemple montre toutes les entrées d’hôte actuellement requises utilisées pour répartir les appels entre chacun des mandataires SIP BYOC. Il affiche également le nom d’hôte FQDN de chaque proxy utilisé pour passer la validation du nom de sujet du certificat X.509. Le protocole est fourni pour garantir que le point de terminaison distant établit une connexion sécurisée.

Lorsque vous sélectionnez TLS comme protocole de transport pour BYOC Premises, vous établissez des liaisons sécurisées à l'aide de TLS sur TCP directement entre le point d'extrémité du client et Genesys Cloud Edge. Une autorité de certification spécifique à l’organisation émet un certificat de serveur qui signe chaque point de terminaison Genesys Cloud Edge TLS. L'autorité de certification racine de votre organisation est le certificat valide qui gère le service SIP.

Vous pouvez obtenir le certificat de clé publique de votre organisation à partir de Genesys Cloud. Pour plus d’informations, voir Configurer les autorités de certification.

Vous pouvez régler les paramètres de transport et de sécurité des supports dans la configuration Externe jonction. Pour plus d’informations, voir Paramètres externes jonction.