如何解决“无法build立具有权限的SSL / TLS安全通道的信任关系”
真的以为我有这个问题修正，但它只是以前伪装。
我有一个使用HTTPS托pipe在IIS 7中的WCF服务。 当我在Internet Explorer中浏览这个网站时，它就像一个魅力，这是因为我已经将证书添加到本地根证书颁发机构存储。
我正在开发一台机器，所以客户端和服务器是同一台机器。 该证书是直接从IIS 7pipe理单元签入的。
我现在不断得到这个错误…
无法build立具有权限的SSL / TLS安全通道的信任关系。
…当从客户端控制台调用。
我手动给自己的权限和networking服务的证书，使用findprivatekey和使用cacls.exe 。
我尝试使用SOAPUI连接到服务，并且工作，所以它必须是我的客户端应用程序中的一个问题，它是基于过去使用http的代码。
我还能在哪里看到我似乎用尽了所有可能性，为什么我不能连接？
作为一种解决方法，您可以在客户端上向ServicePointManager的ServerCertificateValidationCallback添加一个处理程序：
System.Net.ServicePointManager.ServerCertificateValidationCallback += (se, cert, chain, sslerror) => { return true; };
但是请注意， 这不是一个好的做法，因为它完全忽略了服务器证书，并告诉服务点经理无论证书是否可以严重危害客户端安全。 你可以改进这一点，做一些自定义检查（证书名称，散列等）。 至less您可以在使用testing证书时避开开发过程中的问题。
当我遇到这个问题时，是因为client.config的terminal类似于：
https://myserver/myservice.svc
但证书是期待的
https://myserver.mydomain.com/myservice.svc
更改端点以匹配服务器的FQDN可以解决我的问题。 我知道这不是造成这个问题的唯一原因。
前两个使用lambda，第三个使用正则代码…希望你觉得有帮助
//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; }
您的问题出现是因为您正在使用自签名密钥。 客户端不信任此密钥，密钥本身也不提供链路来validation或证书撤销列表。
你有几个select – 你可以
-
closures客户端上的证书validation（坏行为，中间人攻击比比皆是）
-
使用makecert创build一个根CA，并从中创build证书（确定移动，但仍然没有CRL）
-
使用Windows证书服务器或其他PKI解决scheme创build一个内部根CA，然后相信根证书（有点痛苦pipe理）
-
从其中一个可信CA购买SSL证书（昂贵的）
我遇到了同样的问题，我可以用两种解决scheme解决它：首先，我使用“计算机帐户”的MMCpipe理单元“证书”，并将自签名证书拖入“受信任的根证书颁发机构”文件夹。 这意味着本地计算机（生成证书的计算机）现在将信任该证书。 其次，我注意到证书是为一些内部计算机名称生成的，但是Web服务正在使用另一个名字进行访问。 这在validation证书时导致不匹配。 我们为computer.operations.local生成了证书，但使用https://computer.internaldomain.companydomain.com访问了Web服务。; 当我们将URL切换到用于生成证书的URL时，我们没有更多的错误。
也许只是切换url会起作用，但是通过使证书可信，您还可以避免Internet Explorer中的红色屏幕，它告诉您它不信任证书。
单线解决scheme。 在客户端调用服务器之前，将其添加到任何位置：
System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };
这应该只用于testing目的，因为客户端将跳过SSL / TLS安全检查。
请执行以下步骤：
-
在IE中打开服务链接。
-
点击地址栏中提到的证书错误，然后点击查看证书。
-
支票发给：姓名。
-
取出发行的名称，并将服务和客户端端基地址名称中的localhost提及replace为完全限定的域名（FQDN）。
例如：https：// localhost ：203 / SampleService.svc到https：// INL-126166-.groupinfra.com：203 / SampleService.svc
我与自签证书有类似的问题。 我可以通过使用与服务器的FQDN相同的证书名称来解决此问题。
理想情况下，SSL部分应该在服务器端进行pipe理。 客户端不需要为SSL安装任何证书。 此外，还提到了一些关于从客户端代码绕过SSL的post。 但我完全不同意这一点。
我只是将证书拖到“受信任的根证书颁发机构”文件夹中，一切正常。
哦。 我首先从pipe理员命令提示符中添加了以下内容：
netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET\INTERAKTIV
我不确定用户需要的名称（我可以看到你是挪威人）： user=NT-AUTHORITY/INTERACTIVE ？
您可以通过发出以下命令来查看所有现有的urlacl： netsh http show urlacl
我有同样的问题。 我也在当地的商店里加了CA证书，但是我做错了。
使用mmc控制台（开始 – >运行 – > mmc ），您应该添加证书pipe理单元作为服务帐户（selectIIS的服务帐户）或计算机帐户（它为计算机上的每个帐户添加）
这里是我正在谈论的图像 
从现在开始，您可以添加证书的CA（ 受信任的根CA和中间CA ），一切都会正常工作
发生这种情况时，只使用主机名连接到WCF服务，例如https：//host/MyService.svc，同时使用与名称绑定的证书，例如host.mysite.com。
切换到https://host.mysite.com/MyService.svc ，这解决了它。
当尝试通过连接到WCF服务时发生这种情况。 例如https://111.11.111.1:port/MyService.svc同时使用与名称绑定的证书，例如mysite.com。
切换到https://mysite.com:port/MyService.svc解决了它。
除了上面的答案之外，如果客户端运行的是错误的TLS版本，例如服务器只运行TLS 1.2，则可能会遇到此错误。
您可以通过使用以下方法解决它
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; //tested in .NET 4.5
刚刚解决了类似的问题。
我意识到我有一个应用程序池在一个帐户下运行，该帐户只有对使用该证书的读取权限。
.NET应用程序可以正确地检索证书，但只有在调用GetRequestStream（）时才引发该exception。
证书权限可以通过MMC控制台进行pipe理
添加到您的客户端代码：
ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback( delegate { return true; });
