IIS के साथ एक ही सर्वर पर SNI और वाइल्डकार्ड SSL प्रमाणपत्र

Question

मैं एक ऐसी वेबसाइट होस्ट करना चाहता हूं, जिसे आईआईएस और एसएसएल के साथ आईआईएस और एसएसएल के साथ एक दूसरे स्तर के डोमेन (जैसे domain2.com, domain3.com) के तहत आने वाली कई वेबसाइटों के साथ सबडोमेनस (जैसे सबडोमेन.कॉम) को सुनना चाहिए।

उप-डोमेन वाली वेबसाइट के लिए मेरे पास एक वाइल्डकार्ड प्रमाणपत्र (* .domain.com) है और मेरे पास विशेष रूप से अन्य साइटों (domain2.com और domain3.com) के लिए भी प्रमाण पत्र हैं।

क्या इस तरह के सेटअप को एक ही IIS (यदि वह मायने रखता है, एक Azure Cloud Service वेब भूमिका में) पर होस्ट किया जा सकता है?

मुद्दा बिल्कुल वैसा ही है जैसा कि टिटोबॉफ़ ने यहां बताया है : सैद्धांतिक रूप से इसके लिए हमें SNI का उपयोग करके बाइंडिंग की आवश्यकता होगी, साथ ही डोमेन 2 / 3.com के लिए निर्दिष्ट होस्ट और फिर * .domain.com के लिए * होस्ट के साथ कैच-ऑल वेबसाइट। लेकिन व्यवहार में कोई फर्क नहीं पड़ता कि कैसे बाइंडिंग स्थापित की जाती है अगर कैच-ऑल वेबसाइट इस पर है, तो उसे domain2 / 3.com पर भी सभी अनुरोध प्राप्त होंगे (हालांकि माना जाता है कि यह केवल अंतिम उपाय के रूप में मेल खाता है)।

किसी भी सहायता की सराहना की जाएगी।

अभी भी अनसुलझी है

दुर्भाग्य से मैं इसे हल करने में सक्षम नहीं था: यह केवल बेहद जटिल तरीकों से हल करने योग्य प्रतीत होता है, जैसे कि एक सॉफ्टवेयर बनाना जो IIS और इंटरनेट के बीच बैठता है (इसलिए मूल रूप से एक फ़ायरवॉल) और आने वाले अनुरोधों को संशोधित करता है (SSL हैंडशेक होने से पहले! ) परिदृश्य की अनुमति देने के लिए। मुझे पूरा विश्वास है कि यह IIS के साथ संभव नहीं है, चाहे जो भी हो, देशी मॉड्यूल से भी नहीं।

मुझे स्पष्ट करना होगा: हम Azure Cloud Services का उपयोग करते हैं, इसलिए हमारे पास एक और अड़चन है कि हम कई IP पते का उपयोग नहीं कर सकते हैं (देखें: http://feedback.azure.com/forums/169386-cloud-services-web-and -वर्क-रोल / सुझाव / 1259311-एकाधिक-एसएसएल और डोमेन-टू-वन-ऐप )। यदि आप अपने सर्वर पर कई आईपी को इंगित कर सकते हैं, तो आपके पास यह समस्या नहीं है क्योंकि आप आईपी के लिए भी बाइंडिंग बना सकते हैं, और वे वाइल्डकार्ड बाइंडिंग के साथ मिलकर काम करेंगे। अधिक विशेष रूप से, आपको वाइल्डकार्ड साइट के लिए एक आईपी की आवश्यकता होती है (लेकिन चूंकि आपके पास एक अलग आईपी है अब आपको वाइल्डकार्ड होस्ट नाम बाइंडिंग कॉन्फ़िगर नहीं करना होगा) और अन्य सभी गैर-वाइल्डकार्ड वाले लोगों के लिए एक और आईपी।

वास्तव में हमारा वर्कअन एक गैर-मानक एसएसएल पोर्ट, 8443 का उपयोग था। इसलिए एसएनआई बाइंडिंग वास्तव में इस पोर्ट के लिए बाध्य है, इस प्रकार यह अन्य बाइंडिंग के साथ काम करता है। अच्छा नहीं है, लेकिन हमारे लिए एक स्वीकार्य समाधान है जब तक आप वेब भूमिकाओं के लिए कई आईपी का उपयोग नहीं कर सकते।

अब काम न करने वाला बाँध

पहला https बाइंडिंग एक साधारण प्रमाणपत्र के साथ SNI है, दूसरा SNI नहीं है, जिसमें वाइल्डकार्ड प्रमाणपत्र है।

Http साइट काम करती है, साथ ही SNI https साइट, लेकिन वाइल्डकार्ड बाइंडिंग वाला "HTTP एरर 503 है। सेवा अनुपलब्ध है।" (बिना किसी अन्य जानकारी के, कोई असफल अनुरोध अनुरेखण या इवेंट लॉग प्रविष्टि)।

अंत में यह मूल रूप से काम कर रहा है

टोबियास की तरह ईटीडब्ल्यू ट्रेस लॉग को सक्षम करने से पता चलता है कि मूल त्रुटि निम्नलिखित थी:

अनुरोध (अनुरोध आईडी 0xF500000080000008) कारण के कारण अस्वीकार कर दिया गया: UrlGroupLookupFailed।

जहाँ तक मैं समझता हूँ कि इसका मतलब है कि http.sys किसी भी उपलब्ध समापन बिंदु के अनुरोध को रूट करने में सक्षम नहीं है।

पंजीकृत समापन बिंदुओं की जाँच से netsh http show urlaclपता चलता है कि पोर्ट 443 के लिए वास्तव में कुछ पंजीकृत था:

Reserved URL            : https://IP:443/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

इसे हटाने के साथ netsh http delete urlacl url=https://IP:443/अंत में मेरे एसएसएल बंधन को सक्षम किया गया।

Comments

आप बहुधा IP या गैर-मानक पोर्ट का सहारा लिए बिना, SNI का उपयोग करके IIS पर ऐसा करने में सक्षम होना चाहिए।

— जो स्नाइडरमैन

आपका मतलब है कि IIS को इसका समर्थन करना चाहिए? मैं सहमत हूँ :-)।

— 11

मैं आपसे पूरी तरह सहमत हूं, पिडोन। मैं वास्तव में निराश हूं कि IIS (या अधिक सटीक रूप से http.sys होने के लिए) एक डिफ़ॉल्ट SSL प्रमाणपत्र के रूप में वाइल्डकार्ड प्रमाणपत्र के संयोजन का समर्थन नहीं करता है और एसएनआई के साथ कई ठोस प्रमाण पत्र प्रस्तुत किए जाते हैं। समस्या 2012 से अच्छी तरह से जानी जाती है जैसा कि आप यहाँ देख सकते हैं: forum.iis.net/t/1192170.aspx । मैंने अभी Microsoft को एक ईमेल लिखा है और मुझे जल्द ही प्रतिक्रिया मिलने की उम्मीद है।

— टोबियास जे।

धन्यवाद टोबियास। Microsoft द्वारा उत्तर दिए जाने के बाद कृपया यहाँ वापस आएं।

— पिडोन

संभवतः http.sys अनुरोध को मना कर रहा है इसलिए IIS में कोई विफल अनुरोध लॉग नहीं किया गया है। Http.sys ETW ट्रेस लॉग बनाएं: 1) ट्रेस लॉग शुरू करें। रन: logman start httptrace -p Microsoft-Windows-HttpService 0xFFFF -o httptrace.etl -ets2) 503 रिक्वेस्ट 3) स्टॉप ट्रेस लॉग। रन: logman stop httptrace -ets4) फाइल में ट्रेस लॉग लिखें। रन: tracerpt.exe httptrace.etl -of XML -o httptrace.xml5) xml फ़ाइल में 503 के कारण की जाँच करें और इसे यहाँ पोस्ट करें।

— टोबियास जे।

Answer 1

बारिस सही है! एक IP पर SSL प्रमाणपत्र कॉन्फ़िगर किया गया: PORT बाइंडिंग (उदाहरण: 100.74.156.187:443) हमेशा http.sys में पूर्वता लेता है! तो समाधान इस प्रकार है:

अपने वाइल्डकार्ड-फ़ॉलबैक-सर्टिफ़िकेट के लिए एक IP: 443 बाइंडिंग को कॉन्फ़िगर न करें, लेकिन इसके लिए एक *: 443 बाइंडिंग (* "ऑल अनसाइनड") को कॉन्फ़िगर करें ।

यदि आपने अपने वाइल्डकार्ड प्रमाणपत्र को Azure Cloud Service SSL एंडपॉइंट (जैसा कि मेरे पास है) पर कॉन्फ़िगर किया है, तो आपको IP से Azure Cloud Service रनटाइम (IISconfigurator.exe) द्वारा बनाए गए SSL बाइंडिंग को बदलना होगा: PORT को * PORT। मैं अपनी वेब भूमिका के ऑनस्टार्ट में निम्न विधि को कॉल कर रहा हूं :

public static void UnbindDefaultSslBindingFromIp()
{
    Trace.TraceInformation(">> IISTenantManager: Unbind default SSL binding from IP");
    using (var serverManager = new Microsoft.Web.Administration.ServerManager())
    {
        try
        {
            var websiteName = string.Format("{0}_Web", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id);
            var site = serverManager.Sites[websiteName];
            var defaultSslBinding = site.Bindings.Single(b => b.IsIPPortHostBinding && b.Protocol == "https");
            defaultSslBinding.BindingInformation = string.Format("*:{0}:", defaultSslBinding.EndPoint.Port);
            serverManager.CommitChanges();
        }
        catch (Exception ex)
        {
            Trace.TraceError(ex.ToString());
        }
    }
}

निम्न स्क्रीनशॉट हमारी क्लाउड सेवा का एक कार्यशील विन्यास दिखाता है। कृपया गैर-मानक पोर्ट के बारे में भ्रमित न हों। स्क्रीनशॉट उत्सर्जित क्लाउड सेवा से है।

उल्लेख करने के लिए एक और बात: सभी बाइंडिंग को * में न बदलें क्योंकि HTTP (पोर्ट 80) बाइंडिंग केवल IP के साथ काम करता है: तैनात क्लाउड सेवा में बाध्यकारी। कुछ और IP से बाँध रहा है: 80 तो *: 80 काम नहीं करता है क्योंकि * का अर्थ है "सभी अप्रकाशित" और IP पहले से ही http.sys में कहीं और असाइन किया गया है।

Comments

आपके विस्तृत उत्तर के लिए धन्यवाद। मैंने अपना प्रश्न अपडेट किया: जैसा कि मुझे याद है अब मैं शायद इस सेटअप के साथ नहीं गया था क्योंकि मुझे अब भी वही त्रुटि मिली है।

— 23

Answer 2

सुनिश्चित करें कि आपका कैच-ऑल बाइंडिंग प्रकार का नहीं है आईपी: पोर्ट। जब IP: पोर्ट बाइंडिंग HTTPS बाइंडिंग के लिए मौजूद होता है जबकि SNI की आवश्यकता नहीं होती है, तो वह बाइंडिंग हमेशा पूर्वता लेगा। अपने कैच-ऑल केस के लिए, एक *: पोर्ट बाइंडिंग (* सभी असंबद्ध होने के नाते) का उपयोग करें।

Comments

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

— पिडोन

पोर्ट करके, मैं इसे लेता हूं कि आप आईपी का मतलब है। आप एक बंदरगाह के बिना एक बंधन नहीं हो सकता। Inetmgr इसे अनुमति नहीं देगा। एसएनआई बाइंडिंग के लिए आप विशिष्ट आईपी या "ऑल अनसाइनड" का उपयोग कर सकते हैं और परिणाम समान होगा। यह कैच ऑल बाइंडिंग है, जिसके लिए आपके पास वाइल्डकार्ड प्रमाणपत्र है, जिसे "ऑल अनसाइनड" पर होना चाहिए न कि किसी विशिष्ट आईपी पर।

— बारिसगलार

मेरा मतलब बंदरगाह था लेकिन मैं "गैर-मानक बंदरगाह" कहना चाहता था। आईपी ​​निर्दिष्ट नहीं किया गया था, जैसा कि आप कहते हैं और यह अभी भी काम नहीं करता है, टोबियास के लिंक को भी देखें। IIS की इस सीमा के आसपास काम करने के दो तरीके हैं: एक कस्टम पोर्ट या अन्य बाइंडिंग की तुलना में अलग IP का उपयोग करें: Azure क्लाउड सेवाओं पर उत्तरार्द्ध उपलब्ध नहीं है इसलिए हम कस्टम पोर्ट के साथ गए हैं।

— पिडोन

bariscaglar Microsoft डेवलपर (IIS पर काम कर रहा है) के साथ मेरी बहुत अच्छी और उपयोगी बातचीत हुई! Thx बारिस! साथ में हमने व्यवहार का विश्लेषण किया और हम इस निष्कर्ष पर पहुंचे, कि वर्णित व्यवहार http.sys का वांछित व्यवहार है। लेकिन एक अच्छा वर्कअराउंड है। विवरण के लिए मेरा उत्तर देखें।

— टोबियास जे।

किसी को भी पढ़ने के लिए सिर्फ एक नोट, मैंने हाल ही में पता लगाया है कि यदि आप दूरस्थ डेस्कटॉप के लिए किसी सेवा को कॉन्फ़िगर करने के लिए एज़्योर पोर्टल का उपयोग करते हैं (या अन्यथा प्रमाणित कॉन्फ़िगरेशन को बदलते हैं) तो यह एक आईपी का कारण बन सकता है: पोर्ट बाइंडिंग स्वचालित रूप से बनाई जा सकती है और आपके सभी एसएनआई को तोड़ सकती है। । मेरे पास उस विशेष मुद्दे का हल नहीं है। यह RoleEnvironment.Changed के बाद होता है इसलिए मैं इसे WebRole.cs में नहीं पकड़ सकता।

— माइक

Answer 3

IIS एसएनआई का समर्थन करता है, यहां तक ​​कि एज़्योर क्लाउड सेवा वेब भूमिकाओं में भी, हालांकि आप पोर्टल के माध्यम से कॉन्फ़िगर नहीं कर सकते हैं और यदि आप इसे तैनाती के बाद बॉक्स पर करते हैं, तो यह आपकी अगली तैनाती के साथ मिटा दिया जाएगा। इसका उपाय यह है कि आप विन्यास को स्वचालित करें। विवरण के लिए यहां एक नज़र डालें:

http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/

Comments

धन्यवाद, लेकिन जैसा कि मैंने समझाया कि एसएनआई के साथ कोई समस्या नहीं है (मैं इसका उपयोग कर रहा हूं) लेकिन इसके बजाय कैसे वाइल्डकार्ड होस्ट नाम मिलान आईआईएस में काम करता है।

— Piedone

यह लेख अब मौजूद नहीं है, लेकिन यहां यह वेब आर्काइव पर है: web.archive.org/web/20151020041907/http://www.vic.ms/microsoft/…

— माइक