There’s certainly no lack of information out there regarding issues with wildcard certificates in various situations with Exchange and, increasingly, Lync. Jeff Schertz recently posted a good article on the topic as it relates to Lync. It’s worth adding another tidbit to his information, which is that a wildcard certificate on Exchange Web Services will cause Lync Phone Edition not to connect to Exchange. If you look at the log files from the phone you’ll see something like this (irrelevant parts of the log have been removed):
INFO :: NAutoDiscover::DnsAutodiscoverTask::PopulateAutodiscoverUrlsFromDnsSrv: SRV record found for record, _autodiscover._tcp.domain.com, value, mail.domain.com.
INFO :: NAutoDiscover::DnsAutodiscoverTask::TryAutodiscoverUrls: Trying url, https://mail.domain.com/autodiscover/autodiscover.xml
INFO :: WebServices::CSoapTransport::OpenNewInternetHandle: Connecting using INTERNET_OPEN_TYPE_PRECONFIG flag
WARN :: WebServices::CSoapTransport::OpenAndSendDummyRequest: HttpSendRequest failed. Server=mail.domain.com, Path=/autodiscover/autodiscover.xml
ERROR :: WebServices::CSoapTransport::GetHttpHeaders: Failed to send a dummy request: hr=0x80072f06, url=https://mail.domain.com/autodiscover/autodiscover.xml
INFO :: NAutoDiscover::DnsAutodiscoverTask::TryAutodiscoverUrls: GetHttpHeaders failed with 0x80072f06
WARN :: NAutoDiscover::DnsAutodiscoverTask::TryAutodiscoverUrls: Exception with this url. hr=0x80072f06
The error code I highlighted is ERROR_INTERNET_SEC_CERT_CN_INVALID, meaning that the CN (subject) of the certificate is not valid.
Be aware that this doesn’t cause any problems with the regular Lync client, only Lync Phone Edition. As you probably guessed, the solution is to replace that wildcard certificate with a regular certificate that contains the EWS FQDN in either the subject or subject alternative name field.