ยกเลิกคำขอ: ไม่สามารถสร้างช่องทางที่ปลอดภัยของ SSL / TLS

เราไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ HTTPS ที่ใช้WebRequestเนื่องจากข้อความแสดงข้อผิดพลาดนี้:

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

เรารู้ว่าเซิร์ฟเวอร์ไม่มีใบรับรอง HTTPS ที่ถูกต้องตามเส้นทางที่ใช้ แต่เพื่อหลีกเลี่ยงปัญหานี้เราใช้รหัสต่อไปนี้ที่เรานำมาจากโพสต์ StackOverflow อื่น:

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

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

ปัญหาคือว่าเซิร์ฟเวอร์ไม่เคยตรวจสอบใบรับรองและล้มเหลวด้วยข้อผิดพลาดข้างต้น ใครบ้างมีความคิดเกี่ยวกับสิ่งที่ฉันควรทำอย่างไร

ฉันควรพูดถึงเพื่อนร่วมงานและฉันทำการทดสอบเมื่อไม่กี่สัปดาห์ที่ผ่านมาและมันก็ใช้ได้ดีกับสิ่งที่คล้ายกับที่ฉันเขียนไว้ด้านบน "ความแตกต่างที่สำคัญ" อย่างเดียวที่เราพบคือฉันใช้ Windows 7 และเขาใช้ Windows XP สิ่งนั้นเปลี่ยนไปหรือไม่?

ในที่สุดฉันก็พบคำตอบ (ฉันไม่ได้สังเกตที่มาของฉัน แต่มาจากการค้นหา);

ในขณะที่รหัสทำงานใน Windows XP ใน Windows 7 คุณต้องเพิ่มรหัสนี้ในตอนต้น:

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

และตอนนี้มันทำงานได้อย่างสมบูรณ์แบบ

ภาคผนวก

ตามที่กล่าวไว้โดย Robin French; หากคุณได้รับปัญหานี้ในขณะที่กำหนดค่า PayPal โปรดทราบว่าพวกเขาจะไม่สนับสนุน SSL3 ตั้งแต่เดือนธันวาคมปี 2018 เป็นต้นไปคุณจะต้องใช้ TLS นี่คือหน้า Paypalเกี่ยวกับมัน

วิธีแก้ปัญหานี้ใน. NET 4.5 คือ

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

หากคุณไม่มี. NET 4.5 ให้ใช้

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

ตรวจสอบให้แน่ใจว่าการตั้งค่า ServicePointManager ถูกสร้างขึ้นก่อนที่จะสร้าง HttpWebRequest มิฉะนั้นจะไม่สามารถใช้งานได้

ผลงาน:

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

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

ล้มเหลว:

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

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

ปัญหาที่คุณมีคือผู้ใช้ aspNet ไม่มีสิทธิ์เข้าถึงใบรับรอง คุณต้องให้สิทธิ์การเข้าถึงโดยใช้ winhttpcertcfg.exe

ตัวอย่างเกี่ยวกับวิธีตั้งค่านี้อยู่ที่: http://support.microsoft.com/kb/901183

ภายใต้ขั้นตอนที่ 2 ในข้อมูลเพิ่มเติม

แก้ไข: ใน IIS รุ่นล่าสุดคุณสมบัตินี้มีอยู่ในเครื่องมือจัดการใบรับรอง - และสามารถเข้าถึงได้โดยคลิกขวาที่ใบรับรองและใช้ตัวเลือกสำหรับการจัดการคีย์ส่วนตัว รายละเอียดเพิ่มเติมได้ที่นี่: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

ข้อผิดพลาดเป็นเรื่องทั่วไปและมีหลายสาเหตุที่การเจรจา SSL / TLS อาจล้มเหลว สิ่งที่พบบ่อยที่สุดคือใบรับรองเซิร์ฟเวอร์ที่ไม่ถูกต้องหรือหมดอายุและคุณดูแลด้วยการมอบเบ็ดตรวจสอบใบรับรองเซิร์ฟเวอร์ของคุณเอง แต่ไม่จำเป็นต้องเป็นเหตุผลเดียวเท่านั้น เซิร์ฟเวอร์อาจต้องการการรับรองความถูกต้องซึ่งอาจกำหนดค่าด้วยชุดของ ciphers ที่ลูกค้าของคุณไม่สนับสนุนอาจมีเวลาที่ใหญ่เกินไปสำหรับการจับมือที่จะประสบความสำเร็จและเหตุผลอื่น ๆ อีกมากมาย

ทางออกที่ดีที่สุดคือการใช้ชุดเครื่องมือแก้ไขปัญหา SChannel SChannel เป็นผู้ให้บริการ SSPI ที่รับผิดชอบ SSL และ TLS และลูกค้าของคุณจะใช้มันสำหรับการจับมือกัน ลองดูที่TLS / เครื่องมือ SSL และการตั้งค่า

ยังเห็นวิธีการเปิดใช้การบันทึกเหตุการณ์ Schannel

ฉันมีปัญหานี้พยายามที่จะตีhttps://ct.mob0.com/Styles/Fun.pngซึ่งเป็นภาพที่จัดทำโดย CloudFlare บนมันเป็น CDN ที่รองรับสิ่งที่บ้าคลั่งอย่าง SPDY และ SSL SSL เปลี่ยนเส้นทางที่แปลก

แทนที่จะระบุ Ssl3 เช่นเดียวกับในคำตอบของ Simons ฉันสามารถแก้ไขได้โดยไปที่ Tls12 เช่นนี้:

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

หลังจากผ่านไปหลายชั่วโมงด้วยปัญหาเดียวกันนี้ฉันพบว่าบัญชี ASP.NET ที่บริการไคลเอ็นต์กำลังทำงานอยู่ไม่มีสิทธิ์เข้าถึงใบรับรอง ฉันคงได้โดยไปลงในแอพลิเคชันที่ IIS เว็บแอปทำงานภายใต้จะเข้าสู่การตั้งค่าขั้นสูงและการเปลี่ยนแปลงรหัสประจำตัวไปจากบัญชีLocalSystemNetworkService

ทางออกที่ดีกว่าคือการทำให้ใบรับรองทำงานกับNetworkServiceบัญชีเริ่มต้นแต่ใช้งานได้สำหรับการทดสอบการทำงานที่รวดเร็ว

วิธีการที่มีการตั้งค่า

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

ดูเหมือนว่าจะใช้ได้เนื่องจาก Tls1.2 เป็นโปรโตคอลที่ปลอดภัยรุ่นล่าสุด แต่ฉันตัดสินใจที่จะมองลึกลงไปและตอบเราจำเป็นต้อง hardcode มันจริงๆ

รายละเอียด: Windows Server 2012R2 x64

จากอินเทอร์เน็ตจะมีการบอกว่า. NetFramework 4.6+ จะต้องใช้ Tls1.2 เป็นค่าเริ่มต้น แต่เมื่อฉันอัปเดตโครงการเป็น 4.6 ไม่มีอะไรเกิดขึ้น ฉันพบข้อมูลบางอย่างที่บอกว่าฉันต้องทำการเปลี่ยนแปลงบางอย่างด้วยตนเองเพื่อเปิดใช้งาน Tls1.2 โดยค่าเริ่มต้น

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

แต่การอัพเดท windows ที่เสนอนั้นใช้ไม่ได้กับรุ่น R2

แต่สิ่งที่ช่วยฉันได้คือเพิ่มค่า 2 ค่าลงในรีจิสทรี คุณสามารถใช้สคริปต์ PS ถัดไปเพื่อเพิ่มสคริปต์เหล่านั้นโดยอัตโนมัติ

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

นั่นคือสิ่งที่ฉันกำลังมองหา แต่ฉันก็ยังตอบคำถามไม่ได้ว่าทำไม NetFramework 4.6+ ไม่ได้ตั้งค่า ... ค่าโปรโตคอลโดยอัตโนมัติ

สิ่งที่คำตอบเดิมไม่มี ฉันเพิ่มรหัสเพิ่มเติมบางส่วนเพื่อให้เป็นหลักฐานแสดงหัวข้อย่อย

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

ความเป็นไปได้อีกอย่างหนึ่งคือการนำเข้าใบรับรองที่ไม่เหมาะสมในกล่อง ตรวจสอบให้แน่ใจว่าได้เลือกกล่องกาเครื่องหมายล้อมรอบ ตอนแรกฉันไม่ได้ทำมันดังนั้นรหัสก็เลยหมดเวลาหรือโยนข้อยกเว้นเดียวกับคีย์ส่วนตัวไม่สามารถหาได้

ข้อยกเว้น "การร้องขอถูกยกเลิก: ไม่สามารถสร้างช่องทางที่ปลอดภัย SSL / TLS" สามารถเกิดขึ้นได้หากเซิร์ฟเวอร์ส่งคืนการตอบกลับHTTP 401 ที่ไม่ได้รับอนุญาตให้ร้องขอ HTTP

คุณสามารถตรวจสอบว่าสิ่งนี้เกิดขึ้นหรือไม่โดยการเปิดการบันทึกระดับ System.Net สำหรับแอปพลิเคชันไคลเอนต์ของคุณดังที่อธิบายไว้ในคำตอบนี้

เมื่อกำหนดค่าการบันทึกนั้นแล้วให้เรียกใช้แอปพลิเคชันและสร้างข้อผิดพลาดซ้ำอีกครั้งจากนั้นค้นหาผลลัพธ์การบันทึกสำหรับบรรทัดดังนี้:

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

ในสถานการณ์ของฉันฉันไม่สามารถตั้งค่าคุกกี้เฉพาะที่เซิร์ฟเวอร์คาดหวังนำไปสู่เซิร์ฟเวอร์ที่ตอบสนองต่อการร้องขอที่มีข้อผิดพลาด 401 ซึ่งนำไปสู่ข้อยกเว้น "ไม่สามารถสร้างช่องทางที่ปลอดภัย SSL / TLS"

อีกสาเหตุที่เป็นไปได้ของThe request was aborted: Could not create SSL/TLS secure channelข้อผิดพลาดคือไม่ตรงกันระหว่างค่า cipher_suites ที่ไคลเอ็นต์พีซีของคุณกำหนดไว้และค่าที่เซิร์ฟเวอร์กำหนดค่าว่าเต็มใจและยอมรับได้ได้ ในกรณีนี้เมื่อลูกค้าของคุณส่งรายการค่า cipher_suites ที่สามารถรับได้ในการเริ่มต้น / การเจรจาต่อรอง SSL "Hand Hello" ข้อความเริ่มต้นการจับมือ / การเจรจาต่อรองเซิร์ฟเวอร์เห็นว่าไม่มีค่าที่ยอมรับได้และอาจส่งคืน "การแจ้งเตือน" "การตอบสนองแทนการดำเนินการขั้นตอน" เซิร์ฟเวอร์ Hello "ของ handshake SSL

เพื่อตรวจสอบความเป็นไปได้นี้คุณสามารถดาวน์โหลดMicrosoft Message Analyzerและใช้เพื่อรันการติดตามการเจรจา SSL ที่เกิดขึ้นเมื่อคุณพยายามและล้มเหลวในการสร้างการเชื่อมต่อ HTTPS ไปยังเซิร์ฟเวอร์ (ในแอป C # ของคุณ)

หากคุณสามารถทำการเชื่อมต่อ HTTPS ที่ประสบความสำเร็จจากสภาพแวดล้อมอื่น (เช่นเครื่อง Windows XP ที่คุณกล่าวถึง - หรืออาจกด HTTPS URL ในเบราว์เซอร์ที่ไม่ใช่ของ Microsoft ที่ไม่ได้ใช้การตั้งค่าชุดรหัสของระบบปฏิบัติการเช่น Chrome หรือ Firefox) เรียกใช้การติดตามวิเคราะห์ข้อความอื่นในสภาพแวดล้อมนั้นเพื่อจับภาพสิ่งที่เกิดขึ้นเมื่อการเจรจา SSL สำเร็จ

หวังว่าคุณจะเห็นความแตกต่างระหว่างสองข้อความสวัสดีลูกค้าที่จะช่วยให้คุณระบุสิ่งที่เกี่ยวกับการเจรจา SSL ที่ล้มเหลวทำให้เกิดความล้มเหลว จากนั้นคุณควรจะสามารถทำการเปลี่ยนแปลงการกำหนดค่าให้กับ Windows ที่จะทำให้มันประสบความสำเร็จ IISCryptoเป็นเครื่องมือที่ยอดเยี่ยมสำหรับการใช้งานนี้ (แม้สำหรับเครื่องพีซีไคลเอนต์แม้จะมีชื่อ "IIS")

คีย์รีจิสทรีของ Windows สองตัวต่อไปนี้ควบคุมค่า cipher_suites ที่พีซีของคุณจะใช้:

• HKLM \ Software \ Policies \ Microsoft \ Cryptography \ Configuration \ SSL \ 00010002
• HKLM \ SYSTEM \ CurrentControlSet \ Control \ Cryptography \ Configuration \ Local \ SSL \ 00010002

นี่คือการเขียนแบบเต็มของวิธีที่ฉันตรวจสอบและแก้ไขอินสแตนซ์ของปัญหาที่หลากหลายCould not create SSL/TLS secure channel: http://blog.jonschneider.com 2016/08/fix-ssl-handshaking-error-in-windows.html

รากของข้อยกเว้นนี้ในกรณีของฉันคือในบางจุดในรหัสต่อไปนี้จะถูกเรียกว่า:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

นี่มันแย่จริงๆ ไม่เพียง แต่จะสั่งให้. NET ใช้โพรโทคอลที่ไม่ปลอดภัยเท่านั้น แต่สิ่งนี้จะส่งผลต่อคำขอ WebClient (และที่คล้ายกัน) ใหม่ทุกครั้งที่เกิดขึ้นภายใน appdomain ของคุณ (โปรดทราบว่าคำขอเว็บขาเข้าจะไม่ได้รับผลกระทบในแอป ASP.NET ของคุณ แต่มีคำขอ WebClient ใหม่เช่นเพื่อพูดคุยกับบริการเว็บภายนอก)

ในกรณีของฉันมันไม่จำเป็นจริง ๆ ดังนั้นฉันสามารถลบคำสั่งและคำขอเว็บอื่น ๆ ทั้งหมดของฉันเริ่มทำงานได้ดีอีกครั้ง จากการอ่านของฉันที่อื่นฉันได้เรียนรู้บางสิ่ง:

• นี่เป็นการตั้งค่าส่วนกลางใน appdomain ของคุณและหากคุณมีกิจกรรมที่เกิดขึ้นพร้อมกันคุณไม่สามารถตั้งค่าได้อย่างน่าเชื่อถือเป็นค่าเดียวทำการกระทำของคุณจากนั้นตั้งค่ากลับมา การกระทำอื่นอาจเกิดขึ้นระหว่างหน้าต่างเล็ก ๆ นั้นและได้รับผลกระทบ
• การตั้งค่าที่ถูกต้องคือปล่อยให้มันเป็นค่าเริ่มต้น สิ่งนี้ทำให้. NET สามารถใช้สิ่งที่เป็นค่าเริ่มต้นที่ปลอดภัยที่สุดต่อไปเมื่อเวลาผ่านไปและคุณอัพเกรดเฟรมเวิร์ก การตั้งค่าให้ TLS12 (ซึ่งเป็นที่ปลอดภัยที่สุดเช่นการเขียนนี้) จะทำงานในขณะนี้แต่ใน 5 ปีอาจจะเริ่มก่อให้เกิดปัญหาลึกลับ
• หากคุณจำเป็นต้องตั้งค่าจริง ๆ คุณควรพิจารณาดำเนินการในแอปพลิเคชันพิเศษหรือ appdomain แยกต่างหากและหาวิธีพูดคุยระหว่างมันกับพูลหลักของคุณ เนื่องจากเป็นค่าส่วนกลางเดียวการพยายามจัดการภายในพูลแอพที่ยุ่งจะทำให้เกิดปัญหา คำตอบนี้: https://stackoverflow.com/a/26754917/7656 มอบโซลูชันที่เป็นไปได้ผ่านทางพร็อกซีที่กำหนดเอง (หมายเหตุฉันยังไม่ได้นำไปใช้เป็นการส่วนตัว)

ฉันมีปัญหานี้เพราะ web.config ของฉันมี:

<httpRuntime targetFramework="4.5.2" />

และไม่:

<httpRuntime targetFramework="4.6.1" />

ในขณะที่คุณสามารถบอกได้ว่ามีสาเหตุมากมายที่อาจเกิดขึ้น คิดว่าฉันจะเพิ่มสาเหตุที่พบ ...

ถ้าคุณตั้งค่าของWebRequest.Timeoutไป0นี้เป็นข้อยกเว้นที่จะถูกโยนทิ้ง ด้านล่างเป็นรหัสที่ฉันมี ... (ยกเว้นแทนที่จะกำหนดค่าตายตัว0สำหรับค่าการหมดเวลาฉันมีพารามิเตอร์ที่ตั้งค่าไว้โดยไม่ตั้งใจ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 ...

คำตอบด้านบนลงมติอาจจะเพียงพอสำหรับคนส่วนใหญ่ อย่างไรก็ตามในบางกรณีคุณอาจได้รับข้อผิดพลาด "ไม่สามารถสร้างช่องทางที่ปลอดภัย SSL / TLS" ได้แม้จะบังคับใช้ TLS 1.2 ถ้าเป็นเช่นนั้นคุณอาจต้องการปรึกษาบทความที่เป็นประโยชน์นี้สำหรับขั้นตอนการแก้ไขปัญหาเพิ่มเติม ในการสรุป: เป็นอิสระจากปัญหารุ่น TLS / SSL ไคลเอนต์และเซิร์ฟเวอร์ต้องยอมรับใน "ชุดรหัส" ในช่วง "จับมือ" ของการเชื่อมต่อ SSL ลูกค้าจะแสดงรายการรหัสที่รองรับสำหรับเซิร์ฟเวอร์เพื่อตรวจสอบกับรายการของตัวเอง แต่สำหรับเครื่องที่ใช้ Windows บางรุ่น cipher-suites ทั่วไปบางตัวอาจถูกปิดการใช้งาน (ดูเหมือนจะเกิดจากการพยายาม จำกัด พื้นผิวการโจมตี) เพื่อลดโอกาสที่ลูกค้าและเซิร์ฟเวอร์จะเห็นด้วยกับชุดรหัส หากพวกเขาไม่เห็นด้วยคุณอาจเห็น "รหัสแจ้งเตือนร้ายแรง 40" ในตัวแสดงเหตุการณ์และ "ไม่สามารถสร้างช่องทางที่ปลอดภัย SSL / TLS" ในโปรแกรม. NET ของคุณ

บทความข้างต้นอธิบายถึงวิธีการแสดงรายการชุดรหัสที่ได้รับการสนับสนุนของเครื่องทั้งหมดและเปิดใช้งานชุดรหัสเพิ่มเติมผ่าน Windows Registry เพื่อช่วยตรวจสอบว่าชุดรหัสใดที่เปิดใช้งานบนไคลเอนต์ลองไปที่หน้าการวิเคราะห์นี้ใน MSIE (การใช้การติดตาม System.Net อาจให้ผลลัพธ์ที่ชัดเจนมากขึ้น) หากต้องการตรวจสอบเซิร์ฟเวอร์ชุดเข้ารหัสที่รองรับให้ลองใช้เครื่องมือออนไลน์นี้ (สมมติว่าเซิร์ฟเวอร์นั้นเข้าถึงอินเทอร์เน็ตได้) ควรดำเนินการโดยไม่บอกว่าการแก้ไขรีจิสทรีต้องกระทำด้วยความระมัดระวังโดยเฉพาะอย่างยิ่งในกรณีที่เกี่ยวข้องกับระบบเครือข่าย (เครื่องของคุณเป็น VM ที่โฮสต์จากระยะไกลหรือไม่หากคุณต้องการหยุดการเชื่อมต่อเครือข่าย VM จะสามารถเข้าถึงได้หรือไม่?)

ในกรณีของ บริษัท ของฉันเราเปิดใช้งานชุด "ECDHE_ECDSA" เพิ่มเติมหลายรายการผ่านการแก้ไขรีจิสทรีเพื่อแก้ไขปัญหาทันทีและป้องกันปัญหาในอนาคต แต่ถ้าคุณไม่สามารถ (หรือจะไม่แก้ไข) Registry การแก้ไขปัญหาจำนวนมาก (ไม่จำเป็นต้องสวย) เป็นสิ่งที่ควรคำนึงถึง ตัวอย่างเช่น: โปรแกรม. NET ของคุณสามารถมอบหมายการรับส่งข้อมูล SSL ให้กับโปรแกรม Python แยกต่างหาก (ซึ่งอาจทำงานได้ด้วยเหตุผลเดียวกันกับที่ Chrome ร้องขออาจประสบความสำเร็จเมื่อคำขอ MSIE ล้มเหลวในเครื่องที่ได้รับผลกระทบ)

หนึ่งในสาเหตุที่ใหญ่ที่สุดของปัญหานี้คือรุ่น. NET Framework ที่ใช้งานอยู่ รุ่นรันไทม์. NET Framework จะมีผลกับโปรโตคอลความปลอดภัยที่เปิดใช้งานตามค่าเริ่มต้น

ดูเหมือนจะไม่มีเอกสารประกอบที่เชื่อถือได้ว่ามันทำงานเฉพาะในรุ่นที่แตกต่างกัน แต่ดูเหมือนว่าค่าเริ่มต้นจะถูกกำหนดมากหรือน้อยดังนี้

• .NET Framework 4.5 และรุ่นก่อนหน้า - SSL 3.0, TLS 1.0
• .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
• .NET Framework 4.7+ - ค่าเริ่มต้นของระบบ (OS)

(สำหรับเวอร์ชั่นเก่าไมล์สะสมของคุณอาจแตกต่างกันไปขึ้นอยู่กับว่ารันไทม์. NET ใดติดตั้งอยู่บนระบบตัวอย่างเช่นอาจมีสถานการณ์ที่คุณกำลังใช้เฟรมเวิร์กที่เก่ามากและไม่รองรับ TLS 1.0 หรือ 4.6 ไม่รองรับ x และ TLS 1.3)

เอกสารของ Microsoftแนะนำอย่างยิ่งให้ใช้ 4.7+ และค่าเริ่มต้นของระบบ:

เราขอแนะนำให้คุณ:

• กำหนดเป้าหมาย. NET Framework 4.7 หรือเวอร์ชันที่ใหม่กว่าในแอปของคุณ กำหนดเป้าหมาย. NET Framework 4.7.1 หรือเวอร์ชันที่ใหม่กว่าในแอพ WCF ของคุณ
• อย่าระบุเวอร์ชัน TLS กำหนดค่ารหัสของคุณเพื่อให้ระบบปฏิบัติการตัดสินใจเกี่ยวกับเวอร์ชัน TLS
• ดำเนินการตรวจสอบรหัสอย่างละเอียดเพื่อตรวจสอบว่าคุณไม่ได้ระบุรุ่น TLS หรือ SSL

สำหรับไซต์ ASP.NETให้ตรวจสอบเวอร์ชัน. NET Framework ใน<httpRuntime>องค์ประกอบของคุณเนื่องจากจะเป็นตัวกำหนดว่าไซต์ของคุณใช้งานจริงหรือไม่

<httpRuntime targetFramework="4.5" />

ที่ดีกว่า:

<httpRuntime targetFramework="4.7" />

อันนี้ใช้ได้สำหรับฉันใน 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;
        }
    }

ในกรณีที่ลูกค้าเป็นเครื่อง windows เหตุผลที่เป็นไปได้อาจเป็นได้ว่าโปรโตคอล tls หรือ ssl ที่ต้องการโดยบริการไม่ได้เปิดใช้งาน

สามารถตั้งค่าใน:

แผงควบคุม -> เครือข่ายและอินเทอร์เน็ต -> ตัวเลือกอินเทอร์เน็ต -> ขั้นสูง

เลื่อนการตั้งค่าลงไปที่ "ความปลอดภัย" และเลือกระหว่าง

• ใช้ SSL 2.0
• ใช้ SSL 3.0
• ใช้ TLS 1.0
• ใช้ TLS 1.1
• ใช้ TLS 1.2

ในกรณีของฉันบัญชีบริการที่เรียกใช้แอปพลิเคชันไม่ได้รับอนุญาตให้เข้าถึงคีย์ส่วนตัว เมื่อฉันให้สิทธิ์นี้ข้อผิดพลาดก็หายไป

1. MMC
2. ใบรับรอง
3. ขยายสู่ส่วนบุคคล
4. เลือกใบรับรอง
5. คลิกขวา
6. งานทั้งหมด
7. จัดการกุญแจส่วนตัว
8. เพิ่ม

หากคุณใช้รหัสจาก Visual Studio ให้ลองใช้ Visual Studio ในฐานะผู้ดูแลระบบ แก้ไขปัญหาสำหรับฉัน

ฉันต่อสู้กับปัญหานี้มาทั้งวัน

เมื่อฉันสร้างโครงการใหม่ด้วย. NET 4.5 ในที่สุดฉันก็สามารถใช้งานได้

แต่ถ้าฉันลดระดับเป็น 4.0 ฉันได้รับปัญหาเดียวกันอีกครั้งและมันกลับไม่ได้สำหรับโครงการนั้น (แม้เมื่อฉันพยายามอัปเกรดเป็น 4.5 อีกครั้ง)

แปลกไม่มีข้อผิดพลาดอื่น ๆ แต่"ยกเลิกคำขอ: ไม่สามารถสร้างช่องทางที่ปลอดภัย SSL / TLS" เกิดขึ้นสำหรับข้อผิดพลาดนี้

System.Net.WebException: การร้องขอถูกยกเลิก: ไม่สามารถสร้างช่องทางที่ปลอดภัย SSL / TLS

ในกรณีของเราเราอยู่ที่ไหนโดยใช้ผู้จำหน่ายซอฟต์แวร์ดังนั้นเราจึงไม่สามารถเข้าถึงเพื่อแก้ไขรหัส. NET Apparently .NET 4 จะไม่ใช้ TLS v 1.2 เว้นแต่ว่าจะมีการเปลี่ยนแปลง

การแก้ไขสำหรับเรากำลังเพิ่มคีย์ SchUseStrongCrypto ในรีจิสทรี คุณสามารถคัดลอก / วางรหัสด้านล่างลงในไฟล์ข้อความที่มีนามสกุล. reg และดำเนินการได้ มันทำหน้าที่เป็น "แพทช์" ของเรากับปัญหา

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

ลองสิ่งนี้:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

การแก้ไขนี้สำหรับฉันเพิ่มบริการเครือข่ายไปยังสิทธิ์ คลิกขวาที่ใบรับรอง> งานทั้งหมด> จัดการคีย์ส่วนตัว ... > เพิ่ม ... > เพิ่ม "บริการเครือข่าย"

ปัญหาสำหรับฉันคือฉันพยายามปรับใช้บน IIS เป็นบริการเว็บฉันติดตั้งใบรับรองบนเซิร์ฟเวอร์ แต่ผู้ใช้ที่เรียกใช้ IIS ไม่มีสิทธิ์ที่ถูกต้องในใบรับรอง

จะให้การเข้าถึง ASP.NET กับไพรเวตคีย์ในใบรับรองในที่เก็บใบรับรองได้อย่างไร

ฉันมีปัญหาเดียวกันนี้และพบว่าคำตอบนี้ทำงานได้อย่างถูกต้องสำหรับฉัน กุญแจคือ 3072 ลิงค์นี้ให้รายละเอียดเกี่ยวกับการแก้ไข '3072'

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

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

ในกรณีของฉันฟีดสองต้องแก้ไข:

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

คำถามนี้มีคำตอบมากมายเนื่องจากเป็นข้อความแสดงข้อผิดพลาดทั่วไป เราพบปัญหานี้ในเซิร์ฟเวอร์บางตัวของเรา แต่ไม่ใช่เครื่องพัฒนาของเรา หลังจากดึงผมของเราออกมาส่วนใหญ่เราพบว่าเป็นข้อผิดพลาดของ Microsoft

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

โดยพื้นฐานแล้ว MS ถือว่าคุณต้องการการเข้ารหัสที่อ่อนแอกว่า แต่ระบบปฏิบัติการจะได้รับการแพตช์เพื่ออนุญาต TLS 1.2 เท่านั้นดังนั้นคุณจะได้รับข้อความ "การร้องขอถูกยกเลิก: ไม่สามารถสร้างช่องทางที่ปลอดภัยของ SSL / TLS"

มีการแก้ไขสามประการ

1) แก้ไขระบบปฏิบัติการด้วยการอัพเดทที่เหมาะสม: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) เพิ่มการตั้งค่าลงในไฟล์ app.config / web.config ของคุณ

3) เพิ่มการตั้งค่ารีจิสทรีที่กล่าวถึงแล้วในคำตอบอื่น

ทั้งหมดนี้กล่าวถึงในบทความฐานความรู้ที่ฉันโพสต์

ความเป็นไปได้อีกอย่างหนึ่งคือรหัสที่ถูกเรียกใช้ไม่มีการกำหนดล่วงหน้าที่ต้องการ

ในกรณีของฉันฉันได้รับข้อผิดพลาดนี้เมื่อใช้ดีบักเกอร์ Visual Studio เพื่อทดสอบการเรียกใช้บริการเว็บ Visual Studio ไม่ได้ทำงานเป็นผู้ดูแลระบบซึ่งทำให้เกิดข้อยกเว้นนี้

สิ่งนี้เกิดขึ้นกับฉันในไซต์เดียวและปรากฎว่ามีเฉพาะรหัส RC4 ในความพยายามก่อนที่จะทำให้เซิร์ฟเวอร์แข็งขึ้นฉันได้ปิดใช้งานการเข้ารหัส RC4 เมื่อฉันเปิดใช้งานอีกครั้งปัญหานี้ได้รับการแก้ไข