Certificate creation and requirements for 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 Skype for Business and Lync*, either as part of an on-prem deployment or when deploying Pexip in a public DMZ for enabling direct federation with remote SfB/Lync environments.

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.

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

Creating a certificate signing request (CSR)

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. 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 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.

In Microsoft Skype for Business and Lync integrations, your proxying nodes that take federated calls must have a proper certificate. The certificates on any externally facing nodes must be signed by a public CA provider (and thus will be trusted by a Skype for Business / Lync Edge Server). Any internally-facing nodes typically need certificates signed by your private CA.

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 (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.

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 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 and Certificate and DNS examples for an on-premises integration with Skype for Business for more information.

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).

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.

Assigning a certificate to a Conferencing Node

In Pexip Infinity, certificates are managed from the Pexip Infinity Administrator interface under Certificates > 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 > 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 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 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.

Setting the Configured FQDN for a Conferencing Node

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

The Configured 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 Configured 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 Configured 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 Configured 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):

  1. In Windows (server edition), launch Server Manager.
  2. Launch the Certification Authority tool.
  3. Expand the navigation tree for your Certification Authority and select Certificate Templates.

  4. Right-click on Certificate Templates and select Manage to open the Certificate Templates Console.

  5. Create a new template based on the existing Web Server template:

    1. Right-click on Web Server (in the list of templates) and select Duplicate Template.

    2. On the General tab, enter the Template display name and Template name for your new template, for example "Web Client and Server" and "WebClientServer" respectively.
    3. On the Extensions tab, select Application Policies and select Edit.

    4. Add Client Authentication to the set of application policies:

      1. Select Add.
      2. Select Client Authentication and select OK.
      3. Select OK.

    5. Select OK to complete the addition of the new template.
  6. You can now close down the Certificate Templates Console.

  7. Add the new template to your Certificate Authority:

    1. From the Certification Authority tool, expand the navigation tree for your Certification Authority, right-click on Certificate Templates and select New > Certificate Template to Issue.

    2. Select your new Web Client and Server template and select OK.

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.