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 the Infinity Connect web app)
  • Infinity Connect mobile clients (certificates are mandatory for these clients)
  • third-party video network infrastructure devices
  • Outlook clients (if the VMR Scheduling for Exchange service is enabled).

Yous can employ Pexip Infinity's inbuilt Certificate Signing Asking (CSR) generator to assist in acquiring a server certificate from a Certificate Authority.

This topic covers:

  • Certificates overview
    • Document usage guidelines
    • Alarms
  • Managing a node's TLS server certificate
    • Uploading a TLS server certificate
    • Viewing or modifying existing TLS certificates and changing node assignments
    • Uploading multiple TLS document files
    • Downloading an existing TLS certificate
    • Replacing an existing certificate (past generating a new certificate signing request)
  • Managing trusted CA certificates

Further information:

  • To configure Pexip Infinity to verify peer certificates, and mutual TLS authentication, encounter Verifying SIP TLS connections with peer systems.
  • To use the Microsoft Certification Authority tool in Agile Directory Certificate Services (Advertizing CS), see Configuring Windows Server Manager to employ a certificate template with client and server capabilities.

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

Certificates overview

The Public Key Infrastructure (PKI) provides a framework for digital certificate direction. It provides the following benefits:

  • Authentication: identities are validated to ensure that only authorized users and devices have access to a server.
  • Encryption: sessions tin can exist encrypted, so information can be transmitted privately.
  • Data integrity: ensures that any messages or data transferred to and from devices and servers is not altered.

The principal elements of the PKI are:

  • Public/private key pairs: public and individual keys are used to encrypt and decrypt the data being transferred to a server. Only the private fundamental, which is kept secret past the server, can decrypt the information that is encrypted by the public key. This machinery is known as asymmetric cryptography (every bit the encryption is done using non-identical keys); the two keys are mathematically related, and whatsoever is encrypted with a public primal tin only be decrypted by its corresponding individual cardinal and vice versa.
  • Certificate: a document contains the public key and information about its owner (oft referred to as the bailiwick and is typically expressed every bit a hostname or domain proper name) and its issuer (typically a trusted, third-political party Certificate Authority). This certificate metadata is formatted according to the ITU-T X.509 international standard. A document is not considered valid unless it has been directly or indirectly signed by a trusted CA.
  • Certificate Authority (CA): a CA is an organization such as Symantec or Comodo that issues digital certificates to corporations after having verified the applicant'south identity. The certificate is proof that a certain server or website is owned by a certain organization. A CA can use its own individual key to sign the certificates it bug. That signed certificate can and so exist verified as being signed by a trusted CA by checking the signature against the CA's own root certificate (via its public key). However, many CAs do not sign with their root certificate, but instead with an intermediate certificate — an intermediate authorization is a certificate issuer that has itself been issued by a root or another higher level intermediate authority. This method creates a concatenation of trust.
  • Concatenation of trust: when a device validates a certificate, it compares the document issuer with its listing of trusted CAs. If a match is not institute, information technology checks if the certificate of the issuing CA was issued by a trusted CA, and so on until the end of the certificate chain. The meridian of the chain, the root certificate, must be issued by a trusted Certificate Authorization. Web browsers and other clients typically have a list of CA certificates that they trust, and can thus verify the certificates of individual servers, nevertheless, the server is often required to nowadays a full certificate chain along with its server document.

TLS document usage inside Pexip Infinity

The certificates used within Pexip Infinity are standard digital certificates, but they are referred to as TLS certificates as they are used when establishing a TLS connection to a Pexip node.

The clients that connect to Pexip Infinity over TLS must trust the identity of the Document Authorization (CA) that signed the node'south TLS document. The Pexip Infinity platform ships with a self-signed document for the Direction Node, and each Conferencing Node is deployed with a cocky-signed certificate. These certificates have a 4096 bit public key and are also appended with 2048 bit Diffie-Hellman parameters. Each self-signed certificate will expire after 30 days.

As these certificates are self-signed, they will not exist trusted past clients. We therefore recommend that you supercede these certificates with your own certificates that have been signed by either an external CA or a trusted internal CA.

You lot tin can use a tool such as https://www.sslshopper.com/ssl-checker.html to verify certificates and the concatenation of trust (specify port 5061 i.e. employ 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 Ship 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) so sure spider web browsers will cease yous from accessing that node via the web when using the DNS proper name of that node, until you correct the certificate issue. You may browse straight to the IP address of the node in the meantime.

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, information technology sends a asking to the server asking it to provide identification.
  3. The server sends back a copy of its TLS document and its public key.
  4. The customer checks whether the CA that issued the document is 1 that it trusts.
  5. If the CA is trusted, and if the certificate is otherwise valid, the client creates a session primal encrypted with the server'due south public cardinal and sends it to the server.
  6. The server decrypts the session key. It then uses the session central to encrypt an acknowledgment which it sends to the client in lodge to initiate the encrypted communication.
  7. The server and the client now encrypt all communication using the session key.

Certificate usage guidelines

When requesting/generating certificates for your Pexip Infinity platform:

  • Do not employ SHA-1 certificates on your Conferencing Nodesouth — use SHA-256 certificates instead. (Some clients, such as iOS devices, already mandate the utilise of SHA-256 certificates, and browsers will soon stop accepting SHA-one certificates.)
  • If browsers (Infinity Connect web app clients, for example) need to access your Pexip Infinity platform, ensure that your certificates incorporate at least ane subject alternative proper noun (SAN) entry — typically a repeat of the Common Name. (Chrome and Firefox browsers are dropping back up for Common Name matching.)

Wildcard TLS certificates are not supported in SIP or Microsoft Skype for Business organization / Lync environments (every bit per RFC 5922). If you lot are using SIP or Skype for Concern / Lync, your Conferencing Nodes must non utilize wildcard TLS certificates.

Alarms

An warning is raised on the Direction Node if:

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

Managing a node's TLS server certificate

Yous tin can upload, view/modify, delete and download the TLS server certificates that are used by the Management Node and by each Conferencing Node. You tin can likewise generate a certificate signing request for an existing certificate / subject name.

Note that after making any changes to certificates, you lot demand to expect for the files to be synchronized to the relevant Direction Node or Conferencing Node (typically after approximately one minute). If changing the certificates in a concatenation, a reboot of the associated Conferencing Nodes may be required if the changes do not produce the desired consequence.

Uploading a TLS server certificate

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

  1. From the Pexip Infinity Administrator interface, get to > TLS certificates.
  2. Select Add TLS certificate.

  3. Complete the post-obit fields:

    TLS certificate

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

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

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

    You lot tin can paste multiple certificates into the text expanse, only one of those certificates must pair with the associated private cardinal.
    Private primal

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

    Individual key files typically have a .Primal or .PEM extension. Pexip Infinity supports RSA and ECDSA keys.
    Private key passphrase If the individual fundamental is encrypted, you must also supply the associated passphrase.
    TLS parameters

    Optionally, paste any additional PEM-formatted parameters into the text expanse 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 tin be added. Such parameters can exist generated through the OpenSSL toolkit using the commands openssl dhparam and openssl ecparam. For example, the control openssl dhparam -two -outform PEM 2048 generates 2048 flake DH parameters.

    Notation that these parameters tin alternatively exist added 'as is' to the stop of the TLS certificate.
    Nodes

    Select ane or more than nodes to which the new TLS document is to be applied.

    If required, you can upload a certificate so utilize information technology to a node later.
  4. Select Salvage.

If a document with the same field of study name already exists (e.g. when replacing an expired certificate), the new certificate is uploaded alongside the original certificate (unless the issuer and series number details are identical, in which case the existing certificate is updated with the new contents from the file). If the original TLS certificate was assigned to ane or more Conferencing Nodes y'all need to motility those node assignments over to the new document.

Viewing or modifying existing TLS certificates and changing node assignments

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

  1. Go to > TLS certificates.

    By default you are shown a list and the current status of All certificates that have been uploaded. Condition values include:

    • Good: information technology is a good, valid document.
    • Temporary: information technology is a self-signed certificate.
    • Weak signature: the certificate is signed with SHA-ane or some other old signature. We recommend that you apply SHA-256 certificates instead.
    • Empty subject: the certificate only has SANs. Information technology is a valid certificate but many browsers will non have it.
    • Over <n> days: all browsers volition not trust certificates that are valid for longer than 825 days, and Safari will too not trust certificates with a kickoff date on or after 1st September 2020 and that are valid for longer than 398 days.
    • <north> days left: when the certificate is due to elapse within the adjacent 60 days.
    • Expired: when the certificate has expired.

    You tin can alternatively select to view Certificates past Node to come across which certificate has been assigned to the Management Node or to a particular Conferencing Node.

  2. Select the subject name of the document y'all want to view or change.

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

  3. If required, y'all tin can modify the:

    • Nodes to which the certificate is assigned. If you lot assign a certificate to a node, it will automatically supplant whatever other document that was previously assigned to that node.
    • TLS certificate information (past expanding the PEM-formatted data department).
    • TLS parameters associated with the certificate (by expanding the PEM-formatted information department).

    Y'all cannot modify the private key.

  4. Select Relieve.

Uploading multiple TLS certificate files

To upload a batch of TLS certificates:

  1. Go to > TLS certificates.
  2. Select Import files.

  3. Select Choose Files to option one or more than PEM-formatted text files that you lot want to import.

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

    Annotation that trusted CA certificate files can likewise be imported via this method if required.

  4. Enter the Private key passphrase if the private primal is encrypted.

  5. 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).

  6. You tin and then select each imported TLS certificate in turn and assign it to a Direction Node or one or more than Conferencing Nodesouth as advisable.

If a certificate with the same bailiwick name already exists (e.g. when replacing an expired certificate), the new certificate is uploaded alongside the original certificate (unless the issuer and serial number details are identical, in which case the existing certificate is updated with the new contents from the file). If the original TLS certificate was assigned to one or more Conferencing Nodes you need to motility those node assignments over to the new document.

Deleting an existing TLS certificate

To delete one or more TLS certificates:

  1. Go to > TLS certificates.
  2. Select the boxes next to the certificates to exist deleted, and from the Action drop-downwardly carte select Delete selected TLS certificates and select Go.

Downloading an existing TLS certificate

To download an existing TLS certificate:

  1. Go to > TLS certificates.

  2. Select the subject name of the certificate you want to download.

    The certificate information is shown.

  3. Go to the lesser of the page and select Download.

  4. By default the certificate itself and any intermediate certificates are selected to be included in the download.

    Y'all tin also choose to include the private primal (in which example you must also supply a passphrase).

  5. Select the download format, either PEM or PKCS # 12 (PFX).

  6. Select Download.

    A file called <subject_name>_certificate or <subject_name>_keycert (if the private key was included) with either a .pem or .pfx extension is downloaded. This file contains the certificate and/or the individual central as requested.

    You can as well download multiple certificates into ane file: select the boxes next to the certificates to be downloaded, and from the Action drib-down menu select Download and select Go. In this instance the generated file is called all_certificates or all_keycerts (if individual keys were included).

Note that you cannot download a temporary / self-signed document.

You lot tin can use the Pexip Infinity Management Node to convert PEM certificates to PFX format (or vice versa), by uploading a PEM-formatted certificate and so downloading it again in PFX format. When downloading you can also include the individual key and all necessary intermediate certificates in the PFX bundle.

Replacing an existing certificate (past generating a new document signing request)

You lot tin can generate a certificate signing asking (CSR) for an existing document / subject field name, for example if your current document is shortly due to elapse and you desire to replace it. Before generating the CSR y'all can change the certificate data to be included in the new request, such every bit adding extra subject area alternative names (SANs) to those already present in the existing document.

For instructions on how to do this, see Requesting a document signing asking (CSR) for an existing certificate / bailiwick name.

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 document concatenation 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 a SIP TLS outbound connectedness to that device, and that device chooses a cipher suite that requires authentication and a document is exchanged
  • verify connections to an LDAP server
  • verify connections to an Commutation on-premises server when using VMR Scheduling for Commutation or One-Impact Join.
  • verify connections to an endpoint's API, if required, when using One-Touch Join.

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

In addition, y'all tin upload a customized gear up of trusted CA certificates to the Pexip Infinity platform.

Chain of trust

For a server's TLS document to exist 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, simply instead with an intermediate certificate. Clients, however, may only trust the root CA. Therefore the server (in this example the Management Node or Conferencing Node) is ofttimes required to nowadays a total 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 document 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 boosted 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 > Trusted CA certificates. This shows a list and the current status of all the trusted CA certificates that have been uploaded. From here you lot can:

  • Upload a file of Trusted CA certificates: select Import files, select Choose Files to option i 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 aforementioned discipline name already exists (e.g. when replacing an expired certificate), the new document is uploaded aslope the original certificate (unless the issuer and serial number details are identical, in which instance the existing certificate is updated with the new contents from the file).

  • View or alter an existing certificate: select the Bailiwick name of the document you desire 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 i or more certificates: select the boxes side by side to the certificates to be deleted, and from the Action drop-downwardly menu select Delete selected Trusted CA certificates and select Get.