Я внедряю мультитенантное приложение, где мое приложение размещает и обслуживает техническую документацию для продукта арендатора.

Теперь, тот подход , который я рассматривал был - я у себя документацию на docs.<tenant>.mycompany.comи попросить мой арендатор настроить запись CNAME DNS в точку 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 как черный ящик. Он обращается к подходящей библиотеке DNS, чтобы запросить сопоставление дружественного полного доменного имени (FQDN) с подходящим IP-адресом (v4 или v6). Неважно, как он получает этот IP-адрес. Если CNAMEв DNS существует 20 псевдонимов между исходной записью и записью Aили AAAA, распознаватель DNS будет следовать за ними, пока не будет получен IP-адрес.

TLS

Когда браузер выполняет квитирование TLS , он должен убедиться , что сервер он обменивается данными с уполномочивается предоставлять безопасное обслуживание сайта на полное доменное имя с просьбой: docs.tenantcompany.com.

Помните: браузер не заботится о docs.<tenant>.mycompany.comтом, что DNS-распознаватель забрал все записи об косвенности через CNAMEзапись.

Наш метод авторизации сервера для обслуживания защищенных сессий docs.tenantcompany.com- это использование SSL-сертификата, который подписан органом, которому в хранилище корневых сертификатов браузера было установлено предварительное доверие. Это не всегда самая сильная форма аутентификации сервера к клиенту - многие могут пойти не так в модели централизованного ЦС - но это лучшее, что у нас есть на данный момент.

Здесь есть еще два предостережения:

Обмен ключами

Многие коммерческие поставщики SSL-сертификатов подписывают только один запрос на подпись, который эффективно связывает подстановочный сертификат с одним закрытым ключом. Компании-арендатору может быть нелегко делиться этим вне своей организации, поскольку любой, кто владеет закрытым ключом, может явно поставить под угрозу связь с другими защищенными системами компании-арендатора.

Некоторые поставщики подписывают несколько запросов на подпись сертификатов под одним и тем же сертификатом, что позволяет устанавливать один групповой сертификат на нескольких серверах и системах без совместного использования закрытого ключа между ними.

Masquerading

Если компания-арендатор предоставит вам копию своего сертификата с подстановочными знаками (либо поделившись закрытым ключом, либо подписав свой собственный CSR), вы можете маскироваться под него <anydomain>.tenantcompany.com, нарушая важную защиту, которая обеспечивает целостность серверов, идентифицированных в tenantcompany.comпространстве имен DNS. Это может быть плохим положением как для вас, так и для компании-арендатора, с точки зрения юридической ответственности.