You are here: Integration > Microsoft Lync / Skype for Business > Certificate creation and requirements

Certificate creation and requirements for Lync / Skype for Business integrations

Pexip Infinity supports the use of Base64-encoded X.509 SSL/TLS certificates. Such certificates are used when integrating Pexip Infinity with Microsoft Lync and Skype for Business*, either as part of an on-prem deployment or when deploying Pexip in a public DMZ for enabling direct federation with remote Lync/SfB environments.

For an on-prem integration between Lync/SfB and Pexip Infinity, it is common to use an internal/enterprise Certificate Authority (CA) for requesting and creating certificates. However, for a public DMZ deployment of Pexip Infinity, a certificate from a public TLS/SSL certificate vendor/CA such as for instance Verisign, Comodo or GlobalSign is required.

We strongly recommend that all Pexip Infinity Conferencing Node certificates should have both "Server Authentication" and "Client Authentication" Enhanced Key Usage properties.

* Note that where this documentation refers to "Lync/SfB", it represents both Microsoft Lync and Skype for Business unless explicitly stated otherwise.

Creating a certificate signing request (CSR)

The on-prem and public DMZ Lync/SfB integration guidelines both recommend that the same single certificate is installed on all Conferencing Nodes. This provides support for redundant Conferencing Node deployments and multiple SIP domains for Lync/SfB federation. Therefore, the certificate created for the Conferencing Nodes will typically need to contain multiple SANs (Subject Alternative Names). This type of certificate is also known as a UC certificate.

While this means that this single certificate will potentially contain a relatively high number of names, the administrator only has to manage a single SAN certificate across all Conferencing Node (unless multiple domain/subdomain support is required).

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.

You can use Pexip Infinity's inbuilt Certificate Signing Request (CSR) generator to assist in acquiring a server certificate from a Certificate Authority. Alternatively, you can use third-party tools such as OpenSSL toolkit.

Public DMZ environment requirements

When requesting certificates for Conferencing Nodes for public DMZ deployments:

  • the Subject name (commonName attribute) should be set to the hostname referenced by the _sipfederationtls._tcp SRV record
  • Subject Alternative Name (altNames attribute) entries must be included for every individual node in the public DMZ (including the hostname referenced in the Subject name).

See Assigning publicly-issued TLS server certificates to Conferencing Nodes for more information and examples for a public DMZ deployment.

On-prem environment requirements

When requesting certificates for Conferencing Nodes for on-prem deployments:

  • the Subject name (commonName attribute) must be the Trusted Application Pool FQDN
  • Subject Alternative Name (altNames attribute) entries must be included for every node in the pool, plus the common application pool FQDN.

See Assigning a server certificate to the Pexip Infinity Conferencing Nodes for more information and examples for an on-prem deployment.

Comparison of public DMZ and on-prem examples

When using Pexip Infinity's inbuilt CSR generator the examples below show the entries that would be required to match our example public DMZ deployment, and our example on-premises deployment (for the Europe-located pool of Pexip nodes):

Field Public DMZ environment On-prem environment (Europe)
Subject name User-provided custom Common Name User-provided custom Common Name
Custom subject name
Subject alternative names,
(and will also be included automatically),,
(and will also be included automatically)

Adding additional nodes in the future

These SAN/UC certificates can normally be updated at any time (although usually for an additional fee) from most certificate vendors.

Thus, if for instance you need to add two additional nodes, you can create a new CSR containing the original altNames and the two additional altNames, submit the CSR to the certificate vendor, pay the additional fee (which is usually per SAN entry), get an updated SAN/UC certificate and then upload this new certificate to all nodes (the original certificate will be revoked and become unusable).

Assigning a certificate to a Conferencing Node

In Pexip Infinity, certificates are managed from the Pexip Infinity Administrator interface under Platform configuration > TLS certificates. You apply a certificate to a Conferencing Node by uploading the server certificate and associated private key and then assigning it to the Conferencing Nodes in question. The certificate should be in Base64-encoded X.509 (PEM) format.

The result of uploading and assigning our example public DMZ certificate and private key would look similar to this:

Certificates issued by intermediate CAs

In most cases, server certificates are issued by intermediate Certificate Authorities (as opposed to Root CAs). 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.

The intermediate CA certificates can be bundled/concatenated in a single text file and uploaded to the Management Node by going to Platform configuration > Trusted CA certificates and selecting Import. Whenever a Certificate Authority provides a server certificate issued through one or more intermediate CAs, the provider normally also provides this bundle of intermediate CA certificates as part of the process.

To identify whether or not a certificate has been issued by an intermediate CA, ensure that the certificate has a .cer file extension and open the certificate file on a Windows PC. Navigating to the Certification Path pane will display the CA structure of the certificate.

In the example below, the certificate for has been issued by the intermediate CA Gandi Standard SSL CA, which is a subordinate CA for UTN-USERFirst-Hardware, which in turn is a subordinate CA for USERTrust, which is the root CA in this case:

In this particular case, UTN-USERFirst-Hardware and Gandi Standard SSL CA are the intermediate Certificate Authorities for the certificate. This means that we would have to bundle together these two CA certificates in a text file and upload it using the Import trusted CAs facility on the Management Node in order to ensure proper certificate chain trust for the server certificates we install on the Conferencing Nodes.

Configuring the SIP TLS FQDN for a Conferencing Node

When assigning a server certificate to a Conferencing Node, you must configure the SIP TLS FQDN for this Conferencing Node to an FQDN matching that of the certificate. The SIP TLS FQDN setting is configurable for each Conferencing Node, by going to Platform configuration > Conferencing Nodes and selecting the Conferencing Node in question.

The SIP TLS FQDN setting allows the administrator to set the DNS FQDN that a Conferencing Node will use when presenting its identity to connecting clients (by controlling which value the Conferencing Node will insert in its SIP contact header). Each Conferencing Node must have a unique SIP TLS FQDN.

Using our public DMZ example, when assigning a Conferencing Node a common certificate issued to but where that certificate contains each Conferencing Node's FQDN as one of the certificate's altNames, you would then normally also configure the node's hostname ( in this example) as the SIP TLS FQDN for this Conferencing Node (and would also be the DNS A-record pointing to the publicly-reachable IP address of the Conferencing Node in question):

In our on-premises example, the node with a hostname of would have its SIP TLS FQDN also set to, and so on for the other Conferencing Nodes.