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 auditeurs TLS uniquement sont disponibles sur le port 5061 de l'hôte. 

Les chiffrements TLS pris en charge incluent :

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

Les codes TLS suivants sont toujours pris en charge, mais il est prévu de les supprimer dans une prochaine version.

• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384*

* Pour les échanges de clés éphémères à courbe elliptique Diffie-Hellman (ECDHE), seules les courbes elliptiques secp384r1 (courbe NIST/SECG sur un champ premier de 384 bits) sont prises en charge.

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

Les certificats d'autorité de certification racine sont disponibles dans deux formats de fichier différents : DER et PEM. Ces deux formats de fichier contiennent les mêmes données, mais ils diffèrent dans la manière dont elles sont encodées. Ne téléchargez que le format de fichier qui convient le mieux à votre système.

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

Les terminaux BYOC Cloud fournissent leur propre certificat de serveur et tous les certificats intermédiaires de la chaîne de certificats lorsqu'ils agissent en tant que serveur pendant la poignée de main TLS. Les terminaux du client ne doivent faire confiance qu'à l'autorité de certification racine DigiCert mentionnée ci-dessus.

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

L'URI SIP est un mécanisme qui permet de connecter un point d'extrémité VoIP. Chaque point de terminaison VoIP a un URI SIP correspondant pour se connecter à l’homologue distant respectif. L'URI contient l'adresse distante du dispositif SIP sous la forme d'un nom d'hôte DNS qui inclut le protocole, le numéro de destination et l'hôte distant.

Outre le nom d'hôte, l'URI peut également contenir des attributs permettant de contrôler la connexion. Vous appliquez des attributs à la partie d’utilisateurYYZY et à la partie hôte de l’URI. Pour que l'URI fonctionne correctement, vous devez appliquer des attributs à la partie appropriée de l'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)

La meilleure pratique consiste à utiliser une configuration TGRP, car elle permet de sélectionner la ligne réseau en fonction des attributs de l'URI SIP. Les attributs TGRP contrôlent le routage de sorte que le nom d'hôte de l'URI de la demande est défini comme le nom commun ou le nom alternatif du sujet du certificat X.509. Cette configuration permet à la validation du nom du sujet d'aboutir.

DNIS (Service d’identification du numéro composé)

Le routage DNIS peut fonctionner avec les trunks Secure BYOC Cloud ; cependant, la validation du nom du sujet peut limiter la faisabilité de cette option de routage. Vous utilisez généralement le routage DNIS lorsque le transporteur limite le contrôle de l’URI SIP et préfère une adresse IP. Si les appels sont envoyés directement à une adresse IP plutôt qu'à un nom d'hôte pris en charge, la validation du nom du sujet des certificats X.509 échoue.

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.