Нужен ли отдельный сертификат SSL для перенаправления DNS?

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

Теперь, тот подход , который я рассматривал был - я у себя документацию на docs.<tenant>.mycompany.comи попросить мой арендатор настроить запись CNAME DNS в точку docs.tenantcompany.comк docs.<tenant>.mycompany.com.

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

— codematix
источник

Просто чтобы уточнить, у вас есть шаблон для * .mycompany.com?

— Зиман

@WildVelociraptor да у меня есть сертификат SSL для подстановочного знака для*.mycompany.com

— codematix

@codematix Во избежание каких-либо сомнений, подстановочный сертификат для *.example.com не будет совпадать docs.tenantname.example.com ! Подстановочный знак подходит только для одного «поддомена»; это будет соответствовать docs-tenantname.example.com , например. Хороший пример тому - Amazon S3: *.s3.amazonaws.comсертификат завершается ошибкой при доступе к корзине с точкой, например www.example.com(которая заканчивается именем хоста www.example.com.s3.amazonaws.com); такие имена групп требуются для веб-хостинга S3.

— Calrion

Обратите внимание, что использование cname, указывающего на ваш собственный сервер, означает, что вы можете избежать необходимости предоставления предоставленного арендатором сертификата. Некоторые поставщики сертификатов (включая letsencrypt.org ) поддерживают проверку владения доменом через https. Что касается рекомендаций по безопасности, этот подход намного превосходит (уже обсуждался на serverfault.com/a/765957/4480 ). Можно позволить своему арендатору предоставить свой собственный сертификат (хотя самому арендатору его проще создать), но они НЕ ДОЛЖНЫ предоставлять подстановочный сертификат.

— Брайан

Ответы:

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

Если docs.tenantcompany.comэто CNAME foo.example.com, сертификат не нужно покрывать foo.example.com, просто docs.tenantcompany.com.

— Джейсон Мартин
источник

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

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

— Райан Болджер
источник

Спасибо, что поправили меня. Вы правы, это не перенаправление, а псевдоним CNAME.

— codematix

У моего клиента есть Server Aдомен example.com. Я сделал для него сайт и поддерживал сайт в Server B. Мой клиент настроил свой DNS, A Recordкоторый указывает dog.example.comна IP-адрес моего сервера Server B. Теперь мой клиент получает SSL для dog.example.com. У меня вопрос, должен ли мой клиент выдать мне сертификат SSL, чтобы он был внутри Server B? Или он просто должен это вставить Server A? Или что еще мы должны сделать? Мы оба смущены этим, спасибо!

— user2875289

Если запись A dog.example.comуказывает на IP-адрес вашего сервера, то да. Ваш сервер должен содержать сертификат и закрытый ключ для этого имени. Сервер А в вашем примере не имеет значения.

— Райан Болджер

@RyanBolger Да, как ты и сказал. Мой клиент применил сертификат dog.example.comи отправил мне сертификат и закрытый ключ. Я помещаю их внутрь Server Bи настраиваю Nginx для их использования. И все теперь отлично работает. Спасибо вам!

— user2875289

Просто примечание по техническому вопросу; поскольку сейчас есть записи "ALIAS", я бы не сказал, что CNAME также являются псевдонимами;]

— Гарет Клэборн

Я хотел понять, есть ли у моей компании-арендатора 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. Это может быть плохим положением как для вас, так и для компании-арендатора, с точки зрения юридической ответственности.

— Космический оссифраж
источник

Большое спасибо за подробный ответ. Это очень помогло и помогло мне рассмотреть этические и юридические аспекты того, что я пытаюсь сделать.

— codematix