16

I have a c# app that calls a web service method that authenticates using a certificate. The code works, because when it is installed on server A (without a proxy) it authenticates.

When I install the code on server B, at client site, its installed behind a proxy. I've really tried almost everything but I keep getting this error:

Could not create SSL/TLS secure channel

Do you think this issue can be caused by a proxy server? If you've had any personal experience with this please share.

Thanks

JL.
  • 78,954
  • 126
  • 311
  • 459

5 Answers5

17

In my experience, nearly all such messages are due to some machine in the chain (client, proxy, server) not "liking" a certificate for some reason.

To elaborate on what twk said, if you're using self-signed certificates, or your own CA, you need to install the signing cert in the trusted authorities store on the server at least, and possibly on the proxy.

Common problems I've encountered:

  • The certificate on the server is not signed by an authority that the PROXY or the CLIENT trusts
  • The certificate on the CLIENT is not signed by an authority that the PROXY or the SERVER trusts
  • Oops, I forgot to export the private key when I created the cert to be installed on the client
  • My process does not have read permissions to the private key on the client
  • The client certificate is password protected and I didn't specify credentials when reading the certificate.
Bryan Slatner
  • 1,588
  • 2
  • 16
  • 19
13

I was having the same problem. In my case the certificates need the Network service access. You can check by

  1. Open certificate MMC
  2. Navigate to Certificates (Local Computer) > Personal > Certificates
  3. Right click on your certificate and select All Tasks> Manage Private Keys… from the context menu
  4. Set the appropriate permission
Snakebyte
  • 3,735
  • 3
  • 16
  • 12
5

If your certificate is not trusted (is self signed) then C# client will refuse to connect.

twk
  • 3,122
  • 2
  • 26
  • 36
  • You can buy a cert from Verisign (or Thawte, etc.), but it won't be trusted unless Verisign's signing key is in the "Trusted Root Certification Authorities" keystore. Now, in the case of most major CAs, the signing key is already there. However, that's NOT a guarantee. You should definitely check! At the very least, load up the certificate manager and double click on the key and go to the "certification path" tab and make sure it says "This certificate is OK." And, on the client side, you should also see "You have a private key that corresponds to this certificate" on the General tab. – Bryan Slatner Oct 22 '09 at 21:08
2

Add this to the constructor:

ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Reza Heidari
  • 1,192
  • 2
  • 18
  • 23
0

My answer is similar to that of Snakebyte. In my case the certificate's private key needs the IIS_IUSRS user access.

  1. Open certificate MMC
  2. Right click on your certificate and select All Tasks> Manage Private Keys… from the context menu
  3. Add the IIS_IUSRS user and set the appropriate permissions.
lucapan
  • 81
  • 1
  • 4