Server Certificates

The Transport Layer Security (TLS) protocol is a cryptographic protocol that forms a secure connection between the client and the server.

For example, when a phone connects to the Connection Server, it receives the TLS certificate from the server. A certificate is a digitally-signed statement that binds the value of a public key to the identity of the service that holds the corresponding private key. Before the connection is established, the phone verifies that the certificate is valid and the requested URL matches with the one on the certificate.

A TLS-secured connection is mandatory for the Connection Server (CoS), and thus all connections both from end-users (such as CDT users) and configuration users (such as SC users) are secure.

All peer to peer connections can be secured with the Internal Server Certificate. If one of the server connections is secured, all of them must be. In addition to that, we recommend to secure connections between High-Availability Controller components (HAC-HAC), and Infrastructure Administrator and HACs (IA-HAC). Additionally, SIP bridges and external Quality Monitoring components can be secured with a certificate. Also websites used by CDT, Online Monitoring, or Reporting can be secured with a certificate to provide https://protocol.

The customer, or the ASP provider, who is responsible of setting up the system, must acquire the certificates. Same certificates can be used for several services on the same server. Same certificate can also be used on several servers if it is by request asked to be of the type that its private key (the certificate request) can be moved from one server to another, and the service that uses the certificate uses the same virtual address on every server. If the service needs to be running on several servers simultaneously, all those servers require the specific certificate for that service.

We recommend using certificates issued by a public Certification Authority (CA), only. If the system is installed using self-signed certificates, a specific client-end component must be installed that provides the trusted root for the server certificate.

Note:

Microsoft has announced a policy change to the Microsoft Root Certificate Program that will no longer allow root certificate authorities to issue X.509 certificates using the SHA-1 hashing algorithm for SSL and code signing after January 1, 2016. Using the SHA-1 hashing algorithm in digital certificates could allow an attacker to spoof content, perform phishing attacks or perform man-in-the-middle attacks.

To enhance security and provide users with undisturbed experience, we recommend that all certificates used in Sinch Contact Pro are replaced with new ones using SHA-2 algorithm.