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.