Microsoft Lync and Skype for Business are two of the most important tools in the domain of workspace collaboration. A large number of companies across the globe rely on them to work with teams in a better way. Therefore, if you want to deploy any of them for your company, you’ve made a great choice. However, the SSL/TLS certificate requirements for both of them are a tricky affair. They’re very strict, so you need to understand them properly if you want your Lync/SfB deployment to work flawlessly. So here we’ll take a look on all those requirements, and also on the entire process of implementing a SSL/TLS certificate for your Lync/SfB server. Let’s get started:

Creating a Certificate Signing Request (CSR)

Whether you want to deploy your Lync/SfB server on premises, or on a public DMZ, you should use the same certificate that’s installed on your conferencing nodes. This will allow you to add redundant conferencing nodes easily and also to add multiple SIP domains for your Lync/SfB federation. Due to this particular reason the certificate signing request (CSR) that you generate for your conferencing nodes should contain multiple Subject Alternative Names (SANs). These types of certificates are also known as UCC or Exchange Server SSL Certificates.

A Single Certificate for All SAN Names

While an SSL certificate may initially this mean some trouble as you’ll have to add multiple SAN names to your certificate, the hard work that you do now will save you precious time in future as you’ll have to manage just one single SAN SSL certificate for all your conferencing nodes (unless you there’re multiple domains/subdomains to be managed).

It is worthwhile to acquiring your SAN SSL certificate from trusted certificate authorities. Initially, you need to create request for certificate and submit it for validation procedure. Certificate authorities will verify your given details and send your certificate.

Keep in mind that wildcard certificates are not supported for Lync/SfB deployments. You must use a proper UC certificate only for deployment of these things.

On-premise CSR requirements:

For an on-premise Lync/SfB deployment here’re the requirements of CSR:

  • Subject Name should be same as Trusted Application Pool FQDN
  • Subject Alternative Name (SAN) entries must be included for every node in your pool and common application FQDN

Public DMZ CSR requirements:

On the other hand, if yours is going to be a public DMZ deployment, then your requirements will be as follows:

  • The hostname referenced by _sipfederationtls._tcp SRV record should be put as Subject name
  • And SAN entries should include every single node in the public DMZ, including the hostname mentioned in Subject name.

Add SAN Names:

If you want to add extra nodes at any point of time in future, you can do that easily by generating a new CSR with SAN entries of original nodes and SAN entries of new nodes. For example, if you want to add two additional nodes, you can generate your new CSR with all the original SAN entries and two additional SAN entries of your new nodes. Once that CSR is generated, you can submit it to your CA, pay the additional fee for your extra nodes and get a new UC certificate. Once you get your new certificate, the only thing that remains is uploading it to all the nodes. Your previous certificate becomes invalid as soon as you upload the new one. That’s it!

Assigning a certificate to a Conferencing Node

Certificates can be assigned to a node very easily. Once you’ve uploaded a certificate along with its private key, you can assign it easily to conferencing nodes as long as that certificate was in Base64-encoded X.509 (PEM) format.

Certificate Issued by Intermediate CAs

Many times it happen that server certificates are issued by intermediate CAs instead of Root CAs. If that’s the case with your certificate, an intermediate CA certificate chain should also be installed on the Management Node. This will help properly establish the chain of trust when your clients try to connect to a conferencing node.

  • The first step for installing an intermediate CA certificate chain is to know whether your certificate has been issued by an intermediate CA or not. To do so check whether your certificate file is in .cer extension or not.
  • If it is, open it on a Windows PC, navigate to the Certification Path pane and it will show you the CA structure of company that signed your certificate.
  • Once you find that your certificate has been issued by an intermediate CA, import the intermediate CA certificates (which come bundled in a single file) to your Management Node. Your intermediate CA would’ve provided this file to you already along with your certificate.

Configuring SIP TLS FQDN for a Conferencing Node

The SIP TLS FQDN setting allows you to define the DNS FQDN that a conferencing node will use to present its identity when clients try to connect to it. This setting should be unique for each conferencing node, and it should match the FQDN of certificate that you’re going to assign to the node.

Configuring Windows Server Manager to use a certificate template with client and server capabilities

If your conferencing node will connect to a video network infrastructure device that performs TLS verification, then your certificate should also have client authentication capabilities. By default, the web server certificate supports server authentication only. In this final section of article I’ll explain how to use a certificate template with both client and server authentication capabilities on your Windows Server. Here’re the necessary steps:

  • Launch Server Manager of Windows
  • Launch Certification Authority tool
  • Expand the navigation tree of your CA and select Certificate Templates
  • Right click Certificate Templates, select Manage and open Certificate Template Console
  • Based on your existing Web Server template creates a new template with the required changes. Right click on Web Server in your list of templates, and select Duplicate Template.
  • In General Tab, enter your desired Template display name and Template name for your new template.
  • Navigate to Extensions tab, select Application Policies >> Edit.
  • Add client authentication to the set of policies by clicking Add >> Client Authentication and clicking
  • Hit OK once again to save your new template.
  • Now close the Certificate Templates Console, and add the new template to your CA. From Certification Authority Tool, expand the navigation tree of your CA, right-click Certificate Templates and choose New >> Certificate Template to Issue.
  • Now select the new template that you just created and hit OK.

And that’s it. There’re the entire sets of certificate requirements needed for a Lync/Skype for Business deployment. Whether you want to deploy on premises, or in a public DMZ, I hope that this article will be able to help you in doing that. Thanks for reading and have a great day!