You are here: Administration > Platform configuration > TLS and trusted CA certificates

Managing TLS and trusted CA certificates

TLS certificates are used by the Management Node and each Conferencing Node to verify their identity to clients connecting to them over HTTPS (web) or SIP TLS. These clients include:

  • video endpoints
  • web browsers (including Infinity Connect Web App)
  • Infinity Connect Mobile clients (certificates are mandatory for these clients)
  • third-party video network infrastructure devices.

Wildcard TLS certificates are not supported in SIP or Microsoft Lync / Skype for Business environments (as per RFC 5922). If you are using SIP or Lync / Skype for Business, your Conferencing Nodes must not use wildcard TLS certificates.

Note that communication between the Management Node and Conferencing Nodes, and between Conferencing Nodes themselves, does not rely on TLS certificates; instead it uses an IPsec transport. For more information see Encryption methodologies.

This topic covers:

Certificate usage overview

The clients that connect to Pexip Infinity over TLS must trust the identity of the Certificate Authority (CA) that signed the node's TLS certificate. The Pexip Infinity platform ships with a self-signed certificate for the Management Node, and each Conferencing Node is deployed with a self-signed certificate. These certificates have a 4096 bit public key and are also appended with 2048 bit Diffie-Hellman parameters.

As these certificates are self-signed, they will not be trusted by clients. We therefore recommend that you replace these certificates with your own certificates that have been signed by either an external CA or a trusted internal CA. You can use Pexip Infinity's inbuilt Certificate Signing Request (CSR) generator to assist in acquiring a server certificate from a Certificate Authority.

You can use a tool such as https://www.sslshopper.com/ssl-checker.html to verify certificates and the chain of trust (specify port 5061 i.e. use the format <domain>:5061 for the server hostname to ensure that SIP TLS connections are checked).

The Management Node and Conferencing Nodes enable HSTS (HTTP Strict Transport Security) to ensure greater security. This means that if your deployment moves from using a valid TLS certificate to using an invalid certificate (e.g. you redeploy a Conferencing Node, or your certificate expires or is invalidated for some reason) then certain web browsers will stop you from accessing that node via the web when using the DNS name of that node, until you correct the certificate issue. You may browse directly to the IP address of the node in the meantime.

Overview of process for encrypting communication using TLS

In general, to achieve encrypted communication using TLS the following must happen:

  1. The CA issues a signed certificate which is uploaded to the server.
  2. When a client needs to communicate with the server, it sends a request to the server asking it to provide identification.
  3. The server sends back a copy of its TLS certificate and its public key.
  4. The client checks whether the CA that issued the certificate is one that it trusts.
  5. If the CA is trusted, and if the certificate is otherwise valid, the client creates a session key encrypted with the server's public key and sends it to the server.
  6. The server decrypts the session key. It then uses the session key to encrypt an acknowledgment which it sends to the client in order to initiate the encrypted communication.
  7. The server and the client now encrypt all communication using the session key.

Alarms

An alarm is raised on the Management Node if:

  • the Management Node or a Conferencing Node has no associated TLS certificate
  • a TLS certificate has an incomplete chain of trust to the root CA certificate
  • one or more of your trusted CA certificates is due to expire within the next 30 days.

Managing a node's TLS server certificate

You can upload and view the TLS server certificates that are used by the Management Node and by each Conferencing Node.

Note that after making any changes to certificates, there will be a delay of up to 1 minute while the files are synchronized to the relevant Management Node or Conferencing Node.

Uploading a TLS server certificate

To upload a new TLS server certificate for the Management Node or a Conferencing Node:

  1. From the Pexip Infinity Administrator interface, go to Platform configuration > TLS certificates.
  2. Select Add TLS certificate.
  3. Complete the following fields:

    TLS certificate

    Paste the PEM-formatted certificate into the text area or alternatively select the file containing the new TLS certificate.

    You must upload the certificate file that you have obtained from the Certificate Authority (typically with a .CRT or .PEM extension). Do not upload your certificate signing request (.CSR file).

    The certificate must be valid for the hostname or FQDN of the Management Node or Conferencing Node to which it will be assigned.

    You can paste multiple certificates into the text area, but one of those certificates must pair with the associated private key.

    Private key

    Paste the PEM-formatted private key into the text area or alternatively select the file containing the private key that is associated with the new TLS certificate.

    Private key files typically have a .KEY or .PEM extension. Pexip Infinity supports RSA and ECDSA keys.

    TLS parameters

    Optionally, paste any additional PEM-formatted parameters into the text area or alternatively select the file containing the parameters that are to be associated with the new TLS certificate.

    Custom DH parameters and an EC curve name for ephemeral keys can be added. Such parameters can be generated through the OpenSSL toolkit using the commands openssl dhparam and openssl ecparam. For example, the command openssl dhparam -2 -outform PEM 2048 generates 2048 bit DH parameters.

    Note that these parameters can alternatively be added 'as is' to the end of the TLS certificate.

    Nodes

    Select one or more nodes to which the new TLS certificate is to be applied.

    If required, you can upload a certificate and then apply it to a node later.

  4. Select Save.

Viewing or modifying existing TLS certificates and changing node assignments

To view information about an existing TLS certificate, change a certificate's contents, or change the nodes to which a certificate is applied:

  1. Go to Platform configuration > TLS certificates.

    By default you are shown a list and the current status of All certificates that have been uploaded. A Status of Temporary means that it is a self-signed certificate.

    You can alternatively select to view Certificates by Node to see which certificate has been assigned to the Management Node or to a particular Conferencing Node.

  2. Select the subject name of the certificate you want to view or modify.

    The decoded certificate data is shown, including any chain of trust information.

  3. If required, you can modify the:

    • Nodes to which the certificate is assigned
    • TLS certificate data
    • TLS parameters associated with the certificate.

    You cannot modify the private key.

  4. Select Save.

Uploading multiple TLS certificate files

To upload a batch of TLS certificates:

  1. Go to Platform configuration > TLS certificates.
  2. Select Import files.
  3. Select Choose Files to pick one or more PEM-formatted text files that you want to import.

    • The files should contain server TLS certificates with matching private keys.
    • Private keys can be uploaded as separate files or appended to the server TLS certificate file(s).
    • DH or EC parameters may be appended to each server TLS certificate.

    Note that trusted CA certificate files can also be imported via this method if required.

  4. Select Import.

    This adds the certificates in the selected files to the existing list of TLS certificates (or to the list of trusted CA certificates, if appropriate). If a certificate with the same subject name already exists (e.g. when replacing an expired certificate), that certificate will be updated with the new contents from the file. Any duplicate certificates are ignored.

  5. You can then select each imported TLS certificate in turn and assign it to a Management Node or one or more Conferencing Nodes as appropriate.

Verifying peer certificates for SIP TLS connections

For connections over SIP TLS, you can use the SIP TLS verification mode setting to control whether the certificate presented by the peer is verified before the connection is allowed. When this setting is enabled:

  • The peer certificate is verified (in date, issued by a trusted authority etc).
  • OCSP, if enabled, is used to check that the certificate has not been revoked (see Using OCSP to check the status of certificates below for more information).
  • The identity of the peer as presented in the certificate is checked against the identity expected by Pexip Infinity.
  • The peer certificate must be a client certificate (see Mutual TLS authentication and client/server certificates below for more information) — otherwise you will get "unsupported certificate" errors in the support log.

When this setting is enabled, all peers (including endpoints connecting directly with Pexip Infinity) must have their own certificate.

To enable or disable this setting, go to Platform configuration > Global settings. The options available are:

Field Description
SIP TLS verification mode

Determines whether to verify the peer certificate for connections over SIP TLS.

Off: the peer certificate is not verified; all connections are allowed.

On: the peer certificate is verified, and the peer's remote identities (according to RFC5922) are compared against the Application Unique String (AUS) identified by Pexip Infinity before the connection is allowed.

Using OCSP to check the status of certificates

Pexip Infinity allows you to use Online Certificate Status Protocol (OCSP) to check whether a certificate has been revoked. TLS certificates that support OCSP are encoded with the URL of an OCSP responder — a server that will check and respond with the status of the certificate.

OCSP checking only applies when SIP TLS verification mode is On. To enable or disable the use of OCSP, and to configure the URL of the OCSP responder, go to Platform configuration > Global settings. The options available are:

Field Description
OCSP state

Determines whether OCSP is used to check the status of TLS certificates.

Off: OCSP is not used.

On: OCSP is used, and the request is sent to the URL specified in the TLS certificate. If no URL is specified in the TLS certificate, the OCSP responder URL configured below is used.

Override: OCSP is used, and the request is sent to the OCSP responder URL configured below, regardless of any URL encoded in the TLS certificate.

OCSP responder URL

The URL to which OCSP requests are sent if either:

  • the OCSP state is set to On but no URL is present in the TLS certificate, or
  • the OCSP state is set to Override (in which case any URL present in the certificate is ignored).

Mutual TLS authentication and client/server certificates

If a Conferencing Node makes an outbound connection to, or receives an incoming connection from, a video network infrastructure device (such as a Cisco VCS) that is configured to perform TLS verification checking, then that external system will verify that the certificate on the Conferencing Node is valid. In these cases, both the Conferencing Node and the external system can adopt the role of a client as well as acting as a server. Therefore, for mutual TLS authentication — where both parties are verifying the other party's certificate — both the Conferencing Node's TLS server certificate and the external system's certificate must be capable of being used as a client certificate as well as a server certificate.

A certificate's capabilities are contained in its Enhanced Key Usage properties. They indicate if the certificate can be used for server authentication (typically shown as "TLS Web Server Authentication") and for client authentication (typically shown as "TLS Web Client Authentication").

When requesting certificates for your Conferencing Nodes, if you want the node to be able to verify itself as a client when connecting to an external system, then you must request that the certificate can act as a client certificate (as well as a server certificate). All CSRs generated via Pexip Infinity's inbuilt CSR generator always request client certificate and server certificate capabilities.

If you create your certificate signing requests via the OpenSSL toolkit, then you can modify the [v3_req] section of your openssl request configuration file so that it contains extendedKeyUsage=serverAuth, clientAuth . Other Certificate Authorities have different methods of requesting client authentication.

The following table summarizes the certificate requirements for inbound connections to, and outbound connections from Conferencing Nodes:

  Inbound SIP TLS connections Outbound SIP TLS connections
When SIP TLS verification mode is Off
  • The Conferencing Node's certificate must have server authentication properties.
  • Pexip Infinity enables ADH ciphers (Anonymous Diffie-Hellman) — this enables support for endpoints that do not have certificates.
  • Pexip Infinity may or may not authenticate the far end, depending on which cipher suite is selected by the far end:
    • if an ADH cipher is selected, the far end is not authenticated and certificates are not exchanged
    • if a cipher that requires authentication is selected and a certificate is exchanged, that certificate must be valid (issued by a trusted authority, in date etc.) and it must be a server certificate.
When SIP TLS verification mode is On

As above, plus:

  • The client system/endpoint must present a valid certificate (issued by a trusted authority, in date etc.) and it must be a client certificate.
  • The identity of the peer as presented in the certificate must match the identity expected by Pexip Infinity.

As above, plus:

  • The identity of the peer as presented in the certificate must match the identity expected by Pexip Infinity.

This means that Pexip Infinity cannot connect out over TLS to endpoints that don't have a certificate (even if an ADH cipher is selected) — you must use TCP/UDP instead.

When OCSP state is On or Override (and SIP TLS verification mode is On)
  • The client certificate must not be revoked.
  • The far end certificate must not be revoked.
If the far end system performs a TLS verification process
  • The Conferencing Node's certificate must have client authentication properties and must not be a self-signed certificate.
  • The Conferencing Node's certificate must have client authentication properties and must not be a self-signed certificate.

Managing trusted CA certificates

Trusted CA certificates are used within Pexip Infinity to:

  • verify client certificates presented to Pexip Infinity when SIP TLS verification mode is enabled
  • provide a certificate chain of trust when clients connect to a Conferencing Node over SIP TLS
  • verify the server certificate on a video network infrastructure device when a Conferencing Node makes an SIP TLS outbound connection to that device, and that device chooses a cipher suite that requires authentication and a certificate is exchanged
  • verify connections to an LDAP server.

Pexip Infinity ships with an inbuilt list of trusted CA certificates. This list is based on the Mozilla CA Certificate Store and cannot be modified.

In addition, you can upload a customized set of trusted CA certificates to the Pexip Infinity platform.

Chain of trust

For a server's TLS certificate to be trusted by a client, the client must be configured to trust the Certificate Authority (CA) that signed the server certificate. Many CAs do not sign with their root certificate, but instead with an intermediate certificate. Clients, however, may only trust the root CA. Therefore the server (in this case the Management Node or Conferencing Node) is often required to present a full certificate chain along with their TLS server certificate.

When this is the case, the chain of intermediate CA certificates must be installed on the Management Node to ensure that the certificate chain of trust is properly established when clients connect to a Conferencing Node over SIP TLS.

To do this you must upload a custom Trusted CA certificates file that contains all the required CA certificates, one after each other, in PEM format.

Uploading and managing additional trusted CA certificates

You can upload a customized set of trusted CA certificates to the Pexip Infinity platform. Any trusted CA certificates uploaded here are used in addition to the default set of trusted CA certificates that ships with Pexip Infinity.

To manage the set of custom trusted CA certificates, go to Platform configuration > Trusted CA certificates. This shows a list and the current status of all the trusted CA certificates that have been uploaded. From here you can:

  • Upload a file of Trusted CA certificates: select Import files, select Choose Files to pick one or more PEM files that you want to import, and then select Import.

    This adds the certificates in the selected files to the existing list of trusted CA certificates (or to the list of TLS certificates, depending on the certificate types contained in the file). If a certificate with the same subject name already exists (e.g. when replacing an expired certificate), that certificate will be updated with the new contents from the file. Any duplicate certificates are ignored.

  • View or modify an existing certificate: select the Subject name of the certificate you want to view. The decoded certificate data is shown.

    If required, you can modify the PEM-formatted certificate data and select Save.

  • Download all certificates: select Export. A ca-certificates.pem file containing all of the custom-added certificates in PEM format is created and automatically saved to your local file system.
  • Delete one or more certificates: select the boxes next to the certificates to be deleted, and from the Action drop-down menu select Delete selected Trusted CA certificates and select Go.