Есть ли какие-либо причины безопасности, по которым не следует использовать wildcard-сертификат, помимо управляемости и возможности эксплуатации при использовании на нескольких серверах?

Есть ли какие-либо причины безопасности, по которым не следует использовать wildcard-сертификат, помимо управляемости и возможности эксплуатации при использовании на нескольких серверах?

У меня есть консультант по безопасности, который говорит мне, что мы не можем использовать wildcard SSL-сертификаты по соображениям безопасности. Чтобы быть точным, я бы предпочел использовать отдельные сертификаты или многодоменные сертификаты (SAN). Однако нам нужен сервер (plesk) для обслуживания сотен поддоменов.

Согласно моим исследованиям, основная причина, по которой люди не используют подстановочные знаки на своих сайтах, заключается в следующем (по-видимому, это исходит от Verisign):

  • Безопасность: Если один сервер или поддомен скомпрометирован, все поддомены могут быть скомпрометированы.
  • Управление: Если wildcard-сертификат необходимо отозвать, всем поддоменам потребуется новый сертификат.
  • Совместимость: Универсальные сертификаты могут работать некорректно со
    старыми конфигурациями клиент-сервер.
  • Защита: SSL-сертификаты VeriSign Wildcard не защищены расширенной гарантией NetSure.

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

решение1

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

С точки зрения безопасности вы попали в точку - один закрытый ключ защищает все домены, которые находятся под wildcard. Так, например, если у вас был многодоменный сертификат SAN, который покрывал www.example.comи something.example.comбыл скомпрометирован, только эти два домена подвергаются риску атаки с использованием скомпрометированного ключа.

Однако если бы эта же система использовала *.example.comсертификат для обработки трафика SSL для wwwи somethingподдоменов и была бы скомпрометирована, то все, что защищено этим подстановочным знаком, потенциально подвергалось бы риску, даже службы, не размещенные непосредственно на этом сервере, например, webmail.example.com.

решение2

Безопасность: Если один сервер или поддомен скомпрометирован, все поддомены могут быть скомпрометированы.

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

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

Управление: Если wildcard-сертификат необходимо отозвать, всем поддоменам потребуется новый сертификат.

Если вы используете wildcard для *.example.org, то вам нужно заменить только один сертификат. Если у вас есть сертификат для one.example.org, two.example.org и three.example.org, то вам нужно заменить 3 сертификата. Поэтому wildcard-сертификат требует меньше работы. Так что да, этот сертификат будет отозван и заменен, но поскольку вам нужно заменить только один вместо сотен, это должно быть очень просто.

Совместимость: Универсальные сертификаты могут работать некорректно со старыми конфигурациями клиент-сервер.

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

Связанный контент