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

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

Я хотел понять, есть ли у моей компании-арендатора сертификат SSL с подстановочными знаками, будет ли он работать с этой настройкой или новый сертификат SSL должен быть приобретен для docs.tenantcompany.com ?

Краткий ответ: Нет. Если у вашей компании-арендатора есть подстановочный знак в имени *. Tenantcompany.com , этого достаточно для установки на вашем сервере, чтобы перекрыть доступ через это имя. . Хотите ли вы сделать это или нет - это совсем другой вопрос.

Сертификат в имени docs. .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-адрес. Если существует 20 псевдонимов CNAME в DNS между исходной записью и записью A ​​или AAAA , преобразователь DNS будет следовать за ними, пока не будет получен IP-адрес. .

TLS

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

Помните: браузер не заботится о документах. .mycompany.com - преобразователь DNS абстрагировал все сведения об косвенном обращении через CNAME запись.

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

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

Совместное использование ключей

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

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

Маскировка

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