सवाल एक ही आईपी पते और एक ही बंदरगाह पर एकाधिक एसएसएल डोमेन?


यह है एक कैननिकल प्रश्न एक ही आईपी पर एकाधिक एसएसएल वेबसाइटों को होस्ट करने के बारे में।

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

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

मुझे संदेह है कि मैंने कुछ गलत किया। क्या कई एसएसएल प्रमाण पत्र इस तरह इस्तेमाल किए जा सकते हैं?


107
2018-02-04 22:36


मूल


यह क्यू शरीर कई कर्टों का कहना है और इसके लिए उत्तर सही हैं। लेकिन शीर्षक कई डोमेन और आप कहते हैं एक प्रमाण के साथ एकाधिक डोमेन हो सकता है (और कोई एसएनआई नहीं), देखें serverfault.com/questions/126072/... तथा serverfault.com/questions/279722/... सुरक्षा पर भी पार करें। एसएक्स। - dave_thompson_085


जवाब:


अतिरिक्त HTTP-विशिष्ट आरएफसी समेत अपाचे और एसएनआई पर सबसे अद्यतित जानकारी के लिए, कृपया देखें अपाचे विकी


एफवाईएसआई: "एक आईपी पर एकाधिक (अलग) एसएसएल प्रमाण पत्र" टीएलएस अपग्रेडिंग के जादू से आपको लाया जाता है। यह नए अपाचे सर्वर (2.2.x) और उचित रूप से हालिया ब्राउज़र (मेरे सिर के शीर्ष से संस्करणों को नहीं जानता) के साथ काम करता है।

आरएफसी 2817 (HTTP / 1.1 के भीतर टीएलएस में अपग्रेड करने के लिए) में गोरी का विवरण है, लेकिन मूल रूप से यह बहुत से लोगों के लिए काम करता है (यदि बहुमत नहीं है)।
आप ओपनएसएल के साथ पुराने फंकी व्यवहार को पुन: पेश कर सकते हैं s_client आदेश (या किसी भी "पुराना पर्याप्त" ब्राउज़र) हालांकि।

जोड़ने के लिए संपादित करें: जाहिर है curl openssl से बेहतर यहाँ क्या हो रहा है आपको दिखा सकता है:


SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

68
2018-02-04 23:46



यह बहुत उपयोगी है - धन्यवाद! एसएसएल के बजाय टीएलएस के लिए अपाचे को कॉन्फ़िगर करने के तरीके के बारे में कोई जानकारी? - Josh
मुझे लगता है कि अपाचे 2.2 को केवल अपने साइफर सूची में टीएलएस बिट्स सक्षम करने की आवश्यकता है। मैं मानता हूं कि मैंने कभी भी इन दो साइटों तक कार्रवाई में थोड़ा "एसएसएल से टीएलएस में अपग्रेड करना" देखा है। टीएलएस दस्तावेज़ों की मेरी समझ यह है कि यह इस तरह के अपग्रेड पर बातचीत करने के लिए एक स्वीकार्य (लेकिन असामान्य) स्थिति है ... - voretaq7
यह पहली बार है जब मैंने कभी इसे देखा है और मैं अभी भी अपने जबड़े को फर्श से खींचने की कोशिश कर रहा हूं ... - Josh
ठीक है मेरा जवाब सिर्फ लंबाई में तीन गुना - स्पष्ट रूप से कर्ल SSLv3 और TLSv1 बातचीत दोनों कर सकता है ताकि मैं विफलता और सफलता दिखा सकूं। काश मैं जादू भाग दिखाने के लिए एक प्रोटोकॉल डीबगर आसान था। (यह भी रिपोर्ट करने के लिए परीक्षण और खुश है कि johnlai2004 सर्वर सही ढंग से SSLv2 कनेक्शन से इनकार करता है :-) - voretaq7
यह बेहद सहायक है और मुझे आशा है कि जॉनलाई 2004 आपके उत्तर को स्वीकार करेगा। आपका बहुत बहुत धन्यवाद! - Josh


हाँ, लेकिन कुछ चेतावनी हैं।

यह सर्वर नाम संकेत के माध्यम से, परिवहन परत सुरक्षा के लिए एक विस्तार के माध्यम से पूरा किया जाता है।

सर्वर नाम संकेत क्या है?

सर्वर नाम संकेत (आरएफसी 6066; obsoleted आरएफसी 4366, आरएफसी 3546) एक विस्तार है परिवहन परत सुरक्षा जो क्लाइंट को सर्वर को उस होस्ट का नाम बताने की अनुमति देता है जो वह पहुंचने का प्रयास कर रहा है।

एसएनआई टीएलएस 1.0 के साथ संगत है और spec के अनुसार उच्च है, लेकिन कार्यान्वयन भिन्न हो सकते हैं (नीचे देखें)। इसका उपयोग एसएसएल के साथ नहीं किया जा सकता है, इसलिए कनेक्शन को टीएलएस पर बातचीत करनी चाहिए (देखें आरएफसी 4346 परिशिष्ट ई) एसएनआई के इस्तेमाल के लिए। यह आमतौर पर समर्थित सॉफ़्टवेयर के साथ स्वचालित रूप से होता है।

एसएनआई की आवश्यकता क्यों है?

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

विकल्प प्रत्येक वेब होस्टनाम के लिए अद्वितीय आईपी पते असाइन करना है। यह आमतौर पर वेब के शुरुआती दिनों में किया जाता था, इससे पहले कि यह व्यापक रूप से ज्ञात था कि आईपी पते समाप्त हो जाएंगे और संरक्षण उपाय शुरू हो जाएंगे, और एसएसएल आभासी मेजबान (एसएनआई का उपयोग नहीं कर रहे हैं) के लिए अभी भी ऐसा किया गया है।

चूंकि मेजबान नाम को प्रेषित करने की इस विधि को कनेक्शन पहले से स्थापित करने की आवश्यकता है, यह SSL / TLS कनेक्शन के साथ काम नहीं करता है। जब तक सुरक्षित कनेक्शन स्थापित होता है, तब तक वेब सर्वर को पता होना चाहिए कि क्लाइंट को कौन सा मेजबाननाम सेवा देने जा रहा है, क्योंकि वेब सर्वर स्वयं सुरक्षित कनेक्शन स्थापित कर रहा है।

एसएनआई क्लाइंट को मेजबाननाम को टीएलएस वार्ता के हिस्से के रूप में प्रेषित करके इस समस्या को हल करता है, ताकि सर्वर पहले से ही जागरूक हो कि कनेक्शन की सेवा के लिए कौन सा आभासी होस्ट इस्तेमाल किया जाना चाहिए। सर्वर सही वर्चुअल होस्ट के लिए प्रमाणपत्र और कॉन्फ़िगरेशन का उपयोग कर सकता है।

विभिन्न आईपी पते का उपयोग क्यों नहीं करें?

HTTP Host: 1 99 0 के दशक के मध्य तक एक समस्या के रूप में मान्यता प्राप्त आईपीवी 4 पतों की कमी के कारण एक ही आईपी पते से एक से अधिक वेब होस्ट को सेवा देने की अनुमति देने के लिए हेडर को परिभाषित किया गया था। साझा वेब होस्टिंग वातावरण में, सैकड़ों अनूठी, असंबद्ध वेबसाइटों को इस स्थान पर एक ही आईपी पते का उपयोग करके सेवा स्थान को संरक्षित किया जा सकता है।

साझा होस्टिंग वातावरण में तब पाया गया कि आईपी एड्रेस स्पेस का सबसे बड़ा उपभोक्ता सुरक्षित वेब साइटों के लिए अद्वितीय आईपी पते रखने की आवश्यकता थी, जिससे आईएनवी 6 के रास्ते पर स्टॉप-गैप उपाय के रूप में एसएनआई की आवश्यकता पैदा हुई। आज कभी-कभी 5 आईपी पते (/ 2 9) को महत्वपूर्ण औचित्य के बिना प्राप्त करना मुश्किल होता है, जिसके परिणामस्वरूप तैनाती में देरी होती है।

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

चेतावनियां

कुछ ऑपरेटिंग सिस्टम / ब्राउज़र संयोजन एसएनआई का समर्थन नहीं करते हैं (नीचे देखें), इसलिए एसएनआई का उपयोग सभी परिस्थितियों के लिए उपयुक्त नहीं है। इस तरह के सिस्टम / ब्राउज़र संयोजनों को लक्षित करने वाली साइटें एसएनआई से गुजरना चाहती हैं और प्रत्येक वर्चुअल होस्ट के लिए अद्वितीय आईपी पते का उपयोग जारी रखती हैं।

विशेष ध्यान दें, विंडोज एक्सपी पर इंटरनेट एक्सप्लोरर का कोई संस्करण एसएनआई का समर्थन नहीं करता है। चूंकि यह संयोजन अभी भी इंटरनेट ट्रैफिक के हिस्से नेटमैर्केटशेयर के अनुसार दिसंबर 2012 में एक महत्वपूर्ण (लेकिन तेजी से घट रहा है; इंटरनेट ट्रैफिक का लगभग 16%) का प्रतिनिधित्व करता है, एसएनआई इन उपयोगकर्ता आबादी को लक्षित करने वाली साइट के लिए अनुचित होगा।

समर्थन

कई, लेकिन सभी नहीं, आमतौर पर इस्तेमाल किए गए सॉफ़्टवेयर पैकेज एसएनआई का समर्थन करते हैं।

(इस सूची से चूक का मतलब समर्थन की कमी का मतलब नहीं है; इसका मतलब है कि मैं कितना टाइप कर सकता हूं, या मुझे खोज में जानकारी तुरंत नहीं मिल सका। अगर आपका सॉफ़्टवेयर पैकेज सूचीबद्ध नहीं है, तो खोज इसके नाम के लिए प्लस sni अगर खुलासा मौजूद है और इसे कैसे सेट अप किया जाए तो प्रकट करना चाहिए।)

लाइब्रेरी समर्थन

अधिकांश पैकेज एसएसएल / टीएलएस समर्थन प्रदान करने के लिए बाहरी पुस्तकालय पर निर्भर करते हैं।

  • जीएनयू टीएलएस
  • जेएसएसई (ओरेकल जावा) 7 या उच्चतम, केवल एक ग्राहक के रूप में
  • libcurl 7.18.1 या उच्चतर
  • एनएसएस 3.1.1 या उच्चतर
  • ओपनएसएसएल 0.9.8j या उच्चतर
    • कॉन्फ़िगर फ्लैग के साथ OpenSSL 0.9.8f या उच्चतम
  • क्यूटी 4.8 या उच्चतर

सर्वर समर्थन

लोकप्रिय सर्वर सॉफ़्टवेयर समर्थन एसएनआई के अधिकांश मौजूदा संस्करण। इनमें से अधिकांश के लिए सेटअप निर्देश उपलब्ध हैं:

ग्राहक सहायता

अधिकांश मौजूदा वेब ब्राउज़र और कमांड लाइन उपयोगकर्ता एजेंट एसएनआई का समर्थन करते हैं।

डेस्कटॉप

  • क्रोम 5 या उच्चतर
    • विंडोज एक्सपी पर क्रोम 6 या उच्चतम
  • फ़ायरफ़ॉक्स 2 या उच्चतर
  • इंटरनेट एक्सप्लोरर 7 या उच्चतर, विंडोज विस्टा / सर्वर 2008 या उच्चतर पर चल रहा है
    • विंडोज एक्सपी पर इंटरनेट एक्सप्लोरर आईई संस्करण के बावजूद एसएनआई का समर्थन नहीं करता है
  • Konqueror 4.7 या उच्चतम
  • ओपेरा 8 या उच्चतम (कार्य करने के लिए सक्षम टीएलएस 1.1 की आवश्यकता हो सकती है)
  • सफारी 3.0 विंडोज विस्टा / सर्वर 2008 या उच्चतर, या मैक ओएस एक्स 10.5.6 या उच्चतम पर

मोबाइल

  • 3.0 हनीकॉम्ब या उच्चतर पर एंड्रॉइड ब्राउज़र
  • आईओएस सफारी आईओएस 4 या उच्चतर पर
  • विंडोज फोन 7 या उच्चतर

कमांड लाइन

  • curl 7.18.1 या उच्चतर
  • 1.14 या उससे अधिक wget (वितरण एक बैकपोर्ट किया हो सकता है पैच एसएनआई समर्थन के लिए)

समर्थन नहीं

  • ब्लैकबेरी ब्राउज़र
  • विंडोज एक्सपी पर इंटरनेट एक्सप्लोरर (कोई संस्करण)

(नोट: इस उत्तर के लिए कुछ जानकारी प्राप्त की गई थी विकिपीडिया।)


96
2017-08-14 23:05



बहुत बेहतर :-) उम्मीद है कि अंततः इसे स्वीकार किए गए एक से अधिक स्कोर प्राप्त हो सकता है, जो शीर्ष पर अंतिम संपादन के अलावा, दुर्भाग्यवश दुर्भाग्य से गलत है। - Bruno
@ ब्रूनो मैं निश्चित रूप से शिकायत नहीं करूंगा अगर आपको कुछ सौ लोग इसे ऊपर उठाने के लिए पाते हैं। :) - Michael Hampton♦
नवीनतम ब्लैकबेरी ब्राउज़र (10?) वेबकिट के हाल के संस्करण का उपयोग करता है, इसलिए यह अब एसएनआई का समर्थन करता है। - dave1010


समस्या:

जब एक वेब क्लाइंट और वेब सर्वर एक दूसरे से HTTPS पर बात करते हैं, तो सबसे पहले चीज जो होने की जरूरत है वह सुरक्षित हैंडशेक है।

इस तरह के हैंडशेक का एक सरल उदाहरण यहां दिया गया है:

tls handshake

यदि यह HTTP था और HTTPS नहीं था, तो ग्राहक द्वारा भेजा गया पहला सामान ऐसा कुछ होगा:

GET /index.html HTTP/1.1
Host: example.com

इसने एक एकल आईपी पते पर कई वर्चुअल होस्ट किए हैं, क्योंकि सर्वर जानता है कि क्लाइंट किस डोमेन तक पहुंचना चाहता है, उदाहरण example.com।

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

आप अभी भी अपने वेब सर्वर पर वर्चुअल होस्ट सेट अप कर सकते हैं, लेकिन सर्वर हमेशा प्रत्येक क्लाइंट को एक ही प्रमाणपत्र भेज देगा। यदि आपने अपने सर्वर पर example.com और example.org दोनों वेबसाइटों को होस्ट करने का प्रयास किया है, तो सर्वर हमेशा example.com के लिए प्रमाण पत्र भेजता है जब कोई ग्राहक HTTPS कनेक्शन का अनुरोध करता है। तो जब कोई ग्राहक एक स्थापित HTTPS कनेक्शन पर example.org का अनुरोध करता है, तो ऐसा होगा:

enter image description here

यह समस्या प्रभावी रूप से उन डोमेन की संख्या को सीमित करती है जिन्हें आप HTTPS पर प्रति आईपी पते पर सर्वर पर कर सकते हैं।

समाधान:

इस समस्या को हल करने का सबसे आसान तरीका क्लाइंट के लिए सर्वर को यह बताने के लिए है कि वह कौन सा डोमेन एक्सेस करना चाहता है हैंडशेक के दौरान। इस तरह से सर्वर सही प्रमाण पत्र की सेवा कर सकते हैं।

यह वही है SNI, या सर्वर नाम संकेत करता है।

एसएनआई के साथ, क्लाइंट सर्वर नाम भेजता है, जो पहले संदेश के हिस्से के रूप में एक्सेस करना चाहता है, उपरोक्त हैंडशेक आरेख में "क्लाइंट हैलो" चरण।

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

enter image description here

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


37
2017-08-14 19:13





http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

क्लाइंट ब्राउज़र को एसएनआई का भी समर्थन करना चाहिए। यहां कुछ ब्राउज़र हैं जो करते हैं:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

16
2018-02-05 00:46





एचटीटीपीएस पर काम करने के लिए नाम-आधारित vhosts के लिए सर्वर नाम संकेत (RFC6066) TLS एक्सटेंशन आवश्यक है।

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


6
2017-08-14 19:10



फाल्कन के उत्तर आईआईएस के अलावा एक ही आईपी पर काम करने के लिए कई आईआईएस साइट्स प्राप्त करने के लिए कुछ विशेष बदलावों की भी आवश्यकता है। आपको सर्वर के लिए कॉन्फ़िगरेशन फ़ाइल मैन्युअल रूप से संपादित करना है या बाध्यकारी परिवर्तन करने के लिए एक CLI उपकरण का उपयोग करना है, GUI उपकरण ऐसा नहीं कर सकता है। आईआईएस में इसे हेडर होस्ट करने के लिए एसएसएल कर्ट असाइन करने के रूप में प्रस्तुत किया जाता है। अपाचे को थोड़ी देर के लिए मुद्दा नहीं मिला है। - Brent Pabst
आह ठीक है, यह कुछ साफ करता है। आप कैसे जान सकते हैं कि कोई ग्राहक (ब्राउज़र) इसका समर्थन करता है या नहीं? उदाहरण के लिए यदि मैं MSIE6 को देखना चाहता हूं, तो मैं वर्चुअल एक्सपी मशीन स्थापित किए बिना परीक्षण कैसे कर सकता हूं? - Luc
@Luc en.wikipedia.org/wiki/Server_Name_Indication#Support - cjc
@ फाल्कन एसएनआई एक्सपी पर आईई के साथ काम नहीं करता है; जो अभी भी लगभग एक चौथाई डेस्कटॉप इंटरनेट उपयोगकर्ताओं के लिए जिम्मेदार है। जब मैं संभावित आगंतुकों का एक चौथाई काम नहीं करता हूं तो मैं इसे "व्यापक रूप से कार्यान्वित" नहीं कहूंगा। - Chris S
@ माइकल हैम्पटन आईई एसएसएल के लिए मूल विंडोज क्रिप्टो स्टैक का उपयोग करता है। XP एसएनआई का समर्थन नहीं करता है, इसलिए आईपी के चल रहे आईई के किसी भी संस्करण के लिए या तो नहीं है। आईई केवल Vista और नए ओएस में एसएनआई का समर्थन करता है। - Chris S