Certificates, certificates, all I see are certificates...

I was working on a Lync implementation for a local ISP. The design was set forward with one single site, which contains a Director, Front-end and edge pool, where each pool contains two servers for High Availability. After deploying the edge servers we noticed that the XDS replication was not occurring from the front-end servers to the Edge servers. We checked the Lync file share and the network to verify that the Front-end server could talk to the Edge servers on port 4443. Everything turned out OK, yet no matter what we did, the replication towards the edge servers didn't kick off.

While searching the internet for a possible solution, the following comment kept spinning in my mind:
"Replication issue's with the edge server are usually Network or certificate related." As we had checked the network, we started troubleshooting the certificates again. The certificates turned out OK, yet when investigating the certificates I did see that the Trusted Root Certificate store did contain a lot of certificates. I didn't count them, but usually you will see around 30 root certificates, the root CA container of the edge did contain so many certificates they didn't fit in a single view.

I started logging using the Lync Logging tool, yet this only gave the following warning: Master Directory not discovered yet. Investigated the eventlog where the following warning drew my attention in the system log:

Log Name:      System

Source:        Schannel

Date:         

Event ID:      36885

Task Category: None

Level:         Warning

Keywords:     

User:          SYSTEM

Computer:     

Description:

When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.

I searched the Microsoft Forums where I found following thread:
 http://social.technet.microsoft.com/Forums/en-AU/ocsedge/thread/1cd3be72-1f65-48ae-aa8c-498f79917492

We added the registry DWORD and replication kicked of perfectly.

Edit the registry on the Edge server to add a DWord value, SendTrustedIssuerList, to the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key and assign it a value of 0. This will prevent schannell.dll from truncating the Root CA list from the edge server, and allow validation tests to pass.

More info on this registry setting can be found here:

This entry controls the flag controlling sending of list of trusted issuers. In the case of servers that trust hundreds of certificate authorities for client authentication, there are too many issuers for the server to be able to send them all to the client when requesting client authentication. In this situation, this registry key can be set, and instead of sending a partial list, Schannel will not send any to the client.
Not sending a list of trusted issuers might impact what the client sends when asked for a client certificate. For example, when Internet Explorer receives a request for client authentication, it only displays the client certificates that chain up to one of the certificate authorities that is sent by the server. If the server did not send a list, then Internet Explorer displays all of the client certificates that are installed on the client machine. This behaviour might be desirable, when PKI environments include cross certificates, the client and server certificates will not have the same Root CA and therefore, Internet Explorer cannot chose a certificate that chains up to on of the server’s CAs. By configuring the server to not send a trusted issuer list then Internet Explorer will send all its certificates.
This entry does not exist in the registry by default. This value is true by default.

http://technet.microsoft.com/en-us/library/cc776467%28v=ws.10%29.aspx

A few days later we where testing the web conferencing and discovered that only anonymous users where able to join a conference. When a user selected domain user, in the web-interface following error would occur:

We enabled logging with the web-client and this showed us the following:

We applied the same registry setting to the Directors and front-end pool servers. After applying the settings user where able to join a conference using the Lync web client.