Today I’d like to talk about certificates and a problem that seems to be becoming more and more common with Lync Phone Edition. The problem is that Lync Phone Edition devices that are tethered receive the message “Connection to Microsoft Exchange is unavailable. Please contact your support team”.
The most common cause of this error I have seen is having the Lync pool certificates issued from a different Certificate Authority (CA) than the Exchange server certificates. This problem has become more and more common as organizations move to using certificates from Public CA on their Exchange servers internally. The root of the problem is the Lync Phone Edition devices will not trust a CA other than the one that issued the certificate to the Lync pool it is connecting to.
To reproduce this issue I have configured a lab environment as follows:
Lync Environment:
- Enterprise Edition Pool: lyncpool.lyncguys.com
- Certificate Issued By: Internal Certificate Authority (Lyncguys-LG-DC-CA)
- Common Name: Pool FQDN (lyncpool.lyncguys.com)
Exchange Environment
- Single Exchange 2010 Server: LG-Ex.lyncguys.com
- Public and DNS name: mail.lyncguys.com
- Certificate Issued By: DigiCert
- Common Name: Mail.lyncguys.com
I created a test account (kevin@lyncguys.com) and signed in via a tethered CX600 (Aries) phone. As expected, I immediately saw the error when I tried to access the calendar.
*Note – A Lync Phone Edition device (other than CX700/Tanjay) will require the tethered connection between the PC/Laptop and phone to authenticate to Exchange and view the calendar. Exchange does not support Pin Auth currently, so this article does not apply to devices that are not tethered.
To work around the limitation in Lync Phone Edition there is a Lync Management Shell command that will allow you to add the public providers root certificate to the Web Services Configuration on the Lync servers. The command requires you to know the “thumbprint” from the root certificate.
To find the thumbprint, open Outlook Web Access (OWA) from an internet browser, click on the “Lock” icon in the browser and choose “View Certificates”:
The certificate your Exchange server is using will be displayed:
Next, click on the “Certification Path” tab at the top of the certificate window, click on the top certificate in the list and choose “View Certificate”.
Now click on the “Details” tab and scroll down to “Thumbprint”. Highlight the thumbprint and press CTRL+C to copy it to your clipboard.
Open notepad or another text editor and paste the thumbprint into the editor. Next, remove all spaces from the thumbprint as shown in the screen shot below.
Take the thumbprint without any spaces and copy it into the command below, then run the command from Lync Management Shell:
$cert = new-cswebtrustedCACertificate -thumbprint “Thumbprint_Here” -castore TrustedRootCA
i.e:
Verify that pasting the command into the Lync Management Shell did not add a “?” to the beginning of your command (shown below):
Now that the certificate information has been stored as a variable ($cert), run the following command to add the certificate to the Web Service Configuration for the Lync servers:
set-cswebserviceConfiguration -trustedCACerts @{Add=$cert}
To verify the command completed successfully run the command:
Get-CSWebServiceConfiguration, the thumbprint of the newly added certificate will appear in the “TrustedCACerts” list.
After this process is complete, reboot the Lync Phone Edition devices and verify the calendar is functional.
*Tip – In my lab the intermediate certificates for DigiCert were not installed correctly on the Exchange server causing the error to still display. To correct this issue download the DigiCert Certificate Utility and run it on all Exchange servers in the CAS array to verify the certificate chain is installed correctly. *
One other thing to note, there is no command to remove a single certificate from the “TrustedCACerts list in the Lync Web Services Configuration. However, you can use the replace option with the Set-CSWebServiceConfiguration command to add a new CA Certificate to the store and remove all others.
i.e.
$cert = new-cswebtrustedCACertificate -thumbprint “Thumbprint_Here” -castore TrustedRootCA
set-cswebserviceConfiguration -trustedCACerts @{Replace=$cert}
If you need to remove all CA Certificates from the store and would not like to use a new one, you can use the command “Remove-CSWebServiceConfiguration” which will set all of the Web Service Configuration back to default. This will remove all configured settings for the Web Service Configuration, so if you have modified any other settings, you will have to update them again after running this command.
H/T to My co-worker Randy Wintle for his help tracking this down
Hope this helps!
The Lync Guy's Blog 
Excellent and very useful article. Thanks Kevin.
“The root of the problem is the Lync Phone Edition devices will not trust a CA other than the one that issued the certificate to the Lync pool it is connecting to.”
Hi Kevin, please point me to the relevant pharagraph in the official Lync supportability document, that contains exactly this sentence written down. I am looking for this sentence since 2007, but couldnt find it!
In the microsoft article referenced at the bottom it says:
“Note that the certification authority that signs the default server certificate used when installing Lync Server 2010 is automatically trusted and does not need to be added to the TrustedCACerts property of a collection of Web Services configuration settings. TrustedCACerts should only contain the identities of CAs that need to be trusted in addition to the CA that issued the default certificate. In most cases, the CA that issued the default certificate will be the only certification authority that needs to be trusted.”
That is about the best you are going to get (as far as I have seen).
HTH
-kp
Well, to be honest the situation in the referenced article is quite far from the situation that we are discussing here. If you are right, Microsoft expects all Lync professionals must own mindreader capabilities to figure this out. This is dim discussion at best, not clear speech.
Hi Richard,
If you feel that way it would definitely be useful for you to submit that feedpack to the Lync documentation team (lyncdoc@microsoft.com). You could even include the URLs I mentioned and this article. I won’t speak for MSFT on how/why/if thisis hasn’t been covered as extensively as it could have/should have been.
-kp
Peter, dont get me wrong: dim siscussion I was referring to technet / Lync docs talking about a critical requirement, that only mindreaders could decipher from stupidly worded pharagraphs. Requirements should be written as straight-forward as 1-2-3, instead of indirectly referencing to indirect indirect dependencies. I think you know what I mean…
Hi Richard,
I know exactly what you mean, that is a big part of the reason I write this blog. If you email the email address below they will read it and most likely take some action on it. The Lync documentation tries very hard to provide clear documentation that is also useful. On such a feature rich product it can be hard to cover everything though, so sometimes they don’t hit the nail on the head, that is when emailing them helps.
HTH
-kevin
Richard,
Being one of those people that write (or did write, up to the time I left Microsoft) those ‘dim discussions’ and prose that ‘only mind readers could decipher’, I’m curious if you followed up with LyncDoc? I was still with the Product Group, but am not sure that I recall an email from you referring to this issue and suggesting a clearer paragraph. I wasn’t responsible for writing this particular item, but know who did. And, he would be most interested in clearing up the confusion if you’re still out there and want to resolve it.
Frankly, we don’t believe that we word things stupidly, or use vague, indirect references. We could argue and debate over who’s right. At the end of the day, if it’s not correct or not understandable by some – I’d like to see it get fixed and have the contacts to make that happen. Contact me, if you still want it fixed (now nearly two years later) at rkingsla._a_t.outlook.com
Actually Lync Phone Edition does trust a list of public CA providers. You can see the list here http://technet.microsoft.com/en-us/library/gg398270(v=ocs.14).aspx
Unfortunately Digicert is not one of them
Hi Brennon,
Yes LPE does have a list of public CA providers, however once it gets a cert from AD it no longer trusts that list and any other certs it needs to trust have to be added via the method in this article.
HTH
-kp
Thanks Kevin. I have 2 more queries:
1. Looking at the New-CsWebTrustedCACertificate command description at http://technet.microsoft.com/en-us/library/gg412746.aspx, it says “To add a new CA to the collection of trusted certification authorities, you must add the certificate chain for that CA in the local computer’s certificate store. After you have verified that the certificate chain has been installed, you can then use the New-CsWebTrustedCACertificate to create a certificate ID object that can be added to a collection of Web Services configuration settings”. It seems like this additonal step needs to be done before running the command to create a new object with the -Thumbprint parameter.
2. For the Set-CsWebServiceConfiguration -TrustedCACerts parameter to work, it seems that the InferCertChainFromSSL property must also be set to false. This is mentioned in command description at http://technet.microsoft.com/en-us/library/gg398396(v=ocs.14).aspx.
Would greatly appreciate if you can clarify the above. I’m currently facing a customer with this exact situation and need to help them get calendar working with their CX600 phones.
Hi Brennon,
This just means you have to have the certificates installed on the Lync Front End and Director servers. Basically, just install the public root cert and any subordinate certificates that are used for your Exchange cert to each front end director.
HTH
-kp
Pingback: Lync 2011 Mac EXC_BAD_ACCESS crash
Kevin….I have this issue in Lync 2013. I have verified the WebServices Cert matches OWA but I still get the issue. Any other suggestions? I’m using a Polycom CX600.
Hey Bryan,
Please make sure the root and intermediate certs are all being passed correctly by the reverse proxy. You can test from digicert.com/help.
HTH
Kevin
Thanks Kevin. What FQDN do I run this against? OWA email address? One of the Lync pool addresses (Front-End, etc)? Reverse proxy? Internally we are using a Kemp Load Balancer where the Web Services should be pointed to.
The OWA address would be a good start. You can also observe the HTTPS transaction from your client (with fiddler and wireshark). I believe Drago posted an article on his site that has some details on a missing intermediate certificate and how he troubleshot it (www.lynclog.com).
HTH
Kevin