विंडो के SSL सिफर-सुइट को कुछ SSL प्रमाणपत्रों के तहत प्रतिबंधित क्यों किया जाता है?

Question

समस्या: Windows Server 2008 R2 सर्वर पर कुछ प्रमाणपत्रों का उपयोग करते समय केवल ssl सिफर सुइट्स का समर्थन करेगा:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

यह XP क्लाइंट को सर्वर से कनेक्ट होने से रोकता है क्योंकि डिफ़ॉल्ट रूप से XP क्रिप्टोग्राफिक एपीआई किसी भी एईएस सिफर का समर्थन नहीं करता है।
परिणामस्वरूप, इंटरनेट एक्सप्लोरर या रिमोट डेस्कटॉप का उपयोग करके कनेक्ट करने का प्रयास करते समय सर्वर लॉग में निम्न त्रुटियां दिखाई देती हैं। (चूंकि वे माइक्रोसॉफ्ट के CAPI का उपयोग करते हैं)

Schannel त्रुटि 36874 "एक TLS 1.0 कनेक्शन दूरस्थ क्लाइंट अनुप्रयोग से प्राप्त किया गया था, लेकिन क्लाइंट द्वारा समर्थित सिफर सुइट्स का डोडेन सर्वर द्वारा समर्थित है। SSL कनेक्शन अनुरोध विफल हो गया है।"
Schannel त्रुटि 36888 "निम्नलिखित घातक चेतावनी उत्पन्न की गई थी: 40. आंतरिक त्रुटि स्थिति 1204 है"

Comments

गैरी, यदि आपने अपना प्रश्न हल किया है तो कृपया उसे उत्तर के रूप में चिह्नित करें।

— बर्नी व्हाइट

Answer 1

यदि सर्टिफिकेट रिक्वेस्ट फॉर्म में लिगेसी की ऑप्शन का उपयोग करके सर्वर पर सर्टिफिकेट का उपयोग किया जा रहा है, तो उस सर्टिफिकेट की निजी कुंजी को माइक्रोसॉफ्ट की विरासत क्रिप्टोग्राफिक एपीआई फ्रेमवर्क में स्टोर किया जाएगा। जब वेब सर्वर अपने नए, क्रिप्टोग्राफिक नेक्स्ट जनरेशन (CNG) फ्रेमवर्क का उपयोग करके अनुरोधों को संसाधित करने का प्रयास करता है, तो ऐसा प्रतीत होता है कि विरासत ढांचे में संग्रहीत RSA निजी कुंजी से संबंधित कुछ भी नए ढांचे के लिए अनुपलब्ध है। नतीजतन, आरएसए सिफर सुइट्स का उपयोग गंभीर रूप से सीमित है।

समाधान:
कस्टम प्रमाणपत्र अनुरोध विज़ार्ड में CNG कुंजी टेम्प्लेट का उपयोग करके प्रमाणपत्र अनुरोध उत्पन्न करें।

एमएमसी | स्थानीय कंप्यूटर प्रमाणपत्र प्रबंधक | व्यक्तिगत प्रमाण पत्र फ़ोल्डर | (राइट क्लिक) | सभी कार्य -> ​​उन्नत संचालन | कस्टम अनुरोध बनाएँ | "नामांकन नीति के बिना आगे बढ़ें" | "(कोई टेम्पलेट नहीं) सीएनजी कुंजी का चयन करें" | अपनी आवश्यकताओं के अनुसार प्रमाणपत्र अनुरोध को पूरा करने के लिए आगे बढ़ें।

सत्यापित करना कि कुंजी सही जगह पर है:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

सही सिफर-सूट को सत्यापित करने के लिए उपकरण:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

एसएसएल सिफर-सूट सेटिंग्स:
http://support.microsoft.com/kb/245030
http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order -इन-इंटरनेट-एक्सप्लोरर-7-ऑन-windows-vista.aspx

हमें यह पता लगाने में एक सप्ताह का समय लगा। मुझे उम्मीद है कि यह किसी को एक ही मुसीबत बचाता है।

Comments

किसी को पता है कि यह कैसे करना है - या अन्यथा समस्या को हल करें - स्व-हस्ताक्षरित प्रमाण पत्र के लिए।

— MGOwen

अपने काम के लिए और अपने परिणामों को साझा करने के लिए बहुत बहुत धन्यवाद! हमने एक Microsoft समर्थन मामला खोला और Microsoft स्वयं यह पता लगाने में सक्षम नहीं था कि कुछ ग्राहक कनेक्ट क्यों नहीं कर पाए। आपके द्वारा बताए अनुसार हमारे पास समस्या है। लेकिन Technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx के अनुसार Microsoft सर्वश्रेष्ठ संगतता संग्रह करने के लिए विरासत कुंजी टेम्पलेट का उपयोग करने की अनुशंसा करता है! अच्छा कार्य!

Answer 2

अपने आप को इस मुद्दे को सटीक रूप से समझें और इस पोस्ट ने मुझे एक टन समय बचाया इसलिए सभी को धन्यवाद!

गैरी का समाधान हाजिर है, लेकिन मैं पीएफएक्स को पीईएम में परिवर्तित करके और फिर पीएफएक्स पर फिर से ओपनसेल का उपयोग करके समस्या को हल करने में कामयाब रहा। नए पीएफएक्स ने आईआईएस में प्रमाण पत्र को केवल इस अंतर के साथ आयात किया कि मैं लापता सिफर देख सकता हूं।

इस तरह से:

openssl pkcs12 -in mycert.pfx -out mycert.cer -nodes

फिर सेर फ़ाइल को तीन में विभाजित करें, कुंजी, प्रमाणपत्र और मध्यवर्ती प्रमाणपत्र [s]

openssl pkcs12 -export -out mycert-new.pfx -inkey mycert.key \
-in mycert.crt -certfile mycert-intermediate.crt

फिर यदि आप IIS में नई .pfx फ़ाइल आयात करते हैं तो यह उन सभी सिफर का उपयोग करेगा, जिन्हें आप देखने की उम्मीद करते हैं।

इसलिए प्रमाणपत्र को फिर से जारी करने की आवश्यकता नहीं है।

Comments

यह मेरे लिए इसी तरह की स्थिति में काम करता है, लेकिन इसके विपरीत नरम, मूल प्रश्न: विंडोज सर्वर 2012 R2 पर विज्ञापन FS भूमिका आपको सर्टिफिकेट अनुरोध के लिए लिगेसी एपीआई का उपयोग करने की आवश्यकता है - लेकिन फिर यह केवल 2 एईएस सिफर दिखाता है ऊपर दिखाए गए! निर्यात करना, ओपनएसएसएल के साथ कुंजी को फिर से भरना, और फिर से आयात करना इसे एक ही हल करता है - अन्य प्रोटोकॉल अचानक काम करना शुरू कर देते हैं। शुक्रिया, @gelilloadbad!

— इवॉल्व

Answer 3

धन्यवाद, आपकी पोस्ट ने मेरी मदद की, हालाँकि मेरी समस्या बिलकुल नहीं थी।

हालांकि, इसका कारण मेरे हिस्से पर एक WinHTTP सर्वर एपीआई कॉन्फ़िगरेशन गलती थी। मेरा IP बदल गया, और जब मैंने "MY" मशीन में एक नया सर्वर प्रमाणपत्र डाला, तो मैंने HttpSetServiceConfiguration के लिए ALREADY_EXISTS रिटर्न कोड को अनदेखा कर दिया।

इसलिए मैंने पिछले सर्वर टीएलएस प्रमाणपत्र का उपयोग किया, जिसमें गलत नाम था और मेरे नए सर्वर नाम से मेल नहीं खाता था।

यदि आप HttpDeleteServiceConfiguration () या कमांड लाइन "netsh http डिलीट sslcert 0.0.0.0:8443" सही ढंग से नहीं करते हैं, तो आपको इन लक्षणों के साथ एक बुरा त्रुटि मिलेगी:

1) टीएलएस में, आपके क्लाइंट हैलो को तुरंत अपने सर्वर से टीसीपी पैकेट के साथ एके और रीसेट फ्लैग बिट्स सेट के साथ मिलना है। (एक हाथ मिलाने की विफलता चेतावनी, मुझे लगता है?)

2) इवेंट व्यूअर को "निम्न घातक चेतावनी उत्पन्न हुई: 40। आंतरिक त्रुटि स्थिति 107 है।"

"SSL 3.0 कनेक्शन अनुरोध दूरस्थ क्लाइंट अनुप्रयोग से प्राप्त किया गया था, लेकिन क्लाइंट अनुप्रयोग द्वारा समर्थित कोई भी सिफर सर्वर द्वारा नहीं दिया गया है। SSL कनेक्शन अनुरोध विफल हो गया है।"

इसलिए इससे पहले कि आप एक सिफर सूट बेमेल का पीछा करते हैं, यह सुनिश्चित करें कि आप वास्तव में उस सर्वर प्रमाणपत्र का उपयोग कर रहे हैं जिसे आप उपयोग करना चाहते हैं:

         netsh http show sslcert

और हैश मूल्यों की जाँच करें!

Comments

यह उत्तर बहुत अस्पष्ट है और इससे कोई मतलब नहीं है। आपको सीधे जवाब देने का लक्ष्य रखना चाहिए "विंडो का एसएसएल सिफर-सूट कुछ एसएसएल प्रमाणपत्रों के तहत प्रतिबंधित क्यों है?" और स्कैनेल त्रुटि की व्याख्या के साथ पालन करें।

— बर्नी व्हाइट

Answer 4

यह KeySpec = 2 - AT_SIGNATURE समस्या हो सकती है

Certutil -verifystore -v मेरा "प्रमाण की थम्बप्रिंट" KeySpec मान को सत्यापित करने के लिए। अगर इसके 2 आपको सर्टिफिकेट को PFX फाइल के रूप में एक्सपोर्ट करना होगा और फिर इसे ठीक करने के लिए certutil -importpfx AT_KEYEXCHANGE चलाएं।

Comments

मेरे मामले में भी यही मुद्दा था। वास्तव में, यह उत्तर एकमात्र है जो वास्तव में कारण को इंगित करने का प्रयास करता है। हालांकि, यह उत्तर एक स्पष्टीकरण से लाभान्वित करेगा कि AT_SIGNATURE गैर-ECDHE सिफर सुइट्स के लिए पर्याप्त क्यों नहीं है - क्योंकि ऐसे सुइट्स के लिए RSA का उपयोग केवल प्रमाणीकरण (हस्ताक्षर) के लिए ही नहीं किया जाता है, बल्कि कुंजी विनिमय के लिए भी किया जाता है।

— जैकब बेरेज़ांस्की