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 client TLS 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 .
| 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 must have a Client TLS certificate assigned, and that 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 . 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:
|
Mutual TLS authentication and client/server certificates
Certificates with client authentication properties are typically not required in most Pexip Infinity deployments. However, in advanced scenarios your Conferencing Nodes' certificates may require a client authentication EKU when responding to SIP/TLS client certificate challenges.
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 mutual TLS verification checking, then that external system will verify that the certificate presented by 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, the certificates presented by the Conferencing Node and by the external system must have client and server capabilities, as appropriate.
- When a Conferencing Node is acting in a server capacity, the node's configured TLS certificate is used.
- When a Conferencing Node is acting in a client capacity, the node's configured Client TLS certificate is used.
Availability of client certificates
Public Certificate Authorities are stopping issuing certificates with client authentication EKU (Extended Key Usage) capabilities, due to a change in web browser trusted CA policy. By May 2026, it will be impossible to acquire new certificates with both client and server authentication EKUs from public CAs.
Therefore if your environment requires your Conferencing Node certificates to have client (and server) EKU then you will need to manage this through your own private Certificate Authority.
Requesting client certificates
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). By default, CSRs generated via Pexip Infinity's inbuilt CSR generator only request server certificate capabilities. You can configure the advanced settings in the CSR generator to also request client certificate capabilities (by enabling the Client authentication EKU option).
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.