SChannel Errors on Lync Server Preventing Client Logon

I was at a client setting up a brand-spanking new Lync 2013 deployment on Windows 2012.  I was setting up two pools in two datacenters. The server deployment went without a hitch and we got everything up and running in no time flat. However, we could not sign on with a Lync 2013 client to either pool.  The client just complained it couldn't log on. 

Looking at the server event logs, we saw numerous SChannel errors as below:

Event ID: 36874 - TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

Event ID: 36888 - A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.

Looking around for solutions on the web, I came across these two apparent gems:
http://social.technet.microsoft.com/Forums/lync/en-US/41718327-203f-445f-8657-87b0a8545ead/lync-2013-client-signin-issue-with-lync-2013-server?forum=lyncprofile (Look towards the bottom for the answer)
and
http://www.logicspot.net/index.php?id=50

If you don't feel like reading the aforementioned links, the answer was to use Regedit to disable TLS 1.2 on the Lync front-ends. This was the solution provided by MS Support. Sure enough, doing that fixed the problem, but as noted in the links above, this broke Windows Update.  To get Windows Update to work, you would have to remove the registry entry, restart the server, run Windows Update, re-add the registry entry and reboot the server once more.

Since this was a brand-new Lync deployment on brand new Windows 2012 servers, I had a hard time believing this was the only fix for the problem. Since the problem was affecting two independent pools, I figured there must be some common feature shared between them causing the issue. After much flailing about, I turned my attention to the recently installed Windows Certificate Authority installation. Another consultant had installed a CA for the company in preparation for Lync.

Comparing against known good installations, we noticed the signature hash algorithm used for the root certificate was SHA512, but other working deployments used SHA256 or lower. We reissued the root certificate using SHA256, and installed new certificates on the Lync front-ends using this hash algorithm. After a server restart, clients were able to log on successfully, and the SChannel errors went away.

I'm not a cryptography expert, so I'm not exactly sure why SHA512 caused issues with TLS 1.2. Poking around the Internet gave me the impression that SHA512 and TLS 1.2 just don't work together (but damned if I can find where I saw that again).

Regardless, this just goes to show that even if a workaround provided by Microsoft themselves might solve an issue, it doesn't necessarily mean its the right way to do it.

Lync Deskphones and Wildcard Certificates

A critical component of any Lync deployment is the deskphone.  While some users may be comfortable with using a headset/PC combo as their primary telephony interface, I've found that most users still prefer a deskphone.

However, getting a Lync deskphone to work with Lync can be a bit tricky if you aren't diligent about following Microsoft best-practices to the letter.  You may have a Lync environment that works perfectly well for computer-based Lync clients, but you may come across various connectivity issues when you plug in a Lync deskphone that does presence and Exchange calendaring. 

I recently came across a client who were having Exchange connectivity issues with their Polycom CX600 phones.  The Polycom CX600 is likely the most popular Lync deskphone. It provides a very slick interface into Lync and Exchange so you can see your presence, contacts and upcoming meeting information. It is also very cost-effective compared to other similar products.

When users signed into Lync on their CX600 (either via keypad or USB-PC integration), they were soon presented with the following error:

Microsoft Exchange integration unavailable.  Connection to Exchange is unavailable due to invalid network credentials.

The CX600 uses Exchange Web Services (EWS) and autodiscover to find the connection to Exchange.  If there are issues with either service, it will pretty much guarantee that the CX600 won't connect.  I verified that both EWS and autodiscover were working properly.

When I reviewed the certificate loaded on the Exchange Client Access Server, I saw that the common name (CN) was set to their public domain (ie. contoso.com).  The Subject Alternate Names (SAN) included all the required names.  Microsoft Lync documentation recommends that you do not use certificates with the CN set to a wildcard domain name.  You CAN use wildcards in the SAN, but the CN really should be a valid name.  In this case contoso.com is the same as *.contoso.com. 

The client replaced the certificate with one whose CN matched the externally accessible name of the CAS server (owa.contoso.com) as reported by Exchange.  They issued an IISReset, restarted the CX600 and the error went away.  They now have full connectivity to Exchange via the CX600.

I've seen variations on this many times on both Exchange and Lync.  If you're only using Lync PC clients, you may never notice any issues, but as soon as you bring deskphones and even mobile phones into the mix, these sort of things often come up. 

So as a general rule, if you're creating certificates for Lync or Exchange, DON'T use a wildcard as the first name.