问题
Really thought I had this issue fixed, but it was only disguised before.
I have a WCF service hosted in IIS 7 using HTTPS. When I browse to this site in Internet Explorer, it works like a charm, this is because I have added the certificate to the local root certificate authority store.
I'm developing on 1 machine, so client and server are same machine. The certificate is self-signed directly from IIS 7 management snap in.
I continually get this error now...
Could not establish trust relationship for the SSL/TLS secure channel with authority.
... when called from client console.
I manually gave myself permissions and network service to the certificate, using findprivatekey and using cacls.exe.
I tried to connect to the service using SOAPUI, and that works, so it must be an issue in my client application, which is code based on what used to work with http.
Where else can I look I seem to have exhausted all possibilities as to why I can't connect?
回答1:
As a workaround you could add a handler to the ServicePointManager's ServerCertificateValidationCallback on the client side:
System.Net.ServicePointManager.ServerCertificateValidationCallback +=
(se, cert, chain, sslerror) =>
{
return true;
};
but be aware that this is not a good practice as it completely ignores the server certificate and tells the service point manager that whatever certificate is fine which can seriously compromise client security. You could refine this and do some custom checking (for certificate name, hash etc). at least you can circumvent problems during development when using test certificates.
回答2:
When I have this problem it is because the client.config had its endpoints like:
https://myserver/myservice.svc
but the certificate was expecting
https://myserver.mydomain.com/myservice.svc
Changing the endpoints to match the FQDN of the server resolves my problem. I know this is not the only cause of this problem.
回答3:
Your problem arises because you're using a self signed key. The client does not trust this key, nor does the key itself provide a chain to validate or a certificate revocation list.
You have a few options - you can
turn off certificate validation on the client (bad move, man in the middle attacks abound)
use makecert to create a root CA and create certificates from that (ok move, but there is still no CRL)
create an internal root CA using Windows Certificate Server or other PKI solution then trust that root cert (a bit of a pain to manage)
purchase an SSL certificate from one of the trusted CAs (expensive)
回答4:
the first two use lambda, the third uses regular code... hope you find it helpful
//Trust all certificates
System.Net.ServicePointManager.ServerCertificateValidationCallback =
((sender, certificate, chain, sslPolicyErrors) => true);
// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
= ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));
// validate cert by calling a function
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);
// callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
bool result = false;
if (cert.Subject.ToUpper().Contains("YourServerName"))
{
result = true;
}
return result;
}
回答5:
A one line solution. Add this anywhere before calling the server on the client side:
System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };
This should only be used for testing purposes because the client will skip SSL/TLS security checks.
回答6:
I encountered the same problem and I was able to resolve it with two solutions: First, I used the MMC snap-in "Certificates" for the "Computer account" and dragged the self-signed certificate into the "Trusted Root Certification Authorities" folder. This means the local computer (the one that generated the certificate) will now trust that certificate. Secondly I noticed that the certificate was generated for some internal computer name, but the web service was being accessed using another name. This caused a mismatch when validating the certificate. We generated the certificate for computer.operations.local, but accessed the web service using https://computer.internaldomain.companydomain.com. When we switched the URL to the one used to generate the certificate we got no more errors.
Maybe just switching URLs would have worked, but by making the certificate trusted you also avoid the red screen in Internet Explorer where it tells you it doesn't trust the certificate.
回答7:
Please do following steps:
Open service link in IE.
Click on the certificate error mention in address bar and click on View certificates.
Check issued to: name.
Take the issued name and replace localhost mention in service and client endpoint base address name with A fully qualified domain name (FQDN).
For Example: https://localhost:203/SampleService.svc To https://INL-126166-.groupinfra.com:203/SampleService.svc
回答8:
If you use .net core try this:
client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
new X509ServiceCertificateAuthentication()
{
CertificateValidationMode = X509CertificateValidationMode.None,
RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
};
回答9:
I had the same problem. I also had added CA certificates in the local store, but I did in the WRONG way.
Using mmc Console (Start -> Run -> mmc ) you should add Certificates snap-in as Service account (choosing the service account of IIS) or Computer account (it adds for every account on the machine)
Here an image of what I'm talking about
From here now, you can add certificates of CAs (Trusted Root CAs and Intermediate CAs), and everything will work fine
回答10:
In addition to the answers above, you could encounter this error if your client is running the wrong TLS version, for example if the server is only running TLS 1.2.
You can fix it by using:
// tested in .NET 4.5:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
回答11:
I had similar issue with self-signed certificate. I could resolve it by using the certificate name same as FQDN of the server.
Ideally, SSL part should be managed at the server side. Client is not required to install any certificate for SSL. Also, some of the posts mentioned about bypassing the SSL from client code. But I totally disagree with that.
回答12:
I just dragged the certificate into the "Trusted Root Certification Authorities" folder and voila everything worked nicely.
Oh. And I first added the following from a Administrator Command Prompt:
netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET\INTERAKTIV
I am not sure of the name you need for the user (mine is norwegian as you can see !):
user=NT-AUTHORITY/INTERACTIVE ?
You can see all existing urlacl's by issuing the command: netsh http show urlacl
回答13:
This occurred when trying to connect to the WCF Service via. the IP e.g. https://111.11.111.1:port/MyService.svc while using a certificate tied to a name e.g. mysite.com.
Switching to the https://mysite.com:port/MyService.svc resolved it.
回答14:
This occurred when trying to connect to the WCF Service using only host name e.g. https://host/MyService.svc while using a certificate tied to a name e.g. host.mysite.com.
Switching to the https://host.mysite.com/MyService.svc and this resolved it.
回答15:
Just fixed a similar issue.
I realized I had an application pool that was running under an account that only had reading permission over the certificate that it was used.
The .NET application could correctly retrieve the certificate but that exception was thrown only when GetRequestStream() was called.
Certificates permissions can be managed via MMC console
回答16:
Add this to your client code :
ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(
delegate
{
return true;
});
来源：https://stackoverflow.com/questions/1742938/how-to-solve-could-not-establish-trust-relationship-for-the-ssl-tls-secure-chan