真的以为我修好了这个问题，但之前只是伪装了。
我使用HTTPS在IIS 7中托管了WCF服务。当我在Internet Explorer中浏览到此站点时，它就像一个魅力，这是因为我已将证书添加到本地根证书颁发机构商店。
我正在一台机器上开发，所以客户端和服务器是同一台机器。该证书直接从IIS 7管理管理单元中自签名。
我现在不断得到这个错误......
无法为具有权限的SSL / TLS安全通道建立信任关系。
...从客户端控制台调用时。
我使用findprivatekey并使用cacls.exe手动为证书提供权限和网络服务。
我试图使用SOAPUI连接到服务，这是有效的，所以它必须是我的客户端应用程序中的一个问题，这是基于过去使用http的代码。
在哪里可以看到我似乎已经耗尽了为什么我无法连接的所有可能性？
作为一种解决方法，您可以在客户端向ServicePointManager的ServerCertificateValidationCallback添加处理程序：
System.Net.ServicePointManager.ServerCertificateValidationCallback +=
(se, cert, chain, sslerror) =>
{
return true;
};
但请注意，这不是一个好的做法，因为它完全忽略了服务器证书，并告诉服务点经理无论哪种证书都可以，这会严重损害客户端的安全性。您可以对此进行优化并进行一些自定义检查（对于证书名称，哈希等）。至少你可以在开发过程中避免使用测试证书时的问题。
除了上面的答案，如果您的客户端运行错误的TLS版本，您可能会遇到此错误，例如，如果服务器只运行TLS 1.2。
您可以使用以下方法修复它：
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; //tested in .NET 4.5
如果您使用.net核心试试这个：
client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
new X509ServiceCertificateAuthentication()
{
CertificateValidationMode = X509CertificateValidationMode.None,
RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
};
我只是将证书拖到“受信任的根证书颁发机构”文件夹中，并且所有内容都很顺利。
哦。我首先从管理员命令提示符添加以下内容：
netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET\INTERAKTIV
我不确定用户需要的名称（我的名字是挪威语！）：user=NT-AUTHORITY/INTERACTIVE？
您可以通过发出命令来查看所有现有的urlacl：netsh http show urlacl
尝试通过连接到WCF服务时发生这种情况。 IP例如https://111.11.111.1:port/MyService.svc使用与名称相关的证书，例如mysite.com。
切换到https://mysite.com:port/MyService.svc解决了它。
尝试仅使用主机名连接到WCF服务时发生这种情况，例如https://host/MyService.svc使用与名称相关的证书，例如host.mysite.com。
切换到https://host.mysite.com/MyService.svc，这解决了它。
刚刚解决了类似的问题。
我意识到我有一个应用程序池，该应用程序池在一个帐户下运行，该帐户只对其使用的证书具有读取权限。
.NET应用程序可以正确检索证书，但只有在调用GetRequestStream（）时才抛出该异常。
证书权限可以通过MMC console进行管理
将其添加到您的客户端代码：
ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(
delegate
{
return true;
});
当我遇到这个问题时，因为client.config的端点如下：
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;
}
一线解决方案。在客户端调用服务器之前将其添加到任何位置：
System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };
这应仅用于测试目的，因为客户端将跳过SSL / TLS安全检查。
我遇到了同样的问题，我能够用两个解决方案来解决它：首先，我使用MMC管理单元“证书”作为“计算机帐户”并将自签名证书拖到“受信任的根证书颁发机构”文件夹中。这意味着本地计算机（生成证书的计算机）现在将信任该证书。其次，我注意到证书是为某些内部计算机名生成的，但是使用其他名称访问了Web服务。验证证书时，这会导致不匹配。我们为computer.operations.local生成了证书，但是使用https://computer.internaldomain.companydomain.com访问了Web服务。当我们将URL切换到用于生成证书的URL时，我们不再有错误。
也许只是切换URL会起作用，但通过使证书可信，您也可以避免Internet Explorer中的红色屏幕，它告诉您它不信任证书。
请执行以下步骤：
例如：https：// localhost：203 / SampleService.svc到https://INL-126166-.groupinfra.com:203/SampleService.svc
我有自签名证书的类似问题。我可以使用与服务器的FQDN相同的证书名称来解决它。
理想情况下，SSL部分应在服务器端进行管理。客户端无需为SSL安装任何证书。此外，一些帖子提到绕过客户端代码中的SSL。但我完全不同意这一点。
我有同样的问题。我也在本地商店添加了CA证书，但我做错了。
使用mmc控制台（开始 - >运行 - > mmc），您应该添加证书管理单元作为服务帐户（选择IIS的服务帐户）或计算机帐户（它为计算机上的每个帐户添加）
这是我正在谈论的图像
从现在开始，您可以添加CA（受信任的根CA和中间CA）的证书，一切都会正常工作