TLS trunk transport protocol specification

Requirements

To set up a secure trunk for BYOC Cloud, your carrier or telephony provider must also support secure VoIP connections with SIP using TLS over TCP and SRTP. BYOC Cloud does not support IPSEC for secure trunks. Setting up a secure BYOC Cloud trunk is similar to a non-secure trunk with just a few alternate settings. Secure trunks do; however, have other requirements for the connection to succeed.

Connections

The call’s originating device initiates the VoIP connections. However, both VoIP endpoints act as both servers and clients. You configure a secure TLS connection for both endpoints for both originating (inbound) and terminating (outbound) calls. Both VoIP endpoints must have an X.509 certificate signed by a public certificate authority and each client endpoint must trust the certificate authority that signed the server. Both connections use one-way or server-side TLS, but mutual TLS (MTLS) is not supported.

Secure trunks for BYOC Cloud connect to the same VoIP endpoints as the non-secure counterparts. For more information about these connection addresses, see BYOC Cloud public SIP IP addresses.

Ports and protocol versions

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

Supported TLS ciphers include:

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

Certificate trust

When the client creates a secure connection to a server, it checks the validity of the certificate. The certificate authorizes the legitimacy of the contained key. A valid certificate adheres to the following:

Certificate authority

A reputable certificate authority must issue the certificate for it to be valid.

The customer endpoints must trust the BYOC Cloud endpoints. Genesys Cloud signs the BYOC Cloud endpoints with X.509 certificates issued by DigiCert, a public Certificate Authority. More specifically, the root certificate authority that signs the BYOC Cloud endpoints is separated by region and uses certificates authorized by either DigiCert High Assurance EV Root CA or DigiCert Global Root G2/DigiCert Global Root G3. You can download the appropriate root public key certificate for your region from DigiCert.

Root certificates

Genesys Cloud regenerates or replaces the BYOC Cloud endpoint certificates when the private key changes. It is important not to trust the server certificate itself as it could change without notice. You configure the customer endpoints to trust the root certificate to prevent any issues. In the event the root certificate changes, deprecation notifications appear in the Genesys Cloud Release Notes.

Certificate file formats

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.

• A DER certificate is encoded using the Distinguished Encoding Rules (DER) method, which is a binary format. DER certificates are intended for use in Java-based systems.
• A PEM certificate is encoded using the Privacy-Enhanced Mail (PEM) method, which is a base64-encoded format. PEM certificates are intended for use in Unix-based systems.

Certificate authorities by region

The BYOC Cloud endpoints must also trust the customer endpoints. For the BYOC Cloud endpoints to trust the customer endpoints, one of these public certificate authorities must sign the customer endpoints:

• Actalis
• Amazon Trust Services
• Certum
• Deutsche Telekom / T-TelSec
• DigiCert / QuoVadis / Symantec / Thawte / Verisign 
• Entrust / SSL.com
• GlobalSign
• Go Daddy / Starfield 
• Harica
• IdenTrust
• Internet Security Research Group
• Network Solutions
• Sectigo / AddTrust / Comodo / UserTrust
• SwissSign
• Telia / TeliaSonera 
• Trustwave / Secure Trust / Viking Cloud

All remote endpoints receiving secure SIP TLS connections from BYOC Cloud SIP Servers must be configured with a certificate. This certificate is either itself signed or more commonly signed by an intermediate certificate authority issued by one of the Root Certificate Authorities that the Genesys Cloud BYOC Cloud SIP servers trust. If the certificate is unsigned, the connection will fail. The remote endpoint should present its end-entity certificate as well as all intermediate certificate authorities in the TLS handshake.

TLS handshake with intermediate trust

TLS uses a handshake to negotiate the secure connection between the two endpoints. The handshake shares both public certificates and connection-specific requirements. The client initiates the handshake and requests a secure connection from the server. The server must provide both its own signed certificate and all intermediate certificates in the certificate chain.

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.

The BYOC Cloud endpoints only trust the root certificate authority certificates from the providers listed above. The customer endpoints must provide both its own server certificate and all intermediate certificate authority certificates in the certificate chain when acting as the server during the TLS handshake.

Subject name validation

A valid certificate must contain the subject name of the location that the client connected (URI).

A client of a secure connection uses subject name validation to ensure that the remote endpoint identifies itself as the expected target. If a server certificate does not contain the name to which the client is connected as either the common name or the subject alternate name, then the client should refuse that connection.

To ensure that subject name validation succeeds, connections to BYOC Cloud use the following table as a list of potential endpoints.

• Americas
• EMEA
• Asia Pacific

Public certificate authorities must sign the customer endpoint X.509 certificates with the common name or subject alternate name used as the trunk’s SIP Servers or Proxies value. The BYOC endpoint validates the connection by the host name – an IP address is not acceptable. For more information about BYOC Cloud trunks, see Create a BYOC Cloud trunk.

Date validation

A valid certificate must be within the date validity period and not past the expiration date.

X.509 certificates have a validity period, which is a date range that specifies when the certificate is acceptable. At a date near or on the expiration date, Genesys Cloud renews the endpoint’s certificate with a new certificate that includes an extended validation period.

Certificate revocation list

A valid certificate must be an actively issued certificate and not contained on the authorities revocation list.

When a public certificate authority signs X.509 certificates, it includes an address of a certificate revocation list. The public certificate authority can revoke a certificate before the expiration period by adding it to a revocation list. The secure client checks the revocation list when it establishes a connection and confirms that the certificate is valid. A public certificate authority typically revokes an endpoint public certificate if the security of the key pair becomes compromised.

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.  

The primary attributes specify the trunk selection and the transport protocol. In secure connections, the transport attribute specifies the TLS transport protocol.

For more information, see the Inbound section of Configure SIP routing for a BYOC Cloud trunk.

Inbound SIP routing

When you use secure SIP for BYOC Cloud using TLS, Genesys Cloud recommends that you use a set of distinct URIs for each proxy using the TGRP for inbound SIP routing. However, there are a few other options for you to consider when selecting an inbound routing method:

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 (Dialed Number Identification Service)

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 (Fully Qualified Domain Name)

FQDN may work with Secure BYOC Cloud trunks; however, subject name validation of the X.509 certificate is not expected to pass because the FQDNs are user-defined. Wildcard certificates could support the user-defined names but are not used because of lack of support on some SIP devices.

SRV records for TLS are available and the proxy certificates do contain the SRV domain name and the SRV record name. However, public certificate authorities do not allow the use of underscore characters in common names and subject alternate names that are used in SRV records for the service and transport names. If the remote SIP device validates the certificate common name, it validates only the domain name. It doesn’t validate the entire resource record name, which includes the service and transport.

For more information, see the Inbound section of Configure SIP routing for a BYOC Cloud trunk.

Examples

To help you correctly configure your SIP URI, the following example is for a connection using TGRP. This example shows all the currently required host entries that are used to distribute calls between each of the BYOC SIP Proxies. It also shows the FQDN host name of each proxy that is used to pass the subject name validation of the X.509 certificate. The protocol is provided to ensure that the remote endpoint initiates a secure connection.

When you select TLS as the trunk transport protocol for BYOC Premises, you establish secure trunks using TLS over TCP directly between the customer endpoint and the Genesys Cloud Edge. An organization-specific certificate authority issues a server certificate that signs each Genesys Cloud Edge TLS endpoint. Your organization root certificate authority is the valid certificate managing the SIP service.

You can obtain the public key certificate for your organization from within Genesys Cloud. For more information, see Configure certificate authorities.

You can adjust the transport and media security settings in the External trunk configuration. For more information, see External trunk settings.