2

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.

laindir
  • 1,650
  • 1
  • 14
  • 19
  • I forgot to re-login after changing the test user to a local administrator. When the test user is an admin, it works; when not, I get the error. Question edited. – laindir Jun 12 '12 at 13:53

2 Answers2

3

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)

Chris
  • 2,471
  • 25
  • 36
  • 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 Jun 12 '12 at 13:50
  • Also, that command would grant access for the account to the private key--something that should not exist on a client. – laindir Jun 12 '12 at 14:44
  • Worked for me, thanks a lot!! Just one thing, it should be `-c LOCAL_MACHINE\MY` `-s "certname"` and `-a "testuseraccountname"` :) – Aviad P. Dec 29 '12 at 19:47
3

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)

Community
  • 1
  • 1
laindir
  • 1,650
  • 1
  • 14
  • 19
  • 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. – nullPainter Mar 07 '17 at 00:10