Многодоменный подстановочный знак SSL, отображающий несколько приложений службы приложений Azure

Question

У меня есть следующие (запланированные) настройки:

1. Веб-сайт: domain.com (страница Wordpress, размещенная на GoDaddy, включен стандартный сертификат SSL)
2. API: x.domain.com указывает на x.azurewebsites.net через запись CNAME
3. Клиент 1: a.x.domain.com (клиент 1) указывает на a.azurewebsites.net через запись CNAME
4. Клиент 2: b.x.domain.com (клиент 2) указываетb.azurewebsites.net через запись CNAME
5. Клиент 3: c.x.domain.com (клиент 3), указывающий на c.azurewebsites.net через запись CNAME

Поскольку Safari имеет более строгую политику в отношении файлов cookie (по сравнению сChrome, FF, Edge), нам нужно будет разместить API в том же домене и клиентов в соответствующих поддоменах, поэтому запланированные шаги 2-5.

У нас есть 4 (x, a, b,c) запущены службы приложений Azure (linux). Каждый разделен на промежуточную и производственную среду (один и тот же экземпляр, разные домены).

Псевдонимы CNAME и сопоставление пользовательских доменов в службе Azure Web App уже работают. IP-запись A по-прежнему указывает на веб-сайт Wordpress.

Следующим шагом является привязка необходимых сертификатов SSL . Здесь я определил разные варианты, но не уверен, какой из них будет работать, а какой - рекомендуемый / лучший вариант:

Вариант 1 : поддержка GoDaddy рекомендуется купить 8стандартные SSL-сертификаты (4 услуги * 2 для постановки и производства). Для меня это звучит как излишнее и, вероятно, является самым дорогим, хотя и гибким решением.

Вариант 2 : мы покупаем второй домен (например, domain2.com), запускаем API xи назначьте Клиентов 1-3 (a.domain2.com, b.domain2.com, c.domain2.com) в качестве поддоменов первого уровня. (2.1) В таком случае, действительно ли можно использовать один подстановочный SSL-сертификат в нескольких экземплярах Azure? (2.2) Поскольку строгая политика cookie Safari требует, чтобы API был на уровне домена выше, чем клиенты, нам потребуется третий домен (+ сертификат) для подготовки (помимо производства) ... Или может multi-доменный подстановочный SSL-сертификат разрешить этот сценарий?

Вариант 3 : если ответ на вопрос 2.1 - «нет», мы можем объединить 4 веб-приложения Azureв один кластер Kubernetes и затем использовать 2 подстановочных SSL-сертификата в одном и том же экземпляре (1 этап, 1 продукт).

Вариант 4 : я успешно использую Let's encrypt для нескольких частных веб-сайтов,но я немного не решаюсь использовать их в коммерческих услугах. Azure имеет неофициальное расширение для управления и расширения. Давайте зашифруем сертификаты. Это то, что мы должны рассмотреть, и каковы недостатки?

Лично я думаю, что вариант 2 был бы лучшим, так как он не требовал бы перенастройки наших сервисов (как вариант 3). Помните, что веб-сайт (корневой домен) не расположен на Azure;хотя при необходимости мы могли бы переместить его в Azure.

Или есть 5-й вариант, который мне не хватает?

Answer 1

Есть опция, которую вы упускаете.

При условии, что x является статическим в вашем случае, тогда вы можете получить один групповой сертификат для *.x.domain.com.

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

В вашем случае вы будете использовать сертификат только в Azure, и у вас будет общая поверхность атаки для всех приложений. Поэтому было бы хорошо использовать подстановочный сертификат.

Если бы x были переменной и именем хоста нижнего уровня, вам не повезло. RFC 6125 требует, чтобы клиенты, проверяющие сертификаты, оценивали использование подстановочного знака только в самой левой (нижний уровень) части имени домена. Например. *.x.domain.com действует, но a.*.domain.com - нет.

Спонсором Let's Encrypt являются некоторые из крупнейших игроков отрасли. Если вы можете преодолеть короткий срок действия с помощью автоматизации, я очень рекомендую их. Теперь им доверяют все основные браузеры и операционные системы. У меня был успех с автоматизацией PowerShell, размещающей мой DNS в Azure. Если ваш корневой домен принадлежит третьей стороне, вы можете рассмотреть возможность создания зоны DNS для x.domain.com и создания записей NS для заглушки в стороннем поставщике DNS, указывающем на серверы имен зон Azure.

Answer 2

Несмотря на то, что архитектор Джейми опубликовал очень полезный ответ, и я был готов реализовать Let's encrypt -подход, я только что обнаружил, что Microsoft фактически выпустила собственный вариант:

Управляемые сертификаты службы приложений (предварительный просмотр)это обеспечивает бесплатный вариант сертификата для приложений, размещенных в службе приложений. Подробности можно найти в документах Microsoft Azure .