Getting “Could not establish secure channel for SSL/TLS with authority” even though ServerCertificateValidationCallback returns true

Question

I'm working with a vendor who has set up a WCF service (WebHttpBinding) using Transport security with Certificate authentication. I host a similar service for the vendor which is working correctly, so I have a basic idea how this is supposed to work.

Running on Windows 7, when I consume the service under my own account, everything works fine, and I get a response back. When I consume it under a test account, I get an exception in mscorlib that it "Could not establish secure channel for SSL/TLS with authority X.X.X.X". If I add the test account to the built in Administrators group, it works fine.

The certificate for the server is self-signed with the subject field set as CN=X.X.X.X, and I have the server cert in the Personal store and the CA cert in the Trusted Root Certificate Authorities store.

Additionally, if I try setting the System.Net.ServicePointManager.ServerCertificateValidationCallback to print a diagnostic and return true, I get some interesting behavior. Running under my account, the callback is called twice, and then the WCF call succeeds. Running under the test account, it is called once, returns, and then I get the exception above.

My best guess is that this is related to some privilege the test account lacks, but I don't understand how Windows handles certificates well enough to know for sure, and I don't know where to start looking.

Answer 1

This is the root of the problem: ... I have the server cert in the Personal store and the CA cert in the Trusted Root Certificate Authorities store.

If you install the server cert under the test account's personal store it should resolve it, i think the command for cmd prompt should be something like

winhttpcertcfg.exe -g -c LOCALMACHINE\MY -s "certtype" "testuseraccountname"

or use the mmc snap in. (i'm not too sure how reliable this is though, I use the above tool)

Answer 2

Took a couple hours on the phone with a Microsoft engineer, but the problem is solved. Since this is the exact same error message you see with some server certificate problems, I assumed that must be the issue. As it turned out, the test account did not have access to the client certificate private key. This should be resolvable using winhttpcertcfg (like in winhttpcertcfg giving access to iiS user in Windows 7)