TLS 1.2 and Skype for Business

By now you’re probably heard a lot of grumblings about the insecure nature of TLS 1.0 and and 1.1, and that everyone should be moving to TLS 1.2. Let’s talk about TLS 1.2, SfB, Office 365, and related things.

What’s TLS?

TLS stands for Transport Layer Security. TLS is the successor to SSL, Secure Socket Layer. You can read a nice multi-part overview of SSL/TLS here
that includes details on vulnerabilities and attacks. In a nutshell, TLS is the protocol used to encrypt your stuff.

The challenge

IT has an ongoing challenge of ensuring that related systems are at compatible levels. With TLS, the idea is to enable TLS 1.2 AND disable earlier, less secure versions. It’s plain silly to leave the less secure versions enabled, unless you’re still in transition to TLS 1.2 and need the lower levels for compatibility.

About PCI Compliance

When people say PCI, they probably really mean PCI DSS, or the Payment Card Industry Data Security Standard. These are the rules that credit card processing companies say you need to follow. They’re a good read, and probably worth following even if you don’t process payments via card. You can read more here

SfB and TLS

At present, SfB does not support TLS 1.2. Microsoft is late to this party. You can expect an up-coming update to permit SfB to run on TLS 1.2 with less secure levels disabled. A word of caution however – if you have third party software for something like a call center, user/number management, e911, or whatever, make sure that it also works in a TLS 1.2-only environment.


LPE is Lync Phone Edition, the software and hardware standard for the previous edition of phones. Common model numbers are the Polycom CX500, CX600 and CX3000. HP and Aastra also make some models. All LPE phones run the same software, based on a super old version of Windows CE. This version does NOT support TLS 1.2, so if you need to run only TLS 1.2 now, your LPE devices need to be replaced. There was rumour in the past that Microsoft was looking at updating the LPEs to be able to run TLS 1.2, however I’ve not seen any official word or any updates that they’re still looking at the issue.

PLEASE don’t be one of those organizations that buys a pile of cheap used LPEs. You’ll only regret it when you have to replace them, deploy a new phone management solution, and retrain your users.


There is a tonne of material on Office 365 TLS 1.2 here  that you should review. While this article is relatively short, it’s chock full of links to more detailed resources.

More SfB and TLS 1.2 news here when it’s available…

Office Online Server/Office Web App Server Pool Certificates

I’m working on a deployment that’s using a farm of OOS servers behind a load balancer (actually, behind a high-availability pair of load balancers!) for high-availability. If you’re just using one server, this is a great guide to what you need to implement. If you’re using a farm with 2 or more servers behind a load balancer, there are a few more considerations.

To start with, the subject name on the certificate needs to be the URL that you’re defining in the SfB topology. You might use, for example. Now the fun part – the first SAN listed on your certificate also needs to be

Everything will work at this point, but you don’t have a very good high-availability story. The load balancer will need to be configured to monitor each server in the farm to determine if the server is functional. Otherwise, a server could stop functioning and the load balancer would continue to send traffic to it – that’s no good. The load balancer will most likely monitor the servers by trying to access (and the same thing for oosnode2, etc.), and watching for a 200 OK to be returned.

Most load balancers have setup wizards that will set the monitoring up for you as part of the configuration process for OOS, SfB, Exchange, SharePoint, and more. Check the vendor’s website.

In order for the HTTPS request to to success, needs to be a SAN on the certificate. The same holds true for the other servers in the farm.

You could cheat and monitor your OOS servers by using HTTP and thus not require a certificate. This is a bad thing to do. You should be monitoring the actual URL that will be accessed on the server for a true indication of the server status.

To summarize, your OOS certificate needs to have:

Subject Name (SN) of the URL you will use in the SfB topology, such as

The first Subject Alternate Name (SAN) needs to be the same as the SN.

Then, you’ll need a SAN entry for each server in the farm, such as and



Cool tool – check certificates already installed on a server

Working with Lync everyday for a number of different organizations, I often need to gather information about the certificates that they’re using, or perhaps that a federated organization is using. This can be on a Lync Edge server, reverse proxy, web server, Exchange server, load balancer, or any number of other devices. The easiest way for me to get an overview of the certificates in use is with DigiCert’s SSL Certificate Checker.

When you enter an FQDN into the checker, you’re provided with a page of information including the Common Name/Subject Name, any Subject Alternate Names, and a variety of cryptography and administrative items.  A couple of certificate vulnerabilities are checked, as is the expiry date, revocation lists, and the certificate chain through any intermediates to the Root CA is validated.

I really appreciate how the checker displays some items with comments like “Signature algorithm = SHA1 + RSA (good)”, giving you a quick indication if things are in order.

If you’re not sure of an FQDN, you can use an IP address. I’ll do this sometimes when I don’t know the hostname for a server, but I know the IP address or the address of another server at the organization (changes are the one I’m after is plus or minus a few IP addresses). When you run the checker by IP address, you’ll receive a warning that the Certificate name doesn’t match what you entered. That’s fine, you can have a look at the Common Name and Subject Alternate Names and re-run the checker with one of those if you’d like.



Cool tool – Decode a CSR

Have you ever found yourself with a CSR file (a Certificate Signing Request), wondering what’s in it? The good news is that you can decode a CSR so that it’s human readable. There are a number of ways to do this, however the one I find easiest is this website

I use this whenever I’ve generated a CSR from a command line where there are a gazillion parameters and maybe and ini file involved, just to make sure that everything came through correct. This is especially useful if you’re the one generating the CSR, and you hand the CSR off to someone in another department to submit it to the certificate authority.



Cool tool – DigiCert Certificate Utility

The DigiCert Certificate Utility is one of the best certificate tools out there. You can use it to generate requests and process new certificates or renewals, fix missing private keys, fix certificate chains that are missing certificates – from any vendor, not just DigiCert. If you’re a programmer, you can use this to sign files and batches of code.

You can find this little bit of magic, along with the rest of what it can do, right here

The utility doesn’t install, it’s just an exe that you run. Best of all, it’s totally free!

Certificates from 30,000 feet

When dealing with certificates, people tend to fall into three groups: The first are the security nerds that dream about cryptanalysis and PKI. The second is those people that understand what certificates they need to plug in where, but maybe don’t know the exact differences between things like MD5 and SHA1. The third group are those that follow the steps in the article they’re reading, hoping – sometimes praying – that things just work when they’re finished the last step.

In this post, I’m aiming to help those of you in the hoping/praying group understand a little bit more about what certificates are, why they’re that way, and maybe move you out of the hoping/praying group and into the understanding group. Certificates aren’t typically explained well to the average IT administrator. You either see an explanation of the math behind certificates, or you get vague references to things like the SANs that you’ll need on your certificate, if only you were deploying the exact Lync environment that’s in the blog you’re reading. So, let’s talk about certificates – what they are, how they work, and what different types of certificates exist.

The Basics

Certificates serve two purposes: they identify a device, and they permit encryption.

If I were to draw a comparison between a certificate and any non-IT concept or object, I would compare certs to a driver’s license. They’re both issued by some authoritative source, and they are both used to validate your identity.


(Who would name their daughter “Test Card”? I guess someone with a last name of “Sample” might)

Cert General

A driver’s license will have a photo, and maybe some biometric things like age height, weight, hair colour, eye colour, and a signature. It probably also has an address. It’s also got your name. There’s usually the name of the issuer, an expiry date, and there might be a hologram that you can use to determine if you trust the driver’s license. A certificate has these things, or at least the IT equivalent of them. A certificate has a name (the “Subject Name”, or SN), as well as nicknames, properly know as Subject Alternate Names, or SANs. There’s a field that contains the name of the issuer, location information, and a public key in place of all that biometric stuff.


The first concept that we need to explore is trust. If I’m trying to order a beer with my dinner, I might need to show ID to prove my age. If I show my driver’s license to the staff, they can easily recognize the license and establish my age. If I’m travelling in Europe, I might run into issues if I show my driver’s license, as the staff may not recognize it, and therefore they don’t trust it. However, it’s likely that I also have my passport with me, and the staff can easily recognize that, and trust it. At a restaurant near my home, the staff trust my driver’s license because it’s in a format that they’re expecting, and they recognize and trust the issuer.

This same concept of trust is how certificates work, too. You can configure a computer or application to trust a certificate, or you can configure the computer or application to trust the certificate issuer, called a Certificate Authority. In the Windows world, Windows has a default list of commonly trusted Certificate Authorities, and updates to this list can be done via Windows Update. You can also add and remove Certificate Authorities from this list manually or via Group Policy or scripting. This is especially important when you deploy your own Certificate Authority on your Domain.

Some applications, like the Firefox browser, choose not to use the Windows list of trusted Certificate Authorities and instead have their own list. Different devices – an iPhone, a Windows Phone, a CX600, or a Galaxy S5 – will all have different lists of which Certificate Authorities they trust.

Public and Private Keys

Now that we’ve got the concept of trust down, let’s get a bit deeper into how certificates work. In the physical world, we have keys and locks, and the key is used to open the lock. The key may or may not be required to secure the lock. In the IT world, we have public keys and private keys. Together, they’re called a key pair. The private key is NEVER given out, and is held on and used by the server identified on the certificate. The public key is ALWAYS given out, and is provided in one of the fields on the certificate.


If I want to encrypt something to send to the server, I will use the servers public key to encrypt the information. The server will then use its private key to decrypt the information.

This kind of encryption, called asymmetric encryption, is a bit of a resource hog. There’s another type of encryption, Symmetric Encryption, that uses just one key to encrypt and decrypt, and it’s a much less intensive operation. Since the same key is used for encryption and decryption, you can’t stick in on a certificate that’s publicly available. Instead, the symmetric key is generated using your own private key and the other servers public key, and some math that I’m pretty sure involves dark magic. This keeps the asymmetric key is safe from prying eyes. Symmetric encryption isn’t as strong as asymmetric, so every so often, a new key is generated and replaces the old key.

You can see that a key pair is a little bit different that a physical lock and key. Where a physical key opens the matching lock, the public key and private key in a key pair work as a lock and key in one direction, and a key and lock in the opposite direction.


Something else that the server can do, is sign something to prove that it’s genuine, kind of like the hologram on the driver’s license. The server performs this signing function with its private key, and you would use the public key to validate the signature. (Our analogy to the physical world falls apart here, and there is no physical-world equivalent of signing with a lock and key).

So, enough about keys. If you’re interested in learning more, I encourage you to have a look at Wikipedia and Bruce Schneier has a great book on cryptography.

Root and Intermediate Certificate Authorities

Okay, so now we know that we have Certificate Authorities that issue certificates, like the motor vehicle office offers drivers licenses. Let’s say that one night, someone breaks into the motor vehicle office, and steals everything that they’d need to make their own drivers licenses. Ouch, that would be pretty bad, right? The driver’s license office might respond by changing the hologram, and if the cards had any kind of chip on them, they’d maybe generate a list of the chips that were on the cards that were stolen, so the stolen drivers licenses could be easily spotted.

Similarly, it would be really bad if someone hacked your Certificate Authority and stole the root certificate. The root certificate is what signs all of the certificates that are issue. The hackers are now able to generate fake certificates that looked valid. Now, all of these fake certificates would be signed by the certificate authority (we talked about signing with keys earlier). The certificate authority would publish something called a Certificate Revocation List, or CRL, that would have the serial number of the certificate that was on the certificate authority. The CRL is usually always accessible via http on a public website. This way anyone can check that validity of a certificate.

In this scenario, the certificate authority would also publish the serial numbers of all of the genuine certificates that were previously issues by the CA with the compromised root certificate. The certificate authority needs to issue a new root certificate, and everybody needs to get a new certificate issued – what a pain! But wait, it gets worse. Windows, your mobile phone, and all kinds of other devices have the root certificate from the Certificate Authority in the list of Certificate Authorities that they trust – and now that root certificate is compromised. There’s no easy way to add the new Certificate Authority root CA into the trust certificates list. You’ll need an update on your device (maybe Windows Update, maybe Apple issues a new iOS version), or you can do in manually. That’s definitely painful.

There is another way to do certificates that prevents this pain, and it’s by using Intermediate Certificates. If a Certificate Authority’s Root Certificate is Papa Bear and a certificate is Baby Bear, an Intermediate Certificate introduces a new generation of bear. The CA Root Certificate becomes Grandpa Bear, the Intermediate Certificate becomes Papa bear, and your certificate is Baby Bear. The Root CA (Papa Bear) can now generate a couple of Intermediate Certificates (Papa Bears). After the Root CA has generated the Intermediate Certificates, the Root Certificate Authority machine is turned off, disconnected from the network, and locked up. This is like Grandpa Bear living under witness protection, or maybe with body guards. The Intermediate Certificates are then what are used to issue your certificate. There are probably multiple intermediate certificates in use by your certificate authority. This is like multiple Papa Bears having lots of Baby Bears.

Now in our theft/hacking scenario, if the CA is hacked and the Intermediate Certificates are stolen, the CA goes through the same CRL process that we saw earlier, except the Root Certificate, powered off and secured, wasn’t compromised. All those devices still trust the Root CA. Replacement Intermediate Certificates are issued, and they in turn generate replacement certificates. Customers (you!) still need to reissue certificates, but you don’t need to worry about updating root CAs on all of your devices.

You can read all about securing a Microsoft Certificate Authority on TechNet. (The TechNet article is free of bear analogies.)

There’s one thing about Intermediate Certificates that I haven’t explained. The Certificate Authority gives you a copy of the Intermediate Certificate when you download your certificate from them. You put the certificate in the “Personal” certificate store, and you put the Intermediate in – you guessed it – the Intermediate Certificate store. Now when anyone needs to interact with your certificate, your server shows them your certificate AND it shows them the intermediate certificate. Think of showing your driver’s license, as well as a “certificate of authenticity” from the motor vehicle office that generated it.

Please, please, make sure that you only put a certificate into the spot where it should go. No Personal (issued to a server, user, or device) certificate in the Intermediate Certification Authorities store, no Root and Intermediate Certificates in the Personal store, etc.. Some applications can choke when they check your certificate store and find the wrong type of certificate in them. Choking isn’t good, as there’s no Heimlich maneuver  for servers. You need to be particularly alert when you’re installing a certificate that you’ve just downloaded from a CA. If you just double click the downloaded file, it may stuff your certificate, intermediate certificate, and root certificate all into the Personal Certificates store. If you do double click such a file, run the certificates MMC (the easy way is to run certlm.msc, otherwise open mmc, add the certificate snap-in, and select Local Computer). Open each store, and if you see something in the wrong place, drag it to the correct store. Delete any duplicates – but only after you ensure that the serial numbers match, otherwise the duplicate name with a unique serial number is valid, and may be in use).

You may want to do this clean-up routine on your server’s certificate stores if you’re not sure what state they are in.

Wildcard and Self-Signed Certificates

You probably still have some Lync specific questions like “What is a wildcard certificate, and why doesn’t Lync like them”.

We’ve already said that a certificate is your driver’s license with your picture, name, age, height, weight, and signature. This is great for validating your identity, but what about a situation where you also need to validate who you’re talking too? That’s often the case when you have two servers that need to communicate, like your Edge and your Front-End, or maybe your Mediation Server and your Exchange UM server. In a case like this, the servers need to show each other their certificates. When two servers use their certificates to validate their identity and encrypt traffic, it’s called Mutual Transport Layer Security, Mutual TLS, or just MTLS.

This is really different from plain TLS, which isn’t mutual at all. TLS secures traffic both ways, but only proves the identity of one of the parties in the conversation. You use TLS when you browse to a web server over HTTPS, like your bank. The server has a certificate, but your client doesn’t. Depending on the server and what you’re doing on it, you might have to validate your identity with a username and password, or you might have some form of two-factor authentication.

So, a wildcard cert looks like this:

Google Wildcard

If we were to compare a wildcard certificate to a form of “wildcard” driver’s license, it would have no first name, no height, weight, age or signature, and instead of your mugshot, it would have that really bad photo from your Sample family reunion last summer where your crazy uncle Dave looked like he was ready to pass out. And that would allow anyone who was at that reunion, who shares your last name, to drive. Yes, even your crazy uncle Dave. Seriously – who would think that this kind of driver’s license is a good idea?

Group DL

Wildcard seem like a pretty silly thing. Are they completely useless? Well, no. They do serve a valuable function, and that is to provide a low cost certificate that you can use on a variety of your devices to ensure traffic is encrypted. A Bank would NEVER use a wildcard cert. Google uses wildcard certs where they just need to ensure encryption, such as when you search. However, Google uses a full Subject Name on certificates for things like Gmail, where you need to validate the server’s identity.

Another type of certificate is a “self-signed” certificate. These show up in web interfaces on routers and switches, and they’re also used in Exchange when that’s installed. Putting a self-signed certificate on your server is like your server saying “hey, I’m your server! Here’s my certificate that I issued to myself! Trust me!!!”. This is a crazy, crazy concept. Here is the driver’s license equivalent of a self-signed certificate:


That’s right, your 6 year old cousin Megan (she was only three at the family reunion where the picture for your wildcard certificate was taken) drew up her own driver’s license! Hand her the keys to the Prius and stand back everyone! 6 year old Megan drive!

No, she can’t. She probably can’t even see out the windshield or reach the peddles. The concept of Megan drawing her own driver’s license making her able to drive and use it as a form of ID is silly, and only her mom, dad, and her stuffed unicorn would ever trust it as a form of identification.

Self-signed certs, by default, are only ever trusted by the server that issued the certificate to itself. If you want your computer to trust it, you have to add that certificate to the Personal store of your computer. You shouldn’t add the self-signed certificate to the Trusted Root Certificate Authorities store, because it’s not a Certificate Authority. And, just because you can trust a self-signed certificate, that doesn’t mean that you should. Self-signed certificates are great for your lab, but not much more. If you’re thinking of using a self-signed certificate in a production environment, you should consider why you need a certificate in the first place. If you have reason to need a certificate, set up Active Directory Certificate Services. If you don’t need a certificate, save yourself the trouble and just use HTTP or whatever protocol gets the job done without the certificate.