Вопрос или проблема
Мне нужны советы или рекомендации по значению SAN в сертификатах.
Вот контекст:
У нас есть 2 сервера, которые хостят одно и то же приложение (кластерное приложение в режиме active-active). Сверху у нас есть внешний TCP балансировщик нагрузки, который просто действует как TCP реле для одного или другого сервера.
Типичный сценарий таков:
пользователь будет запрашивать балансировщик нагрузки, а балансировщик нагрузки будет передавать запрос одному или другому серверу (конфигурация round robin)
-
IP балансировщика нагрузки 10.10.10.1, а его имя lb.mydomain.net
-
IP сервера 1 для пользователя 10.10.11.1, а его FQDN server1.mydomain.net
-
IP сервера 1 для администратора 10.10.11.2, а его FQDN server1-admin.mydomain.net
-
IP сервера 2 для пользователя 10.10.11.3, а его FQDN server2.mydomain.net
-
IP сервера 2 для администратора 10.10.11.4, а его FQDN server2-admin.mydomain.net
Как обычно, мы настраиваем SSL сертификат на наших хостах/приложениях, но в этом случае я не уверен, какая конфигурация будет подходить:
Сценарий 1: создать сертификат с lb.mydomain.net в качестве CN и значениями SAN: server1.mydomain.net, server1-admin.mydomain.net, server2.mydomain.net и server2-admin.mydomain.net
Сценарий 2: создать тот же сертификат, но добавив все IP. Однако, по всей видимости, это не очень безопасно согласно этой статье
Какова должна быть лучшая практика?
Большое спасибо!
Если ваш балансировщик нагрузки поддерживает завершение TLS (обработка), то балансировщику нагрузки нужно только одно имя в его сертификате: lb.mydomain.net. Поскольку балансировщик нагрузки действует как абстрактный уровень, отдельные имена узлов не видны клиентам и не требуется, чтобы они были представлены в сертификате балансировщика нагрузки. Отдельные узлы NLB должны иметь сертификат, содержащий только имя сервера в серверном сертификате:
Когда клиент подключается к вашему приложению, устанавливаются два отдельных соединения (и TLS-сессии):
- Между клиентом и NLB. Всё, что находится за NLB, в действительности не видно клиенту.
- Между NLB и узлом бэкенда. Узлы бэкенда вообще не знают, что есть что-то перед NLB.
Если ваш NLB не поддерживает завершение TLS, то он действует как прозрачный мост и просто передает трафик между клиентом, тогда у каждого узла должен быть сертификат с именем lb.mydomain.net в сертификате SAN. Балансировщик нагрузки будет полностью прозрачен для всех, клиентов и узлов NLB. Эта конфигурация менее распространена и подходит для совершенно бессостояних приложений или приложений, которые реплицируют внутреннее (включая сеансовое) состояние друг с другом.
Что касается сценария 2, то вы вообще не должны его использовать. Подключение к приложениям по IP никогда не было хорошей идеей, если у вас работает DNS. Идея использовать IP как резервный вариант на случай сбоя DNS: предупреждения или ошибки TLS – это ваша меньшая проблема. Используйте только DNS-имена для подключения ваших сетевых приложений. Тогда вы указываете только DNS-имена в сертификатах. Привязка к IP убивает цель DNS и делает адресацию IP еще более сложной, поскольку IP жестко запрограммирован где-то на клиенте, и вы не сможете изменить IP сервера без перенастройки клиентов.
Ответ или решение
Лучшие практики для SAN значений сертификатов при использовании TCP Load Balancer
При настройке системы с использованием TCP Load Balancer и нескольких серверов, важно правильно управлять SSL-сертификатами для обеспечения безопасного доступа. Независимо от того, какой сценарий вы выберете, правильное применение SAN (Subject Alternative Name) значений является критически важным для поддержания безопасности и стабильности вашей системы.
Контекст
В вашем окружении имеется:
- TCP Load Balancer с именем
lb.mydomain.netи IP-адресом10.10.10.1. - Два сервера с именами
server1.mydomain.netиserver2.mydomain.netдля пользователей и их администраторами сserver1-admin.mydomain.netиserver2-admin.mydomain.net. - Два IP-адреса для каждого сервера.
Вы рассматриваете два сценария для настройки сертификатов:
-
Сценарий 1: Сертификат для Load Balancer, где CN (Common Name) – это
lb.mydomain.net, а SAN значения включаютserver1.mydomain.net,server1-admin.mydomain.net,server2.mydomain.netиserver2-admin.mydomain.net. -
Сценарий 2: Аналогичный сертификат, но с добавлением IP-адресов серверов, что, как вы заметили, может быть менее безопасным.
Рекомендации
Поддержка TLS Termination
Если ваш Load Balancer поддерживает TLS termination (обработка SSL на уровне Load Balancer), сертификат должен содержать только одно имя: lb.mydomain.net. В этом случае Load Balancer становится абстракцией, и имена отдельных серверов остаются невидимыми для клиентов. Это избавляет от необходимости добавлять SAN значениями отдельные имена серверов, что упрощает управление сертификатами и повышает их безопасность.
При использовании TLS termination клиент устанавливает два отдельных соединения:
- Соединение между клиентом и Load Balancer.
- Соединение между Load Balancer и бэкенд-сервером.
В данной архитектуре важно, чтобы бэкенд-серверы имели собственные сертификаты, содержащие только их имена. Это обеспечит защиту внутреннего трафика и упростит управление сертификатами на уровне серверов.
Отсутствие TLS Termination
Если ваш Load Balancer не поддерживает TLS termination и просто передает трафик, в таком случае каждый сервер должен иметь сертификат, который включает в себя имя lb.mydomain.net в SAN. Это делает Load Balancer прозрачным для клиентов и серверов. Однако такая конфигурация менее распространена и рекомендуется только для полностью безсостояний (stateless) приложений.
Использование IP-адресов в сертификатах
В сценарии 2 необходимо избегать добавления IP-адресов в сертификаты. Использование IP для подключения к приложениям не рекомендуется, так как это усложняет администрирование и не соответствует принципам работы DNS. Если DNS настраивается корректно, использование IP-адресов превращает конфигурацию в запутанную систему, где изменение адресов потребует дополнительных настроек на стороне клиента.
Вместо этого рекомендуется использовать только DNS-имена в сертификатах. Это не только безопаснее, но и обеспечивает большую гибкость при изменении инфраструктуры.
Заключение
Рекомендую вам использовать первый сценарий, при условии что Load Balancer поддерживает TLS Termination. Если это невозможно, убедитесь, что имя Load Balancer присутствует в сертификатах всех серверов. Избегайте добавления IP-адресов в сертификаты, сосредоточив усилия на правильной настройке DNS. Это обеспечит безопасность и упрощение управления сертификатами в долгосрочной перспективе.