Certificate creation and requirements
for Skype for Business / Lync integrations
Pexip Infinity supports the use of Base64-encoded X.509 SSL/TLS certificates. Such certificates are used when integrating Pexip Infinity with Microsoft Skype for Business and Lync
For an on-prem integration between SfB/Lync 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
- Configuring Windows Server Manager to use a certificate template with client and server capabilities
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 "SfB/Lync", it represents both Microsoft Skype for Business and Lync unless stated otherwise.
The on-prem and public DMZ SfB/Lync 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 SfB/Lync 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 Skype for Business / Lync environments (as per RFC 5922). If you are using SIP or Skype for Business / Lync, 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.
When requesting certificates for Conferencing Nodes for public DMZ deployments:
The Subject name (commonName attribute) should be set to the target hostname referenced by the _sipfederationtls._tcp SRV record (the pool name of the Conferencing Nodes).
In our examples, if the DNS SRV record is:
_sipfederationtls._tcp.vc.example.com. 86400 IN SRV 1 100 5061 px.vc.example.com.
then the Subject name must be px.vc.example.com
The Subject Alternative Name (altNames attribute) entries must include:
- the target hostname referenced in the Subject name
- the FQDNs of all of the public DMZ nodes that are involved in call signaling
- the domain names that are used in any DNS SRV records that route calls to those Conferencing Nodes (e.g. vc.example.com from the example _sipfederationtls SRV record above).
- Assign the same certificate to all of the public DMZ nodes that are involved in call signaling.
See Assigning publicly-issued TLS server certificates to Conferencing Nodes for more information and examples for a public DMZ deployment.
When requesting certificates for Conferencing Nodes for on-prem deployments:
- The Subject name (commonName attribute) must be the Trusted Application Pool FQDN (such as confpool-eu.vc.example.com in our examples).
- The Subject Alternative Name (altNames attribute) entries must include the Trusted Application Pool FQDN (i.e. a repeat of the Subject name), plus the FQDNs of all of the nodes in the pool that are involved in signaling.
- Assign the same certificate to all of the enterprise nodes that are involved in call signaling.
See Assigning the certificate to Conferencing Nodes for more information and examples for an on-prem deployment.
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||px.vc.example.com||confpool-eu.vc.example.com|
|Subject alternative names||px01.vc.example.com, px02.vc.example.com, vc.example.com (and px.vc.example.com will also be included automatically)||conf01.vc.example.com, conf02.vc.example.com, conf03.vc.example.com
(and confpool-eu.vc.example.com will also be included automatically)
See Certificate and DNS examples for public DMZ / hybrid integrations with Skype for Business / Lync and Certificate and DNS examples for an on-premises integration with Skype for Business / Lync for more information.
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).
If you expect to deploy more nodes in the future, and have a predictable naming scheme for your nodes, you can also add extra altNames in anticipation of those future nodes.
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 px.vc.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 (px01.vc.example.com in this example) as the SIP TLS FQDN for this Conferencing Node (and px01.vc.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 conf01.vc.example.com would have its SIP TLS FQDN also set to conf01.vc.example.com, and so on for the other Conferencing Nodes.
Configuring Windows Server Manager to use a certificate template with client and server capabilities
If a Conferencing Node connects with a video network infrastructure device that performs a TLS verification process, the server certificate on the Conferencing Node needs Client Authentication capabilities. By default, the "Web Server" certificate template used by the Microsoft Certification Authority tool in Active Directory Certificate Services (AD CS) creates a certificate with Server Authentication capabilities only. This section describes how to configure Windows Server Manager to use a certificate template with client and server capabilities.
To set up a certificate template with Server and Client Authentication (using Windows Server Manager 2016):
- In Windows (server edition), launch .
- Launch the tool.
- Expand the navigation tree for your Certification Authority and select .
Right-click onand select to open the .
Create a new template based on the existingtemplate:
Right-click on(in the list of templates) and select .
- On the Template display name and Template name for your new template, for example "Web Client and Server" and "WebClientServer" respectively. tab, enter the
- On the tab, select and select .
Add Client Authentication to the set of application policies:
- Select .
- Select Client Authentication and select .
- Select .
- Select to complete the addition of the new template.
- You can now close down the Certificate Templates Console.
Add the new template to your Certificate Authority:
The new Web Client and Server template can now be used when submitting a certificate request to that Microsoft Certification Authority.
Note that all CSRs generated via Pexip Infinity's inbuilt CSR generator always request client certificate and server certificate capabilities.