Моя ситуация:
Server A
и Server B
.Server A
настроили прокси, который служит данным (по SSL) от Server B
.Server B
достижимо через 1.1.1.1
(one.server.example.com
) и 2.2.2.2
(two.server.example.com
). Server A
решает, какое соединение это должно использовать для соединения (обработка отказа).Server B
настроен с виртуальным хостом server.example.com
и имеет два псевдонима, one.server.example.com
и two.server.example.com
.Я хотел бы знать, должен ли я купить два сертификата SSL (потому что мы соединяемся с обоими one.server.example.com
и two.server.example.com
), или если Вы будете достаточны потому что one.server.example.com
и two.server.example.com
просто псевдонимы server.example.com
.
Кроме того, если это не 'рекомендуемый' способ настроить такие вещи, сообщите мне. Никогда не делал это прежде..
Есть несколько способов обойти это:
Получить wildcard сертификат: Это позволяет использовать любое количество первичных поддоменов, однако, это может быть несколько дорогостоящим.
ALT имена в сертификате: Альтернативные имена в сертификатах обычно более дешевая опция, позволяющая указать разрешенные домены/субдодомены, которые можно использовать для сертификата
Если это бэкэндная (не публичная) служба на сервере B, то вы можете быть собственным центром сертификации и установить соответствующее доверие сертификации на сервере A. Это практически бесплатно, но требует немного больше работы?
Похоже, вы неправильно реализовали обход отказа. Здесь вы просто используете два IP-адреса на одном сервере и указываете на него два доменных имени. Если сервер B
выйдет из строя, где избыточность?
Взгляните на мосты маршрутизаторов и реализации VRRP типа keepalived.
После этого, если вы хотите разместить несколько доменных имён на одном IP, используя VRRP за кулисами, то решение принимается из поддержки подключения на стороне клиента: поддерживает ли оно расширение TLS SNI, поддерживает ли оно расширение X509 SubjAltName
или нет. Самым общим решением, конечно же, является использование подстановочного сертификата