Yêu cầu đã bị hủy bỏ: Không thể tạo kênh bảo mật SSL / TLS

Chúng tôi không thể kết nối với máy chủ HTTPS WebRequestvì thông báo lỗi này:

The request was aborted: Could not create SSL/TLS secure channel.

Chúng tôi biết rằng máy chủ không có chứng chỉ HTTPS hợp lệ với đường dẫn được sử dụng, nhưng để bỏ qua vấn đề này, chúng tôi sử dụng mã sau đây mà chúng tôi đã lấy từ một bài đăng StackOverflow khác:

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

Vấn đề là máy chủ không bao giờ xác nhận chứng chỉ và không thành công với lỗi trên. Có ai có bất cứ ý tưởng về những gì tôi nên làm?

Tôi nên đề cập rằng một đồng nghiệp và tôi đã thực hiện các bài kiểm tra vài tuần trước và nó đã hoạt động tốt với một cái gì đó tương tự như những gì tôi đã viết ở trên. "Sự khác biệt lớn" duy nhất chúng tôi tìm thấy là tôi đang sử dụng Windows 7 và anh ấy đang sử dụng Windows XP. Điều đó có thay đổi gì không?

Cuối cùng tôi đã tìm thấy câu trả lời (tôi không lưu ý nguồn của mình nhưng đó là từ một tìm kiếm);

Mặc dù mã hoạt động trong Windows XP, trong Windows 7, bạn phải thêm mã này vào đầu:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

Và bây giờ, nó hoạt động hoàn hảo.

ĐỊA CHỈ

Như Robin Pháp đã đề cập; nếu bạn gặp phải vấn đề này trong khi định cấu hình PayPal, xin lưu ý rằng họ sẽ không hỗ trợ SSL3 bắt đầu từ tháng 12, 3 năm 2018. Bạn sẽ cần sử dụng TLS. Đây là trang Paypal về nó.

Giải pháp cho vấn đề này, trong .NET 4.5 là

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Nếu bạn không có .NET 4.5 thì hãy sử dụng

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Hãy chắc chắn rằng các cài đặt ServicePointManager được thực hiện trước khi tạo httpWebRequest, nếu không nó sẽ không hoạt động.

Làm:

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Thất bại:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

Vấn đề bạn gặp phải là người dùng aspNet không có quyền truy cập vào chứng chỉ. Bạn phải cấp quyền truy cập bằng winhttpcertcfg.exe

Một ví dụ về cách thiết lập tính năng này là tại: http://support.microsoft.com/kb/901183

Dưới bước 2 để biết thêm thông tin

EDIT: Trong các phiên bản gần đây hơn của IIS, tính năng này được tích hợp trong công cụ quản lý chứng chỉ - và có thể được truy cập bằng cách nhấp chuột phải vào chứng chỉ và sử dụng tùy chọn để quản lý khóa riêng. Thêm chi tiết tại đây: /server/131046/how-to-grant-iis-7-5-access-to-a-cert ve-in-certer-store / 132791 # 130321

Lỗi là chung chung và có nhiều lý do tại sao đàm phán SSL / TLS có thể thất bại. Phổ biến nhất là chứng chỉ máy chủ không hợp lệ hoặc hết hạn và bạn đã xử lý vấn đề đó bằng cách cung cấp móc xác thực chứng chỉ máy chủ của riêng bạn, nhưng không nhất thiết là lý do duy nhất. Máy chủ có thể yêu cầu xác thực lẫn nhau, nó có thể được cấu hình với một bộ mật mã không được khách hàng của bạn hỗ trợ, nó có thể có thời gian trôi quá lớn để bắt tay thành công và nhiều lý do khác.

Giải pháp tốt nhất là sử dụng bộ công cụ xử lý sự cố SChannel. SChannel là nhà cung cấp SSPI chịu trách nhiệm về SSL và TLS và khách hàng của bạn sẽ sử dụng nó để bắt tay. Hãy xem Công cụ và Cài đặt TLS / SSL .

Xem thêm Cách bật ghi nhật ký sự kiện Schannel .

Tôi gặp vấn đề này khi cố gắng truy cập https://ct.mob0.com/Styles/Fun.png , đây là hình ảnh được phân phối bởi CloudFlare trên CDN của nó, hỗ trợ các nội dung điên rồ như SPDY và ​​các chuyển hướng SSL kỳ lạ.

Thay vì chỉ định Ssl3 như trong câu trả lời của Simons, tôi đã có thể sửa nó bằng cách đi xuống Tls12 như thế này:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

Sau nhiều giờ với vấn đề tương tự, tôi thấy rằng tài khoản ASP.NET mà dịch vụ khách hàng đang chạy không có quyền truy cập vào chứng chỉ. Tôi đã sửa nó bằng cách vào Nhóm ứng dụng IIS mà ứng dụng web chạy bên dưới, đi vào Cài đặt nâng cao và thay đổi danh tính thành LocalSystemtài khoản từ đó NetworkService.

Một giải pháp tốt hơn là để chứng chỉ làm việc với NetworkServicetài khoản mặc định nhưng điều này hoạt động để kiểm tra chức năng nhanh chóng.

Cách tiếp cận với thiết lập

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Có vẻ ổn, vì Tls1.2 là phiên bản mới nhất của giao thức bảo mật. Nhưng tôi quyết định nhìn sâu hơn và trả lời chúng ta có thực sự cần mã hóa nó không.

Thông số kỹ thuật: Windows Server 2012R2 x64.

Từ internet, người ta nói rằng .NetFramework 4.6+ phải sử dụng Tls1.2 theo mặc định. Nhưng khi tôi cập nhật dự án của mình lên 4.6 thì không có gì xảy ra. Tôi đã tìm thấy một số thông tin cho biết tôi cần thủ công thực hiện một số thay đổi để bật Tls1.2 theo mặc định

https://support.microsoft.com/en-in/help3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-prot nỗi

Nhưng bản cập nhật windows được đề xuất không hoạt động cho phiên bản R2

Nhưng điều giúp tôi là thêm 2 giá trị vào registry. Bạn có thể sử dụng tập lệnh PS tiếp theo để chúng sẽ được thêm tự động

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Đó là loại những gì tôi đang tìm kiếm. Nhưng tôi vẫn không thể trả lời câu hỏi tại sao NetFramework 4.6+ không tự động đặt ... Giá trị giao thức này?

Một cái gì đó mà câu trả lời ban đầu không có. Tôi đã thêm một số mã để làm cho nó bằng chứng đạn.

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Một khả năng khác là nhập chứng chỉ không đúng trên hộp. Hãy chắc chắn để chọn hộp kiểm bao quanh. Ban đầu tôi không làm điều đó, vì vậy mã đã hết thời gian hoặc ném ngoại lệ giống như khóa riêng không thể định vị được.

Có thể xảy ra ngoại lệ "Yêu cầu đã bị hủy: Không thể tạo kênh bảo mật SSL / TLS" nếu máy chủ trả về phản hồi trái phép HTTP 401 cho yêu cầu HTTP.

Bạn có thể xác định xem điều này có xảy ra hay không bằng cách bật ghi nhật ký System.Net cấp theo dõi cho ứng dụng khách của bạn, như được mô tả trong câu trả lời này .

Khi cấu hình ghi nhật ký được đặt đúng chỗ, hãy chạy ứng dụng và tạo lại lỗi, sau đó tìm trong đầu ra ghi nhật ký cho một dòng như thế này:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

Trong tình huống của tôi, tôi đã thất bại trong việc đặt một cookie cụ thể mà máy chủ đang mong đợi, dẫn đến máy chủ phản hồi yêu cầu với lỗi 401, từ đó dẫn đến ngoại lệ "Không thể tạo kênh bảo mật SSL / TLS".

Một nguyên nhân có thể khác của The request was aborted: Could not create SSL/TLS secure channellỗi là sự không khớp giữa các giá trị cext_suites được cấu hình của PC khách của bạn và các giá trị mà máy chủ được định cấu hình là sẵn sàng và có thể chấp nhận . Trong trường hợp này, khi khách hàng của bạn gửi danh sách các giá trị của cext_suites mà nó có thể chấp nhận trong thông báo bắt tay / thương lượng SSL ban đầu, máy chủ thấy rằng không có giá trị nào được cung cấp có thể chấp nhận được và có thể trả về "Thông báo "phản hồi thay vì tiến hành bước" Server Hello "của bắt tay SSL.

Để điều tra khả năng này, bạn có thể tải xuống Microsoft Message Analyzer và sử dụng nó để chạy theo dõi thương lượng SSL xảy ra khi bạn cố gắng và không thiết lập kết nối HTTPS với máy chủ (trong ứng dụng C # của bạn).

Nếu bạn có thể tạo kết nối HTTPS thành công từ môi trường khác (ví dụ: máy Windows XP mà bạn đã đề cập - hoặc có thể bằng cách nhấn URL HTTPS trong trình duyệt không phải của Microsoft không sử dụng cài đặt bộ mật mã của HĐH, chẳng hạn như Chrome hoặc Firefox), chạy một dấu vết Trình phân tích thư khác trong môi trường đó để nắm bắt những gì xảy ra khi đàm phán SSL thành công.

Hy vọng, bạn sẽ thấy một số khác biệt giữa hai thông báo Hello Client sẽ cho phép bạn xác định chính xác điều gì về việc đàm phán SSL thất bại đang khiến nó thất bại. Sau đó, bạn sẽ có thể thực hiện các thay đổi cấu hình cho Windows sẽ cho phép nó thành công. IISCrypto là một công cụ tuyệt vời để sử dụng cho việc này (ngay cả đối với các PC khách, mặc dù tên "IIS").

Hai khóa đăng ký Windows sau đây chi phối các giá trị của cext_suites mà PC của bạn sẽ sử dụng:

• HKLM \ PHẦN MỀM \ Chính sách \ Microsoft \ Mật mã \ Cấu hình \ SSL \ 00010002
• HKLM \ HỆ THỐNG \ CurrentControlset \ Control \ Cryptography \ Cấu hình \ Local \ SSL \ 00010002

Dưới đây là một bài viết đầy đủ về cách tôi đã điều tra và giải quyết một trường hợp của Could not create SSL/TLS secure channelvấn đề này: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

Nguồn gốc của ngoại lệ này trong trường hợp của tôi là tại một số điểm trong đoạn mã sau đây đã được gọi:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Điều này thật sự tệ. Nó không chỉ hướng dẫn .NET sử dụng giao thức không an toàn, mà điều này còn tác động đến mọi yêu cầu WebClient (và tương tự) mới được thực hiện sau đó trong miền appd của bạn. (Lưu ý rằng các yêu cầu web đến không bị ảnh hưởng trong ứng dụng ASP.NET của bạn, nhưng các yêu cầu WebClient mới, chẳng hạn như để nói chuyện với một dịch vụ web bên ngoài,).

Trong trường hợp của tôi, nó không thực sự cần thiết, vì vậy tôi chỉ có thể xóa câu lệnh và tất cả các yêu cầu web khác của tôi bắt đầu hoạt động tốt trở lại. Dựa trên việc đọc ở nơi khác, tôi đã học được một vài điều:

• Đây là cài đặt toàn cầu trong tên miền ứng dụng của bạn và nếu bạn có hoạt động đồng thời, bạn không thể đặt nó thành một giá trị, thực hiện hành động của mình và sau đó đặt lại. Một hành động khác có thể diễn ra trong cửa sổ nhỏ đó và bị ảnh hưởng.
• Cài đặt chính xác là để mặc định. Điều này cho phép .NET tiếp tục sử dụng bất cứ giá trị mặc định an toàn nhất nào khi thời gian trôi qua và bạn nâng cấp các khung công tác. Đặt nó thành TLS12 (bảo mật nhất cho văn bản này) sẽ hoạt động ngay bây giờ nhưng sau 5 năm có thể bắt đầu gây ra sự cố bí ẩn.
• Nếu bạn thực sự cần thiết lập một giá trị, bạn nên xem xét thực hiện nó trong một ứng dụng chuyên dụng hoặc tên miền riêng biệt và tìm cách nói chuyện giữa nó và nhóm chính của bạn. Bởi vì đó là một giá trị toàn cầu duy nhất, cố gắng quản lý nó trong nhóm ứng dụng bận rộn sẽ chỉ dẫn đến rắc rối. Câu trả lời này: https://stackoverflow.com/a/26754917/7656 cung cấp một giải pháp khả thi bằng proxy tùy chỉnh. (Lưu ý tôi chưa đích thân thực hiện nó.)

Tôi gặp vấn đề này vì web.config của tôi có:

<httpRuntime targetFramework="4.5.2" />

và không:

<httpRuntime targetFramework="4.6.1" />

Như bạn có thể nói có rất nhiều lý do điều này có thể xảy ra. Nghĩ rằng tôi sẽ thêm nguyên nhân tôi gặp phải ...

Nếu bạn đặt giá trị WebRequest.Timeoutthành 0, đây là ngoại lệ được ném. Dưới đây là mã tôi đã có ... (Ngoại trừ thay vì mã hóa cứng 0cho giá trị thời gian chờ, tôi có một tham số vô tình được đặt thành 0).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Các câu trả lời hàng đầu bình chọn có lẽ sẽ đủ cho hầu hết mọi người. Tuy nhiên, trong một số trường hợp, bạn có thể tiếp tục gặp lỗi "Không thể tạo kênh bảo mật SSL / TLS" ngay cả sau khi buộc TLS 1.2. Nếu vậy, bạn có thể muốn tham khảo bài viết hữu ích nàyđể biết thêm các bước khắc phục sự cố. Để tóm tắt: độc lập với vấn đề phiên bản TLS / SSL, máy khách và máy chủ phải đồng ý về "bộ mật mã". Trong giai đoạn "bắt tay" của kết nối SSL, khách hàng sẽ liệt kê các bộ mật mã được hỗ trợ cho máy chủ để kiểm tra danh sách của chính nó. Nhưng trên một số máy Windows, một số bộ mật mã thông thường có thể đã bị vô hiệu hóa (dường như do các nỗ lực có chủ đích nhằm hạn chế bề mặt tấn công), làm giảm khả năng máy khách và máy chủ đồng ý trên bộ mật mã. Nếu họ không thể đồng ý, thì bạn có thể thấy "mã cảnh báo gây tử vong 40" trong trình xem sự kiện và "Không thể tạo kênh bảo mật SSL / TLS" trong chương trình .NET của bạn.

Bài viết nói trên giải thích cách liệt kê tất cả các bộ mật mã có khả năng được hỗ trợ của máy và cho phép các bộ mật mã bổ sung thông qua Windows Registry. Để giúp kiểm tra bộ mật mã nào được bật trên máy khách, hãy thử truy cập trang chẩn đoán này trong MSIE. (Sử dụng theo dõi System.Net có thể cho kết quả rõ ràng hơn.) Để kiểm tra bộ mật mã nào được máy chủ hỗ trợ, hãy thử công cụ trực tuyến này (giả sử rằng máy chủ có thể truy cập Internet). Nó nên đi mà không nói rằng chỉnh sửa Registry phải được thực hiện một cách thận trọng , đặc biệt là khi có liên quan đến mạng. (Máy của bạn có phải là máy ảo được lưu trữ từ xa không? Nếu bạn bị ngắt mạng, VM có thể truy cập được không?)

Trong trường hợp của công ty tôi, chúng tôi đã kích hoạt một số bộ "ECDHE_ECDSA" bổ sung thông qua chỉnh sửa Registry, để khắc phục sự cố ngay lập tức và bảo vệ chống lại các sự cố trong tương lai. Nhưng nếu bạn không thể (hoặc sẽ không) chỉnh sửa Registry, thì rất nhiều cách giải quyết (không nhất thiết phải đẹp) xuất hiện trong tâm trí. Ví dụ: chương trình .NET của bạn có thể ủy quyền lưu lượng SSL của nó cho một chương trình Python riêng (có thể chính nó hoạt động, vì lý do tương tự rằng các yêu cầu Chrome có thể thành công khi yêu cầu MSIE không thành công trên máy bị ảnh hưởng).

Một trong những nguyên nhân lớn nhất của vấn đề này là phiên bản .NET Framework hoạt động. Phiên bản thời gian chạy .NET framework ảnh hưởng đến các giao thức bảo mật được bật theo mặc định.

Dường như không có bất kỳ tài liệu có thẩm quyền nào về cách thức hoạt động cụ thể trong các phiên bản khác nhau, nhưng có vẻ như các mặc định được xác định ít nhiều như sau:

• .NET Framework 4.5 trở về trước - SSL 3.0, TLS 1.0
• .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
• .NET Framework 4.7+ - Mặc định hệ thống (HĐH)

(Đối với các phiên bản cũ hơn, số dặm của bạn có thể thay đổi phần nào dựa trên thời gian chạy .NET được cài đặt trên hệ thống. Ví dụ: có thể bạn đang sử dụng khung rất cũ và TLS 1.0 không được hỗ trợ hoặc sử dụng 4.6. x và TLS 1.3 không được hỗ trợ)

Tài liệu của Microsoft khuyên bạn nên sử dụng 4.7+ và hệ thống mặc định:

Chúng tôi khuyên bạn:

• Target .NET Framework 4.7 hoặc phiên bản mới hơn trên ứng dụng của bạn. Target .NET Framework 4.7.1 trở lên trên các ứng dụng WCF của bạn.
• Không chỉ định phiên bản TLS. Định cấu hình mã của bạn để cho HĐH quyết định phiên bản TLS.
• Thực hiện kiểm tra mã kỹ lưỡng để xác minh rằng bạn không chỉ định phiên bản TLS hoặc SSL.

Đối với các trang web ASP.NET , hãy kiểm tra phiên bản .NET framework trong <httpRuntime>phần tử của bạn , vì điều này xác định thời gian chạy nào thực sự được sử dụng bởi trang web của bạn:

<httpRuntime targetFramework="4.5" />

Tốt hơn:

<httpRuntime targetFramework="4.7" />

Cái này hoạt động với tôi trong MVC webclient

    public string DownloadSite(string RefinedLink)
    {
        try
        {
            Uri address = new Uri(RefinedLink);

            ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

            System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

            using (WebClient webClient = new WebClient())
            {
                var stream = webClient.OpenRead(address);
                using (StreamReader sr = new StreamReader(stream))
                {
                    var page = sr.ReadToEnd();

                    return page;
                }
            }

        }
        catch (Exception e)
        {
            log.Error("DownloadSite - error Lin = " + RefinedLink, e);
            return null;
        }
    }

Trong trường hợp máy khách là máy windows, một lý do có thể là giao thức tls hoặc ssl được yêu cầu bởi dịch vụ không được kích hoạt.

Điều này có thể được đặt trong:

Bảng điều khiển -> Mạng và Internet -> Tùy chọn Internet -> Nâng cao

Cuộn cài đặt xuống "Bảo mật" và chọn giữa

• Sử dụng SSL 2.0
• Sử dụng SSL 3.0
• Sử dụng TLS 1.0
• Sử dụng TLS 1.1
• Sử dụng TLS 1.2

Trong trường hợp của tôi, tài khoản dịch vụ chạy ứng dụng không có quyền truy cập khóa riêng. Khi tôi cho phép, lỗi đã biến mất

1. mmc
2. chứng chỉ
3. Mở rộng sang cá nhân
4. chọn chứng chỉ
5. nhấp chuột phải
6. Tất cả các nhiệm vụ
7. Quản lý khóa riêng
8. Thêm vào

Nếu bạn đang chạy mã của mình từ Visual Studio, hãy thử chạy Visual Studio với tư cách quản trị viên. Đã khắc phục sự cố cho tôi.

Tôi đã đấu tranh với vấn đề này cả ngày.

Khi tôi tạo một dự án mới với .NET 4.5, cuối cùng tôi cũng đã làm được.

Nhưng nếu tôi hạ cấp xuống 4.0, tôi lại gặp vấn đề tương tự và điều đó không thể khắc phục được cho dự án đó (ngay cả khi tôi cố gắng nâng cấp lên 4.5 một lần nữa).

Lạ không có thông báo lỗi nào khác nhưng "Yêu cầu đã bị hủy: Không thể tạo kênh bảo mật SSL / TLS." đã đưa ra lỗi này

System.Net.WebException: Yêu cầu đã bị hủy bỏ: Không thể tạo kênh bảo mật SSL / TLS.

Trong trường hợp của chúng tôi, chúng tôi sử dụng một nhà cung cấp phần mềm để chúng tôi không có quyền truy cập để sửa đổi mã .NET. Rõ ràng .NET 4 sẽ không sử dụng TLS v 1.2 trừ khi có thay đổi.

Cách khắc phục cho chúng tôi là thêm khóa SchUseStrongCrypto vào sổ đăng ký. Bạn có thể sao chép / dán mã dưới đây vào một tệp văn bản với phần mở rộng .reg và thực thi nó. Nó phục vụ như là "bản vá" của chúng tôi cho vấn đề.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Thử cái này:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Điều này cố định cho tôi, thêm Dịch vụ mạng để cấp phép. Nhấp chuột phải vào chứng chỉ> Tất cả tác vụ> Quản lý khóa riêng ...> Thêm ...> Thêm "Dịch vụ mạng".

Vấn đề đối với tôi là tôi đã cố gắng triển khai trên IIS như một dịch vụ web, tôi đã cài đặt chứng chỉ trên máy chủ, nhưng người dùng chạy IIS không có quyền chính xác trên chứng chỉ.

Làm cách nào để cấp quyền truy cập ASP.NET vào khóa riêng trong chứng chỉ trong kho chứng chỉ?

Tôi đã có vấn đề tương tự và thấy câu trả lời này hoạt động đúng với tôi. Khóa là 3072. Liên kết này cung cấp các chi tiết về bản sửa lỗi '3072'.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

Trong trường hợp của tôi, hai nguồn cấp dữ liệu yêu cầu sửa chữa:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

Câu hỏi này có thể có nhiều câu trả lời vì đó là về một thông báo lỗi chung. Chúng tôi gặp vấn đề này trên một số máy chủ của chúng tôi, nhưng không phải máy phát triển của chúng tôi. Sau khi nhổ hết tóc, chúng tôi thấy đó là lỗi của Microsoft.

https://support.microsoft.com/en-us/help/4458166/appluggest-that-rely-on-tls-1-2-strong-encoding-experience-connect

Về cơ bản, MS giả định rằng bạn muốn mã hóa yếu hơn, nhưng HĐH được vá để chỉ cho phép TLS 1.2, do đó bạn nhận được thông báo "Yêu cầu đã bị hủy bỏ: Không thể tạo kênh bảo mật SSL / TLS."

Có ba bản sửa lỗi.

1) Vá hệ điều hành với bản cập nhật phù hợp: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Thêm cài đặt vào tệp app.config / web.config.

3) Thêm cài đặt đăng ký đã được đề cập trong câu trả lời khác.

Tất cả những điều này được đề cập trong bài viết cơ sở kiến ​​thức tôi đã đăng.

Một khả năng khác là mã được thực thi không có các yêu cầu bắt buộc.

Trong trường hợp của tôi, tôi đã gặp lỗi này khi sử dụng trình gỡ lỗi Visual Studio để kiểm tra cuộc gọi đến dịch vụ web. Visual Studio không hoạt động với tư cách Quản trị viên, điều này gây ra ngoại lệ này.

Điều này đã xảy ra với tôi trên chỉ một trang web, và hóa ra nó chỉ có sẵn mật mã RC4. Trong một nỗ lực trước đây để làm cứng máy chủ, tôi đã vô hiệu hóa mật mã RC4, một khi tôi kích hoạt lại thì vấn đề này đã được giải quyết.