Spezifikation des TLS-Trunk-Transportprotokolls

Deprecation Announcement: On March 24, 2025, Genesys announced that in a future release, Genesys Cloud will no longer support the following BYOC Cloud TLS ciphers. 
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

 For more information, see Deprecation: BYOC Cloud SIP TLS ciphers.

When you select TLS as the trunk transport protocol for BYOC Cloud or BYOC Premises, you can create secure trunks using TLS over TCP. Secure trunks for BYOC allow remote VoIP endpoints to communicate with Genesys Cloud securely using SIP TLS (SIPS) and Secure RTP (SRTP). Secure VoIP calls protect both the control (signaling) and the media (audio) of the call.

Weitere Informationen finden Sie unter Wählen Sie ein Trunk-Transportprotokoll.

Warnung: Wenn Sie ein Trunk-Transportprotokoll wählen, ist es wichtig, dass Sie beide Enden des Trunks so konfigurieren, dass sie dasselbe Protokoll verwenden. Wenn sie nicht dasselbe Protokoll verwenden, funktioniert der Trunk nicht.

Anforderungen

Um einen sicheren Trunk für BYOC Cloud einzurichten, muss Ihr Netzbetreiber oder Telefonieanbieter auch sichere VoIP-Verbindungen mit SIP unter Verwendung von TLS über TCP und SRTP unterstützen. BYOC Cloud unterstützt kein IPSEC für sichere Trunks. Das Einrichten eines sicheren BYOC-Cloud-Trunks ähnelt dem Einrichten eines nicht sicheren Trunks, weist jedoch nur wenige alternative Einstellungen auf. Für sichere Leitungen gelten allerdings andere Anforderungen für eine erfolgreiche Verbindung.

Verbindung

Das Gerät, von dem der Anruf ausgeht, initiiert die VoIP-Verbindungen. Beide VoIP-Endpunkte fungieren jedoch sowohl als Server als auch als Client. Sie konfigurieren eine sichere TLS-Verbindung für beide Endpunkte sowohl für eingehende als auch für ausgehende Anrufe. Beide VoIP-Endpunkte müssen über ein X.509-Zertifikat verfügen, das von einer öffentlichen Zertifizierungsstelle unterzeichnet wurde, und jeder Client-Endpunkt muss der Zertifizierungsstelle vertrauen, die den Server unterzeichnet hat.Beide Verbindungen verwenden unidirektionales oder serverseitiges TLS, aber gegenseitiges TLS (MTLS) wird nicht unterstützt.

Sichere Trunks für BYOC Cloud verbinden sich mit denselben VoIP-Endpunkten wie die unsicheren Gegenstücke. Weitere Informationen zu diesen Verbindungsadressen finden Sie unter BYOC Cloud public SIP IP addresses.

Ports und Protokollversionen

BYOC Cloud only supports endpoints using the TLS version 1.2 protocol. TLS-only listeners are available on host port 5061. 

Zu den unterstützten TLS-Chiffren gehören:

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

The following TLS Ciphers are still supported but slated for deprecation in a future release.

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

Zertifikat Vertrauen

Wenn der Client eine sichere Verbindung zu einem Server herstellt, prüft er die Gültigkeit des Zertifikats. Das Zertifikat bestätigt die Legitimität des enthaltenen Schlüssels. Ein gültiges Zertifikat erfüllt die folgenden Anforderungen:

Zertifizierungsstelle

Eine angesehene Zertifizierungsstelle muss das Zertifikat ausstellen, damit es gültig ist.

Die Endpunkte des Kunden müssen den Endpunkten der BYOC-Cloud vertrauen. Genesys Cloud signiert die BYOC Cloud-Endpunkte mit X.509-Zertifikaten, die von DigiCert, einer öffentlichen Zertifizierungsstelle, ausgestellt werden. Genauer gesagt ist die Stammzertifizierungsstelle, die die BYOC-Cloud-Endpunkte signiert, nach Regionen getrennt und verwendet Zertifikate, die entweder von DigiCert High Assurance EV Root CA oder DigiCert Global Root G2/DigiCert Global Root G3 autorisiert wurden. Sie können das entsprechende öffentliche Stammschlüsselzertifikat für Ihre Region von DigiCert herunterladen.

Stammzertifikate

Genesys Cloud generiert oder ersetzt die BYOC-Cloud-Endpunktzertifikate neu, wenn sich der private Schlüssel ändert. Es ist wichtig, dem Serverzertifikat selbst nicht zu vertrauen, da es sich ohne Vorankündigung ändern kann. Sie konfigurieren die Kundenendpunkte so, dass sie dem Stammzertifikat vertrauen, um Probleme zu vermeiden. Falls sich das Stammzertifikat ändert, werden in der Genesys Cloud Benachrichtigungen zur Veralterung angezeigt. Versionshinweise .

Dateiformate für Zertifikate

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.

  • Ein DER-Zertifikat wird nach der Methode der Distinguished Encoding Rules (DER) kodiert, die ein binäres Format ist. DER-Zertifikate sind für die Verwendung in Java-basierten Systemen vorgesehen.
  • Ein PEM-Zertifikat wird mit der Privacy-Enhanced Mail (PEM)-Methode kodiert, die ein Base64-kodiertes Format ist. PEM-Zertifikate sind für die Verwendung in Unix-basierten Systemen vorgesehen.

Zertifizierungsstellen nach Region

Die Regionen, die Zertifikate von DigiCert High Assurance EV Root CA verwenden, sind:

  • Asien-Pazifik (Tokio) / apne1
  • Asien-Pazifik (Seoul) / apne2
  • Asien-Pazifik (Sydney) / apse2
  • Asien-Pazifik (Mumbai) / aps1
  • Kanada (Zentral) / cac1
  • Europa (Frankfurt) / euc1
  • Europa (Irland) / euw1
  • Europa (London) / euw2
  • Südamerika (São Paulo) / sae1
  • US-Ost (Nordvirginia) / use1
  • US-Ost (Ohio) / use2
  • US-West (Oregon) / usw2

Hinweis: In diesen Regionen ist eine Migration auf DigiCert Global Root G2 und DigiCert Global Root G3 erforderlich. Genesys empfiehlt, dass Sie den G2- und G3-Roots sowie dem EV-Root vertrauen, um sich auf eine zukünftige Migration vorzubereiten.

Laden Sie das DigiCert High Assurance EV Root CA-Zertifikat in dem Dateiformat herunter, das für Ihr System am besten geeignet ist.

Laden Sie das DigiCert Global Root G2-Zertifikat in dem Dateiformat herunter, das am besten zu Ihrem System passt.

Laden Sie das DigiCert Global Root G3-Zertifikat in dem Dateiformat herunter, das am besten zu Ihrem System passt.

Die Regionen, die Zertifikate von DigiCert Global Root G2 und DigiCert Global Root G3 verwenden, sind:

  • Asien-Pazifik (Osaka) / apne3 
  • Europa (Zürich) / euc2
  • Naher Osten (UAE) / mec1

Hinweis: Diese Regionen verwenden derzeit das DigiCert Global Root G2 mit der Möglichkeit, in Zukunft auf DigiCert Global Root G3 zu wechseln. Die beste Praxis von Genesys ist, beiden Zertifikaten zu vertrauen.

Laden Sie das DigiCert Global Root G2-Zertifikat in dem Dateiformat herunter, das am besten zu Ihrem System passt.

Laden Sie das DigiCert Global Root G3-Zertifikat in dem Dateiformat herunter, das am besten zu Ihrem System passt.


Die BYOC-Cloud-Endpunkte müssen auch den Kunden-Endpunkten vertrauen. Damit die BYOC-Cloud-Endpunkte den Kunden-Endpunkten vertrauen können, muss eine dieser öffentlichen Zertifizierungsstellen die Kunden-Endpunkte signieren:

  • Actalis
  • Amazon Trust Services
  • Certum
  • Deutsche Telekom / T-TelSec
  • DigiCert / QuoVadis / Symantec / Thawte / Verisign 
  • Entrust / SSL.com
  • GlobalSign
  • Go Daddy / Starfield 
  • Harica
  • IdenTrust
  • Forschungsgruppe Internetsicherheit
  • Netzwerk-Lösungen
  • Sectigo / AddTrust / Comodo / UserTrust
  • SwissSign
  • Telia / TeliaSonera 
  • Trustwave / Sicheres Vertrauen / Viking Cloud

Alle entfernten Endpunkte, die sichere SIP TLS-Verbindungen von BYOC Cloud SIP-Servern empfangen, müssen mit einem Zertifikat konfiguriert werden. Dieses Zertifikat ist entweder selbst signiert oder, was häufiger der Fall ist, von einer Zwischenzertifizierungsstelle signiert, die von einer der Stammzertifizierungsstellen ausgestellt wurde, denen die Genesys Cloud BYOC Cloud SIP-Server vertrauen. Wenn das Zertifikat nicht signiert ist, schlägt die Verbindung fehl. Der entfernte Endpunkt sollte sein Endzertifikat sowie alle Zwischenzertifizierungsstellen im TLS-Handshake vorlegen.


TLS-Handshake mit zwischengeschaltetem Vertrauen

TLS verwendet einen Handshake, um die sichere Verbindung zwischen den beiden Endpunkten auszuhandeln. Der Handshake umfasst sowohl öffentliche Zertifikate als auch verbindungsspezifische Anforderungen. Der Client initiiert den Handshake und fordert vom Server eine sichere Verbindung an. Der Server muss sowohl sein eigenes signiertes Zertifikat als auch alle Zwischenzertifikate in der Zertifikatskette bereitstellen.

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.

Die BYOC-Cloud-Endpunkte vertrauen nur den Stammzertifizierungsstellen-Zertifikaten der oben aufgeführten Anbieter. Die Kundenendpunkte müssen sowohl ihr eigenes Serverzertifikat als auch alle Zwischenzertifizierungsstellen-Zertifikate in der Zertifikatskette bereitstellen, wenn sie während des TLS-Handshakes als Server fungieren.

Notiz : Für den TLS-Handshake auf BYOC-Cloud-Trunks gibt es ein Timeout von 500 ms. Unter normalen Umständen 500 ms sind mehr als genug Zeit, um eine TLS-Verbindung herzustellen.

Validierung von Themennamen

Ein gültiges Zertifikat muss den Subjektnamen des Ortes enthalten, mit dem sich der Client verbunden hat (URI).

Ein Client einer sicheren Verbindung verwendet die Überprüfung des Betreffs, um sicherzustellen, dass der entfernte Endpunkt sich als das erwartete Ziel identifiziert. Wenn ein Serverzertifikat den Namen, mit dem der Client verbunden ist, weder als Common Name noch als Subject Alternate Name enthält, sollte der Client diese Verbindung ablehnen.

Warnung: Bei Verbindungen, die den Zielnamen nicht validieren können, besteht die Gefahr des Spoofing und des Connection Hijacking.

Um sicherzustellen, dass die Validierung des Subjektnamens erfolgreich ist, verwenden Verbindungen zur BYOC Cloud die folgende Tabelle als Liste möglicher Endpunkte.

US-Ost (N. Virginia) / us-ost-1

Gängiger Name

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

Gängiger Name

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

US-West (Oregon) / us-west-2

Gängiger Name

lb01.voice.usw2.pure.cloud

lb02.voice.usw2.pure.cloud

lb03.voice.usw2.pure.cloud

lb04.voice.usw2.pure.cloud

Kanada (Kanada Zentral) / ca-central-1

Gängiger Name

lb01.voice.cac1.pure.cloud

lb02.voice.cac1.pure.cloud

lb03.voice.cac1.pure.cloud

lb04.voice.cac1.pure.cloud

Südamerika (Sao Paulo) / sae1

Gängiger Name

lb01.voice.sae1.pure.cloud

lb02.voice.sae1.pure.cloud

lb03.voice.sae1.pure.cloud

lb04.voice.sae1.pure.cloud

Europa (Irland) / eu-west-1

Gängiger Name

lb01.voice.euw1.pure.cloud

lb02.voice.euw1.pure.cloud

lb03.voice.euw1.pure.cloud

lb04.voice.euw1.pure.cloud

Europa (London) / eu-west-2

Gängiger Name

lb01.voice.euw2.pure.cloud

lb02.voice.euw2.pure.cloud

lb03.voice.euw2.pure.cloud

lb04.voice.euw2.pure.cloud

Europa (Frankfurt) / eu-central-1

Gängiger Name

lb01.voice.euc1.pure.cloud

lb02.voice.euc1.pure.cloud

lb03.voice.euc1.pure.cloud

lb04.voice.euc1.pure.cloud

Europa (Zürich) / euc2

Gängiger Name

lb01.voice.euc2.pure.cloud

lb02.voice.euc2.pure.cloud

lb03.voice.euc2.pure.cloud

lb04.voice.euc2.pure.cloud

Naher Osten (UAE) / mec1

Gängiger Name

lb01.voice.mec1.pure.cloud

lb02.voice.mec1.pure.cloud

lb03.voice.mec1.pure.cloud

lb04.voice.mec1.pure.cloud

Asien-Pazifik (Tokio) / ap-northeast-1

Gängiger Name

lb01.voice.apne1.pure.cloud

lb02.voice.apne1.pure.cloud

lb03.voice.apne1.pure.cloud

lb04.voice.apne1.pure.cloud

Asien-Pazifik (Seoul) / ap-nordost-2

Gängiger Name

lb01.voice.euw2.pure.cloud

lb02.voice.euw2.pure.cloud

lb03.voice.euw2.pure.cloud

lb04.voice.euw2.pure.cloud

Asien-Pazifik (Sydney) / ap-southeast-2

Gängiger Name

lb01.voice.apse2.pure.cloud

lb02.voice.apse2.pure.cloud

lb03.voice.apse2.pure.cloud

lb04.voice.apse2.pure.cloud

Asien-Pazifik (Mumbai) / ap-south-1

Gängiger Name

lb01.voice.euw2.pure.cloud

lb02.voice.euw2.pure.cloud

lb03.voice.euw2.pure.cloud

lb04.voice.euw2.pure.cloud

Asien-Pazifik (Osaka) / apne3

Gängiger Name

lb01.voice.euw3.pure.cloud

lb03.voice.euw2.pure.cloud

lb03.voice.euw3.pure.cloud

lb04.voice.euw3.pure.cloud

Öffentliche Zertifizierungsstellen müssen die X.509-Zertifikate des Kundenendpunkts mit dem gemeinsamen Namen oder dem alternativen Namen des Betreffs signieren, der als Wert für die SIP-Server oder Proxies des Trunks verwendet wird. Der BYOC-Endpunkt validiert die Verbindung anhand des Hostnamens - eine IP-Adresse ist nicht zulässig. Weitere Informationen zu BYOC Cloud Trunks finden Sie unter Erstellen eines BYOC Cloud Trunks.

Überprüfung des Datums

Ein gültiges Zertifikat muss innerhalb der Gültigkeitsdauer liegen und das Ablaufdatum darf nicht überschritten sein.

X.509-Zertifikate haben eine Gültigkeitsdauer, d. h. einen Datumsbereich, der angibt, wann das Zertifikat akzeptabel ist. Wenn das Ablaufdatum erreicht ist, erneuert Genesys Cloud das Zertifikat des Endpunkts mit einem neuen Zertifikat, das eine verlängerte Gültigkeitsdauer enthält.

Warnung: Sichere Netzwerkverbindungen schlagen fehl, wenn das aktive Zertifikat abgelaufen oder noch nicht gültig ist.

Zertifikat widerrufsliste

Ein gültiges Zertifikat muss ein aktiv ausgestelltes Zertifikat sein und darf nicht in der Sperrliste der Behörden enthalten sein.

Wenn eine öffentliche Zertifizierungsstelle X.509-Zertifikate signiert, enthält sie eine Adresse einer Zertifikatswiderrufsliste. Die öffentliche Zertifizierungsstelle kann ein Zertifikat vor Ablauf der Frist sperren, indem sie es in eine Sperrliste aufnimmt. Der sichere Client prüft die Sperrliste, wenn er eine Verbindung herstellt, und bestätigt, dass das Zertifikat gültig ist. Eine öffentliche Zertifizierungsstelle widerruft in der Regel ein öffentliches Endpunktzertifikat, wenn die Sicherheit des Schlüsselpaars gefährdet ist.

Warnung: Wenn Sie das Kunden-Endpunkt-Zertifikat nicht korrekt einrichten, können ausgehende Anrufe von Genesys Cloud fehlschlagen.

SIP-URI

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.  

Die primären Attribute geben die Leitungswahl und das Transportprotokoll an. Bei sicheren Verbindungen gibt das Attribut transport das TLS-Transportprotokoll an.

Attribut Standort des Attributs Beschreibung Werte
Transport Host Transport-Protokoll UDP | TCP | TLS
TGRP Benutzer Kennzeichnung der Leitungsgruppe Benutzerdefinierte Kennung für eingehende SIP-Terminierung
Kontext des Stammes Benutzer Namensraum der Fernmeldegruppe Regionalspezifischer Namensraum

Weitere Informationen finden Sie im Abschnitt Eingehend unter Configure SIP routing for a BYOC Cloud trunk.

Eingehende SIP-Weiterleitung

Wenn Sie sicheres SIP für BYOC Cloud unter Verwendung von TLS verwenden, empfiehlt Genesys Cloud, dass Sie eine Reihe von unterschiedlichen URIs für jeden Proxy verwenden, der TGRP für eingehendes SIP-Routing verwendet. Es gibt jedoch noch einige andere Optionen, die Sie bei der Auswahl einer Methode zur Weiterleitung eingehender Nachrichten in Betracht ziehen sollten:

TGRP (Trunk Group Routing Protocol)

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 (Dienst zur Identifizierung gewählter Nummern)

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 (Vollständig qualifizierter Domänenname)

FQDNs können mit Secure BYOC Cloud Trunks funktionieren; es wird jedoch nicht erwartet, dass die Validierung des Subjektnamens des X.509-Zertifikats erfolgreich ist, da die FQDNs benutzerdefiniert sind. Wildcard-Zertifikate könnten die benutzerdefinierten Namen unterstützen, werden aber nicht verwendet, weil sie von einigen SIP-Geräten nicht unterstützt werden.

SRV-Einträge für TLS sind verfügbar, und die Proxy-Zertifikate enthalten den SRV-Domänennamen und den Namen des SRV-Eintrags. Öffentliche Zertifizierungsstellen gestatten jedoch nicht die Verwendung von Unterstrichen in allgemeinen Namen und alternativen Namen von Subjekten, die in SRV-Einträgen für Dienst- und Transportnamen verwendet werden. Wenn das entfernte SIP-Gerät den gemeinsamen Namen des Zertifikats validiert, wird nur der Domänenname validiert. Es wird nicht der gesamte Name des Ressourcendatensatzes validiert, der den Dienst und den Transport umfasst.

Weitere Informationen finden Sie im Abschnitt Eingehend unter Configure SIP routing for a BYOC Cloud trunk.

Beispiele

Damit Sie Ihren SIP-URI richtig konfigurieren können, wird im Folgenden ein Beispiel für eine Verbindung mit TGRP aufgeführt. Dieses Beispiel zeigt alle derzeit erforderlichen Host-Einträge, die zur Verteilung von Anrufen zwischen den einzelnen BYOC-SIP-Proxies verwendet werden. Außerdem wird der FQDN-Hostname jedes Proxys angezeigt, der verwendet wird, um die Prüfung des Betreffnamens des X.509-Zertifikats zu bestehen. Das Protokoll wird bereitgestellt, um sicherzustellen, dass der entfernte Endpunkt eine sichere Verbindung initiiert.

 

Wenn Sie TLS als Trunk-Transportprotokoll für BYOC Premises auswählen, richten Sie mit TLS über TCP sichere Trunks direkt zwischen dem Kundenendpunkt und dem Genesys Cloud Edge ein. Eine organisationsspezifische Zertifizierungsstelle stellt ein Serverzertifikat aus, das jeden Genesys Cloud Edge TLS-Endpunkt signiert. Die Stammzertifizierungsstelle Ihrer Organisation ist das gültige Zertifikat, das den SIP-Dienst verwaltet.

Sie können das öffentliche Schlüsselzertifikat für Ihre Organisation von Genesys Cloud aus erhalten. Weitere Informationen finden Sie unter Konfigurieren von Zertifizierungsstellen.

Sie können die Einstellungen für die Transport- und Mediensicherheit in der Konfiguration der externen Leitung anpassen. Weitere Informationen finden Sie unter Externe Leitungseinstellungen.


  • Wenn Sie noch Fragen haben, können Sie unter die Community um Hilfe bitten.
  • Dieses Feld dient der Validierung und sollte unverändert bleiben.