109

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

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

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

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

— जॉन
स्रोत

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

— dave_thompson_085

68

अतिरिक्त HTTP- विशिष्ट RFC सहित अपाचे और SNI के बारे में नवीनतम जानकारी के लिए, अपाचे विकी को देखें।

FYsI: "एकाधिक (भिन्न) SSL प्रमाणपत्र एक IP पर" आपके लिए TLS अपग्रेडिंग के जादू द्वारा लाया जाता है। यह नए अपाचे सर्वरों (2.2.x) और यथोचित हाल के ब्राउज़रों (मेरे सिर के ऊपर के संस्करणों को नहीं जानता) के साथ काम करता है।

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

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

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.

— voretaq7
स्रोत

2

यह बहुत उपयोगी है - धन्यवाद! एसएसएल के बजाय टीएलएस के लिए अपाचे को कॉन्फ़िगर करने के बारे में कोई जानकारी?

— जोश

2

मुझे लगता है कि अपाचे 2.2 को केवल अपनी साइबर सूची में टीएलएस बिट्स को सक्षम करने की आवश्यकता है। मैं मानता हूँ कि मैंने इन दोनों साइटों तक पूरे "SSL से TLS में अपग्रेड" बिट कभी नहीं देखा है। टीएलएस डॉक्स के बारे में मेरी समझ यह है कि यह इस तरह के उन्नयन पर बातचीत करने के लिए एक स्वीकार्य (लेकिन असामान्य) स्थिति है ...

— voretaq7

यह पहली बार है जब मैंने इसे या तो देखा है और मैं अभी भी अपने जबड़े को फर्श से हटाने की कोशिश कर रहा हूं ...

— जोश

1

ठीक है मेरा उत्तर केवल लंबाई में तीन गुना है - जाहिर तौर पर कर्ल SSLv3 और TLSv1 दोनों बातचीत कर सकते हैं ताकि मैं विफलता और सफलता दिखा सकूं। काश, मैजिक पार्ट दिखाने के लिए मेरे पास एक प्रोटोकॉल डीबगर होता। (यह भी परीक्षण किया गया और यह बताकर खुशी हुई कि johnlai2004 का सर्वर SSLv2 कनेक्शनों को सही ढंग से नकारता है :-)

— voretaq7

यह बहुत उपयोगी है और मुझे उम्मीद है कि johnlai2004 आपके उत्तर को स्वीकार करेगा। आपका बहुत बहुत धन्यवाद!

— जोश

97

हां, लेकिन कुछ कैविएट हैं।

यह सर्वर नाम संकेत, ट्रांसपोर्ट लेयर सिक्योरिटी के लिए एक्सटेंशन के माध्यम से पूरा किया जाता है।

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

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

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

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

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

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

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

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

विभिन्न IP पतों का उपयोग क्यों नहीं किया जाता है?

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

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

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

चेतावनियां

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

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

समर्थन

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

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

पुस्तकालय समर्थन

SSL / TLS सहायता प्रदान करने के लिए अधिकांश पैकेज बाहरी लाइब्रेरी पर निर्भर करते हैं।

GNU TLS
JSSE (Oracle Java) 7 या उच्चतर, केवल ग्राहक के रूप में
libcurl 7.18.1 या उच्चतर
एनएसएस 3.1.1 या उच्चतर
ओपनएसएसएल 0.9.8j या उच्चतर
- OpenSSL 0.9.8f या उच्चतर, कॉन्फ़िगर किए गए झंडे के साथ
Qt 4.8 या उच्चतर

सर्वर का समर्थन

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

अपाचे 2.2.12 या उच्चतर
अपाचे ट्रैफिक सर्वर 3.2.0 या उच्चतर
चेरोकी
HAProxy 1.5 या उच्चतर
IIS 8.0 या उच्चतर
lighttpd 1.4.24 या उच्चतर
लाइटस्पीड 4.1 या उच्चतर
nginx 0.5.32 या उच्चतर

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

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

डेस्कटॉप

क्रोम 5 या उच्चतर
- Windows XP पर Chrome 6 या उच्चतर
फ़ायरफ़ॉक्स 2 या उच्चतर
Internet Explorer 7 या उच्चतर, Windows Vista / Server 2008 या उच्चतर पर चल रहा है
- Windows XP पर इंटरनेट एक्सप्लोरर IE संस्करण की परवाह किए बिना SNI का समर्थन नहीं करता है
कोनकेर 4.7 या उच्चतर
ओपेरा 8 या अधिक (कार्य करने के लिए सक्षम टीएलएस 1.1 की आवश्यकता हो सकती है)
Windows Vista / Server 2008 या उच्चतर, या Mac OS X 10.5.6 या उच्चतर पर Safari 3.0

मोबाइल

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

कमांड लाइन

curl 7.18.1 या उच्चतर
1.14 या उससे अधिक की छूट (वितरण SNI समर्थन के लिए एक पैच हो सकता है )

समर्थन नहीं

ब्लैकबेरी ब्राउज़र
Windows XP पर इंटरनेट एक्सप्लोरर (कोई भी संस्करण)

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

— माइकल हैम्पटन
स्रोत

1

बहुत बेहतर :-) उम्मीद है, यह अंततः वर्तमान में स्वीकृत एक से अधिक अंक प्राप्त कर सकता है, जो शीर्ष पर अंतिम संपादन के अलावा, ज्यादातर दुर्भाग्य से गलत है।

— ब्रूनो

1

@ ब्रूनो मैं निश्चित रूप से शिकायत नहीं करूंगा यदि आप कुछ सौ लोगों को इसे उभारने के लिए पाते हैं। :)

— माइकल हैम्पटन

नवीनतम BlackBerry Browser (10?) WebKit के हाल के संस्करण का उपयोग करता है, इसलिए यह बहुत संभव है कि यह SNI का समर्थन करता है।

— dave1010

37

समस्या:

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

यहाँ इस तरह के एक हाथ मिलाना का एक सरल उदाहरण दिया गया है:

tls हाथ मिलाना

अगर यह HTTP और HTTPS नहीं होता, तो ग्राहक को भेजने वाली पहली चीज कुछ इस तरह होती:

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

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

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

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

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

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

समाधान:

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

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

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

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

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

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

— केनी रैशर्ट
स्रोत

16

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

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

* 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

— क्रेग
स्रोत

6

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

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

— फाल्कन मोमोत
स्रोत

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

— ब्रेंट पाब्स्ट

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

— लुक

1

@Luc en.wikipedia.org/wiki/Server_Name_Indication#Support

— cjc

1

@ फाल्कन एसएनआई एक्सई पर आईई के साथ काम नहीं करता है; जो अभी भी लगभग एक चौथाई डेस्कटॉप इंटरनेट उपयोगकर्ताओं के लिए है। संभावित आगंतुकों के एक चौथाई काम नहीं करने पर मैं इसे "व्यापक रूप से लागू" नहीं कहूंगा।

— क्रिस एस

1

@Michael Hampton IE एसएसएल के लिए देशी विंडोज क्रिप्टो स्टैक का उपयोग करता है। XP SNI का समर्थन नहीं करता है, तो XP के IE चलाने का कोई भी संस्करण नहीं है। IE केवल विस्टा और नए OSes में SNI का समर्थन करता है।

— क्रिस एस

एक ही आईपी पते और एक ही पोर्ट पर कई एसएसएल डोमेन?

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

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

विभिन्न IP पतों का उपयोग क्यों नहीं किया जाता है?

चेतावनियां

समर्थन

पुस्तकालय समर्थन

सर्वर का समर्थन

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

डेस्कटॉप

मोबाइल

कमांड लाइन

समर्थन नहीं