Действительно ли возможно использовать только 1 сертификат SSL через 4 Виртуальных машины?

Это возможно, если у вас есть дополнительный компьютер, отвечающий за завершение SSL-соединения и проксирование трафика с этих 4 машин в Интернет. . Обратите внимание, что трафик между прокси-сервером и виртуальными машинами не будет зашифрован. Это называется прокси завершения SSL.

Ваш вопрос немного расплывчатый, поскольку вы не указываете, чего хотите достичь.

Если вы говорите о HTTP, это было бы возможно в настройке с балансировкой нагрузки, где каждый сервер использует одно и то же имя хоста (через балансировщик нагрузки). Это обычное дело, и вы устанавливаете один и тот же сертификат на каждом сервере (помните, что вы не можете повторно выпустить сертификат для каждого сервера!). Однако я действительно не вижу здесь выгоды, зачем вам виртуализировать 4 машины на одной физической машине, а затем балансировать нагрузку на них трафиком?

Второй вариант - использовать специальный сертификат SSL, a " wildcard "сертификат, который будет выдан на * .yourdomain.com и будет считаться действительным для любого вспомогательного хоста вашего домена. Это стоит намного дороже, и параноики могут не считать его таким же надежным, как «фиксированный» SSL-сертификат. Я лично использую это для внутренних служб, где мне все равно, и я просто хочу избавиться от предупреждений.

Это может быть интересно для вас: Можно ли повторно использовать сертификат SSL на разных платформах?

Помните, что разные сертификаты SSL имеют разные модели лицензирования. Некоторые из них «на сервер», а некоторые - «на домен» или «неограниченное количество серверов». Прочтите мелкий шрифт.

Помните, что разные сертификаты SSL имеют разные модели лицензирования. Некоторые из них «на сервер», а некоторые - «на домен» или «неограниченное количество серверов». Прочтите мелкий шрифт.

Помните, что разные сертификаты SSL имеют разные модели лицензирования. Некоторые из них - «на сервер», а некоторые - «на домен» или «неограниченное количество серверов». Прочтите мелкий шрифт.

Я думаю, вам нужно лучше понимать, для чего нужен SSL и как он работает.

SSL реализует несколько функций безопасности, среди которых есть те, которые важны для вас:

• Шифрование данных в пути.
• Аутентификация одного или обоих концов соединения.

(есть другие функции, например, сжатие или согласование безопасного ключа, но на самом деле это вас не волнует).

Часть, которая вызовет у вас проблемы, - это вторая: аутентификация. В частности, серверная сторона аутентификации (другими словами, как клиент удостоверяет, что он обращается к «правильному» серверу).

Для этого SSL полагается на две вещи: сертификат X509 и систему DNS . Он выполняет это посредством следующих шагов:

1. Он использует имя хоста (например, www.mysecureservice.com), предоставленное пользователем или приложением, для получения IP-адреса через разрешение DNS клиента.
2. Он открывает TCP-соединение с этот сервер и запрашивает сертификат X509 удаленной машины (на практике обычно предоставляется несколько сертификатов, но давайте предположим, что есть только один для простоты).
3. Он проверяет подлинность сертификата. Для этого он использует собственные внутренние правила (поскольку сейчас это не так важно и довольно сложно, я не буду подробно останавливаться на том, как именно).
4. Он проверяет, что имя внутри сертификата X509, полученного от сервера, совпадает с именем хоста, которое он использовал на шаге 1 для определения IP-адреса.

Если имя хоста не совпадает, SSL соединение не будет подтверждено. В зависимости от того, какое программное обеспечение использует соединение, оно может вызвать простое предупреждение системы безопасности или вообще отказать в соединении.

Другой механизм, о котором вы должны знать, - это то, что установка SSL-соединения требует больших затрат на ЦП и пропускную способность, поэтому SSL-соединения обычно держится довольно долго. Кроме того, между клиентом и сервером существует «сильная связь», которая делает (почти) невозможным для клиента сменить сервер после того, как он установил соединение SSL, без его полного разрыва и перезапуска с нуля. На самом деле это не проблема с протоколами с сохранением состояния, потому что на сервере все равно должно поддерживаться большее количество элементов состояния, но для протоколов без сохранения состояния (например, HTTP) это означает, что установление SSL-соединения может нарушить балансировку нагрузки.

Теперь к вам вопрос напрямую.

Перво-наперво: вы не можете «совместно использовать» сертификат X509 между хостом и гостевой ОС, поскольку сертификат «установлен» непосредственно на машине. Однако технически вы можете сделать любое из следующего:

• Установите один и тот же сертификат (с тем же именем хоста) на все виртуальные машины, а затем используйте циклический перебор DNS или любой другой тип балансировки сетевой нагрузки для перенаправления пользователей на одна виртуальная машина другой. Это, конечно, предполагает, что все виртуальные машины взаимозаменяемы.
• Установите обратный прокси-сервер на хосте (не рекомендуется), в другой виртуальной машине или на другом устройстве перед вашим хостом (лучшее решение). Этот обратный прокси-сервер получит SSL-соединение, расшифрует его и отправит запрос к одной из виртуальных машин на основе любого установленного вами правила. Однако это будет (почти) работать только в том случае, если то, что вы хотите предложить через SSL-соединение, является содержимым HTTP, а также требует, чтобы серверная система была совместима с этой схемой.
• Настройте так называемую «SSL VPN». на хосте (опять же, не рекомендуется), другой гостевой виртуальной машине или каком-то устройстве перед всем этим. Этот тип настройки более сложен, потому что все зависит от того, какой протокол вы хотите инкапсулировать в SSL-соединение и какой сценарий использования вы ожидаете.

Если этого объяснения недостаточно, не могли бы вы уточнить, что именно вы хотите защитить с помощью инкапсуляции SSL?