TLS jonction spécification du protocole de transport

La sélection de TLS comme protocole de transport jonction pour les locaux BYOC ou le cloud BYOC vous permet de créer des lignes de réseau sécurisées. Plus spécifiquement, les liaisons sécurisées pour BYOC permettent aux points finaux VoIP distants de communiquer avec PureCloud de manière sécurisée à l’aide de SIP TLS (SIPS) et Secure RTP (SRTP). Les appels VoIP sécurisés protègent à la fois le contrôle (signalisation) et le média (audio) de l’appel.

Pour plus d’informations, voir Choisissez un protocole de transport jonction.

Avertissement : Lorsque vous choisissez un protocole de transport jonction, il est important de configurer les deux extrémités de jonction pour utiliser le même protocole. S’ils n’utilisent pas jonction le même protocole, le ne fonctionne pas.

Configuration requise

Pour configurer un jonction sécurisé pour BYOC Cloud, votre opérateur ou votre fournisseur téléphonie doit également prendre en charge les connexions VoIP sécurisées avec SIP utilisant TLS 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 alternatifs. Troncs sécurisés font ; Toutefois, vous devez disposer de conditions supplémentaires pour que la connexion aboutisse.

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_ECDHE_RSA_WITH_AES_128_GCM_SHA256*
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384*

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

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.

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. Il vous suffit de télécharger 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 régions qui utilisent les certificats de DigiCert High Assurance EV Root CA sont les suivantes :

  • Asie-Pacifique (Tokyo) / apne1
  • Asie-Pacifique (Séoul) / apne2
  • Asie-Pacifique (Sydney) / apse2
  • Asie-Pacifique (Mumbai) / aps1
  • Canada (Central) / cac1
  • Europe (Francfort) / euc1
  • Europe (Irlande) / euw1
  • Europe (Londres) / euw2
  • Amérique du Sud (São Paulo) / sae1
  • Est des États-Unis (Virginie du Nord) / utilisation1
  • US East (Ohio) / use2
  • US West (Oregon) / usw2

Remarque :  Ces régions nécessiteront éventuellement une migration vers DigiCert Global Root G2 et DigiCert Global Root G3. Genesys vous recommande de faire confiance aux racines G2 et G3 ainsi qu'à la racine EV pour préparer une future migration.

Téléchargez le certificat DigiCert High Assurance EV Root CA dans le format de fichier qui convient le mieux à votre système.

Téléchargez le certificat DigiCert Global Root G2 dans le format de fichier qui convient le mieux à votre système.

Téléchargez le certificat DigiCert Global Root G3 dans le format de fichier qui convient le mieux à votre système.

Les régions qui utilisent les certificats de DigiCert Global Root G2 et DigiCert Global Root G3 sont les suivantes :

  • Asie-Pacifique (Osaka) / apne3 
  • Europe (Zurich) / euc2
  • Moyen-Orient (EAU) / mec1

Remarque :  Ces régions utilisent actuellement le site DigiCert Global Root G2 avec la possibilité de passer à DigiCert Global Root G3 à l'avenir. La meilleure pratique de Genesys est de faire confiance aux deux certificats.

Téléchargez le certificat DigiCert Global Root G2 dans le format de fichier qui convient le mieux à votre système.

Téléchargez le certificat DigiCert Global Root G3 dans le format de fichier qui convient le mieux à votre système.


Remarque :  Remarque: Genesys Cloud régénère ou remplace les certificats de point de terminaison 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 le Genesys Cloud Notes de version.

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
  • DigiCert / QuoVadis / Symantec / Thawte / Verisign 
  • Confier
  • 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.


Autorité de certification Nom commun du certificat racine Hachure du nom du sujet
Actalis

Actalis Authentication Root CA

930ac5d2

Services Amazon Trust

Amazon Root CA 1

ce5e74ef

Services Amazon Trust

Amazon Root CA 2

6d41d539

Services Amazon Trust

Amazon Root CA 3

8cb5ee0f

Services Amazon Trust

Amazon Root CA 4

de6d66f3

Certum

Certum CA

442adcac

Certum

Autorité de certification du réseau de confiance Certum

48bec511

Certum

Certum Trusted Network CA 2

40193066

DigiCert

DigiCert Global Root CA

3513523f

DigiCert

DigiCert High Assurance EV Root CA (AC racine)

244b5494

DigiCert

DigiCert Global Root G2

607986c7

DigiCert

DigiCert Global Root G3

dd8e9d41

DigiCert

DigiCert ECC P384 Root G5

c1223238

DigiCert

DigiCert RSA4096 Root G5

9ccd262b

DigiCert

DigiCert TLS ECC P384 Root G5

9846683b

DigiCert

DigiCert TLS RSA4096 Root G5

d52c538d

DigiCert / QuoVadis

QuoVadis Root CA 2

d7e8dc79

DigiCert / QuoVadis

QuoVadis Root CA 3

76faf6c0

DigiCert / QuoVadis

QuoVadis Root CA 1 G3

749e9e03

DigiCert / QuoVadis

QuoVadis Root CA 2 G3

064e0aa9

DigiCert / QuoVadis

QuoVadis Root CA 3 G3

e18bfb83

DigiCert / thawte

thawte Primary Root CA

2e4eed3c

DigiCert / thawte

thawte Primary Root CA - G2

c089bbbd

DigiCert / thawte

thawte Primary Root CA - G3

ba89ed3b

DigiCert / thawte

thawte Primary Root CA - G4

854dca2b

DigiCert / Verisign

Autorité de certification primaire publique de classe 3 de VeriSign - G5

b204d74a

Confier

Autorité de certification racine Entrust

6b99d060

Confier

Autorité de certification Entrust.net (2048)

aee5f10d

Confier

Autorité de certification racine Entrust - EC1

106f3e4d

Confier

Autorité de certification racine Entrust - G2

02265526

Confier

Autorité de certification racine Entrust - G3

425d82a9

Confier

Autorité de certification racine Entrust - G4

5e98733a

GlobalSign

GlobalSign Root E46

feffd413

GlobalSign

GlobalSign Root R46

002c0b4f

GlobalSign

AC racine GlobalSign - R3

062cdee6

GlobalSign

GlobalSign ECC Root CA - R4

b0e59380

GlobalSign

GlobalSign ECC Root CA - R5

1d3472b9

GlobalSign

GlobalSign Root CA - R6

dc4d6a89

Go Daddy / Starfield

Autorité de certification de classe 2 de Go Daddy

f081611a

Go Daddy / Starfield

Autorité de certification racine Go Daddy - G2

cbf06781

Go Daddy / Starfield

Autorité de certification racine Go Daddy - G3

4b82aaf1

Go Daddy / Starfield

Autorité de certification racine Go Daddy - G4

fd8d27e1

Go Daddy / Starfield

Autorité de certification de classe 2 de Starfield

f387163d

Go Daddy / Starfield

Autorité de certification racine Starfield - G2

4bfab552

Go Daddy / Starfield

Autorité de certification racine Starfield - G3

3661ca00

Go Daddy / Starfield

Autorité de certification racine Starfield - G4

978d3d03

Go Daddy / Starfield

Autorité de certification racine de Starfield Services - G2

09789157

Go Daddy / Starfield / Amazon Trust Services

Autorité de certification racine de Starfield Services

006016b6

Groupe de recherche sur la sécurité Internet (GRSI)

EIGR Racine X1

4042bcee

Groupe de recherche sur la sécurité Internet (GRSI)

EIGR Racine X2

0b9bc432

Solutions réseau

Autorité de certification de Network Solutions (Dec-2029)

4304c5e5

Solutions réseau

Autorité de certification de Network Solutions (Déc-2030)

4304c5e5

Solutions réseau

Network Solutions EV SSL CA

4df989ce

Sectigo

Services de certificats AAA

ee64a828

Sectigo

AddTrust External CA Root (racine de l'autorité de certification externe)

157753a5

Sectigo

Autorité de certification COMODO ECC

eed8c118

Sectigo

COMODO RSA Autorité de certification

d6325660

Sectigo

Autorité de certification USERTrust ECC

f30dd6ad

Sectigo

USERTrust RSA Certification Authority

fc5a8f99

Sectigo

UTN-USERFirst-Hardware (matériel)

b13cc6df

SwissSign

SwissSign Silver CA - G2

57bcb2da

SwissSign

SwissSign Gold CA - G2

4f316efb

SwissSign

SwissSign Platinum CA - G2

a8dee976

Telia

TeliaSonera Root CA v1

5cd81ad7

Telia

Telia Root CA v2

8f103249

Trustwave

AC mondiale sécurisée

b66938e9

Trustwave

AC SecureTrust

f39fc864

Trustwave

Autorité de certification mondiale Trustwave

f249de83

Trustwave

Autorité de certification Trustwave Global ECC P256

9b5697b0

Trustwave

Autorité de certification Trustwave Global ECC P384

d887a5bb

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 points de terminaison 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 lors de la négociation TLS. Les points de terminaison du client ne doivent faire confiance qu’à l’autorité de certification racine DigiCert répertorié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.

Avertissement : Attention: Les connexions qui ne peuvent pas valider le nom cible risquent l’usurpation et le détournement de 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.

USA Est (N. Virginie) / us-east-1

Nom commun

lb01.voice.use1.pure.cloud

lb02.voice.use1.pure.cloud

lb03.voice.use1.pure.cloud

lb04.voice.use1.pure.cloud

US East 2 (Ohio) / us-east-2

Nom commun

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

Ouest des États-Unis (Oregon) (us-west-2)

Nom commun

lb01.pc-voice.usw2.pure.cloud

lb02.pc-voice.usw2.pure.cloud

lb03.pc-voice.usw2.pure.cloud

lb04.pc-voice.usw2.pure.cloud

Canada (Canada Central) / ca-central-1

Nom commun

lb01.pc-voice.usw2.pure.cloud

lb02.pc-voice.usw2.pure.cloud

lb03.pc-voice.usw2.pure.cloud

lb04.pc-voice.usw2.pure.cloud

Amérique du Sud (Sao Paulo) / sae1

Nom commun

lb01.voix.sae1.pure.cloud

lb02.voix.sae1.pure.cloud

lb03.voice.sae1.pure.cloud

lb04.voice.sae1.pure.cloud

Europe (Irlande) / eu-ouest-1

Nom commun

lb01.voice.euw1.pure.cloud

lb02.voice.euw1.pure.cloud

lb03.voice.euw1.pure.cloud

lb04.voice.euw1.pure.cloud

Europe (Londres) / eu-ouest-2

Nom commun

lb01.pc-voice.usw2.pure.cloud

lb02.pc-voice.usw2.pure.cloud

lb03.pc-voice.usw2.pure.cloud

lb04.pc-voice.usw2.pure.cloud

Europe (Francfort) (eu-central-1)

Nom commun

lb01.voice.euc1.pure.cloud

lb02.voice.euc1.pure.cloud

lb03.voice.euc1.pure.cloud

lb04.voice.euc1.pure.cloud

Europe (Zurich) / euc2

Nom commun

lb01.voice.euc2.pure.cloud

lb02.voice.euc2.pure.cloud

lb03.voice.euc2.pure.cloud

lb04.voice.euc2.pure.cloud

Moyen-Orient (EAU) / mec1

Nom commun

lb01.voice.mec1.pure.cloud

lb02.voice.mec1.pure.cloud

lb03.voice.mec1.pure.cloud

lb04.voice.mec1.pure.cloud

Asie-Pacifique (Tokyo) (ap-northeast-1)

Nom commun

lb01.voice.apne1.pure.cloud

lb02.voice.apne1.pure.cloud

lb03.voice.apne1.pure.cloud

lb04.voice.apne1.pure.cloud

Asie-Pacifique (Séoul) (ap-northeast-2)

Nom commun

lb01.pc-voice.usw2.pure.cloud

lb02.pc-voice.usw2.pure.cloud

lb03.pc-voice.usw2.pure.cloud

lb04.pc-voice.usw2.pure.cloud

Asie-Pacifique (Sydney) (ap-southeast-2)

Nom commun

lb01.voice.apse2.pure.cloud

lb02.voice.apse2.pure.cloud

lb03.voice.apse2.pure.cloud

lb04.voice.apse2.pure.cloud

Asie-Pacifique (Mumbai) (ap-south-1)

Nom commun

lb01.pc-voice.usw2.pure.cloud

lb02.pc-voice.usw2.pure.cloud

lb03.pc-voice.usw2.pure.cloud

lb04.pc-voice.usw2.pure.cloud

Asie-Pacifique (Osaka) / apne3

Nom commun

lb01.pc-voice.usw3.pure.cloud

lb03.pc-voice.usw2.pure.cloud

lb03.pc-voice.usw3.pure.cloud

lb04.pc-voice.usw3.pure.cloud

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.

Avertissement :  Attention: Les connexions réseau sécurisées échouent si le certificat actif a expiré ou n’est pas encore valide.

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.

Avertissement : avertissement: Si vous ne configurez pas correctement le certificat point de terminaison client, les appels sortants de Genesys Cloud peuvent échouer.

URI SIP

L’URI SIP est un mécanisme qui connecte un point de terminaison 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 périphérique SIP sous la forme d’un nom d’hôte DNS comprenant 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.

Attribut Emplacement d’attribut Description Valeurs
Transport Hôte Protocole de transport UDP | TCP | TLS
TGRP Utilisateur Étiquette du groupe de trunk Identifiant de terminaison SIP entrant défini par l’utilisateur
Contexte de trunk Utilisateur Espace de noms de groupe de lignes réseau Espace de noms spécifique à la région

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 la sélection de jonction en fonction des attributs de l’URI SIP. Les attributs TGRP contrôlent le routage afin que le nom d’hôte de l’URI de la demande soit défini sur une valeur définie en tant que nom commun ou nom alternatif de sujet du certificat X.509. Cette configuration permet à la validation du nom de sujet de réussir.

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

Le routage DNIS peut fonctionner avec les lignes réseau 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 de jonction pour les locaux BYOC, vous établissez des liaisons sécurisées directement entre le point de terminaison et le 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.