Testing Certificate Trust Between Two Windows Machines

Here are some easy steps that can be used to verify if two Windows machines trust the issuing certificates used to negotiate MTLS (Mutual Transport Layer Security) between each other.  Some OCS examples of this could be: 

• Front-End servers that need to communicate so the users can IM each other and see presence
• A Front-End server that needs to communicate with an Access Edge Server’s internal interface (remember that an Access Edge Server typically isn’t a member of the domain and therefore may not trust the certificate on the FE as the trust path may only be there for domain members by default).
• An Access Edge Server that needs to communicate with an Access Edge Server in a different OCS deployment that you want to Federate with
• An Access Server that needs to … you get the idea :-)

In this example, I’ll use generic “node 1” and “node 2” names because these steps should be more or less possible in lots of scenarios where two Windows Servers need to talk over MTLS.  Remember that all of this negotiation happens in the context of the computer account (not a service account or user account) so keep that in mind when you open the MMC.  Once you’ve logged onto the server as an Administrator account, try these steps out:

1. Logon to Node 1 and then open the Certificates MMC (remember, computer account not current user)
2. Under the personal store, double-click on the certificate being used for MTLS and then go to the Certification Path tab
3. Click on the issuing certificate and then View Certificate
4. On the Details Tab of that certificate find the serial number and grab the first 4 to 6 digits
5. Now logon to Node 2 and then open the same certificates snap-in (again, computer account)
6. Right-click on Certificates (Local Computer) and select Find Certificates
7. On the Contains tab enter in the 4 to 6 digits you grabbed from Node 1
8. Change the “Look in Field” tab to Serial Number and then click Find Now
9. Review the search results to verify expected behavior of a single certificate being found in the Trusted Root store.  There may be a second certificate is the CA is a Trusted Third-Party
10. You’ll want to repeat this process for each certificate in the certificate chain.  For example, if the MTLS certificate has a chain that is three levels deep (MTLS certificate, intermediate certificate, and root certificate) you’ll want to repeat this process twice:  once for the intermediate certificate and then again for the root certificate.
11. Now repeat this process again in the other direction (from node 2 to node 1) and make changes as needed (i.e., install missing intermediate or root certificates, etc.)
12. If all goes well in terms of the certificate chains, remember that in OCS certificates are read during service startup so you may need to recycle services for any changes to take effect.

NOTE:   If you find any duplicates in your certificate chains a general rule of thumb would be to remove them as it will increase the size of the certificate chain sent down to the remote server during the MTLS negotiation.  Be careful to delete problem certificates from the correct store!  Root certificates should be in the root store; intermediates in the intermediate store.  Some root certificates will also show-up in trusted third-party which I wouldn’t classify as a duplicate.  I’d classify duplicates as more than one instance of the same serial number in the same store or in multiple stores (with the exception being the trusted third-party store).  Also remember that typically if there is an issue with certificate trust, there are multiple ways to getting to the same resolution.  For OCS installations, you’ll very likely find there have been errors logged in the Event Viewer and if SIPStack logging is enabled more errors there as well.  Also, if you’ve successfully logged onto OCS, then the likelihood of a certificate issue is low as that would manifest itself as happening during logon, not after.

I hope these steps are helpful!

Terry