CODEWITHSUNDEEP
c#.netsslwebapi2
Wildan Nugraha
Wildan Nugraha

Reputation: 53

C# How to solve HtppWebResponse return Could not establish trust relationship for the [SSL/TLS] secure channel?

I am using .Net Webapi 2 and i am getting the following error during call another web service with 'Https'.

Could not establish trust relationship for the SSL/TLS secure channel

and i also found temporary solution. with adding this line of code before executing httpwebresponse

ServicePointManager
    .ServerCertificateValidationCallback = 
    RemoveCertificateValidationCallback (delegate { return true; });

first of all i dont have idea what that code mean but at least that code work and i am succed hit Https web service. But that code is detected in veracode scan and it gots medium flaws security issue.

veracode documentation says: that i have to monitor wether certificate is expire or not. because it can make exception.

the question is. is there any solution for me to call https web service from server ? without using that code ? or do i have to install certificate and do i have to configure something in iis for calling https web service from server side / backend ?

Upvotes: 0

Views: 2877

Answers (1)

gregmac
gregmac

Reputation: 25311

This literally means the place where your code is running doesn't trust the certificate installed on the remote site.

Though the code you posted bypasses all authentication checks, this is not really a good practice as SSL gives you a bit of assurance that the site you're talking to is legitimate, and no one is doing a man-in-the-middle attack for example to intercept your data.

Diagnostic step number one is to visit that page in your browser and take a look at the certificate.

enter image description here

Make sure your browser thinks it's secure -- it'll tell you why it doesn't, if it doesn't. Common reasons:

  1. Expired (check Valid from .. to)
  2. Mismatched domain name (check both Issued To and Subject Alternative Name)
  3. Issued by non-trusted authority

In the case of (1) and (2), it's really a server issue the remote service needs to deal with.

With (2) sometimes people only issue a certificate for "www.example.com" and not "example.com" (or "*.example.com", which doesn't include "example.com") so an easy work-around is to visit the site with the matching domain name.

In case of (3), a common reason for this is a self-signed certificate. This is like vouching for yourself, and obviously isn't very trustworthy. It's also possible you simply don't trust the valid CA (Certificate Authority) that signed the certificate. There's a few ways to deal with this:

  • Have the web service get a new certificate from a trusted CA (LetsEncrypt is a good choice these days, and is both automated and free)
  • Update your trust roots (eg, if your system doesn't have the latest updates): Win 7/10, Windows Server
  • Import the root CA certificate (see Certificate Path tab) that signed this certificate to your system and mark it as trusted.

Upvotes: 2

Related Questions