Це канонічне запитання щодо розміщення декількох веб-сайтів SSL на одному IP.

У мене було враження, що кожен сертифікат SSL вимагає власної унікальної комбінації IP-адрес / порту. Але відповідь на попереднє запитання, яке я опублікував , суперечить цій претензії.

Використовуючи інформацію з цього запитання, мені вдалося отримати кілька сертифікатів SSL для роботи на одній і тій же IP-адресі та на порті 443. Я дуже збентежений, чому це працює, враховуючи припущення вище та підкріплене іншими, що кожен веб-сайт домену SSL на веб-сайті той же сервер вимагає власного IP / порту.

Я підозріло, що я щось зробив не так. Чи можна використовувати кілька сертифікатів SSL таким чином?

Для отримання найновішої інформації про Apache та SNI, включаючи додаткові HTC-специфічні RFC, зверніться до 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.

Так, але є деякі застереження.

Це здійснюється за допомогою індикації імені сервера, розширення на безпеку транспортного шару.

Що таке вказівка ​​імені сервера?

Вказівка ​​імені сервера ( RFC 6066 ; застарілий RFC 4366 , RFC 3546 ) - це розширення для безпеки транспортного шару, яке дозволяє клієнту повідомити серверу ім'я хоста, до якого він намагається досягти.

SNI сумісний з TLS 1.0 і вище відповідно до специфікації, але реалізація може відрізнятися (див. Нижче). Він не може бути використаний з SSL, тому з'єднання повинно узгоджувати TLS (див. RFC 4346, додаток E ) для використання SNI. Зазвичай це відбувається автоматично з підтримуваним програмним забезпеченням.

Для чого потрібен SNI?

У звичайному HTTP- з'єднанні браузер повідомляє сервер про ім’я хоста сервера, до якого він намагається встановити за допомогою Host:заголовка. Це дозволяє веб-серверу за однією IP-адресою обслуговувати вміст для кількох імен хостів, що зазвичай називається віртуальним хостингом на основі імен .

Альтернативою є призначення унікальних IP-адрес для кожного імені веб-хосту, що надається. Це зазвичай робилося в перші дні Інтернету, перш ніж було широко відомо, що IP-адреси закінчуються і починаються заходи збереження, і це все ще робиться таким чином для віртуальних хостів SSL (не використовуючи SNI).

Оскільки цей спосіб передачі імені хоста вимагає встановлення з'єднання, він не працює з SSL / TLS-з'єднаннями. До моменту встановлення захищеного з'єднання веб-сервер вже повинен знати, яке ім'я хоста буде служити клієнту, оскільки сам веб-сервер встановлює захищене з'єднання.

SNI вирішує цю проблему, передаючи клієнтові передачу імені хоста в рамках узгодження TLS, щоб сервер уже знав, який віртуальний хост повинен використовуватися для обслуговування з'єднання. Потім сервер може використовувати сертифікат та конфігурацію для правильного віртуального хоста.

Чому б не використовувати різні IP-адреси?

Host:Заголовок HTTP був визначений таким чином, щоб дозволяти обслуговувати більше одного веб-хоста з однієї IP-адреси через дефіцит IPv4-адрес, що було визнано проблемою ще в середині 1990-х. У спільних веб-хостингових середовищах сотні унікальних, не пов’язаних між собою веб-сайтів можуть обслуговуватися за допомогою однієї IP-адреси таким чином, зберігаючи адресний простір.

Тоді спільне середовище хостингу виявило, що найбільшим споживачем простору IP-адрес була потреба захищених веб-сайтів мати унікальні IP-адреси, що створює потребу в SNI як мірі зупинки проміжку на шляху до IPv6. Сьогодні іноді важко отримати лише 5 IP-адрес (/ 29) без істотного обґрунтування, що часто призводить до затримок розгортання.

З появою IPv6 такі методи збереження адрес більше не потрібні, оскільки один хост може мати більше IPv6 адрес, призначених йому, ніж весь Інтернет, який містить сьогодні, але методи, ймовірно, все ще будуть використовуватися далеко в майбутньому для обслуговування застарілого IPv4 з'єднання.

Коваджі

Деякі комбінації операційної системи / браузера не підтримують 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 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-браузер на сотовій версії 3.0 або вище
• iOS Safari на iOS 4 або новішої версії
• Windows Phone 7 або новішої версії

Командний рядок

• CURL 7.18.1 або вище
• wget 1.14 або вище (дистрибутиві можуть підтримувати виправлення для підтримки SNI)

Ніякої підтримки

• Браузер BlackBerry
• Internet Explorer (будь-яка версія) на Windows XP

(Примітка. Деякі відомості для цієї відповіді були отримані з Вікіпедії .)

Проблема:

Коли веб-клієнт та веб-сервер спілкуються між собою через 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 у wikipedia

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 необхідне для того, щоб витримки на основі імен працювали над HTTPS.

Розширення широко впроваджено, і я ще не маю жодних проблем із поточним програмним забезпеченням, але є ймовірність, що деякі клієнти (ті, що не підтримують його) будуть перенаправлені на ваш сайт за замовчуванням, якщо ви залежите від SNI.