Назад | Перейти на главную страницу

Требуется ли подстановочный SSL для одного поддомена?

Типичный сертификат SSL основан на общем имени домена (domain.com), иногда также (www.domain.com).

Я понимаю, для чего используется групповой сертификат (* .domain.com), и он должен / должен проверять все поддомены для этого домена.

Если я хочу, чтобы один поддомен был покрыт сертификатом SSL (mail.domain.com), то это подстановочный сертификат, только вариант? Или можно использовать стандартный сертификат SSL, выданный для этого единственного поддомена?

Я не спрашиваю о передовых методах или причинах, по которым «действительно следует использовать сертификат с подстановочными знаками». С технической точки зрения я спрашиваю, можно ли защитить отдельный поддомен с помощью сертификата, подтвержденного доменом SSL, который НЕ является подстановочным знаком.

Вы можете без проблем использовать сертификат SSL, выданный только для mail.domain.com. Самым большим преимуществом шаблонных сертификатов является то, что существует только «один сертификат, который будет управлять ими всеми» - вам не нужно управлять десятками сертификатов.

Если у вас есть домен «domain.com», вы также можете запросить сертификат для «mail.domain.com». Вам просто нужно будет доказать, что вы являетесь владельцем корневого домена.

Сначала меня немного смутил этот вопрос, поскольку в типичном случае сертификаты обычно рассматриваются как предусматривающие только один предмет. Не защищает отдельную запись DNS (/ поддомен, см. Раздел 3) с помощью сертификата, подтвержденного доменом SSL, который НЕ является подстановочный знак стандартный корпус для сайта?

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

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

  1. Выбор с подстановочными / без подстановочных знаков
  2. Как имя в сертификате соотносится с тем, что вы можете преподнести
  3. Что означает субдомен в контексте вопроса.

Раздел 1. Подстановочные знаки и не-подстановочные знаки

  • Цена: это первое, о чем я хочу упомянуть. Плата коммерческого центра сертификации за шаблонный сертификат в 3-5 раз больше, чем за стандартный сертификат. Например, на момент написания стоимость стандартного сертификата безопасного сайта сроком на 1 год от Symantec (был VeriSign) - 399 долларов. Стоимость годового подстановочного сертификата составляет 1999 долларов (стандарт ~ x5). Сертификаты безопасных сайтов Symantec (более дешевый вариант) можно использовать с альтернативными именами субъектов (SAN), что означает, что, если вы знаете общедоступные DNS-имена, которые вы используете и собираетесь использовать в течение следующего года, вам не нужен подстановочный сертификат даже для нескольких веб-сайтов или безопасных точек подключения.
  • Объем потенциального раскрытия: как упоминалось в комментарии выше, существуют разные уровни раскрытия в случае утечки закрытого ключа. Имея сертификат для одного веб-сервера, злоумышленник может выдавать себя за этот сервер. Для одного веб-сайта разрешаются только серверы, на которых имя веб-сайта также разрешается (см. Раздел 2 - сопоставление имен субъектов). Используя мои общедоступные имена в одной идее сертификата SAN, приведенной выше, они могут выдавать себя за все ваши общедоступные веб-сайты. С помощью подстановочного сертификата они могут выдавать себя за что угодно и утверждать, что это исходит из вашего домена. Аргументы безопасности против подстановочных сертификатов были представлены в RFC.

  • Сопоставление имен: сертификат без подстановочного знака соответствует только точному имени субъекта (в частности, компоненту Common Name или CN имени субъекта для большинства сертификатов). Таким образом, любое разрешение сертификата, привязанное к mail.domain.com, будет работать, даже если оно включает CNAMES или разрешение на несколько IP-адресов, но, например,. smtp.mail.domain.com (или при более типичном использовании someguy@mail.domain.com) НЕ будут работать, если они не настроены как сети SAN. В этом случае подстановочный сертификат * .mail.domain.com будет работать для smtp.mail.domain.com (и в нашем примере защищенной почты предполагается, что оба id-pkix 3 4 а вы вручную настроить подстановочный знак S / MIME).

  • Перспективы: именно здесь берут начало большинство рекомендаций по использованию только подстановочных знаков. С сертификатом с подстановочными знаками для вашего основного домена DNS «domain.com» вы можете разместить любое количество веб-сайтов ниже domain.com, даже те, которые вы не знали, что вам нужны, когда запрашивали сертификат. Вам не нужно беспокоиться о том, чтобы убедиться, что представленный сертификат соответствует названию веб-сайта, потому что оно всегда будет совпадать.

  • Планирование. Что касается проверки в будущем, обратите внимание, что с сертификатом multi-SAN простота управления остается неизменной, если вы включили все свои текущие и запланированные будущие веб-сайты. У вас есть десятки имен для работы, поэтому вы даже можете добавить DNS-имена, которые вы не планируете использовать, но которые, по вашему мнению, может использовать организация. Даже если вам понадобится имя, которое вы не планировали использовать в середине года, покупка еще одного сертификата с несколькими SAN все равно оставит вам трату, скорее всего, менее половины стоимости сертификата с подстановочными знаками.

  • Ограничения с подстановочными знаками: учитывая размер разницы в цене, я не уверен, что небольшие накладные расходы на управление для перехода без подстановочных знаков окупаются стоимости сертификата с подстановочными знаками, если вы не являетесь крупной организацией с десятками или сотнями публичных DNS-имен для безопасный. Также помните, что подстановочный знак соответствует только одному уровню в иерархии DNS ниже domain.com. Поэтому, если вам нужен www. *. Domain.com, вам понадобится новый сертификат специально для www. [Specificicsubdomain] .domain.com или SAN в сертификате с подстановочными знаками для *. *. Domain.com или www. *. domain.com. Обратите внимание, что центры сертификации часто неохотно / отказываются добавлять сети SAN в групповой сертификат.


Раздел 2: Соответствие имени субъекта

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

Итак, для сертификата веб-сервера, если у меня есть это в DNS:

www.otherdomain.org A 172.16.254.1

Но это в файле hosts на конкретной машине:

172.16.254.1 mail.domain.org

Эта конкретная машина будет иметь совпадение имени субъекта с сервером, представляющим сертификат для mail.domain.org на сервере 172.16.254.1, но клиенты, достигающие 172.16.254.1 через поиск DNS на www.otherdomain.org, будут иметь несоответствие имени субъекта для тот же сертификат. Если я затем добавлю это CNAME в DNS:

mail.domain.org CNAME www.otherdomain.org

И попросите всех моих клиентов перейти на mail.domain.org в своем браузере вместо www.otherdomain.org, сертификат перестанет отображать несоответствие имени сертификата этим клиентам. Это потому, что разрешение DNS непрозрачно для браузера.


Раздел 3: терминология DNS

Я также хочу указать, что эта терминология может немного сбивать с толку, когда вы упоминаете «субдомен», мой вывод - это полноценная зона, ниже вашей родительской зоны / домена, где находятся ваши основные серверы имен, у этого субдомена может быть свой собственный серверы имен и подчиненные записи ниже этого.

(Хотя, конечно, в иерархии DNS технически все, кроме корневого, является субдоменом, существует мягкая тенденция рассматривать записи без подчиненных в иерархии как «не субдомены», потому что концептуально они удовлетворяют «субдоменам», но не обязательно всем аспектам надлежащего 'домен'. Например, вы обычно не рассматриваете запись A как имеющую административную автономию, хотя позже вы можете добавить запись сервера имен и заполнить под ней поисковые запросы. Я понимаю, что эта тенденция не обязательно соответствует технической реальности.)

Для разрешения записи на один «ресурс» (веб-сайт, сервер, рабочая станция) я обычно использую просто «веб-сайт / сервер / рабочую станцию», общую «запись DNS», «запись хоста (A)» или для покрытия возможность использования CNAME, F5 wizardry и т. д., по крайней мере, '[тип ресурса веб-сайт / сервер / не поддомен] Полное доменное имя'(FQDN)

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

Имейте в виду, что SSL / TLS традиционно допускает использование только одного сертификата на комбинацию IP / порта. Существует расширение под названием SNI, которое исправляет это, но все еще есть некоторые старые клиенты, которые его не поддерживают (в первую очередь Internet Explorer в Windows XP).