นี่เป็นคำถามที่ยอมรับได้เกี่ยวกับการโฮสต์เว็บไซต์ SSL หลายเว็บไซต์ใน IP เดียวกัน

ฉันอยู่ภายใต้การแสดงผลว่าใบรับรอง SSL แต่ละรายการจำเป็นต้องมีที่อยู่ IP / พอร์ตเฉพาะของตัวเอง แต่คำตอบของคำถามก่อนหน้านี้ที่ฉันโพสต์นั้นขัดแย้งกับการอ้างสิทธิ์นี้

การใช้ข้อมูลจากคำถามนั้นทำให้ฉันสามารถรับใบรับรอง SSL หลายใบเพื่อทำงานบนที่อยู่ IP เดียวกันและที่พอร์ต 443 ฉันสับสนอย่างมากว่าทำไมงานนี้ถึงได้รับข้อสันนิษฐานข้างต้น เซิร์ฟเวอร์เดียวกันต้องการ IP / พอร์ตของตัวเอง

ฉันสงสัยว่าฉันทำอะไรผิด วิธีนี้สามารถใช้ใบรับรอง SSL หลายใบได้หรือไม่?

สำหรับข้อมูลล่าสุดเกี่ยวกับ Apache และ SNI รวมถึง RFC เฉพาะ HTTP เพิ่มเติมโปรดอ้างอิงApache Wiki

FYsI: "ใบรับรอง SSL (แตกต่างกัน) หลายรายการใน IP เดียว" นำคุณมาสู่การอัปเกรด TLS ใช้งานได้กับเซิร์ฟเวอร์ Apache รุ่นใหม่ (2.2.x) และเบราว์เซอร์รุ่นล่าสุดที่มีเหตุผล

RFC 2817 (อัปเกรดเป็น TLS ภายใน HTTP / 1.1) มีรายละเอียดเต็มไปด้วยเลือด แต่โดยทั่วไปแล้วมันใช้งานได้สำหรับคนจำนวนมาก (ถ้าไม่ใช่เสียงส่วนใหญ่)
คุณสามารถสร้างพฤติกรรมขี้ขลาดขึ้นมาใหม่ด้วยs_clientคำสั่งของ openssl (หรือเบราว์เซอร์ "เก่าพอ")

แก้ไขเพื่อเพิ่ม: เห็นได้ชัดว่า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.

ใช่ แต่มีข้อแม้อยู่บ้าง

สิ่งนี้สามารถทำได้ผ่านการระบุชื่อเซิร์ฟเวอร์ซึ่งเป็นส่วนเสริมของ Transport Layer Security

บ่งชี้ชื่อเซิร์ฟเวอร์คืออะไร

บ่งชี้ชื่อเซิร์ฟเวอร์ ( RFC 6066 ; ล้าสมัยRFC 4366 , RFC 3546 ) เป็นส่วนขยายของTransport Layer Securityซึ่งอนุญาตให้ไคลเอนต์บอกชื่อเซิร์ฟเวอร์ของโฮสต์ที่พยายามจะเข้าถึงเซิร์ฟเวอร์

SNI เข้ากันได้กับ TLS 1.0 และสูงกว่าตามข้อกำหนด แต่การใช้งานอาจแตกต่างกัน (ดูด้านล่าง) ไม่สามารถใช้กับ SSL ดังนั้นการเชื่อมต่อจะต้องเจรจา TLS (ดูRFC 4346 ภาคผนวก E ) เพื่อให้ SNI ใช้ สิ่งนี้มักจะเกิดขึ้นโดยอัตโนมัติด้วยซอฟต์แวร์ที่รองรับ

ทำไม SNI ถึงต้องการ?

ในการเชื่อมต่อHTTPปกติเบราว์เซอร์แจ้งเซิร์ฟเวอร์ของชื่อโฮสต์ของเซิร์ฟเวอร์ที่พยายามเข้าถึงโดยใช้Host:ส่วนหัว นี้จะช่วยให้เว็บเซิร์ฟเวอร์ที่อยู่ IP เดียวที่จะให้บริการเนื้อหาสำหรับชื่อโฮสต์หลายซึ่งเป็นที่รู้จักกันทั่วไปว่าเป็นชื่อที่ใช้ virtual hosting

ทางเลือกคือการกำหนดที่อยู่ IP ที่ไม่ซ้ำกันสำหรับแต่ละชื่อโฮสต์ของเว็บที่จะให้บริการ สิ่งนี้ทำกันโดยทั่วไปในช่วงต้น ๆ ของเว็บก่อนที่จะเป็นที่รู้จักกันอย่างกว้างขวางว่าที่อยู่ IP จะหมดลงและมาตรการอนุรักษ์เริ่มขึ้นและยังคงทำเช่นนี้สำหรับโฮสต์เสมือน SSL (ไม่ได้ใช้ SNI)

เนื่องจากวิธีการส่งชื่อโฮสต์ต้องใช้การเชื่อมต่อที่สร้างไว้แล้วจึงไม่สามารถใช้งานได้กับการเชื่อมต่อ SSL / TLS เมื่อถึงเวลาที่มีการตั้งค่าการเชื่อมต่อที่ปลอดภัยเว็บเซิร์ฟเวอร์จะต้องทราบชื่อโฮสต์ที่จะให้บริการกับลูกค้าเพราะเว็บเซิร์ฟเวอร์เองกำลังตั้งค่าการเชื่อมต่อที่ปลอดภัย

SNI แก้ปัญหานี้โดยให้ไคลเอนต์ส่งชื่อโฮสต์เป็นส่วนหนึ่งของการเจรจา TLS เพื่อให้เซิร์ฟเวอร์ทราบแล้วว่าควรใช้โฮสต์เสมือนใดในการให้บริการการเชื่อมต่อ เซิร์ฟเวอร์สามารถใช้ใบรับรองและการกำหนดค่าสำหรับโฮสต์เสมือนที่ถูกต้อง

ทำไมไม่ใช้ที่อยู่ IP อื่น

Host:ส่วนหัวHTTP ได้รับการกำหนดให้อนุญาตให้มีเว็บโฮสต์มากกว่าหนึ่งแห่งให้บริการจากที่อยู่ IP เดียวเนื่องจากการขาดแคลนที่อยู่ IPv4 ซึ่งได้รับการยอมรับว่าเป็นปัญหาตั้งแต่ช่วงกลางทศวรรษที่ 1990 ในสภาพแวดล้อมการโฮสต์เว็บที่ใช้ร่วมกันเว็บไซต์ที่ไม่ซ้ำกันและไม่เกี่ยวข้องหลายร้อยแห่งสามารถให้บริการได้โดยใช้ที่อยู่ IP เดียวด้วยวิธีนี้เพื่อประหยัดพื้นที่ที่อยู่

สภาพแวดล้อมการโฮสต์ที่ใช้ร่วมกันนั้นพบว่าผู้บริโภคที่ใหญ่ที่สุดของพื้นที่ที่อยู่ IP คือความต้องการเว็บไซต์ที่ปลอดภัยที่จะมีที่อยู่ IP ที่ไม่ซ้ำกันทำให้ SNI เป็นตัววัดช่องว่างระหว่างทางสู่ IPv6 วันนี้บางครั้งก็ยากที่จะได้รับน้อยที่สุดเท่าที่ 5 ที่อยู่ IP (/ 29) โดยไม่มีเหตุผลสำคัญมักทำให้เกิดความล่าช้าในการปรับใช้

ด้วยการถือกำเนิดของ IPv6 เทคนิคการอนุรักษ์ที่อยู่ดังกล่าวไม่จำเป็นอีกต่อไปเนื่องจากโฮสต์เดียวสามารถมีที่อยู่ IPv6 ที่ได้รับมอบหมายมากกว่าอินเทอร์เน็ตทั้งหมดที่มีอยู่ในวันนี้ สัมพันธ์

คำเตือน

ชุดของระบบปฏิบัติการ / เบราว์เซอร์บางตัวไม่รองรับ SNI (ดูด้านล่าง) ดังนั้นการใช้ SNI จึงไม่เหมาะสมสำหรับทุกสถานการณ์ เว็บไซต์ที่กำหนดเป้าหมายชุดของระบบ / เบราว์เซอร์ดังกล่าวจะต้องละทิ้ง SNI และใช้ที่อยู่ IP ที่ไม่ซ้ำกันสำหรับโฮสต์เสมือนแต่ละรายการ

จากหมายเหตุเฉพาะไม่มี Internet Explorer รุ่นใดใน Windows XP ที่รองรับ SNI เนื่องจากชุดค่าผสมนี้ยังคงแสดงถึงการลดลงอย่างมีนัยสำคัญ (แต่ลดลงอย่างต่อเนื่องประมาณ 16% ของปริมาณการใช้อินเทอร์เน็ตในเดือนธันวาคม 2012 ตาม NetMarketShare) ส่วนของปริมาณการใช้อินเทอร์เน็ต SNI จะไม่เหมาะสมสำหรับไซต์ที่กำหนดเป้าหมายประชากรของผู้ใช้เหล่านี้

สนับสนุน

แพ็คเกจซอฟต์แวร์ที่ใช้กันทั่วไปจำนวนมาก แต่ไม่ใช่ทั้งหมดที่รองรับ SNI

(การละเว้นจากรายการนี้ไม่ได้แปลว่าขาดการสนับสนุนหมายความว่ามีจำนวน จำกัด ที่ฉันสามารถพิมพ์ได้หรือฉันไม่สามารถค้นหาข้อมูลในการค้นหาได้อย่างรวดเร็วหากแพคเกจซอฟต์แวร์ของคุณไม่อยู่ในรายการให้ค้นหา สำหรับชื่อและsniควรเปิดเผยหากมีการสนับสนุนและวิธีการตั้งค่า)

สนับสนุนห้องสมุด

แพ็คเกจส่วนใหญ่ขึ้นอยู่กับไลบรารีภายนอกเพื่อให้การสนับสนุน SSL / TLS

• GNU TLS
• JSSE (Oracle Java) 7 หรือสูงกว่าเป็นลูกค้าเท่านั้น
• libcurl 7.18.1 ขึ้นไป
• NSS 3.1.1 หรือสูงกว่า
• OpenSSL 0.9.8j หรือสูงกว่า
  • OpenSSL 0.9.8f หรือสูงกว่าพร้อมกำหนดค่าสถานะ
• Qt 4.8 หรือสูงกว่า

การสนับสนุนเซิร์ฟเวอร์

ซอฟต์แวร์เซิร์ฟเวอร์ยอดนิยมรุ่นล่าสุดรองรับ SNI คำแนะนำในการตั้งค่ามีให้ใช้งานโดยส่วนใหญ่:

• Apache 2.2.12 หรือสูงกว่า
• Apache Traffic Server 3.2.0 หรือสูงกว่า
• เชโรกี
• HAProxy 1.5 หรือสูงกว่า
• IIS 8.0 หรือสูงกว่า
• lighttpd 1.4.24 หรือสูงกว่า
• LiteSpeed ​​4.1 หรือสูงกว่า
• nginx 0.5.32 หรือสูงกว่า

ฝ่ายบริการลูกค้า

เว็บเบราว์เซอร์ส่วนใหญ่ในปัจจุบันและตัวแทนผู้ใช้บรรทัดคำสั่งรองรับ SNI

เดสก์ทอป

• Chrome 5 หรือสูงกว่า
  • Chrome 6 หรือสูงกว่าบน Windows XP
• Firefox 2 หรือสูงกว่า
• Internet Explorer 7 หรือสูงกว่าทำงานบน Windows Vista / Server 2008 หรือสูงกว่า
  • Internet Explorer บน Windows XP ไม่รองรับ SNI โดยไม่คำนึงถึงรุ่น IE
• Konqueror 4.7 หรือสูงกว่า
• Opera 8 หรือสูงกว่า (อาจต้องเปิดใช้งาน TLS 1.1 เพื่อให้สามารถใช้งานได้)
• Safari 3.0 บน Windows Vista / Server 2008 หรือสูงกว่าหรือ Mac OS X 10.5.6 หรือสูงกว่า

โทรศัพท์มือถือ

• เบราว์เซอร์ Android บน Honeycomb 3.0 หรือสูงกว่า
• iOS Safari บน iOS 4 หรือสูงกว่า
• Windows Phone 7 หรือสูงกว่า

บรรทัดคำสั่ง

• cURL 7.18.1 ขึ้นไป
• wget 1.14 หรือสูงกว่า (การแจกแจงอาจมี backported patchสำหรับการรองรับ SNI)

ไม่สนับสนุน

• เบราว์เซอร์ BlackBerry
• Internet Explorer (ทุกรุ่น) บน Windows XP

(หมายเหตุ: ข้อมูลบางส่วนสำหรับคำตอบนี้ได้มาจากWikipedia )

ปัญหา:

เมื่อเว็บไคลเอ็นต์และเว็บเซิร์ฟเวอร์คุยกันผ่าน HTTPS สิ่งแรกที่ต้องเกิดขึ้นคือการจับมือที่ปลอดภัย

นี่คือตัวอย่างที่ง่ายของการจับมือกัน:

หากนี่คือ HTTP ไม่ใช่ HTTPS สิ่งแรกที่ลูกค้าจะได้รับจะเป็นดังนี้:

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

สิ่งนี้ทำให้หลายโฮสต์เสมือนบนที่อยู่ IP เดียวที่เป็นไปได้เนื่องจากเซิร์ฟเวอร์รู้ว่าโดเมนใดที่ไคลเอ็นต์ต้องการเข้าถึงนั่นคือ example.com

HTTPS นั้นแตกต่างกัน อย่างที่ฉันพูดไปก่อนหน้านี้การจับมือมาก่อนทุกสิ่ง หากคุณดูขั้นตอนที่สามของการจับมือแสดงไว้ด้านบน (ใบรับรอง) เซิร์ฟเวอร์จะต้องแสดงใบรับรองให้กับลูกค้าเป็นส่วนหนึ่งของการจับมือกัน แต่ไม่มีเงื่อนงำว่าชื่อโดเมนใดที่ไคลเอ็นต์พยายามเข้าถึง ตัวเลือกเดียวที่เซิร์ฟเวอร์มีคือการส่งใบรับรองเดียวกันทุกครั้งซึ่งเป็นใบรับรองเริ่มต้น

คุณยังคงสามารถตั้งค่าโฮสต์เสมือนบนเว็บเซิร์ฟเวอร์ของคุณได้ แต่เซิร์ฟเวอร์จะส่งใบรับรองเดียวกันไปยังไคลเอนต์แต่ละราย หากคุณพยายามโฮสต์ทั้งเว็บไซต์ example.com และ example.org บนเซิร์ฟเวอร์ของคุณเซิร์ฟเวอร์จะส่งใบรับรองสำหรับ example.com เสมอเมื่อไคลเอ็นต์ร้องขอการเชื่อมต่อ HTTPS ดังนั้นเมื่อลูกค้าร้องขอ example.org ผ่านการเชื่อมต่อ HTTPS ที่จัดตั้งขึ้นสิ่งนี้จะเกิดขึ้น:

ปัญหานี้ จำกัด จำนวนโดเมนที่คุณสามารถเซิร์ฟเวอร์ผ่าน HTTPS ได้อย่างมีประสิทธิภาพต่อหนึ่งที่อยู่ IP

การแก้ไขปัญหา:

วิธีที่ง่ายที่สุดในการแก้ปัญหานี้สำหรับลูกค้าที่จะบอกเซิร์ฟเวอร์ซึ่งโดเมนมันต้องการที่จะเข้าถึงในระหว่างการจับมือกัน วิธีนี้เซิร์ฟเวอร์สามารถแสดงใบรับรองที่ถูกต้องได้

นี่คือสิ่งที่SNIหรือการระบุชื่อเซิร์ฟเวอร์

ด้วย SNI ไคลเอนต์ส่งชื่อเซิร์ฟเวอร์ที่ต้องการเข้าถึงโดยเป็นส่วนหนึ่งของข้อความแรกขั้นตอน "ไคลเอนต์สวัสดี" ในแผนภาพการจับมือกันด้านบน

เว็บเบราว์เซอร์รุ่นเก่าบางรุ่นไม่รองรับ SNI ตัวอย่างเช่นใน Windows XP ไม่มีInternet Explorer รุ่นเดียวที่รองรับ SNI เมื่อเข้าถึงทรัพยากรผ่าน HTTPS บนเซิร์ฟเวอร์ที่ใช้โฮสต์เสมือน SNI คุณจะได้รับใบรับรองทั่วไปซึ่งอาจทำให้เบราว์เซอร์แสดงคำเตือนหรือข้อผิดพลาด

ฉันทำให้สิ่งต่าง ๆ ง่ายขึ้นที่นี่เพื่ออธิบายหลักการที่อยู่เบื้องหลังปัญหาและวิธีแก้ปัญหา หากคุณต้องการคำอธิบายทางเทคนิคเพิ่มเติมหน้าวิกิพีเดียหรือRFC 6066อาจเป็นจุดเริ่มต้นที่ดี นอกจากนี้คุณยังสามารถค้นหารายการเซิร์ฟเวอร์และเบราว์เซอร์ล่าสุดที่รองรับ SNI ในวิกิพีเดีย

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 

การระบุชื่อเซิร์ฟเวอร์ (RFC6066) จำเป็นต้องใช้ส่วนขยาย TLS เพื่อให้โฮสต์ vhost ใช้ชื่อเพื่อทำงานผ่าน HTTPS

มีการใช้งานส่วนขยายอย่างกว้างขวางและฉันยังไม่พบปัญหาใด ๆ กับซอฟต์แวร์ปัจจุบัน แต่มีโอกาสที่ลูกค้าบางราย (ที่ไม่สนับสนุน) จะถูกส่งไปยังไซต์เริ่มต้นของคุณหากคุณขึ้นอยู่กับ SNI