TLS trunk transport protocol specification


Feature coming soon

Selecting TLS as the trunk transport protocol for BYOC Premises or BYOC Cloud allows you to create secure trunks. More specifically, secure trunks for BYOC allow remote VoIP endpoints to communicate with PureCloud securely using SIP TLS (SIPS) and Secure RTP (SRTP). Secure VoIP calls protect both the control (signaling) and the media (audio) of the call.

Warning: When choosing a trunk transport protocol, it is important that you configure both ends of the trunk to use the same protocol. If they are not using the same protocol, the trunk fails to function.


Selecting TLS as the trunk transport protocol for BYOC Premises establishes secure trunks directly between the customer endpoint and the PureCloud Edge. An organization-specific certificate authority issues a server certificate that signs each PureCloud 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 PureCloud. 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.


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 and SRTP. BYOC Cloud does not support IPSEC for secure trunks. Setting up a secure BYOC Cloud trunk is similar to non-secure trunk with just a few alternate settings. Secure trunks do; however, have additional 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.

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.

Supported TLS ciphers include:

  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA256

TLS-only listeners are available on host port 5061.

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. PureCloud 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 the DigiCert High Assurance EV Root CA. You can download the root public key certificate from DigiCert

Note: PureCloud will regenerate or replace 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 PureCloud Release Notes.

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

  • Amazon Trust Services
  • Comodo / Sectigo
  • DigiCert / Symantec / Verisign
  • Entrust
  • GoDaddy / Starfield
  • Network Solutions
  • Thwate

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.

Warning: Connections that cannot validate the target name are at risk of spoofing and connection hijacking.

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

Common Name
lb01.byoc.us-east-1.mypurecloud.com
lb02.byoc.us-east-1.mypurecloud.com
lb03.byoc.us-east-1.mypurecloud.com
lb04.byoc.us-east-1.mypurecloud.com
Common Name
lb01.byoc.eu-west-1.mypurecloud.ie
lb02.byoc.eu-west-1.mypurecloud.ie
lb03.byoc.eu-west-1.mypurecloud.ie
lb04.byoc.eu-west-1.mypurecloud.ie
Common Name
lb01.byoc.eu-central-1.mypurecloud.de
lb02.byoc.eu-central-1.mypurecloud.de
lb03.byoc.eu-central-1.mypurecloud.de
lb04.byoc.eu-central-1.mypurecloud.de
Common Name
lb01.byoc.ap-southeast-2.mypurecloud.com.au
lb02.byoc.ap-southeast-2.mypurecloud.com.au
lb03.byoc.ap-southeast-2.mypurecloud.com.au
lb04.byoc.ap-southeast-2.mypurecloud.com.au
Common Name
lb01.byoc.ap-northeast-1.mypurecloud.jp
lb02.byoc.ap-northeast-1.mypurecloud.jp
lb03.byoc.ap-northeast-1.mypurecloud.jp
lb04.byoc.ap-northeast-1.mypurecloud.jp

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 date expiration.

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, PureCloud renews the endpoint’s certificate with a new certificate that includes an extended validation period..

Warning: Secure network connections fail if the active certificate has expired or is not yet valid.

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.

Warning: If you do not correctly set up the customer endpoint certificate, outbound calls from PureCloud may fail.

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 hostname that includes the protocol, destination number, and remote host.

In addition to the hostname, the URI can also contain attributes to control the connection. You apply attributes to the user portion and the host portion of the URI. You must apply attributes to the appropriate portion of the URI to operate correctly.  

The primary attributes specify the trunk selection and the transport protocol. In the case of a secure connection, the transport attribute specifies the TLS transport protocol.

Attribute Attribute location Description Values
Transport Host Transport protocol UDP | TCP | TLS
TGRP User Trunk group label User -defined inbound SIP termination identifier
Trunk context User Trunk group namespace Region specific namespace

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, PureCloud 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)

Best practice is to use a TGRP configuration as it allows for trunk selection based on attributes of the SIP URI. TGRP attributes control routing so the hostname 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. Subject name validation of the X.509 certificates fails if calls are sent directly to an IP address rather than a supported hostname.

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 record name. However public certificate authorities do not allow the use of underscore characters in common names and subject alternate names. Furthermore, you cannot include resource record names in the certificate. If the remote SIP device validates the resource record names certificate, then validation fails.

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, this is an example 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.