Verifying SIP TLS connections with peer systems

When a Conferencing Node attempts to connect to a SIP system, such as an endpoint or a video network infrastructure device, the Pexip Infinity platform can be configured to verify whether the certificate presented by the peer system is valid before the connection is allowed.

In addition, if the peer system is also configured to perform TLS verification checking (mutual TLS authentication), then that external system will verify that the certificate on the Conferencing Node is valid and has the appropriate client authentication capabilities.

Verifying peer certificates for SIP TLS connections

For outbound 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 from a Conferencing Node 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 server certificate, 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 > Global settings > Security.

Field Description
SIP TLS verification mode

Determines whether to verify the peer certificate for outbound connections over SIP TLS. The options are:

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 — the SIP URI — before the connection is allowed.

Default: Off.

The following table summarizes the certificate requirements for outbound connections from Conferencing Nodes:

State Outbound SIP TLS connections
When SIP TLS verification mode is Off Pexip Infinity will authenticate the far end if the far end selects a cipher that requires authentication and a certificate is exchanged. In which case, 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 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 — you must use TCP/UDP instead.

When OCSP state is On or Override (and SIP TLS verification mode is On) 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 (see Mutual TLS authentication and client/server certificates below for more information).

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 > Global settings > Security. 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 specified in the OCSP responder URL field, regardless of any URL encoded in the TLS certificate.

Default: Off.

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.