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

For an on-prem integration between 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.

* Note that where this documentation refers to "Lync", 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 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 federation. Therefore, the certificate created for the Conferencing Nodes will typically need to contain multiple SANs (Subject Alternate 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).

To acquire a server certificate from a Certificate Authority (CA), a certificate signing request (CSR) has to be created and submitted to the CA. One common way of creating a CSR is through the OpenSSL toolkit (http://www.openssl.org), available for Windows, Mac and Linux.

If you are using OpenSSL to create a CSR that includes SAN entries, you must prepare a special configuration file to use with the openssl req command. For example, to create a certificate containing the following Common Name and SANs:

commonName = sip.example.com
altNames = sip.example.com, conf01.example.com, conf02.example.com

the configuration file could look as follows:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
[req_distinguished_name]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg city)
organizationName = Organization name (full company or personal name)
organizationalUnitName = Organizational Unit Name (eg section)
emailAddress = Email Address
emailAddress_max = 64
commonName = Common Name
commonName_max = 64
[v3_req]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = sip.example.com
DNS.2 = conf01.example.com
DNS.3 = conf02.example.com

In the section above marked [req] we have added req_extensions = v3_req — this ensures that the section called [v3_req] is included when creating the CSR. Inside the [v3_req] section, the line subjectAltName = @alt_names ensures that the section [alt_names] is used when deciding which SAN entries this CSR should include. In this example, the SAN entries (DNS.1, DNS.2 and DNS.3) include sip.example.com, conf01.example.com and conf02.example.com. The Common Name entry that we intend to use is duplicated into the Subject Alternate Name list — this is best practice and ensures that all of the nodes can use the same certificate.

Note that this is just an example — it uses the names from our example public DMZ deployment. For our example on-prem deployment the commonName/DNS.1 value would be eu-px.example.com, DNS.2 would be eu-px01.example.com and so on for the Europe-located pool of Pexip nodes.

If you use this configuration file as the basis for your own CSR creation, the only elements you normally need to modify are the items in bold (sip.example.com, conf01.example.com and conf02.example.com) and you may need to add extra DNS.n altNames entries if required. Replace these names with the SAN entries as required for your certificate i.e. with the actual names as used in your deployment.

We will store this configuration file as example.cnf and then create our CSR using the following command:

openssl req -out sip.example.com.csr -new -newkey rsa:2048 -nodes -keyout sip.example.com.key -config ./example.cnf

In the above command, we tell openssl to read our configuration file with the -config ./example.cnf parameter at the end of the command. Note that the openssl command will vary depending on which operating system you are using. When running this command, the user will be prompted to input values as shown by our example contents in grey below:

Country Name (2 letter code) []:NO
State or Province Name (full name) []:Oslo
Locality Name (eg city) []:Oslo
Organization name (full company or person name) []:Pexip
Organizational Unit Name (eg section) []:IT
Email Address []:admin@example.com
Common Name []:sip.example.com

The above command and input will create two files, sip.example.com.csr and sip.example.com.key. The .csr file is the actual CSR, while the .key file is the certificate private key. The private key should be kept secret, while the CSR file contents should be submitted to the CA for signing. After the CA has signed the CSR, the certificate will be ready for uploading.

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 selecting the Conferencing Node in question and uploading the server certificate and associated private key. The certificate should be in Base64-encoded X.509 (PEM) format:

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 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 CA certificates facility on the Management Node in order to ensure proper certificate chain trust for the server certificates we install on the Conferencing Nodes.

These intermediate CA certificates will typically be available for download with the SSL provider itself.

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 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 (conf01.example.com would also be the DNS A-record pointing to the publicly-reachable IP address of the Conferencing Node in question):