WCF त्रुटि "यह इस तथ्य के कारण हो सकता है कि HTTPS मामले में HTTP.SYS के साथ सर्वर प्रमाणपत्र ठीक से कॉन्फ़िगर नहीं किया गया है"

Question 1

मुझे अपने वेब सर्वर पर चलने वाली मेरी WCF सेवा के लिए Windows सेवा से WCF कॉल का उपयोग करने में समस्या हो रही है। यह कॉल कई हफ्तों से काम कर रही है, लेकिन फिर अचानक काम करना बंद कर दिया, और तब से काम नहीं किया है।

मुझे जो अपवाद मिल रहा है, वह है:

सामान्य त्रुटि हुई System.ServiceModel.CommunicationException: HTTP अनुरोध करते समय कोई त्रुटि उत्पन्न हुई

और फिर यह कहता है

यह इस तथ्य के कारण हो सकता है कि HTTPS मामले में HTTP.SYS के साथ सर्वर प्रमाणपत्र ठीक से कॉन्फ़िगर नहीं किया गया है। यह क्लाइंट और सर्वर के बीच सुरक्षा बंधन के बेमेल के कारण भी हो सकता है।

किसी भी तरह के एन्क्रिप्शन के बिना, दोनों सिरों पर मैं जो सुरक्षा का उपयोग कर रहा हूं वह wsHttpBinding है। यह सिर्फ HTTP का उपयोग कर रहा है - HTTPS का नहीं, इसलिए मुझे यकीन नहीं है कि यह HTTPS के बारे में शिकायत क्यों कर रहा है।

बाकी आंतरिक अपवाद स्टैक है:

SystemNet.WebException: अंतर्निहित कनेक्शन को बंद कर दिया गया था: एक अनपेक्षित त्रुटि एक भेजने पर हुई। ---> System.IO.IOException: ट्रांसपोर्ट कनेक्शन में डेटा लिखने में असमर्थ: एक अमान्य तर्क की आपूर्ति की गई थी। --- - System.Net.Sockets.SocketException: System.Net.Sockets.Socket.Socket.MultipleSend (BufferOffsetSize [] बफ़र्स, System.Net.Sockets.NetworkStream.MultipleWrite (BufferOffsetSize []] में एक अमान्य तर्क की आपूर्ति की गई थी। बफ़र)

मुझे यह भी ध्यान देना चाहिए कि मेरे कार्यक्रम में यह बिंदु जहां यह होता है, वेब सेवा के लिए कॉल की "निष्पादित" पंक्ति पर है - अर्थात, जैसे ही मैं वेब सेवा को कॉल करता हूं और इसे लपेटता हूं डेटाकोन्ट्रेक्ट ऑब्जेक्ट को पास करता हूं, यह फटना।

यह सब सेवा जो कर रही है वह बड़ी मात्रा में एक्सएमएल (ग्राहक पक्ष पर कॉल के लिए एक .NET ऑब्जेक्ट के रूप में पारित) हो रही है, जिसके साथ यह कुछ काम करता है। संभवतः XML के लगभग 100-200k को प्रसारित किया जा रहा है। मैंने दोनों साइज़ के डेटा साइज़ की सीमाएँ 6 से अधिक मीज़ों तक बढ़ा दी हैं, लेकिन इससे कोई मदद नहीं मिली।

कोई विचार?

इस मुद्दे पर कुछ और जानकारी:

जब हम क्लाइंट वातावरण को स्थानीय रूप से डुप्लिकेट करते हैं, तो हम पाते हैं कि हम बड़ी मात्रा में XML अपलोड नहीं कर सकते हैं जब तक कि हम निम्नलिखित बदलाव नहीं करते हैं: 1. सर्वर पर, "maxRequestLength" को 100 एमबी (जिस तरह से हम भेज रहे हैं उससे अधिक) सेट करें। 2. पर क्लाइंट, हमने डेटा कॉंट्रेक्टसियराइज़र टैग के तहत maxItemsInObjectGraph का मान "2147483646" पर सेट किया है।

इन परिवर्तनों के साथ, हमारी स्थानीय स्थापना सफलतापूर्वक अपलोड होती है। हालाँकि, क्लाइंट का उनके सर्वर पर स्थापित अभी भी विफल रहता है। ध्यान देने वाली बात यह है कि एक बार जब हमने सर्वर पर मैक्सिमम लाइस्ट वैल्यू में बदलाव किया, तो हमारे टेस्ट इंस्टॉलेशन ने विशेष रूप से maxItemsInObjectGraph सेटिंग से संबंधित एक एरर फेंकना शुरू कर दिया। जबकि हमारे ग्राहक के सर्वर पर, अभी भी मूल "HTTP.sys" त्रुटि हो रही है।

जैसा कि मैंने पहले उल्लेख किया है, हम एसएसएल का उपयोग नहीं कर रहे हैं, और 2 अन्य वेब सेवाएं कॉल हैं जो एक्सएमएल को उसी तरह निष्पादित और अपलोड करती हैं। हालाँकि, चूंकि गैर-कार्यशील सेवा कॉल अधिक डेटा प्रसारित करती है, इसलिए यह एक आकार का मुद्दा प्रतीत होता है।

हालाँकि, अगर समस्या ग्राहक की वही थी जो हमारे परीक्षण स्थापित की थी, तो मुझे नहीं मिलता कि क्लाइंट त्रुटि संदेश ऑब्जेक्टग्राफ त्रुटि से संबंधित क्यों नहीं होगा।

क्या यह संभव है कि हम क्लाइंट पर हर संभावित त्रुटि के लिए सामान्य "अवैध पैरामीटर" "HTTP.sys" त्रुटि प्राप्त कर रहे हैं (यानी यह वास्तव में ऑब्जेक्टग्राफ त्रुटि भी हो रही है, लेकिन अभी यह नहीं दिखा रहा है?)

Question 2

हमारे पास यह समस्या थी क्योंकि होस्ट सर्वर को TLS V1.2 का उपयोग करने के लिए अद्यतन किया गया था और हम मानक SSL का उपयोग करके कनेक्ट कर रहे थे। यह साइटों के पेन परीक्षण के भाग के रूप में किया गया अपडेट था। हमने इस मुद्दे को कोड कनेक्शन में देखा, लेकिन ब्राउज़रों पर नहीं जा रहा है। नीचे दिए गए कोड हल:

if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
    System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

यहाँ से लिया गया: मैं SSL फ़ॉलबैक को कैसे निष्क्रिय कर सकता हूँ और .NET में आउटबाउंड कनेक्शन के लिए केवल TLS का उपयोग करता हूँ? (पूडल शमन)

Question 3

आईआईएस 7 पर चलने वाली सेवा पर भी यही मुद्दा था, इनमें से एक नया जोड़ने पर यह सेवा कई आपूर्तिकर्ताओं सर्वरों (कुछ एसएसएल कुछ नहीं) से जुड़ती है (यह नया आपूर्तिकर्ता टीएलएस 1.2 था) मुझे कुछ अनुरोधों के बाद त्रुटि मिलेगी मूल सर्वर (एसएसएल) से बना है।

इसकी पुष्टि करने के लिए मैंने बस System.Net.ServicePointManager.SecurityProtocolप्रत्येक आपूर्तिकर्ता से प्रत्येक अनुरोध से पहले लॉग इन किया ।

सेवा को पुनरारंभ करने के बाद कम और निहारना (या एप्लिकेशन पूल को पुनरारंभ करना) मुझे आउटपुट मिलेगा Ssl3, Tlsलेकिन मूल आपूर्तिकर्ता सर्वरों के कुछ अनुरोधों के बाद यह बदल गया Ssl3और टीएलएस सेवा के अनुरोधों ने त्रुटि दी।

ठीक करने के लिए मैंने बस वही किया जो user369142 ने सुझाया था। नए सर्वर के लिए प्रत्येक अनुरोध से पहले:

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

और कोई त्रुटि नहीं।

Question 4

इस मुद्दे को एक सच्चे HTTPS बाइंडिंग के साथ और "अपवाद यह इस तथ्य के कारण हो सकता है कि सर्वर प्रमाणपत्र HTTPS मामले में HTTP.SYS के साथ ठीक से कॉन्फ़िगर नहीं किया गया है ..."। कोड और कॉन्फिग्रेशन में सब कुछ डबल चेक करने के बाद, ऐसा लगता है कि त्रुटि संदेश आंतरिक अपवाद के रूप में इतना भ्रामक नहीं है, इसलिए एक त्वरित जांच के बाद हमें पता चला है कि पोर्ट 443 स्काइप (देव सर्वर पर) द्वारा हुक किया गया था। मैं आपको अनुरोध पर ध्यान देने की सलाह देता हूं (फ़िडलर यहां मदद कर सकता है) और सुनिश्चित करें कि आप सेवा तक पहुंच सकते हैं (अपने ब्राउज़र में .svc देखें) और इसके मेटाडेटा।

सौभाग्य।

Question 5

मेरे मामले में मुझे SchUseStrongCrypto.Net के लिए सक्षम होना चाहिए । यह सर्वर को टीएलएस 1.0, 1.1 या 1.2 का उपयोग करके संबंध बनाने के लिए मजबूर करता है। SchUseStrongCryptoसक्षम किए बिना कनेक्शन एसएसएल 3.0 का उपयोग करने की कोशिश कर रहा था, जो मेरे दूरस्थ समापन बिंदु पर अक्षम था।

मजबूत क्रिप्टो के उपयोग को सक्षम करने के लिए रजिस्ट्री कुंजी:

[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

Question 6

हमारे लिए, यह त्रुटि थी क्योंकि सेवा चलाने वाले डेवलपर के कंप्यूटर ने IIS को केवल 127.0.0.1 पर पोर्ट 443 को बाइंड करने के लिए कॉन्फ़िगर किया था।

IIS प्रबंधक में, वेब साइट पर राइट-क्लिक करें और संपादन बाइंडिंग चुनें। यदि पोर्ट के लिए प्रविष्टि 443में IP पता है 127.0.0.1, तो उसे बदल दें *।

Question 7

बहुत सारी खोज करने के बाद और अंतत: प्रभु का नाम लेने के बाद मैंने इसे प्राप्त कर लिया। मैंने सर्वर पर TLS 1.2 स्थापित किया है जहां मेरी wcf सेवा चल रही है। मेरा क्लाइंट सही ढंग से कॉन्फ़िगर किया गया था, लेकिन इसे .NET 4.5.1 पर बनाया गया था जबकि wcf .NET 4.6.1 पर था। यदि आप TLS 1.2 का उपयोग कर रहे हैं तो क्लाइंट और सर्वर दोनों एक ही .NET संस्करण में होने चाहिए। मुझे आशा है कि यह किसी दिन मदद करता है :-)

Question 8

अपने क्लाइंट एप्लिकेशन को 4.5 और ऊपर बदलें। यदि आप 4.5 हैं तो उपयोग करें: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 आवश्यकतानुसार या आप अपने आवेदन को 4.6.1 से ऊपर में अपग्रेड कर सकते हैं।

Question 9

हमारे पास हाल ही में लगभग यही समस्या थी और यह कॉलिंग कंप्यूटर पर स्थापित Microsoft अद्यतन KB980436 ( http://support.microsoft.com/KB/980436 ) के कारण हुआ। हमारे लिए यह ठीक है, इसे अनइंस्टॉल करने से इतर, रजिस्ट्री में UseScsvForTls DWORD को 1 पर सेट करने के लिए KB साइट पर दिए गए निर्देशों का पालन करना था। यदि आप देखते हैं कि यह अपडेट आपके कॉलिंग सिस्टम में स्थापित है, तो आप इसे शॉट देना चाह सकते हैं। ।

Question 10

मेरे पास यह मुद्दा था जब अमेज़ॅन AWS पर IIS और ग्लासफ़िश दोनों के खिलाफ पुराने XP SP3 बॉक्स चल रहे थे। Amazon ने DES-CBC3-SHA साइफर को सक्षम नहीं करने के लिए अपनी डिफ़ॉल्ट लोड बैलेंसर सेटिंग्स को बदल दिया। आपको सक्षम करना होगा कि यदि आप पुराने XP TLS 1.0 को HTTPS के विरुद्ध काम करने की अनुमति देना चाहते हैं, तो amazon ELB पर अन्यथा आपको यह त्रुटि मिलती है। कंसोल में श्रोता टैब पर जाकर और विशेष रूप से जिस श्रोता को आप काम करने का प्रयास कर रहे हैं उसके बगल में सिफर पर क्लिक करके साइबर्स को ELB पर बदला जा सकता है।

Question 11

यदि आपकी WCF सेवा .net फ्रेमवर्क 4.0 का उपयोग कर रही है और किसी ने सर्वर पर TLS 1.0 को निष्क्रिय कर दिया है, तो आपको यह अपवाद दिखाई देगा। .Net 4.0 के कारण TLS के उच्च संस्करणों का समर्थन नहीं करता है।

समर्थित प्रोटोकॉल: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx

Question 12

मैंने कॉम्प्लेक्स डेटा टाइप समस्याओं से संबंधित इन विशेष अपवादों को देखा है, यदि आप संग्रह या एनम के आसपास से गुजर रहे हैं तो निम्न पोस्ट देखें:

जटिल डेटा प्रकार

Question 13

यदि आप स्थानांतरण मोड = स्ट्रीम का उपयोग कर रहे हैं, तो इसे बफ़र्ड में बदलने का प्रयास करें।

यदि यह समस्या नहीं है तो आप अपना कॉन्फ़िगरेशन पोस्ट कर सकते हैं।

Question 14

चूँकि सब कुछ हफ्तों तक ठीक काम कर रहा था, इसलिए रुक गया, मुझे संदेह है कि इसका आपके कोड से कोई लेना-देना नहीं है। शायद यह त्रुटि तब हो रही है जब सेवा सक्रिय है आईआईएस / ASP.NET के भीतर जाती है, तब नहीं जब आपका कोड कहा जाता है। रनटाइम सिर्फ वेब साइट के कॉन्फ़िगरेशन की जाँच कर सकता है और एक सामान्य त्रुटि संदेश फेंक सकता है जिसका सेवा से कोई लेना-देना नहीं है।

मेरा संदेह यह है कि एक प्रमाण पत्र की अवधि समाप्त हो गई है या कि बाइंडिंग गलत तरीके से स्थापित की गई है। यदि HTTPS के लिए वेब साइट गलत तरीके से कॉन्फ़िगर की गई है, तो आपका कोड उनका उपयोग करता है या नहीं, आपको यह त्रुटि मिल सकती है।

Question 15

ब्राउज़र और Https मोड में सेवा को ब्राउज़ करने का प्रयास करें, अगर यह ब्रो-सेबल नहीं है तो यह इस त्रुटि का कारण साबित होता है। अब, इस त्रुटि को हल करने के लिए आपको जाँच करने की आवश्यकता है:

https पोर्ट, जांचें कि क्या यह कुछ अन्य संसाधनों (वेबसाइट) द्वारा उपयोग नहीं किया जा रहा है
जांचें कि क्या https के लिए प्रमाणपत्र ठीक से कॉन्फ़िगर किया गया है या नहीं (कई प्रमाणपत्र का उपयोग करके, प्राधिकारी, स्वयं हस्ताक्षरित प्रमाण पत्र पर हस्ताक्षर करें)
WCF सेवा बाध्यकारी और Https मोड के लिए कॉन्फ़िगरेशन की जाँच करें

Question 16

हमारा मुद्दा बस एंडपॉइंट पर पोर्ट नंबर गलत तरीके से 8080 पर सेट किया गया था। इसे 8443 में बदल दिया और यह काम कर गया।

Question 17

सुरक्षा प्रोटोकॉल को स्पष्ट रूप से सेट करने के बजाय, web.config <संकलन लक्ष्यफ़्रेमवर्क = "4.5"> या उच्चतर सेट करने का एक बेहतर तरीका है।

Question 18

मैंने अपने .NetFramework संस्करण को 4.5.2 से 4.7.2 तक अपग्रेड करके अपनी समस्या हल की।

Question 19

अभी हाल ही में यह अनुभव किया:

System.ServiceModel.CommunicationException:

Http://example.com/WebServices/SomeService.svc पर HTTP अनुरोध करने के दौरान एक त्रुटि हुई । यह इस तथ्य के कारण हो सकता है कि HTTPS मामले में HTTP.SYS के साथ सर्वर प्रमाणपत्र ठीक से कॉन्फ़िगर नहीं किया गया है। यह क्लाइंट और सर्वर के बीच सुरक्षा बंधन के बेमेल के कारण भी हो सकता है।

---> System.Net.WebException: अंतर्निहित कनेक्शन बंद कर दिया गया था: एक अनपेक्षित त्रुटि एक भेजने पर हुई।

---> System.IO.IOException: ट्रांसपोर्ट कनेक्शन के लिए डेटा लिखने में असमर्थ: एक मौजूदा कनेक्शन को रिमोट होस्ट द्वारा जबरन बंद कर दिया गया था।

मुझे एक व्यवस्थापक से पता चला कि IIS एप्लिकेशन पूल जो वेब सेवा की मेजबानी कर रहा था, मेमोरी से बाहर निकलने के बाद स्वचालित रूप से पुनर्नवीनीकरण किया गया। क्लाइंट पर त्रुटि तब हुई जब एप्लिकेशन पूल पुनर्नवीनीकरण किया गया।

एप्लिकेशन पूल में उपलब्ध मेमोरी को बढ़ाकर तत्काल समस्या का समाधान किया गया।

Question 20

हमारे एप्लिकेशन को हाल ही में एक नेटवर्क उपकरण (F5) ओएस अपडेट के माध्यम से एसएसएल से टीएलएस के लिए मजबूर किया गया था। हमने स्व-हस्ताक्षरित सीट्स को री-जनरेट करके इस त्रुटि को ठीक किया। आशा है कि यह भविष्य में किसी को समस्या को हल करने में मदद करता है क्योंकि हमने समाधान पर पहुंचने से पहले कई रखरखाव विंडो को समस्याग्रस्त किया।

Question 21

अभी हाल ही में यह अनुभव किया:

System.ServiceModel.CommunicationException:

Http://example.com/WebServices/SomeService.svc पर HTTP अनुरोध करने के दौरान एक त्रुटि हुई । यह इस तथ्य के कारण हो सकता है कि HTTPS मामले में HTTP.SYS के साथ सर्वर प्रमाणपत्र ठीक से कॉन्फ़िगर नहीं किया गया है। यह क्लाइंट और सर्वर के बीच सुरक्षा बंधन के बेमेल के कारण भी हो सकता है।

---> System.Net.WebException: अंतर्निहित कनेक्शन बंद कर दिया गया था: एक अनपेक्षित त्रुटि एक भेजने पर हुई।

---> System.IO.IOException: ट्रांसपोर्ट कनेक्शन के लिए डेटा लिखने में असमर्थ: एक मौजूदा कनेक्शन को रिमोट होस्ट द्वारा जबरन बंद कर दिया गया था।

ब्लूकैट प्रॉक्सी का हमारा लाइसेंस समाप्त हो गया था! इसलिए बाहरी पार्टी (इंटरनेट) तक पहुंचना संभव नहीं था।

Question 22

हमारे पास एक ही मुद्दा था और हमारे मामले में, प्रमाणपत्र को फिर से स्थापित करके और फिर से बाध्यकारी बनाकर इसे हल किया गया था। हमारे नेतृत्व में क्या तथ्य था कि साइट पर एक साधारण png छवि फ़ाइल प्राप्त करना भी वही त्रुटि देता है।