The MsTurnPing.exe application included in the Lync Server 2013 Resource Kit Tools package contains a bug that may have inadvertently triggered some incorrect practices related to the configuration of Edge server certificates.
Remember that the officially supported, best practice covered in this previous article is that an Edge Pool must utilize a single, identical certificate on all servers for the internal Edge interface which only includes the Edge Pool FQDN as the Common Name. The individual Edge Server’s unique FQDNs are not, and should not be included as these certificate should not include any SAN entries.
Issue
When running MsTurnPing.exe against a single Edge server it should not report any issues as the certificate’s Common Name is the single Edge Server’s FQDN (e.g. edge.schertz.name).
But when run against a multiple server Edge Pool in a DNS Load Balanced arrangement it will not function accurately. The tool will incorrectly report a problem with the certificate because it is hardcoded to utilize the Edge Server’s internal FQDN (e.g. edge1.schertz.name) during the test. But that FQDN should not be included in the certificate, thus causing the tool to report a problem establishing a secure connection to the server. The actual Lync Servers do not utilize the same method as they properly use the Edge Pool name.
- The tool will resolve the Edge Pool FQDN (e.g. edgepool.schertz.name) which is reported as the Cluster Name in the output. But as it connects to each server in the pool the Machine FQDN is reported
================================================================================
Cluster Name: edgepool.schertz.nameMachine FQDN edge1.schertz.name
Exception Message: Operation failed because the network connection was not available.
Cause: Lync Server Audio/Video Authentication service is not started================================================================================
Cluster Name: edgepool.schertz.nameMachine FQDN edge2.schertz.name
Exception Message: Unable to establish a connection.
Cause: Lync Server Audio/Video Authentication service is not started
In this environment there are actually no problems with the Lync Server A/V Authentication service and all ICE/STUN/TURN capabilities are functional.
- Checking the System log on the local server where the tool was executed should report an Schannel error explaining why the previous test connection failed.
Log Name: System
Source: Schannel
Event ID: 36884The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is edge1.schertz.name. The SSL connection request has failed.
Guidance
As the tool reports a false-positive in this scenario this unfortunately has caused some administrators to go down the incorrect route of replacing the internal Edge certificates with SAN certificates containing both the Computer and Pool FQDNs. The problem here is that every computer FQDN would need to be in the SAN as the same exact certificate must be applied to all servers so that the same public and private keys are used by all server nodes, yet there should not be a SAN field contains on the certificates.
The proper guidance is to leave the certificates as Lync intended, with only the Pool FQDN assigned to the single shared certificate and no other FQDNs are included.
Nice post, Jeff… So, at the end of the day – use what the Deployment Wizard recommends – not what one might THINK it should be…. ;o)
Hope things are good with you, mate!
Rick
Yeah, at this point the Deployment Wizard (mostly) knows what it is doing 🙂
You may also want to have a look at below powershell based tool that I developed some time ago to overcome some limitations of msturnping:
http://blogs.technet.com/b/nettracer/archive/2013…
Excellent, thanks for sharing!
My pleasure Jeff 🙂