Чи потрібен окремий сертифікат SSL для переадресації DNS?

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

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

Я хочу, щоб на сайті було включено SSL із сертифікатом мого орендаря. Мені хотілося зрозуміти, чи є у моєї компанії-орендаря сертифікат SSL-макіяжу, чи буде вона працювати з цією установкою чи потрібно буде придбати новий сертифікат SSL docs.tenantcompany.com?

— кодематікс
джерело

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

— Зімхан

@WildVelociraptor Так, у мене є wildcard SSL cert для*.mycompany.com

— codematix

@codematix Щоб уникнути будь-яких сумнівів, сертифікат wildcard для *.example.com не відповідає docs.tenantname.example.com ! Підстановка підходить лише для одного "піддомену"; воно буде відповідати docs-tenantname.example.com , наприклад. S3 Amazon є хорошим прикладом цього: *.s3.amazonaws.comсертифікат виходить з ладу під час доступу до відра з періодом, наприклад www.example.com(що закінчується ім'ям хоста, як www.example.com.s3.amazonaws.com); такі імена відра потрібні для веб-хостингу S3.

— Calrion

Зауважте, що використання імені, яке вказує на ваш власний сервер, означає, що ви можете уникнути необхідності отримати сертифікат, наданий орендарем. Деякі постачальники сертифікатів (включаючи letsencrypt.org ) підтримують підтвердження права власності на домен через https. Що стосується найкращих практик безпеки, цей підхід є набагато вищим (вже обговорювалося на сервері defaultfault.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? Або що ще нам робити? Ми обоє з цим збентежені, дякую!

— користувач2875289

Якщо запис A dog.example.comвказує безпосередньо на IP вашого сервера, то так. Ваш сервер повинен містити сертифікат та приватний ключ для цього імені. Сервер A у вашому прикладі не має значення.

— Райан Болгер

@RyanBolger Так, як ви сказали. Мій клієнт застосував сертифікат dog.example.comі надіслав мені та приватний ключ. Я помістив їх всередину Server Bі налаштував Nginx на їх використання. І зараз все працює добре. Дякую тобі!

— користувач2875289,

Просто примітка про технічну характеристику; оскільки зараз є записи "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-сертифіката, який підписується органом, якому попередньо довіри було встановлено у кореневому магазині сертифікатів браузера. Це не завжди найсильніша форма аутентифікації сервера до клієнта - партії можуть піти не так у централізованій моделі CA - але це найкраще, що ми маємо на даний момент.

Тут є ще два застереження:

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

Багато постачальників комерційних сертифікатів SSL підписують лише один запит на підписання, що ефективно пов'язує сертифікат підстановки з одним приватним ключем. Компанія-орендар може нелегко ділитися цим за межами своєї організації, оскільки кожен, хто володіє приватним ключем, очевидно, може порушити спілкування з іншими захищеними системами компанії-орендаря.

Деякі постачальники будуть підписувати кілька запитів на підписання сертифікатів під одним і тим же сертифікатом, що дозволяє встановлювати один сертифікат підстановки на декілька серверів і систем без спільного використання приватного ключа між ними.

Маскування

Якщо компанія-орендар надає вам копію сертифікату підстановки (шляхом спільного доступу до приватного ключа або підписання власного КСВ), ви можете маскуватися як <anydomain>.tenantcompany.com, порушуючи важливий захист, що забезпечує цілісність серверів, визначених у tenantcompany.comпросторі імен DNS. Це може бути поганим становищем як для вас, так і для орендарної компанії, з точки зору юридичної відповідальності.

— Космічна костінь
джерело

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

— codematix