When it comes to workspace collaboration, Skype for Business is one of the most widely accepted platforms. With its great group calling capabilities, MS Office integration and strong security it’s the platform of choice for many businesses of all sizes.
However, the security aspect of Skype for a business depends solely on the SSL/TLS certificates that you use while deploying it on your servers. It’s also worth pointing out that Microsoft has set very strict certificate requirements when it comes to Skype for Business. Deviate just a bit from the Microsoft supported model and you will find that many functions of your Skype for Business deployment won’t work at all.
Therefore, it makes sense to understand the Microsoft supported a model of SSL/TLS certificate implementation before deploying Skype for Business. In this article, we’re going to do just that. Let’s begin:
#1. Use Trusted SSL Certificates for your Internal Server
You may save money by implementing a public SSL certificate on your internal Skype for Business server, but there’s a very good chance that it will cause problems.
1. The first reason is that of scalability. As your company grows, your Skype for Business deployment will also have to scale to meet the growing demands of your business. In such a scenario if you have a trusted SSL certificate, you’ll not have many problems. However, if you used a public certificate for your internal Skype for Business server, you’re likely to encounter a roadblock.
Consider an example where you buy a new company – when you do that and decide to add the employees of that company as users on your Skype for Business deployment, as soon as you add the new SIP address to your topology you’ll find that existing certificates for many of your won’t be valid anymore. On the other hand, if you have a trusted SSL certificate for your internal server, the transition will be a breeze.
2. Besides that, in many cases, you may not even be allowed to use public certificates. For instance, if your Active Directory domain isn’t a publicly routable domain, you won’t be allowed to use a public certificate.
Then better to stay away from all this trouble and use a trusted certificate from your internal certificate authority.
#2. Use Trusted Certificates for External Services Too
We talked about the importance of using a trusted certificate for internal servers. Now let’s talk a bit about the external services as well. In order to make your Skype for Business server externally accessible you’ll have to have trusted certificates for external services too. Again, you may try to save money by asking your users to install your internal root certificate on their devices, but as your company will grow it’ll be neither scalable nor manageable. Not only your partners will frustratingly give up on this model, you’ll also learn soon that Office 365 integration and a variety of other services will also not work this way. The best route, once again, is to get a separate trusted certificate for all your external services as well.
So now the question is – which certificates do you choose for your external services? To understand that, first of all, we need to understand the types of traffic streams that your Skype for Business server will be getting. They’re of two types basically:
- A web services stream, which handles all web services required to connect with your Skype for Business server. This includes meeting services, dial-in services, autodiscovery services, etc.
- The other stream handles SIP and remaining communication traffic, including entire audio/video payload.
For web services stream you can use a SAN SSL certificate with definitions of all FQDNs, or a wildcard as SAN certificate. Just keep in mind that certificates with a wildcard as subject name won’t work as they’re unsupported. As a result, the officially supported certificate requirements are as follows:
SAN certificate
Wildcard as a SAN certificate
Note that you can’t put the wildcard value in the subject name.
For your edge server certificate, the subject name must have the FQDN of your edge access service. Any other name in that field won’t work. Once you’ve done that, your edge access FQDN should also be in the list of SANs. For web conferencing and every SIP domain FQDN you’ll need additional SANs. Each SIP domain must have at least two SANs: one for SIP service and another just for a domain.
For AV Edge service we don’t need a SAN certificate.
Official requirements for Edge services are as follows:
SAN Certificate
#3. Multiple SIP Domain Support (External)
If more than one domain is hosted in your Skype for Business deployment, the complexities of deployment increase. In such a case you need to have every SIP domain in each certificate. But fortunately, you don’t need to include every subject URL for each SIP domain as a SAN. For example, you don’t need to tie the web conferencing service as a SAN to a SIP domain. The Dial-in URL works as a global URL for the workload of all your SIP domains. For other URL that tends to be unique for each SIP domain, you need to cover them by a SAN. Examples are given below:
Edge Server Multiple SIP domain Certificate Example
Web Services Multiple SIP domain Certificate Example
#4. Internal Certificates
Edge Servers
Edge servers also require an internal certificate bound to the internal IP address linked with the internal DMZ network. This certificate is used for internal communication, file replication, etc. It should be signed by your internal CA, and its requirements depend on whether you want to deploy a single node edge server or multi-edge pool. The examples of requirements are given below:
Single Edge Server
Multiple Edge Pool
As you can see, life is a little simple if you want to deploy a multi-node edge pool. In that scenario, you just need pool FQDN in the certificate and not individual server names.
Front end server
For your front end server certificate, you need all SANs listed for every web service and real-time service along with pool names and server names. These are the minimum requirements. Your actual requirements will vary depending on whether you want to deploy a Standard Edition Front End Server or an Enterprise Edition Front End Pool. For Enterprise Edition your private key should be exportable to transfer between other servers. However, if you wish, you can also request separate certificates for each Front end server – just remember that every server should have the FQDN present in SAN field. Given below are examples:
Standard Edition Front End Server
Enterprise Edition Front End Pool
#5. Multiple SIP Domain Front End Server Certificate
Just like external services, multiple SIP domains also require extra SAN entries for each domain. And again, the requirements will depend on whether you choose to go the standard route or enterprise edition route. Examples for both of them are presented below:
Multiple SIP Domain Front End Server Example (Standard Edition)
Multiple SIP Domain Front End Server Example (Enterprise Edition Pool)
#6. Persistent Chat Servers
These servers require internal certificates only. And once again, your requirements will depend upon whether you want to deploy a single persistent chat server or a multi-node pool.
Single Persistent Chat Server Example
Multiple Node Persistent Chat Pool Example
Also keep in mind that no matter how many SIP domains you have, the requirements of persistent chat servers won’t change. They remain static.
#7. Other Skype for Business servers
Video interop servers, mediation and other Skype for Business servers don’t expect their own naming principals. They perfectly and contently support the rules of Persistent chat servers.
#8. Office Web App Server (WAC)
While this is not a Skype for Business server, it’s important to include the requirements of this server too in this article because many companies utilize the Office integration capabilities of Skype for Business for smooth co-operation. WAC server comes with its own unique certificate requirements. It must have the subject name and SAN of internal FQDN server only, otherwise, it won’t work. Public FQDNs can’t help you in its case. Wildcard certificates are also not supported, and so are any other certificate types. Examples of certificates that can be used for it are given below:
Internal WAC Certificate
To publish externally you’ll need to do some more hard work using Powershell. You’ll have to set the external URL of WAC service in farm settings of Office Web Apps. This will set the discovery XML to include DNS names and URLs of every single office service. Once it’s done, you can publish this WAC server using a public certificate.
Just keep in mind that the external DNS name of service should match in both subject and SAN fields. The certificate is published to your reverse proxy server, which you can use to publish this service to the internet. An example is given below for the sake of better understanding:
External WAC Certificate
So these are the complete set of SSL/TLS certificate requirements for your Skype for Business deployment. If you follow the requirements outlined in this post we hope that your deployment will go very smoothly. All the best!
