Like its predecessor, Microsoft OCS, Microsoft Lync Server 2010 relies heavily on PKI certificates to allow servers to verify their identity in TLS connections with clients, and in mutual TLS (MTLS) connections to other servers.
Unlike OCS, certificates cannot be viewed or managed directly in the management console. Nowhere in the Lync Control Panel can you view the certificate details by right-clicking on the properties of a Lync server role. They are not present in the new Lync Topology Builder either.
Viewing Certificates in Lync Server
There are two primary ways to see which certificates are in use on a particular Lync server, and the associated certificate details:
- On any Lync server role, run the Lync Server Deployment Wizard, click on “Install or Update Lync Server System”, and run Step 3: Request, Install or Assign Certificates. This will bring up the Certificate Wizard which will list and manage all the certificates on this Lync server. You can also request a certificate from an internal CA, or assign an existing certificate from this wizard.
- Use the PowerShell cmdlet Get-CsCertificate from the Lync Management Shell.
- TIP: you need to view all properties on the certificate objects returned to see the SAN’s. You can do this with a Get-CsCertificate | fl –property *
Note: by default, a Standard Edition Lync Front-End server will use 3 certificates to support sign-in and internal and remote access to Web Services (formerly known as Web Components):
- Default Certificate: the certificate used for clients to logon to the Front-End
- Web internal certificate: this certificate is used for HTTP/HTTPS requests to the internal Web Services (including Simple URLs).
- Web external certificate: this certificate is used when remote clients (outside the firewall) access the web services via the reverse proxy.
In many cases you can use the same certificate for different purposes.
New Subject Alternative Name (SAN) Entries Required
Most Lync certificate requirements are similar to OCS. One significant difference is the requirement to add the FQDN’s of the Simple URL’s on the certificates used for the Internal and External Web Services.
For example, if your SIP domain is example.com, and you have configured the Simple URL’s to be https://meet.example.com, https://dialin.example.com, and https://admin.example.com, the SAN on the certificate used on the Internal and External Web Services needs to have:
Note: in addition to the Simple URL’s, you also need a SAN entry for the external facing web services: webext.example.com.
The Web Services will run on a either Front-End server or a Director. If you have configured multiple Simple URL’s for Meetings, Dial-in, and Administration, you need to add the FQDN of all the Simple URLs.
TIP – In the Lab – Watch those Time Zones
If you installed Lync in a lab environment, and your first sign-in experience yields the infamous “There was a problem verifying the certificate from the server”, check the time-zone(s) on your lab machines before you chase down more potentially complex certificate issues.
As you can see in the screen shot below, this certificate in my lab was invalid because the “valid from” date was a date in the future!
Sure enough, my DC and had an incorrect time zone – which was not obvious because the clock settings (time) were correct; just the time zone was incorrect.
It was happy Lync’ing after I set the time zone correctly and re-issued and re-assigned the certificate on the Lync Front-End.
The Microsoft Lync PowerShell blog has a good post with information on Get-CsClientCertificate and Revoke-CsClientCertificate: http://blogs.technet.com/b/csps/archive/2010/11/16/haikudefault.aspx.
The Microsoft Lync website on TechNet has some good information regarding Certificate Infrastructure Requirements: http://technet.microsoft.com/en-ca/library/gg398066.aspx.
Share and Enjoy: