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.


  • 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 was entered in the client which performs a DNS SRV lookup for


  • 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


  • 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 when the responding server’s certificate only includes a wildcard entry for *  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 (


  • 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.

By Jeff Schertz

Site Administrator

11 thoughts on “Lync Phone Edition Incompatible with Wildcard Certificates”
  1. Thanks for the update Jeff, good info. We work with nonprofits who are of course extremely cost conscious, and so a wildcard cert has been very useful for us for basic web services, citrix web interface/secure gateway, and even for our Exchange 2007 and now 2010 OWA/activesync/EWS (yes, it works well).

    However, with Lync we of course went with a true SAN cert. Question – if, down the road a bit, we end up adding a new sip domain, do you know if we have to purchase a whole new cert at full price, or do issuers offer some kind of adjustment/proration?

    1. That totally depends on who you purcahse the certificate from. Some providers will require a new purchase, while other will let you reissue the certificate changes at little to no costs.

  2. I ran into this myself. I was running a CX600 with 7400 (beta) firmware. Using wildcard cert, from a factory reset, phone just loops in a reboot cycle. Tethered, logs in ok after domain auth and gets cert. Replace wildcard cert for iis on fe with internal SAN cert, factory reset, and completes setup ok and updates to 7577.

  3. Problem:

    Lync Phone Edition cannot sign into Microsoft Lync. All other client types can.


    Lync Server 2010 Multi-Tenant Pack. Using edition 4.0.7577.4051

    Front-End Server, Director and Edge Pools all use WildCard Certificate which we know is now supported from the 16 June 2012:

    Lync Phone edition Clients are using firmware version 4.0.7577.4100


    SIP Stack Trace on Edge Pool:

    -“The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?”

    Reverting to Standard UC Cert from same Root CA ( allows the device to sign in. Therefore, the conclusion is that the device’s STILL do not support WildCard Certificates. Is this the case?

    1. Hard to say without seeing the certificates; this should work but I wonder if there is something else different between the two certificates then just the wildcard entry?

      1. Hi Jeff, this is still a problem for us. We are running Lync Multi Tennant pack and are seriously hampered by not being able to support the Lync Phone Edition devices. It looks as though Lync Phone Edition carries out strict domain matching on the certificate – is this the case?

        1. That is correct, but Microsoft is working on updates this behavior to provide the ability to use Lync Phone Edition devices with O365 and LHP environments.

Leave a Reply

Your email address will not be published. Required fields are marked *