1

A third party vendor is adding authentication (yay!), but it doesn't always work for us (boo!).

When the C# application is run "as administrator" it works fine. However, when the application is run as a normal (non-administrator) user it fails with the message

"Authentication failed because the remote party has closed the transport stream"

We are explicitly setting to TLS 1.2

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

We are

  • executing a 4.6 .NET C# WCF client
  • that consumes an HTTPS web service
  • using TLS1.2
  • on a Windows Server 2012 platform
John Rocha
  • 1,656
  • 3
  • 19
  • 30
  • 1
    Have you talked to the third party vendor? It's their code, so they're best positioned to answer any issues with it. – Tim Feb 09 '17 at 21:04
  • 1
    They don't know. They point back to something with our environment since it works when running as the ADMIN user but not as any other users. – John Rocha Feb 09 '17 at 21:48

2 Answers2

5

We figured it out with the help of Getting "Could not establish secure channel for SSL/TLS with authority" even though ServerCertificateValidationCallback returns true as well as winhttpcertcfg giving access to IIS user in Windows 7 too.

The problem was that the certificate was installed for Trusted People for the "computer" account. When running in Admin mode, or as a user that has admin privileges, it worked fine. However, when run as our "service account" (in quotes because it's not a true service account) -- the service account didn't have permission to read the certificate.

We found that digging into the C:\ProgramData\Microsoft\crypto\rsa\machinekeys directory and changing the read permission for the appropriate cert worked.

We didn't like the proposed solution of using icacls to change the read permission of the installed certificate (partially because of the daunting task of actually finding the correct cert entry.)

We figure out that we could run mmc.exe as the service account and then install it to the Trusted People level for that account. And then our non-admin application could read the cert and establish the connection.

TylerH
  • 20,799
  • 66
  • 75
  • 101
John Rocha
  • 1,656
  • 3
  • 19
  • 30
  • Glad you found the problem. And thank you for sharing the answer - it will help folks down the road :) – Tim Feb 09 '17 at 22:03
0

This may be different than OPs original problem but my issue was that I had my IIS Application using Windows Auth Impersonation so it was trying to access the cert file in C:\ProgramData\Microsoft\crypto\rsa\machinekeys with the impersonated user who did not have the rights to do so.

I changed the design to turn Impersonation off and this issue ceased to exist.

Nick Rubino
  • 965
  • 7
  • 9