Đây là Câu hỏi Canonical về Lưu trữ nhiều trang web SSL trên cùng một IP.

Tôi có ấn tượng rằng mỗi Chứng chỉ SSL yêu cầu kết hợp Địa chỉ IP / Cổng duy nhất của riêng nó. Nhưng câu trả lời cho một câu hỏi trước đây tôi đã đăng là mâu thuẫn với yêu cầu này.

Sử dụng thông tin từ Câu hỏi đó, tôi có thể nhận được nhiều chứng chỉ SSL để hoạt động trên cùng một địa chỉ IP và trên cổng 443. Tôi rất bối rối về lý do tại sao công việc này đưa ra giả định ở trên và được củng cố bởi những người khác rằng mỗi trang web tên miền SSL trên cùng một máy chủ yêu cầu IP / Cổng riêng của nó.

Tôi nghi ngờ rằng tôi đã làm điều gì đó sai. Có thể sử dụng nhiều chứng chỉ SSL theo cách này?

Để biết thông tin cập nhật nhất về Apache và SNI, bao gồm các RFC cụ thể HTTP bổ sung, vui lòng tham khảo Wiki Wiki

FYsI: "Nhiều chứng chỉ SSL (khác nhau) trên một IP" được mang đến cho bạn bằng phép thuật nâng cấp TLS. Nó hoạt động với các máy chủ Apache mới hơn (2.2.x) và các trình duyệt hợp lý gần đây (không biết các phiên bản ngoài đỉnh đầu của tôi).

RFC 2817 (nâng cấp lên TLS trong HTTP / 1.1) có các chi tiết chính, nhưng về cơ bản, nó hoạt động cho nhiều người (nếu không phải là đa số).
Mặc dù vậy, bạn có thể tái tạo hành vi sôi nổi cũ bằng s_clientlệnh openssl (hoặc bất kỳ trình duyệt "đủ cũ" nào).

Chỉnh sửa để thêm: rõ ràng curlcó thể cho bạn thấy những gì đang xảy ra ở đây tốt hơn 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.

Có, nhưng có một số hãy cẩn thận.

Điều này được thực hiện thông qua Chỉ định tên máy chủ, một phần mở rộng cho Bảo mật lớp vận chuyển.

Tên máy chủ là gì?

Chỉ định tên máy chủ ( RFC 6066 ; RFC 4366 , RFC 3546 đã lỗi thời ) là một phần mở rộng cho Transport Layer Security cho phép khách hàng nói với máy chủ tên của máy chủ mà nó đang cố truy cập.

SNI tương thích với TLS 1.0 và cao hơn theo thông số kỹ thuật, nhưng việc triển khai có thể khác nhau (xem bên dưới). Không thể sử dụng nó với SSL, do đó, một kết nối phải thương lượng TLS (xem phụ lục E của RFC 4346 ) để SNI được sử dụng. Điều này thường xảy ra tự động với phần mềm được hỗ trợ.

Tại sao SNI cần thiết?

Trong kết nối HTTP bình thường , trình duyệt thông báo cho máy chủ tên máy chủ của máy chủ mà nó đang cố truy cập bằng Host:tiêu đề. Điều này cho phép một máy chủ web trên một địa chỉ IP duy nhất để phục vụ nội dung cho nhiều tên máy chủ, thường được gọi là lưu trữ ảo dựa trên tên .

Cách khác là gán các địa chỉ IP duy nhất cho mỗi tên máy chủ web sẽ được phục vụ. Điều này thường được thực hiện trong những ngày đầu của web, trước khi mọi người biết rằng các địa chỉ IP sẽ hết và các biện pháp bảo tồn bắt đầu, và vẫn được thực hiện theo cách này cho các máy chủ ảo SSL (không sử dụng SNI).

Vì phương thức truyền tên máy chủ này yêu cầu kết nối đã được thiết lập, nên nó không hoạt động với các kết nối SSL / TLS. Vào thời điểm kết nối an toàn được thiết lập, máy chủ web phải biết tên máy chủ nào sẽ phục vụ cho máy khách, vì chính máy chủ web đang thiết lập kết nối an toàn.

SNI giải quyết vấn đề này bằng cách cho máy khách truyền tên máy chủ như một phần của đàm phán TLS, để máy chủ nhận thức được máy chủ ảo nào sẽ được sử dụng để phục vụ kết nối. Sau đó, máy chủ có thể sử dụng chứng chỉ và cấu hình cho máy chủ ảo chính xác.

Tại sao không sử dụng các địa chỉ IP khác nhau?

Host:Tiêu đề HTTP được xác định để cho phép nhiều máy chủ Web được phục vụ từ một địa chỉ IP duy nhất do thiếu địa chỉ IPv4, được công nhận là sự cố sớm nhất là vào giữa những năm 1990. Trong môi trường lưu trữ web được chia sẻ, hàng trăm trang web độc đáo, không liên quan có thể được phục vụ bằng một địa chỉ IP duy nhất theo cách này, bảo tồn không gian địa chỉ.

Các môi trường lưu trữ được chia sẻ sau đó nhận thấy rằng người tiêu dùng không gian địa chỉ IP lớn nhất là nhu cầu các trang web bảo mật phải có địa chỉ IP duy nhất, tạo ra nhu cầu về SNI như một biện pháp ngăn chặn trên đường đến IPv6. Ngày nay, đôi khi rất khó để có được ít nhất 5 địa chỉ IP (/ 29) mà không có lý do chính đáng, thường dẫn đến sự chậm trễ triển khai.

Với sự ra đời của IPv6, các kỹ thuật bảo tồn địa chỉ như vậy không còn cần thiết nữa, vì một máy chủ duy nhất có thể có nhiều địa chỉ IPv6 được gán cho nó hơn toàn bộ Internet ngày nay, nhưng các kỹ thuật này có thể vẫn sẽ được sử dụng trong tương lai để phục vụ cho di sản IPv4 kết nối.

Hãy cẩn thận

Một số kết hợp hệ điều hành / trình duyệt không hỗ trợ SNI (xem bên dưới), vì vậy sử dụng SNI không phù hợp với mọi tình huống. Các trang web nhắm mục tiêu kết hợp hệ thống / trình duyệt như vậy sẽ phải từ bỏ SNI và tiếp tục sử dụng các địa chỉ IP duy nhất cho mỗi máy chủ ảo.

Đặc biệt lưu ý, không có phiên bản Internet Explorer nào trên Windows XP hỗ trợ SNI. Vì sự kết hợp này vẫn thể hiện một phần đáng kể (nhưng giảm dần, khoảng 16% lưu lượng truy cập Internet vào tháng 12 năm 2012 theo NetMarketShare) của lưu lượng truy cập Internet, SNI sẽ không phù hợp cho một trang web nhắm mục tiêu vào các nhóm người dùng này.

Ủng hộ

Nhiều, nhưng không phải tất cả, các gói phần mềm thường được sử dụng đều hỗ trợ SNI.

(Bỏ sót trong danh sách này không nhất thiết có nghĩa là thiếu hỗ trợ; điều đó có nghĩa là có giới hạn về số lượng tôi có thể nhập hoặc tôi không thể nhanh chóng tìm thấy thông tin trong tìm kiếm. Nếu gói phần mềm của bạn không được liệt kê, hãy tìm kiếm cho tên của nó cộng với snisẽ tiết lộ nếu có hỗ trợ và cách thiết lập nó.)

Hỗ trợ thư viện

Hầu hết các gói phụ thuộc vào thư viện bên ngoài để cung cấp hỗ trợ SSL / TLS.

• GNU TLS
• JSSE (Oracle Java) 7 trở lên, chỉ với tư cách là khách hàng
• libcurl 7.18.1 trở lên
• NSS 3.1.1 trở lên
• OpenSSL 0.9.8j trở lên
  • OpenSSL 0.9.8f trở lên, có cờ cấu hình
• Qt 4,8 trở lên

Hỗ trợ máy chủ

Hầu hết các phiên bản hiện tại của phần mềm máy chủ phổ biến đều hỗ trợ SNI. Hướng dẫn thiết lập có sẵn cho hầu hết những điều này:

• Apache 2.2.12 trở lên
• Máy chủ lưu lượng truy cập Apache 3.2.0 trở lên
• Cherokee
• HAProxy 1.5 trở lên
• IIS 8.0 trở lên
• lighttpd 1.4.24 trở lên
• LiteSpeed ​​4.1 trở lên
• nginx 0,5,32 trở lên

Hỗ trợ khách hàng

Hầu hết các trình duyệt web hiện tại và tác nhân người dùng dòng lệnh đều hỗ trợ SNI.

Máy tính để bàn

• Chrome 5 trở lên
  • Chrome 6 trở lên trên Windows XP
• Firefox 2 trở lên
• Internet Explorer 7 trở lên, chạy trên Windows Vista / Server 2008 trở lên
  • Internet Explorer trên Windows XP không hỗ trợ SNI bất kể phiên bản IE
• Konqueror 4.7 trở lên
• Opera 8 trở lên (có thể yêu cầu bật TLS 1.1 để hoạt động)
• Safari 3.0 trên Windows Vista / Server 2008 trở lên hoặc Mac OS X 10.5.6 trở lên

Điện thoại di động

• Trình duyệt Android trên 3.0 Honeycomb trở lên
• iOS Safari trên iOS 4 trở lên
• Windows Phone 7 trở lên

Dòng lệnh

• cURL 7.18.1 trở lên
• wget 1,14 trở lên (Bản phân phối có thể đã đưa ra một bản vá cho hỗ trợ SNI)

Không có hỗ trợ

• Trình duyệt BlackBerry
• Internet Explorer (mọi phiên bản) trên Windows XP

(Lưu ý: Một số thông tin cho câu trả lời này được lấy từ Wikipedia .)

Vấn đề:

Khi một máy khách web và một máy chủ web nói chuyện với nhau qua HTTPS, điều đầu tiên cần phải xảy ra là bắt tay an toàn.

Dưới đây là một ví dụ đơn giản về một cái bắt tay như vậy:

Nếu đây là HTTP và không phải HTTPS, điều đầu tiên khách hàng gửi sẽ là một thứ như thế này:

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

Điều này làm cho nhiều máy chủ ảo trên một địa chỉ IP duy nhất có thể, vì máy chủ biết chính xác miền mà khách hàng muốn truy cập, cụ thể là example.com.

HTTPS thì khác. Như tôi đã nói trước đó, cái bắt tay đến trước mọi thứ khác. Nếu bạn nhìn vào bước thứ ba của cái bắt tay được minh họa ở trên (Chứng chỉ), máy chủ cần xuất trình chứng chỉ cho khách hàng như một phần của cái bắt tay, nhưng không biết khách hàng đang cố truy cập tên miền nào. Tùy chọn duy nhất mà máy chủ có là gửi cùng một chứng chỉ mỗi lần, chứng chỉ mặc định của nó.

Bạn vẫn có thể thiết lập máy chủ ảo trên máy chủ web của mình, nhưng máy chủ sẽ luôn gửi cùng một chứng chỉ cho mỗi máy khách. Nếu bạn đã cố gắng lưu trữ cả các trang web example.com và example.org trên máy chủ của mình, máy chủ sẽ luôn gửi chứng chỉ cho example.com khi khách hàng yêu cầu kết nối HTTPS. Vì vậy, khi khách hàng yêu cầu example.org qua kết nối HTTPS đã thiết lập, điều này sẽ xảy ra:

Vấn đề này giới hạn hiệu quả số lượng tên miền bạn có thể lưu trữ trên HTTPS thành một tên miền trên mỗi địa chỉ IP.

Giải pháp:

Cách dễ nhất để giải quyết vấn đề này là máy khách báo cho máy chủ biết tên miền nào nó muốn truy cập trong quá trình bắt tay . Bằng cách này, máy chủ có thể phục vụ đúng chứng chỉ.

Đây chính xác là những gì SNI hoặc Chỉ định Tên Máy chủ thực hiện.

Với SNI, máy khách sẽ gửi tên máy chủ mà nó muốn truy cập như một phần của tin nhắn đầu tiên, bước "Xin chào khách hàng" trong sơ đồ bắt tay ở trên.

Một số trình duyệt web cũ hơn không hỗ trợ SNI. Chẳng hạn, trên Windows XP không có một phiên bản Internet Explorer nào hỗ trợ SNI. Khi truy cập tài nguyên qua HTTPS trên máy chủ sử dụng máy chủ ảo SNI, bạn sẽ được cung cấp chứng chỉ chung, điều này có thể khiến trình duyệt hiển thị cảnh báo hoặc lỗi.

Tôi đã đơn giản hóa mọi thứ ở đây để chỉ giải thích nguyên tắc đằng sau vấn đề và giải pháp. Nếu bạn muốn giải thích kỹ thuật hơn, trang wikipedia hoặc RFC 6066 có thể đóng vai trò là điểm khởi đầu tốt. Bạn cũng có thể tìm thấy cập nhật danh sách các máy chủ và trình duyệt hỗ trợ SNI trên wikipedia

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

Trình duyệt máy khách cũng phải hỗ trợ SNI. Dưới đây là một số trình duyệt thực hiện:

* 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 

Phần mở rộng TLS chỉ định tên máy chủ (RFC6066) là bắt buộc để các vhost dựa trên tên hoạt động trên HTTPS.

Tiện ích mở rộng được triển khai rộng rãi và tôi chưa gặp phải bất kỳ sự cố nào với phần mềm hiện tại, nhưng có khả năng một số khách hàng (những khách hàng không hỗ trợ) sẽ được chuyển đến trang web mặc định của bạn nếu bạn phụ thuộc vào SNI.