如何解決「無法建立與權威的SSL/TLS安全通道的信任關係」

113

真的以爲我有這個問題修復，但它只是以前僞裝。如何解決「無法建立與權威的SSL/TLS安全通道的信任關係」

我有一個使用HTTPS在IIS 7中託管的WCF服務。當我在Internet Explorer中瀏覽這個網站時，它像一個魅力，這是因爲我有證書添加到本地根證書頒發機構存儲。

我在1臺機器上開發，所以客戶機和服務器是同一臺機器。該證書是自簽名直接從IIS 7管理的定位。

現在我不斷地得到這個錯誤...

無法建立信任關係與權威的SSL/TLS安全通道。

...當從客戶端控制檯調用時。

我手動給了自己的權限和網絡服務的證書，使用findprivatekey和使用cacls.exe。

我試圖使用SOAPUI連接到服務，並且工作，所以它必須是我的客戶端應用程序中的一個問題，它是基於過去使用http的代碼。

我還能在哪裏看起來我似乎已經用盡了所有可能性，爲什麼我無法連接？

來源

2009-11-16 JL.

可能重複（http://stackoverflow.com/questions/703272/could-not-建立信任關係對於ssl-tls-secure-channel-soap） – jww 2014-08-15 20:52:30

如果您有控制證書的創建的權限，請不要忘記「備用主題名稱」。就像你可以把通配符放在「* .full.domainname.com」中一樣。請參閱https://www.digicert.com/subject-alternative-name.htm – granadaCoder 2016-10-28 15:03:39

170

作爲一種變通方法，你可以一個處理程序添加到ServicePointManager的ServerCertificateValidationCallback在客戶端：

System.Net.ServicePointManager.ServerCertificateValidationCallback += 
    (se, cert, chain, sslerror) => 
     { 
      return true; 
     };

但要注意，這是不是一個好的做法，因爲它完全忽略服務器證書並告訴服務點經理，無論證書是否可以嚴重危害客戶的安全。你可以改進它，並做一些自定義檢查（證書名稱，哈希等）。至少您可以在使用測試證書時繞開開發過程中的問題。

來源

2009-11-16 15:39:30

我認爲大多數公共設置將使用購買的證書，但在開發期間在條件#if語句中使用上述代碼。企業開發人員通常應該設置一個內部CA服務器>> http://technet.microsoft.com/en-us/library/cc875810.aspx – 2010-07-15 18:48:31

幫助我弄清楚如何讓我的SSL WCF調用與Fiddler2一起工作來進行調試。 – 2011-03-04 01:45:01

@karank考慮將它放在Global.asax的Application_Start方法中（請參閱http://stackoverflow.com/a/12507094/1175419）。我強烈建議使用#if DEBUG編譯器指令或類似於Luke評論中提到的類似命令。 – 2014-06-19 16:22:55

您的問題出現是因爲您使用的是自簽名密鑰。客戶端不信任此密鑰，密鑰本身也不提供鏈路進行驗證或證書撤銷列表。

您有幾種選擇 - 你可以

關閉證書驗證上客戶端（不好動，人在中間人攻擊比比皆是）
使用makecert創建根CA和創建證書（ok 移動，但仍然沒有CRL）
創建一個內部根CA使用 Windows證書服務器或其他 PKI解決方案，然後信任的根證書（有點痛的管理）
購買從受信任的CA（昂貴的）

來源

2009-11-16 15:40:57 blowdart

關於（4），[StartSSL]（http://www.startssl.com/）實際上會給你一個免費的適用於所有主流瀏覽器的Class 1證書。他們爲我的六個低帶寬站點工作非常好。 – moodboom 2013-05-21 16:33:00

我認爲＃2在這個列表中...這個網址可能有所幫助：https：//blogs.technet.microsoft.com/jhoward/2005/02/02/how-to-use-makecert-for-trusted-root-證書頒發機構和證書頒發機構和註釋34025「如何使用MakeCert進行信任的根證書頒發機構和SSL證書頒發」 – granadaCoder 2016-10-21 13:19:54

注意：StartCom不再可信 - 剛剛從Chrome中刪除https： //en.wikipedia.org/wiki/StartCom – 2017-05-06 05:04:05

-6

之一 SSL證書

添加到您的客戶端代碼：

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

來源

2011-04-14 12:33:31 user662285

客戶端代碼應該在哪裏添加？ – 2014-06-12 06:18:39

這個答案不是很好，因爲它沒有解釋與代碼相關的風險。 – daveD 2015-02-09 15:32:57

我遇到同樣的問題，我可以有兩個解決方案來解決這個問題： ˚F首先，我使用MMC管理單元「證書」作爲「計算機帳戶」，並將自簽名證書拖入「受信任的根證書頒發機構」文件夾。這意味着本地計算機（生成證書的計算機）現在將信任該證書。其次，我注意到證書是爲某些內部計算機名稱生成的，但該Web服務正在使用另一個名稱進行訪問。這在驗證證書時導致不匹配。我們爲computer.operations.local生成了證書，但使用https://computer.internaldomain.companydomain.com訪問了Web服務。當我們將URL切換到用於生成證書的URL時，我們沒有更多的錯誤。

也許只是切換網址會起作用，但通過使證書信任，您還可以避免Internet Explorer中的紅色屏幕，它告訴您它不信任證書。

來源

2011-05-24 09:58:27

我與自簽名證書有類似的問題。我可以通過使用與服務器的FQDN相同的證書名稱來解決此問題。

理想情況下，SSL部分應該在服務器端進行管理。客戶端不需要爲SSL安裝任何證書。此外，一些帖子提到繞過客戶端代碼的SSL。但我完全不同意這一點。

來源

2011-06-17 18:15:51

前兩個使用拉姆達，第三個使用常規代碼...希望你覺得它有用

  //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; 
    }

來源

2011-07-07 16:03:38

//信任所有證書 System.Net.ServicePointManager.ServerCertificateValidationCallback + =（se，cert，chain，sslerror）=> { return true; }; //信任寄件人 System.Net.ServicePointManager.ServerCertificateValidationCallback + =（SE，證書，鏈條，sslerror）=> { 返回cert.Subject.Contains（「CA-1- 9wfvrm1.ceridian。「）; }; – VoodooChild 2013-05-07 16:45:36

任何破解者都可以僞造證書，通過上述所有測試，這是不安全的 – 2018-02-01 11:53:06

當我有這個問題，是因爲client.config有它的終點，如：

https://myserver/myservice.svc

但證書期待

https://myserver.mydomain.com/myservice.svc

更改端點匹配服務器的FQDN解決了我的問題。我知道這不是造成這個問題的唯一原因。

來源

2012-02-08 20:48:44

我剛剛遇到了這個問題，這一次只好使用了錯誤的證書。 – 2012-10-31 20:05:11

我的自動生成配置有 knightscharge 2013-07-16 14:49:11

我只是將證書拖放到「受信任的根證書頒發機構」文件夾中，並認爲一切正常。

哦。我第一次添加從管理員命令提示符下：

netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET\INTERAKTIV

我不知道你需要的用戶名（我的是挪威，你可以看到！）： user=NT-AUTHORITY/INTERACTIVE？

您可以通過發出命令查看所有現有urlacl的：netsh http show urlacl

來源

2012-08-26 23:21:35 Haguna

此嘗試通過連接到WCF服務時發生。 IP例如IP https://111.11.111.1:port/MyService.svc，同時使用與名稱綁定的證書，例如mysite.com。

切換到https://mysite.com:port/MyService.svc解決了它。

來源

2013-05-08 10:35:33 lko

請做以下步驟：在IE

開放服務的鏈接。
點擊地址欄中提到的證書錯誤，然後點擊查看證書。
支票發給：姓名。
取出發出的名稱並將服務和客戶端端點基地址名稱中的localhost提及替換爲完全限定的域名（FQDN）。

例如：https：//開頭本地主機：203/SampleService.svc 到https：// INL-126166-.groupinfra.com：203/SampleService.svc

來源

2014-07-15 17:49:58

非常好，謝謝你的回答！解決了這個問題，但沒有做任何代碼修改。 – 2018-01-18 11:52:10

我有同樣的問題。我也在本地商店中添加了CA證書，但是我採用了錯誤的方式。

使用MMC控制檯（開始 - >運行 - >MMC）你應該添加證書管理單元作爲服務帳戶（選擇IIS的服務帳戶）或計算機帳戶（它增加了對每個帳戶的機器上）

這裏什麼我談論 Add snap-in for a service account or the computer account

從這裏現在的圖像，你可以添加的CA證書（受信任根CA和中間CA）和e什麼東西都可以正常工作

來源

2015-05-26 10:42:57 dar0x

當只使用主機名連接到WCF服務時發生這種情況，例如， https://host/MyService.svc，同時使用與名稱綁定的證書，例如host.mysite.com。

切換到https://host.mysite.com/MyService.svc，這解決了它。

來源

2015-10-06 05:34:54 sonia

單線解決方案。調用服務器上的客戶端之前添加這在任何地方：

System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };

這應該只用於測試目的，因爲客戶端將跳過SSL/TLS安全檢查。

來源

2016-05-30 16:41:43 Gaspa79

這對我有用 – JimiOr2 2017-03-02 06:54:17

測試的一個很好的解決方法我們正在使用一個服務，帶着一系列複雜的安全證書，直到我們可以得到他們不可靠的證書和鏈接才能正常工作karound是唯一讓我們繼續發展的東西。 – markaaronky 2017-10-03 21:37:20

除了上面的答案之外，如果客戶端運行錯誤的TLS版本，例如服務器只運行TLS 1.2，則可能會遇到此錯誤。

您可以通過使用修復：

  ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; //tested in .NET 4.5

來源

2017-05-25 01:28:19 Jtrx

就固定了類似的問題。

我意識到我有一個應用程序池正在一個帳戶下運行，該帳戶只有對使用該證書的讀取權限。

.NET應用程序可以正確地檢索證書，但僅當調用GetRequestStream（）時拋出該異常。

證書權限可經由被管理MMC console

的[無法建立SSL/TLS安全通道的信任關係 - SOAP]

來源

2017-09-16 05:50:03 Alberto

如何解決「無法建立與權威的SSL/TLS安全通道的信任關係」

回答

相關問題