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
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.
This topic covers:
- Creating a certificate signing request (CSR)
- Assigning a certificate to a Conferencing Node
- Certificates issued by intermediate CAs
- Configuring the SIP TLS FQDN for a Conferencing Node
General information on managing certificates within Pexip Infinity can be found at Managing TLS and trusted CA certificates.
* Note that where this documentation refers to "Lync/SfB", it represents both Microsoft Lync and Skype for Business unless explicitly stated otherwise.
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.
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||sip.example.com||eu-px.example.com|
|Subject alternative names||conf01.example.com, conf02.example.com
(and sip.example.com will also be included automatically)
|eu-px01.example.com, eu-px02.example.com, eu-px03.example.com
(and eu-px.example.com will also be included automatically)
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).
In Pexip Infinity, certificates are managed from the Pexip Infinity Administrator interface under . 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:
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 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 sip.pexipdemo.com 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 sip.pexipdemo.com certificate. This means that we would have to bundle together these two CA certificates in a text file and upload it using the Management Node in order to ensure proper certificate chain trust for the server certificates we install on the Conferencing Nodes.trusted CAs facility on the
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 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 sip.example.com 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 (conf01.example.com in this example) as the SIP TLS FQDN for this Conferencing Node (and conf01.example.com 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 eu-px01.example.com would have its SIP TLS FQDN also set to eu-px01.example.com, and so on for the other Conferencing Nodes.