As discussed in this previous article I am not a big fan of wildcard certificates.  Here is another reason why.

Lync Phone Edition devices do not support the use of wildcard entries in certificates on any Lync Server role.  If used on either the Front-End or Access Edge server certificates then the phones may not be able to sign-in to Lync, neither through PIN Authentication nor USB-tethering scenarios.

When looking at the SIP traffic between a Lync Phone Edition device and the Lync registrar the captured traffic will show and initial connection and even brand-new devices will be able to connect and download a certificate from the server.  But the final sign-in step will fail and the traffic will seem to indicate no problems, it appears as if the phone just ‘gives-up’ and doesn’t to reconnect to the Lync Server.

Scenario

• According to the guidelines in my previous article the following certificate should be supported for native Lync use.  The server/pool FQDN is defined as both the Common Name and a SAN entry.  The wildcard entry covers all of the Simple URLs.

A standard Windows Lync 2010 client will successfully sign-in to a Lync server using Automatic Configuration.

• The SIP URI of jeff@mslync.net was entered in the client which performs a DNS SRV lookup for _sipinternaltls._tcp.mslync.net.

• Because the targeted host record is in the same domain as the SIP domain then this is a valid configuration.  The Lync client then attempts to resolve the IP address of, and then connect to port 5061 of sip.mslync.net.

• But when a Lync Phone Edition device attempts to sign-in the following error will appear.  (The example image below was pulled from a Polycom CX600 running CU1 4.0.7577.107 software.  Various different versions of devices and software versions were tested with the same results.)

Cannot connect to the server. Retrying.
If the problem continues, contact your
support team.

It appears that the Windows Lync client supports connecting to the host sip.mslync.net when the responding server’s certificate only includes a wildcard entry for *.mslync.net.  However the Lync Phone Edition client does not like this configuration at all.

• To test this out a new certificate was created and applied to the Lync Front-End Server with an additional SAN entry of the exact FQDN pointed to by the Automatic Configuration SRV record (sip.mslync.net).

• After restarting the Lync Front-End Service (Restart-Service RTCSRV) to force the certificate change both the Windows and Phone Edition clients signed-in immediately.  This validates the fact that Lync Phone Edition requires the server certificate contain the exact FQDN of the host name the device is attempting to connect to.

In a single name-space deployment with a single SIP domain this issue would not typically be seen as the SRV record would be in the same domain and would normally point to the Lync server/pool name, which is in the certificate’s CN and SAN fields.  So in this example if my SIP domain was schertz.local than the first certificate shown would have worked for Lync Phone Edition.

But since most deployments use separate namespaces and often support additional SIP domains as well then wildcard certificates strike out once again.

Update: June 2012

Microsoft has incorporated support for wildcard certificates into the Lync Phone Edition Cumulative Update June 2012 release.  This includes support of both Lync Server and Exchange Server FQDNs, meaning that both authentication to a Lync Server and authentication to an Exchange Client Access Server over Exchange Web Services are supported when the server FQDN used for TLS connections is not actually explicitly contained in the certificate, but a wildcard entry is provided.

The catch-22 here though is that most Lync Phone Edition devices do not ship with recent firmware and must be updated first to at least the 4.0.7577.4100 firmware, which cannot be accomplished in a Lync environment using a wildcard configuration like what is shown in this article.

Hence it is still best practice to avoid wildcard-only entries for the server FQDNs in any new Lync Server deployments.  Realistically the addition of wildcard support is target more towards future Office 365 support for Lync Phone Edition and this is the first step in achieving that.