Certificate error from Polycom DMA 7000 after upgrading to Skype for Business

After upgrading from Lync 2013 to Skype for Business I found that the Polycom DMA 7000
could not connect to Skype4B.


An error similar to this showed on the Lync frontend servers.

TLS outgoing connection failures.

Over the past 221 minutes, Skype for Business Server has experienced TLS outgoing connection failures 15 time(s). The error code of the last failure is 0x80090322(SEC_E_WRONG_PRINCIPAL) while trying to connect to the server "video.customer.com" at address [xxx.xxx.100.150:5061], and the display name in the peer certificate is "customerdma.customer.com".
Cause: Most often a problem with the peer certificate or perhaps the host name (DNS) record used to reach the peer server. Target principal name is incorrect means that the peer certificate does not contain the name that the local server used to connect. Certificate root not trusted error means that the peer certificate was issued by a remote CA that is not trusted by the local machine.

The cause could be found on page 109 in this guide from Polycom:

http://supportdocs.polycom.com/PolycomService/support/global/documents/support/strategic_partner_solutions/uc_solution_microsoft_deployment_guide_sep_15.pdf

TLS Security Prior to Skype for Business, you could configure a MatchURI without TLS validation by generating a certificate for the Trusted Application Server with the fully qualified domain name (FQDN) of the server (dma.domain.com in this example). With Skype for Business, the TLS route is validated. You must now generate a Subject Alternative Name (SAN) that includes both the FQDN for your Trusted Application Server and the MatchURI. If you do not configure, or configure incorrectly, an error message displays “Certificate trust with another server could not be established”, as shown next.

I then tried the solution proposed by Polycom using the certutil tool.

This did not work. It still reported "wrong principal".

To make this work I had to use the Polycom Pool name as the common name of the cert.

I also included all the FQDN for the servers in the Polycom DMA pool as SANs.

This worked and the errors disappeared.