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.

Solution 1

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)

Solution 2

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)

Comments

[laindir]

Sorry, that was a poor choice of wording. When I said "the Personal store", I meant Local Machine\Personal in the mmc snap-in... which is LOCALMACHINE\MY. If I add it to MY for the test account, I still see the same error.

[laindir]

Also, that command would grant access for the account to the private key--something that should not exist on a client.

[Aviad P.]

Worked for me, thanks a lot!! Just one thing, it should be -c LOCAL_MACHINE\MY -s "certname" and -a "testuseraccountname" :)

[nullPainter]

The simpler approach is to use MMC and choose All Tasks -> Manage private keys. As I noted in a comment on the linked post, this only works (on Windows Server 2008, at least) if the certificate is in the Personal store. If it needs to reside somewhere else, move it to the Personal store, set the permissions then move it back again.