अनुरोध निरस्त कर दिया गया: SSL / TLS सुरक्षित चैनल नहीं बना सका

431

WebRequestइस त्रुटि संदेश के कारण हम HTTPS सर्वर से कनेक्ट करने में असमर्थ हैं :

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

समस्या यह है कि सर्वर कभी भी प्रमाणपत्र को मान्य नहीं करता है और उपरोक्त त्रुटि के साथ विफल होता है। क्या किसी के पास कोई विचार है कि मुझे क्या करना चाहिए?

मुझे इस बात का उल्लेख करना चाहिए कि मैंने एक सहकर्मी और कुछ सप्ताह पहले परीक्षण किए थे और जो मैंने ऊपर लिखा था, उसके साथ यह ठीक काम कर रहा था। केवल "प्रमुख अंतर" हमने पाया है कि मैं विंडोज 7 का उपयोग कर रहा हूं और वह विंडोज एक्सपी का उपयोग कर रहा था। क्या वह कुछ बदलता है?

c#  asp.net  windows-8  windows-7  httpwebrequest 
— साइमन डुग्रे
स्रोत
3
इसे भी देखें stackoverflow.com/questions/1600743/…
— Oskar Kjellin
51
यह २०१ question है और इस सवाल को ३०,0,०५६ बार देखा जा चुका है लेकिन फिर भी इसके लिए कोई उचित निर्धारण नहीं है !! मुझे यह मुद्दा बेतरतीब ढंग से मिलता है और यहाँ या किसी भी अन्य सूत्र में बताए गए किसी भी सुधार ने मेरे मुद्दे को हल नहीं किया है।
— निगेल एफडीएस
3
@NigelFds त्रुटि The request was aborted: Could not create SSL/TLS secure channelबहुत सामान्य है। यह मूल रूप से कहता है, "एसएसएल / टीएलएस / एचटीटीपीएस कनेक्शन आरंभीकरण कई संभावित कारणों में से एक के लिए विफल रहा"। इसलिए यदि आप इसे किसी विशिष्ट स्थिति में नियमित रूप से प्राप्त करते हैं, तो आपका सबसे अच्छा विकल्प उस स्थिति के बारे में विशिष्ट विवरण देते हुए एक विशिष्ट प्रश्न पूछना है। और अधिक जानकारी के लिए इवेंट व्यूअर की जाँच करना। और / या कुछ .NET क्लाइंट-साइड डिबगिंग को अधिक विवरण प्राप्त करने के लिए सक्षम करें (क्या सर्वर प्रमाणपत्र पर भरोसा नहीं किया गया है? क्या कोई सी बेमेल है? SSL / TLS प्रोटोकॉल संस्करण बेमेल? आदि)।
— MarnixKlooster ReinstateMonica
4
@MarnixKlooster मैंने पहले ही सभी की जाँच कर ली है, यह प्रमाण पत्र के साथ कोई समस्या नहीं हो सकती है जैसे कि मैं इसे पुन: प्रयास करता हूं, यह काम करता है। और मुझे संदेह है कि मैं इस सवाल को एसओ पर बिना किसी के आने और इसे डुप्लिकेट या कुछ के रूप में चिह्नित कर सकता हूं।
— निगेल एफडीएस
1
मैं 4 वीं बार शायद इस मुद्दे पर लड़ रहा हूं। समान कोड आधार मैं उत्पादन में काम कर रहा हूं और मेरे कुछ साथी देवों के वातावरण में भी ठीक है। पिछली बार के आसपास, मुझे एक रजिस्ट्री मान जोड़ने के लिए निर्देश दिया गया था कंप्यूटर \ HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ .NETFramework \ v4.7.02046 \ SchUseStrongbrypto [DWORD] = 1. और इसने थोड़ी देर के लिए काम किया। मैंने एक समय के लिए एक अलग परियोजना में काम करना शुरू कर दिया और अब मैं इस परियोजना में वापस आ गया हूं और अनुरोध फिर से विफल हो जाता है, यहां तक ​​कि इस रजिस्ट्री कुंजी के साथ भी। बहुत कष्टप्रद।
— मिगेल

जवाबों:

598

मुझे अंत में उत्तर मिला (मैंने अपने स्रोत को नोट नहीं किया है लेकिन यह एक खोज से था);

जबकि कोड विंडोज 7 में, विंडोज एक्सपी में काम करता है, आपको शुरुआत में इसे जोड़ना होगा:

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

और अब, यह पूरी तरह से काम करता है।

परिशिष्ट

जैसा कि रॉबिन फ्रेंच ने उल्लेख किया है; यदि आपको पेपाल को कॉन्फ़िगर करते समय यह समस्या हो रही है, तो कृपया ध्यान दें कि वे दिसंबर, 3, 2018 से शुरू होने वाले एसएसएल 3 का समर्थन नहीं करेंगे। आपको टीएलएस का उपयोग करने की आवश्यकता होगी। इसके बारे में यहाँ पेपल पेज है।

— साइमन डुग्रे
स्रोत
5
नीचे जाने के लिए SecurityProtocolType.Tls12 ने वास्तव में मेरे लिए इस समस्या को ठीक किया। नीचे मेरा जवाब देखें।
— ब्रायन लीजेंड
24
@LoneCoder सिफारिश की गई है के रूप में SecurityProtocolType.Tls12 SecurityProtocolType.Ssl3 के लिए उपयुक्त प्रतिस्थापन है - SSLv3 18 वर्ष और अब POODLE के लिए अतिसंवेदनशील शोषण है
— गैरी
4
SecurityProtocolType.Tls वास्तव में एक बेहतर विकल्प हो सकता है, जब तक कि इसके लिए कोई शोषण नहीं मिलता है (सभी साइटें लेखन के रूप में Tls12 का समर्थन नहीं करती हैं)
— गैरी
3
पेपाल ने SSL3 को निष्क्रिय करने और TLS1.2 को लागू करने के लिए 30 जून 2017 की तारीख निर्धारित की है। यह पहले से ही उनके सैंडबॉक्स पर्यावरण paypal-knowledge.com/infocenter/…
— रॉबिन फ्रेंच में
11
देखें इस साथ ही। आपको विशेष रूप से इसे एक ही प्रकार पर सेट करने की आवश्यकता नहीं है, आप बस इसे भी जोड़ सकते हैं। System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;
— Nae
153

इसका समाधान .NET 4.5 में है

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

यदि आपके पास .NET 4.5 नहीं है तो उपयोग करें

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
— लेडीज जेड
स्रोत
10
धन्यवाद! मुझे .net 4.0 का उपयोग करने की आवश्यकता है और यह नहीं पता कि इसे कैसे हल किया जाए। यह यहाँ काम करने लगता है। :)
— फैबियानो
विंडोज सर्वर 2008R2 (और संभवतः 2012 को भी) पर काम नहीं करता है
— मिस्सम
@billpg, इसे और अधिक सटीक उत्तर के लिए पढ़ें
— विक्रांत
VB प्रकारों के लिए (चूंकि यह उत्तर Google में प्रदर्शित होता है), समतुल्य कोड हैServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType)
— कन्फ्यूजनटावर
@Andrej Z अपने .net ढांचे पर काम कर रहा है 4. धन्यवाद।
— az fav
107

सुनिश्चित करें कि HttpWebRequest बनाने से पहले ServicePointManager सेटिंग की जाती है, अन्यथा यह काम नहीं करेगा।

काम करता है:

        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;
— hogarth45
स्रोत
4
आपके द्वारा उल्लिखित वर्क्स और विफलताओं के बीच अंतर क्या है?
— चांडी कुन्हु
5
बहुत बढ़िया। मेरे अनुरोध ने केवल दूसरी कोशिश के बाद काम किया, जिसका कोई मतलब नहीं था और फिर मैंने आपके पोस्ट को देखा, अनुरोध और वॉइली से पहले सुरक्षा प्रोटोकॉल को स्थानांतरित किया, तय किया। धन्यवाद @ hogarth45
— deanwilliammills
2
बिल्कुल सही! जब मैंने अनुरोध करने से ठीक पहले ServicePointManager को रखा, तो इसने मेरे लिए काम किया, धन्यवाद आदमी, आपने मेरा दिन बचाया।
1
बिल्कुल सही ... यह अद्भुत है
— मरियम बाघेरी
1
हमारे मामले में, अनुरोध पहली बार विफल हुआ और बाद में काम किया। इस उत्तर में बताए गए कारण के कारण यह ठीक था!
— मोहम्मद देहघन
34

आपके पास समस्या यह है कि aspNet उपयोगकर्ता के पास प्रमाणपत्र तक पहुँच नहीं है। आपको winhttpcertcfg.exe का उपयोग करके एक्सेस देना होगा

इसे कैसे सेट किया जाए, इस पर एक उदाहरण है: http://support.microsoft.com/kb/901183

अधिक जानकारी में चरण 2 के तहत

EDIT: IIS के अधिक हाल के संस्करणों में, यह सुविधा प्रमाणपत्र प्रबंधक उपकरण के लिए बनाई गई है - और प्रमाणपत्र पर राइट क्लिक करके और निजी कुंजी के प्रबंधन के लिए विकल्प का उपयोग करके इसे एक्सेस किया जा सकता है। अधिक विवरण यहां: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791##32791

— Avitus
स्रोत
मैंने winhttpcertcfg.exe निष्पादित करने की कोशिश की है ... ध्यान दें कि मैं विंडोज 7 पर हूं। क्या यह कुछ बदल सकता है?
— सिमोन डुगरे
मुझे यकीन नहीं है कि क्या यह संबंधित है, लेकिन इस पोस्ट ने मुझे वीएस से यह कॉल करते समय वीएस को व्यवस्थापक के रूप में चलाने का विचार दिया और मेरे लिए इस मुद्दे को तय किया।
— PFranchise
2
विंडोज 7 और बाद में, प्रमाण पत्र "निजी कुंजी प्रबंधित करें" के लिए स्थानीय उपयोगकर्ता के बजाय स्थानीय कंप्यूटर के लिए स्टोर में होना चाहिए
— लुकोस
1
हां, यह मेरी समस्या थी। mmc.exe का उपयोग करें, प्रमाणपत्र स्नैप-इन जोड़ें (मेरे लिए मैंने तब 'स्थानीय कंप्यूटर' चुना था)। प्रमाण पत्र, सभी कार्यों को राइट-क्लिक करें, निजी कुंजी प्रबंधित करें। 'सबको जोड़ें' (स्थानीय देव के लिए यह सबसे आसान है - स्पष्ट रूप से आपके स्पष्ट आईआईएस वेबसाइट ऐप पूल / उपयोगकर्ता की आवश्यकता है)
— इयान येट्स
@ एलियन येट्स, इस समाधान ने केवल मेरे लिए (y)
— उस्मान
31

त्रुटि सामान्य है और कई कारण हैं कि SSL / TLS वार्ता विफल हो सकती है। सबसे आम एक अमान्य या समाप्त सर्वर प्रमाणपत्र है, और आपने अपना सर्वर प्रमाणपत्र सत्यापन हुक प्रदान करके इस बात का ध्यान रखा है, लेकिन केवल एकमात्र कारण नहीं है। सर्वर को पारस्परिक प्रमाणीकरण की आवश्यकता हो सकती है, इसे आपके ग्राहक द्वारा समर्थित नहीं किए गए सिफर के एक सूट के साथ कॉन्फ़िगर किया जा सकता है, हैंडशेक को सफल होने के लिए बहुत अधिक समय और बहुत अधिक कारणों से बहाव हो सकता है।

सबसे अच्छा समाधान SChannel समस्या निवारण उपकरण सेट का उपयोग करना है। SChannel एसएसएलआई प्रदाता है जो एसएसएल और टीएलएस के लिए जिम्मेदार है और आपका क्लाइंट इसे हैंडशेक के लिए उपयोग करेगा। TLS / SSL उपकरण और सेटिंग्स पर एक नज़र डालें ।

यह भी देखें कि स्कैनेल इवेंट लॉगिंग कैसे सक्षम करें ।

— रेमस रुसानू
स्रोत
कहां है पथ के लिए Schannel event loggingमें विंडोज 7-8-10 ?
— प्रीग्टनटनकोजेरो कैब्रोन 22
समस्या निवारण TLS / SSL को C # में प्रोग्राम करें ?
— कीकेनेट
27

मुझे यह समस्या https://ct.mob0.com/Styles/Fun.png पर हिट करने की कोशिश कर रही थी , जो कि क्लाउडफ्लारे द्वारा वितरित की गई एक छवि है, जो सीडीएन पर है जो एसपीडीवाई और अजीब पुनर्निर्देशित एसएसटी सेरेक्ट जैसे पागल सामान का समर्थन करती है।

Ssl3 को सिमंस के उत्तर के रूप में निर्दिष्ट करने के बजाय मैं इसे Tls12 पर नीचे जाकर इसे ठीक करने में सक्षम था:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");
— ब्रायन लीजेंड
स्रोत
धन्यवाद लोन ... यह पागल है कि कैसे स्थिति के आधार पर मुद्दों की कई अलग-अलग संभावनाएं हैं ... और, जैसा कि मैं देख सकता हूं, इसका कोई वास्तविक दस्तावेज नहीं है। खैर, किसी को इंगित करने के लिए धन्यवाद जो एक ही समस्या का अनुभव कर सकता है।
— साइमन डुग्रे
इसने मेरे लिए काम किया। जब मैंने ऑफिस लैन से अपने होम नेटवर्क पर स्विच किया तो मुझे एरर का सामना करना पड़ा। वही कोड, वही लैपटॉप!
— अमल
क्या आपको हमेशा (सभी अनुरोधों में) या कभी-कभी त्रुटि मिलती है ?
— प्रीग्टनटनकोजेरो कैब्रोन 22
24

इसी मुद्दे के साथ कई घंटों के बाद मैंने पाया कि ASP.NET खाता ग्राहक सेवा के तहत चल रहा था जिसके पास प्रमाणपत्र तक पहुंच नहीं थी। मैंने इसे आईआईएस एप्लिकेशन पूल में जाकर तय किया था कि वेब ऐप के तहत चलता है, एडवांस्ड सेटिंग्स में जा रहा है, और पहचान को LocalSystemखाते से बदल रहा है NetworkService।

एक बेहतर समाधान यह है कि प्रमाणपत्र को डिफ़ॉल्ट NetworkServiceखाते के साथ काम किया जाए लेकिन यह त्वरित कार्यात्मक परीक्षण के लिए काम करता है।

— निक गोच
स्रोत
3
इस उत्तर में अधिक वोट होने चाहिए। एक सप्ताह के शोध के बाद, यह एकमात्र समाधान है जिसने मेरे लिए काम किया। धन्यवाद!!
— user224567893
इसने मेरे लिए काम किया। बहुत बहुत धन्यवाद।
— एमी आँकड़े
18

सेटिंग के साथ दृष्टिकोण 

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

ठीक लगता है, क्योंकि Tls1.2 सुरक्षित प्रोटोकॉल का नवीनतम संस्करण है। लेकिन मैंने गहराई से देखने और जवाब देने का फैसला किया कि क्या हमें वास्तव में इसे हार्डकोड करने की आवश्यकता है।

चश्मा: विंडोज सर्वर 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

लेकिन प्रस्तावित विंडोज़ अपडेट आर 2 संस्करण के लिए काम नहीं करता है

लेकिन क्या मदद मिली कि मैं रजिस्ट्री में 2 मान जोड़ रहा हूं। आप अगली पीएस स्क्रिप्ट का उपयोग कर सकते हैं ताकि वे स्वचालित रूप से जुड़ जाएंगे

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

यह वही है जो मैं देख रहा था। लेकिन फिर भी मैं सवाल पर जवाब नहीं देता कि क्यों नेटफ्रामवर्क 4.6+ इसे सेट नहीं करता है ... प्रोटोकॉल मान स्वचालित रूप से?

— बस अच्छा है
स्रोत
17

मूल उत्तर में कुछ नहीं था। मैंने इसे बुलेट प्रूफ बनाने के लिए कुछ और कोड जोड़े।

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
— SpoiledTechie.com
स्रोत
8
मैं जोड़े गए SSL3 प्रोटोकॉल की सिफारिश नहीं करूंगा।
— पीटर डे ब्रुइजन
SSL3 में एक गंभीर सुरक्षा समस्या है जिसे 'Poodle' कहा जाता है।
— पीटर डी ब्रूजन
@PeterdeBruijn Tls and Tls11हैं अप्रयुक्त बना ?
— कीकेनेट
1
@Kiquenet - हाँ। जून 2018 तक PCI (भुगतान कार्ड उद्योग) TLS1.2 से कम प्रोटोकॉल की अनुमति नहीं देगा। (यह मूल रूप से 06/2017 के लिए स्लेट किया गया था लेकिन एक साल के लिए स्थगित कर दिया गया था)
— ग्लेनग्ल
SSL / TLS परिवार में पांच प्रोटोकॉल हैं : SSL v2, SSL v3, TLS v1.0, TLS v1.1, और TLS v1.2 : github.com/ssllabs/research/wiki/… SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes केवल वैध विकल्प होगा ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12?
— किकेनेट
14

एक अन्य संभावना बॉक्स पर अनुचित प्रमाणपत्र आयात है। सुनिश्चित करें कि संलग्न घेरा बॉक्स का चयन करें। प्रारंभ में मैंने ऐसा नहीं किया था, इसलिए कोड या तो टाइम आउट कर रहा था या समान अपवाद फेंक रहा था क्योंकि निजी कुंजी स्थित नहीं हो सकती थी।

प्रमाणपत्र आयात संवाद

— शर्लक
स्रोत
क्लाइंट प्रोग्राम का उपयोग करने के लिए एक क्लाइंट को फिर से प्रमाणपत्र को स्थापित करने के लिए रखा जाता है। बार-बार उन्हें कार्यक्रम का उपयोग करने से पहले प्रमाणपत्र को फिर से स्थापित करना होगा। मुझे उम्मीद है कि यह उत्तर उस समस्या को हल करता है।
— पंगम्मा
11

"अनुरोध रद्द कर दिया गया था: एसएसएल / टीएलएस सुरक्षित चैनल नहीं बना सका" यदि सर्वर HTTP अनुरोध पर HTTP 401 अनधिकृत प्रतिक्रिया दे रहा है तो अपवाद हो सकता है ।

आप यह निर्धारित कर सकते हैं कि क्या यह आपके क्लाइंट एप्लिकेशन के लिए ट्रेस-स्तर System.Net लॉगिंग को चालू करके हो रहा है, जैसा कि इस उत्तर में वर्णित है ।

एक बार जब लॉगिंग कॉन्फ़िगरेशन चालू हो जाता है, तो एप्लिकेशन चलाएं और त्रुटि को पुन: उत्पन्न करें, फिर इस तरह एक लाइन के लिए लॉगिंग आउटपुट में देखें:

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

मेरी स्थिति में, मैं उस विशेष कुकी को सेट करने में विफल हो रहा था जो सर्वर को उम्मीद थी, जिससे सर्वर को 401 त्रुटि के साथ अनुरोध का जवाब देना पड़ा, जिसके कारण "SSL / TLS सुरक्षित चैनल नहीं बना सका" अपवाद को छोड़ दिया।

— जॉन श्नाइडर
स्रोत
1
मेरा कार्य शेड्यूलर हर दिन निष्पादित करता है (सप्ताहांत नहीं)। मुझे एक ही त्रुटि मिलती है, लेकिन कभी-कभी ( 2 errors in 2 months)। जब मुझे त्रुटि मिलती है, तो कुछ मिनट बाद मैं फिर से मैन्युअल रूप से कोशिश करता हूं और सब ठीक है।
— किकेनेट
10

The request was aborted: Could not create SSL/TLS secure channelत्रुटि का एक अन्य संभावित कारण आपके ग्राहक पीसी के कॉन्फ़िगर किए गए सिफर_सूइट मानों और सर्वर द्वारा कॉन्फ़िगर किए गए मानों को स्वीकार करने में सक्षम होने के बीच एक बेमेल है । इस स्थिति में, जब आपका क्लाइंट सिफर_सूइट मानों की सूची भेजता है, जिसे वह अपने शुरुआती एसएसएल हैंडशेकिंग / बातचीत "क्लाइंट हैलो" संदेश में स्वीकार करने में सक्षम होता है, तो सर्वर देखता है कि कोई भी प्रदान किया गया मान स्वीकार्य नहीं है, और "अलर्ट" वापस कर सकता है SSL हैंडशेक के "सर्वर हैलो" चरण के लिए आगे बढ़ने के बजाय प्रतिक्रिया।

इस संभावना की जांच करने के लिए, आप Microsoft संदेश विश्लेषक डाउनलोड कर सकते हैं , और इसका उपयोग SSL वार्ता पर एक ट्रेस चलाने के लिए कर सकते हैं जो तब होता है जब आप सर्वर पर (अपने C # ऐप में) HTTPS कनेक्शन स्थापित करने का प्रयास करते हैं और विफल होते हैं।

यदि आप किसी अन्य वातावरण से एक सफल HTTPS कनेक्शन बनाने में सक्षम हैं (जैसे कि आपके द्वारा उल्लिखित Windows XP मशीन - या संभवत: HTTPS URL को गैर-Microsoft ब्राउज़र में मारकर जो OS के सिफर सूट सेटिंग्स का उपयोग नहीं करता है, जैसे Chrome या फ़ायरफ़ॉक्स), उस वातावरण में एक और संदेश विश्लेषक ट्रेस चलाने के लिए जिसे कैप्चर किया जाता है जब SSL बातचीत सफल होती है।

उम्मीद है कि, आपको दो क्लाइंट हैलो संदेशों के बीच कुछ अंतर दिखाई देगा, जो आपको सटीक रूप से SSL बातचीत के बारे में बताने की अनुमति देगा, जिससे यह विफल हो रहा है। फिर आपको विंडोज में कॉन्फ़िगरेशन परिवर्तन करने में सक्षम होना चाहिए जो इसे सफल होने की अनुमति देगा। IISCrypto इसके लिए उपयोग करने के लिए एक शानदार टूल है (क्लाइंट पीसी के लिए, "IIS" नाम के बावजूद)।

निम्न दो Windows रजिस्ट्री कुंजियाँ आपके पीसी का उपयोग करने वाले सिफर_सूइट मानों को नियंत्रित करती हैं:

  • HKLM \ SOFTWARE \ नीतियाँ \ Microsoft \ क्रिप्टोग्राफी \ विन्यास \ एसएसएल \ 00010002
  • HKLM \ SYSTEM \ CurrentControlSet \ Control \ क्रिप्टोग्राफी \ विन्यास \ Local \ एसएसएल \ 00010002

यहाँ मैंने पूरी जांच की है कि कैसे मैंने इस Could not create SSL/TLS secure channelसमस्या की एक किस्म की जाँच की और हल किया : http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

— जॉन श्नाइडर
स्रोत
1
मेरे मामले में, यह उत्तर सहायक है। इसके अलावा, जब से मुझे संदेह हुआ कि मेरे ग्राहक पीसी ने कुछ सिफर सूटों को याद किया है, तो मैंने अपना भाग्य आज़माने के लिए सीधे ही एक शॉर्टकट लिया और इस Windows अद्यतन को स्थापित किया ( support.microsoft.com/en-hk/help/3161639 , वास्तव में शुरू होने से पहले Windows रिबूट की जरूरत है)। संदेश विश्लेषक खोज, और पता चला कि मैं भाग्यशाली था और इसने मेरी समस्या को हल किया, खुद को एक खोज के रूप में सहेजा।
— sken130
1
ध्यान दें कि जब आप फ़ायरफ़ॉक्स जैसे ब्राउज़रों में एक HTTPS लिंक का परीक्षण करते हैं, भले ही आप किसी भी दिए गए विंडोज अपडेट द्वारा प्रदान किए गए से अलग सिफर प्राप्त करें, विंडोज अपडेट अभी भी कोशिश करने लायक है, क्योंकि नए सिफर स्थापित करने से सिफर मध्यस्थता प्रभावित होगी क्लाइंट पीसी और सर्वर के बीच, इस प्रकार एक मैच खोजने की उम्मीद बढ़ जाती है।
— sken130
मेरी समस्या का उत्तर देने के लिए। दो चीजें जिन्होंने मुझे बदलाव लाने में मदद की। 1. सिफर सूट वेब सर्वर द्वारा समर्थित है: ssllabs.com/ssltest 2. सिफर सूट जो विभिन्न विंडोज संस्करणों का समर्थन करते हैं: डॉक्स.माइकोलॉजी.com
— पॉल बी।
10

मेरे मामले में इस अपवाद की जड़ यह थी कि कोड में कुछ बिंदु पर निम्नलिखित को बुलाया जा रहा था:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

यह वास्तव में बुरा है। न केवल यह एक असुरक्षित प्रोटोकॉल का उपयोग करने के लिए .NET को निर्देश दे रहा है, बल्कि यह आपके एपडोमेन के भीतर किए गए हर नए WebClient (और समान) अनुरोध को प्रभावित करता है। (ध्यान दें कि आने वाले वेब अनुरोध आपके ASP.NET ऐप में अप्रभावित हैं, लेकिन नए WebClient अनुरोध, जैसे कि बाहरी वेब सेवा से बात करने के लिए, हैं)।

मेरे मामले में, वास्तव में इसकी आवश्यकता नहीं थी, इसलिए मैं सिर्फ बयान को हटा सकता था और मेरे सभी अन्य वेब अनुरोधों ने फिर से ठीक काम करना शुरू कर दिया। मेरे पढ़ने के आधार पर, मैंने कुछ चीजें सीखीं:

  • यह आपके एपडोमेन में एक वैश्विक सेटिंग है, और यदि आपके पास समवर्ती गतिविधि है, तो आप मज़बूती से इसे एक मूल्य पर सेट नहीं कर सकते हैं, अपनी कार्रवाई कर सकते हैं, और फिर इसे वापस सेट कर सकते हैं। एक और कार्रवाई उस छोटी खिड़की के दौरान हो सकती है और प्रभावित हो सकती है।
  • सही सेटिंग इसे डिफ़ॉल्ट रूप से छोड़ना है। यह .NET को समय के साथ सबसे सुरक्षित डिफ़ॉल्ट मान जो भी हो, का उपयोग जारी रखने की अनुमति देता है और आप फ्रेमवर्क को अपग्रेड करते हैं। इसे TLS12 पर सेट करना (जो इस लेखन के रूप में सबसे सुरक्षित है) अब काम करेगा लेकिन 5 वर्षों में रहस्यमय समस्याओं का कारण बन सकता है।
  • यदि आपको वास्तव में एक मूल्य निर्धारित करने की आवश्यकता है, तो आपको इसे एक अलग विशेष एप्लिकेशन या एपडोमेन में करने पर विचार करना चाहिए और इसके और अपने मुख्य पूल के बीच बात करने का तरीका खोजना चाहिए। क्योंकि यह एक एकल वैश्विक मूल्य है, इसे एक व्यस्त ऐप पूल में प्रबंधित करने की कोशिश करने से केवल परेशानी होगी। यह उत्तर: https://stackoverflow.com/a/26754917/7656 कस्टम प्रॉक्सी के माध्यम से एक संभावित समाधान प्रदान करता है। (नोट मैंने इसे व्यक्तिगत रूप से लागू नहीं किया है।)
— टायलर फोर्सिथे
स्रोत
2
आपके अंगूठे के सामान्य नियम के विपरीत, मैं यह जोड़ूंगा कि जब आप इसे TLS 1.2 पर सेट करते हैं, तो डिफ़ॉल्ट रन देने के बजाय अपवाद होना चाहिए। यदि आप .NET 4.6 से अधिक पुराने ढाँचे पर हैं, और आप अपने सर्वर (SSL या TLS 1.0 / 1.1) पर असुरक्षित प्रोटोकॉल अक्षम करते हैं, तो आप तब तक अनुरोध जारी नहीं कर सकते जब तक आप कार्यक्रम को TLS 1.2 में शामिल नहीं करते।
— पॉल
10

मुझे यह समस्या थी क्योंकि मेरे web.config में था:

<httpRuntime targetFramework="4.5.2" />

और नहीं:

<httpRuntime targetFramework="4.6.1" />
— तेरजे सोलेम
स्रोत
मेरे पास यह एक ही मुद्दा था और नीचे एक अधिक विस्तृत उत्तर जोड़ा गया है , जो इस मुद्दे के अधिक और बाहरी हिस्से में जाता है।
— JLRishe
9

जैसा कि आप बता सकते हैं कि ऐसा होने के बहुत सारे कारण हैं। सोचा था कि मैं कारण का सामना करेंगे ...

आप में से मान सेट करते हैं 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 ...
— TCC
स्रोत
2
वाह! इस उल्लेख के लिए धन्यवाद। यह पहली जगह में विश्वास नहीं कर सकता है और पहले विभिन्न चीजों के टन की कोशिश की। फिर, आखिरकार, टाइमआउट को १० सेकंड पर सेट करें और अपवाद गायब हो गया! मेरे लिए यही उपाय है। (y)
— derFunk
9

शीर्ष मतदान जवाब शायद ज्यादातर लोगों के लिए पर्याप्त होगा। हालाँकि, कुछ परिस्थितियों में, आप टीएलएस 1.2 को मजबूर करने के बाद भी "एसएसएल / टीएलएस सुरक्षित चैनल नहीं बना सकते" त्रुटि प्राप्त कर सकते हैं। यदि हां, तो आप इस उपयोगी लेख से परामर्श करना चाह सकते हैंअतिरिक्त समस्या निवारण चरणों के लिए। संक्षेप में: TLS / SSL संस्करण के मुद्दे से स्वतंत्र, क्लाइंट और सर्वर को "सिफर सूट" पर सहमत होना चाहिए। एसएसएल कनेक्शन के "हैंडशेक" चरण के दौरान, क्लाइंट अपने स्वयं के सूची के खिलाफ जांच करने के लिए सर्वर के लिए अपने समर्थित सिफर-सूइट्स को सूचीबद्ध करेगा। लेकिन कुछ विंडोज मशीनों पर, कुछ सामान्य सिफर-सुइट्स को अक्षम किया गया हो सकता है (प्रतीत होता है कि हमले की सतह को सीमित करने के इरादे से किए गए प्रयासों के कारण), ग्राहक और सर्वर की एक सिफर सुइट पर सहमति की संभावना कम हो जाती है। यदि वे सहमत नहीं हो सकते हैं, तो आप इवेंट व्यूअर में "घातक अलर्ट कोड 40" देख सकते हैं और अपने .NET प्रोग्राम में "SSL / TLS सुरक्षित चैनल नहीं बना सकते हैं"।

उपरोक्त लेख बताता है कि मशीन के सभी संभावित रूप से समर्थित सिफर सुइट्स को कैसे सूचीबद्ध किया जाए और Windows रजिस्ट्री के माध्यम से अतिरिक्त सिफर सुइट्स को सक्षम किया जाए। यह जानने में मदद करने के लिए कि ग्राहक पर किस साइपर सूट को सक्षम किया गया है, MSIE में इस नैदानिक ​​पृष्ठ पर जाने का प्रयास करें । (System.Net ट्रेसिंग का उपयोग करने से अधिक निश्चित परिणाम मिल सकते हैं।) यह जानने के लिए कि सर्वर द्वारा किस साइपर के समर्थन का समर्थन किया जाता है, इस ऑनलाइन टूल को आज़माएं (यह मानते हुए कि सर्वर इंटरनेट-सुलभ है)। यह कहने के बिना जाना चाहिए कि रजिस्ट्री संपादन सावधानी से किया जाना चाहिए , खासकर जहां नेटवर्किंग शामिल है। (क्या आपकी मशीन रिमोट-होस्टेड VM है? यदि आप नेटवर्किंग को तोड़ना चाहते हैं, तो क्या वीएम बिल्कुल भी सुलभ होगा?)

मेरी कंपनी के मामले में, हमने कई अतिरिक्त "ECDHE_ECDSA" सुइट्स को रजिस्ट्री संपादन के माध्यम से सक्षम किया, ताकि तत्काल समस्या को ठीक किया जा सके और भविष्य की समस्याओं से बचाव हो सके। लेकिन अगर आप रजिस्ट्री को संपादित नहीं कर सकते (या नहीं करेंगे), तो कई वर्कआर्डो (जरूरी नहीं कि बहुत सुंदर) दिमाग में आए। उदाहरण के लिए: आपका .NET प्रोग्राम अपने SSL ट्रैफ़िक को एक अलग पायथन प्रोग्राम (जो स्वयं काम कर सकता है, उसी कारण से क्रोम अनुरोध सफल हो सकता है जहां MSIE अनुरोध प्रभावित मशीन पर विफल हो सकता है) को प्रस्तुत कर सकता है।

— ए पी डब्ल्यू
स्रोत
9

इस समस्या के सबसे बड़े कारणों में से एक सक्रिय .NET फ्रेमवर्क संस्करण है। .NET फ्रेमवर्क रनटाइम संस्करण को प्रभावित करता है कि कौन से सुरक्षा प्रोटोकॉल डिफ़ॉल्ट रूप से सक्षम हैं।

यह विशेष रूप से विभिन्न संस्करणों में कैसे काम करता है, इस पर कोई आधिकारिक दस्तावेज नहीं लगता है, लेकिन ऐसा लगता है कि चूक अधिक या अधिक निर्धारित की गई हैं:

  • .NET फ्रेमवर्क 4.5 और इससे पहले - एसएसएल 3.0, टीएलएस 1.0
  • .NET फ्रेमवर्क 4.6.x - टीएलएस 1.0, 1.1, 1.2, 1.3
  • .NET फ्रेमवर्क 4.7+ - सिस्टम (OS) डिफॉल्ट्स

(पुराने संस्करणों के लिए, आपका माइलेज कुछ हद तक भिन्न हो सकता है, जिसके आधार पर सिस्टम पर .NET रनटाइम्स लगाए जाते हैं। उदाहरण के लिए, ऐसी स्थिति हो सकती है जहां आप बहुत पुराने ढाँचे का उपयोग कर रहे हैं और TLS 1.0 समर्थित नहीं है, या 4.6 का उपयोग कर रहा है। एक्स और टीएलएस 1.3 समर्थित नहीं है)

Microsoft का दस्तावेज़ीकरण 4.7+ और सिस्टम डिफॉल्ट्स का उपयोग करने की दृढ़ता से सलाह देता है:

हम अनुशंसा करते हैं कि आप:

  • लक्ष्य .NET फ्रेमवर्क 4.7 या बाद के संस्करण आपके ऐप्स पर। अपने .NET WCF ऐप्स पर .NET फ्रेमवर्क 4.7.1 या बाद के संस्करणों को लक्षित करें।
  • TLS संस्करण निर्दिष्ट न करें। ओएस को टीएलएस संस्करण पर निर्णय लेने के लिए अपना कोड कॉन्फ़िगर करें।
  • सत्यापित करने के लिए कि आप TLS या SSL संस्करण निर्दिष्ट नहीं कर रहे हैं, एक संपूर्ण कोड ऑडिट करें।

ASP.NET साइटों के लिए , अपने <httpRuntime>तत्व में .NET फ्रेमवर्क संस्करण की जाँच करें , क्योंकि यह निर्धारित करता है कि कौन सा रनटाइम वास्तव में आपकी साइट द्वारा उपयोग किया जाता है:

<httpRuntime targetFramework="4.5" />

बेहतर:

<httpRuntime targetFramework="4.7" />
— JLRishe
स्रोत
8

यह एमवीसी वेबक्लेयर में मेरे लिए काम कर रहा है

    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;
        }
    }
— अरुण प्रसाद ई.एस.
स्रोत
2
क्या ओवरराइड करेगा सर्वर सर्टिफिकेशन अमान्य
7

इस मामले में कि ग्राहक एक विंडोज़ मशीन है, एक संभावित कारण यह हो सकता है कि सेवा द्वारा आवश्यक tls या ssl प्रोटोकॉल सक्रिय नहीं है।

इसमें सेट किया जा सकता है:

नियंत्रण कक्ष -> नेटवर्क और इंटरनेट -> इंटरनेट विकल्प -> उन्नत

"सिक्योरिटी" के लिए स्क्रॉल सेटिंग्स और बीच चुनें

  • एसएसएल 2.0 का उपयोग करें
  • एसएसएल 3.0 का उपयोग करें
  • टीएलएस 1.0 का उपयोग करें
  • टीएलएस 1.1 का उपयोग करें
  • टीएलएस 1.2 का उपयोग करें

यहां छवि विवरण दर्ज करें

— cnom
स्रोत
उन सभी को टिक करने में कोई समस्या?
— निगेल एफडीएस
कोई समस्या नहीं है, जहाँ तक मुझे पता है ... सिवाय इसके कि ssl की कोई और सिफारिश नहीं की जाती है ... उन्हें पर्याप्त सुरक्षित नहीं माना जाता है।
— cnom
कैसे-यह प्रोग्रामशक्तिक रूप से करने के लिए ?
— किकेनेट
यह कुछ ऐसा है जो विंडोज के पुराने संस्करणों को प्रभावित करता है, कुछ शोध करें, पता करें कि वर्तमान में सुरक्षा विकल्प क्या उपयोग में हैं। आज तक इस लिंक को देखें: tecadmin.net/enable-tls-on-windows-server-and-iis
— Tod
7

मेरे मामले में, एप्लिकेशन चलाने वाले सेवा खाते के पास निजी कुंजी तक पहुंचने की अनुमति नहीं है। एक बार जब मैंने यह अनुमति दी, तो त्रुटि दूर हो गई

  1. एमएमसी
  2. प्रमाण पत्र
  3. व्यक्तिगत तक विस्तृत करें
  4. प्रमाणपत्र का चयन करें
  5. दाएँ क्लिक करें
  6. सभी कार्य
  7. निजी कुंजी प्रबंधित करें
  8. जोड़ना
— दिनेश राजन
स्रोत
7

यदि आप Visual Studio से अपना कोड चला रहे हैं, तो Visual Studio को व्यवस्थापक के रूप में चलाने का प्रयास करें। मेरे लिए मुद्दा तय किया।

— bplus
स्रोत
काश मेरे लिए नहीं!
— benedict_w
यह केवल एक ही है जिसने मेरे मामले में मदद की है! धन्यवाद!!!
— अलेक्जेंडर ओस्ट्रिकोव
6

मैं पूरे दिन इस समस्या से जूझता रहा।

जब मैंने .NET 4.5 के साथ एक नया प्रोजेक्ट बनाया तो मुझे आखिरकार यह काम करना पड़ा।

लेकिन अगर मैं 4.0 पर डाउनग्रेड हो गया तो मुझे फिर से वही समस्या हुई, और यह उस परियोजना के लिए अपरिवर्तनीय था (तब भी जब मैंने 4.5 को फिर से अपग्रेड करने की कोशिश की थी)।

कोई अन्य त्रुटि संदेश न दें, लेकिन "अनुरोध निरस्त कर दिया गया: SSL / TLS सुरक्षित चैनल नहीं बना सका।" इस त्रुटि के लिए आया था

— एक भूत
स्रोत
5
यह काम करने का कारण यह हो सकता है कि विभिन्न .NET संस्करण अलग-अलग SSL / TLS प्रोटोकॉल संस्करणों का समर्थन करते हैं। अधिक जानकारी: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support
— जॉन श्नाइडर
4

System.Net.WebException: अनुरोध रद्द कर दिया गया था: SSL / TLS सुरक्षित चैनल नहीं बना सका।

हमारे मामले में, हम एक सॉफ़्टवेयर विक्रेता का उपयोग करते हैं, इसलिए हमारे पास .NET कोड को संशोधित करने के लिए पहुंच नहीं है। जाहिरा तौर पर .NET 4 टीएलएस 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
— capdragon
स्रोत
3
यहाँ त्वरित संपादन के लिए PS: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
— Tilo
2
यहाँ जल्दी edit2 के लिए PS: New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
— Tilo
4

इसे इस्तेमाल करे:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
— मुहम्मद आवा
स्रोत
मैंने इस पंक्ति को जोड़ा। कभी-कभी यह विफल हो जाता है और मुझे एक ही त्रुटि मिलती हैSystem.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
— जोसेफ काटज़मैन
4

मेरे लिए यह तय है, अनुमति के लिए नेटवर्क सेवा जोड़ें। प्रमाणपत्र पर राइट क्लिक करें> सभी कार्य> निजी कुंजी प्रबंधित करें ...> जोड़ें ...> "नेटवर्क सेवा जोड़ें"।

— jayasurya_j
स्रोत
3

मेरे लिए मुद्दा यह था कि मैं IIS पर एक वेब सेवा के रूप में तैनात करने की कोशिश कर रहा था, मैंने सर्वर पर प्रमाणपत्र स्थापित किया, लेकिन IIS चलाने वाले उपयोगकर्ता के पास प्रमाणपत्र पर सही अनुमतियाँ नहीं थीं।

सर्टिफिकेट स्टोर में ASP.NET को निजी कुंजी के लिए एक्सेस कैसे दिया जाए?

— डैनी कलन
स्रोत
हां, डिट्टो। इसे ठीक करने के लिए, मैंने निक गॉच के जवाब में कहा: लोकल सिस्टम में ऐप पूल की पहचान को बदल दिया। इससे मेरे लिए हल हो गया।
— यहूदा गैब्रियल हिमंगो
1
इसके लिए धन्यवाद
— डेनिस पिचर
3

मैं इसी मुद्दे पर चल रहा था और पाया कि यह जवाब मेरे लिए ठीक से काम करता है। कुंजी 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
— joeydood
स्रोत
3

इस सवाल के कई जवाब हो सकते हैं क्योंकि यह एक सामान्य त्रुटि संदेश के बारे में है। हम अपने कुछ सर्वरों पर इस मुद्दे में भागे, लेकिन हमारी विकास मशीनों में नहीं। हमारे अधिकांश बालों को बाहर निकालने के बाद, हमने पाया कि यह एक Microsoft बग था।

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

अनिवार्य रूप से, MS यह मानता है कि आप कमजोर एन्क्रिप्शन चाहते हैं, लेकिन OS को केवल TLS 1.2 की अनुमति देने के लिए पैच किया गया है, इसलिए आपको खतरनाक "अनुरोध निरस्त हो गया: SSL / TLS सुरक्षित चैनल नहीं बना सका।"

तीन फिक्स हैं।

1) उचित अद्यतन के साथ ओएस पैच: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) अपने app.config / web.config फ़ाइल में एक सेटिंग जोड़ें।

3) एक रजिस्ट्री सेटिंग जोड़ें जो पहले से ही दूसरे उत्तर में उल्लिखित थी।

इन सभी का उल्लेख मेरे द्वारा पोस्ट किए गए ज्ञानकोष लेख में किया गया है।

— माइकल सिल्वर
स्रोत
इसके अलावा, सुनिश्चित करें कि आप अपने ऐप में केवल एक बार ServicePointManager.SecurityProtocol सेट कर रहे हैं। हमने अपने ऐप में एक दूसरी कॉल की खोज की (जो रनटाइम में वैकल्पिक असेंबलियों को लोड करने के साथ जटिल है) जो इसे एसएसएल 3 पर सेट कर रही थी, जिसने फिर उसी त्रुटि संदेश को फेंक दिया।
— माइकल सिल्वर
3

एक और संभावना है कि निष्पादित किए जा रहे कोड में आवश्यक प्रीमियर नहीं हैं।

मेरे मामले में, मुझे यह त्रुटि तब मिली जब किसी वेब सेवा पर कॉल का परीक्षण करने के लिए Visual Studio डीबगर का उपयोग कर रहा था। विजुअल स्टूडियो प्रशासक के रूप में नहीं चल रहा था, जिसके कारण यह अपवाद था।

— नमस्कार जुड़
स्रोत
2

यह मेरे लिए सिर्फ एक साइट पर हो रहा था, और यह पता चला कि इसमें केवल RC4 सिफर उपलब्ध था। सर्वर को सख्त करने के पूर्व प्रयास में, मैंने RC4 सिफर को निष्क्रिय कर दिया था, एक बार जब मैंने इस समस्या को हल कर दिया, तो मैंने इसे फिर से सक्षम कर दिया।

— मार्क रीड
स्रोत
1
प्रतिक्रिया पर लिंक का उपयोग न करें, क्योंकि वे भविष्य में काम नहीं कर सकते हैं, अपने जवाब के अंदर उस पर सबसे अधिक प्रासंगिक पहलुओं को इंगित करें
— रोड्रिगो लोपेज
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.