Я внедряю мультитенантное приложение, в котором мое приложение размещает и обслуживает техническую документацию для продукта клиента.
Итак, подход, который я рассматривал, был таков: я размещаю документацию по адресу docs.<tenant>.mycompany.com и попросить моего клиента настроить DNS-запись CNAME для указания docs.tenantcompany.com к docs.<tenant>.mycompany.com.
Я хочу, чтобы на сайте был включен SSL с сертификатом моего клиента. Я хотел понять, есть ли у моей компании-арендатора сертификат SSL с подстановочными знаками, будет ли он работать с этой настройкой или нужно будет приобретать новый сертификат SSL для docs.tenantcompany.com?
Имя сертификата должно совпадать с тем, что пользователь ввел в браузере, а не с «последней» DNS-записью. Если пользователь входит docs.tenantcompany.com тогда ваш сертификат SSL должен покрыть это.
Если docs.tenantcompany.com CNAME для foo.example.com, сертификат делает не нужно прикрыть foo.example.com, просто docs.tenantcompany.com.
Ответ Джейсона правильный. Но чтобы немного уточнить термины, «перенаправление DNS» - это немного неправильное название. DNS имеет записи CNAME (также известные как псевдонимы), которые представляют собой имя, указывающее на другое имя. Но это не перенаправление. Преобразование имени в имя в IP происходит в фоновом режиме, и ваш браузер заботится только о начальном имени.
Единственное, что выполняет перенаправления, - это веб-серверы, на которых сервер явно указывает вашему браузеру перейти в другое место. Если ваш веб-сервер был фактически выполняя перенаправление на другое имя, вы бы на самом деле нужны сертификаты для обоих имен, потому что ваш браузер в конечном итоге будет подключаться к обоим по отдельности.
Я хотел понять, есть ли у моей компании-арендатора сертификат SSL с подстановочными знаками, будет ли он работать с этой настройкой или новый сертификат SSL должен быть приобретен для
docs.tenantcompany.com?
Короткий ответ: Нет. Если в названии вашей компании-арендатора есть подстановочный знак *.tenantcompany.com, этого достаточно для установки на вашем сервере, чтобы перекрыть доступ через это имя. Хочешь ты этого или нет - другой рассказ.
Сертификат на имя docs.<tenant>.mycompany.com (например, прямой сертификат или подстановочный знак *.<tenant>.mycompany.com) бесполезен, если доступ всегда осуществляется через docs.tenantcompany.com название.
Предположим, вы просматриваете https://docs.tenantcompany.com в разумном браузере. Браузер запускает TLS по протоколу HTTP. Его особенно интересуют две вещи; который:
Подсистема DNS браузера и операционной системы возвращает IP-адрес подходящего хоста, на котором запущен веб-сервер на подходящем порте где-то еще в локальной сети или в Интернете. Для HTTPS (защищенного) трафика порт по умолчанию 443 если иное не переопределено в URL-адресе.
Когда Рукопожатие TLS происходит между браузером и удаленным сервером, сервер представляет доверенный сертификат, который позволяет ему предоставлять службу TLS по запрошенному адресу (docs.tenantcompany.com).
Браузер видит DNS как черный ящик. Он обращается к подходящей библиотеке DNS, чтобы запросить отображение дружественного полного доменного имени (FQDN) в подходящий IP-адрес (v4 или v6). Его не волнует, как он получит этот IP-адрес. Если есть 20 CNAME псевдонимы в DNS между исходной записью и A или AAAA запись, преобразователь DNS будет следовать за ними, пока не будет получен IP-адрес.
Когда браузер выполняет Рукопожатие TLS, ему необходимо убедиться, что сервер, с которым он обменивается данными, авторизован для предоставления услуги безопасного веб-сайта по запрошенному FQDN: docs.tenantcompany.com.
Помните: браузер не заботится о docs.<tenant>.mycompany.com - преобразователь DNS абстрагировал все сведения о косвенном обращении через CNAME запись.
Наш метод авторизации сервера для обслуживания безопасных сеансов на docs.tenantcompany.com осуществляется посредством сертификата SSL, который подписывается органом, для которого в корневом хранилище сертификатов браузера установлено предварительное доверие. Это не всегда самая надежная форма аутентификации между сервером и клиентом - в централизованной модели ЦС многое может пойти не так, - но это лучшее, что у нас есть на данный момент.
Здесь есть еще два предостережения:
Многие поставщики коммерческих сертификатов SSL подписывают только один запрос на подпись, который фактически связывает групповой сертификат с одним закрытым ключом. Компании-арендатору может быть непросто делиться этим за пределами своей организации, поскольку любой, кто владеет закрытым ключом, очевидно, может поставить под угрозу обмен данными с другими защищенными системами компании-арендатора.
Некоторые поставщики подписывают несколько запросов на подпись сертификатов одним и тем же сертификатом, что позволяет устанавливать один подстановочный сертификат на нескольких серверах и системах без совместного использования секретного ключа между ними.
Если компания-арендатор предоставляет вам копию своего сертификата с подстановочными знаками (либо путем предоставления закрытого ключа, либо путем подписания собственного CSR), вы можете замаскироваться под <anydomain>.tenantcompany.com, разрушая важную защиту, которая обеспечивает целостность серверов, указанных в tenantcompany.com Пространство имен DNS. Это может быть плохой позицией как для вас, так и для компании-арендатора с точки зрения закона / ответственности.