Использование подстановочного сертификата [дубликат]
На этот вопрос уже есть ответ здесь:
Я немного работал над сертификатами SSL и моя организация думает о том, чтобы использовать сертификат Wildcard вместо сертификата Multi-domain san, который у нас есть сейчас. Что мне нужно знать: почему мы не должны идти по маршруту сертификатов с подстановочными знаками? Я знаю, как они работают, но мне нужно продать им это. Я знаю достоинства и недостатки.
Я исследовал причины, почему не использовать его, и единственный недостаток, который я действительно могу найти, - это тот же самый недостаток, который каждый сайт или человек говорит: «Если .key скомпрометирован, значит WCS». Мне нужна более веская причина, почему бы не использовать его тогда, потому что мультидомен - это то же самое .key. У нас есть и мы можем принять меры, чтобы сделать это безопаснее.
Мы планируем перейти от одного многодоменного UC к сотням сетей SAN и разбить его с помощью подстановочных знаков. это также будет выполняться через NetScaler SDX 11500. Я не большой специалист по NetScaler, но я это понимаю. Если мы включили SNI, можем ли мы загружать разные сертификаты и ключи?
Также знаете ли вы, что еще нужно сделать, чтобы сделать его более безопасным. Спасибо
В нашей среде основной проблемой с wildcard сертификатом являются проблемы с его использованием на доменах третьего уровня, это вообще невозможно, т.е. для *.domain.tld это нормально, а для *.second.domain.tld - нет
.Это не "или-или", если только вы не сделаете его "или-или", или если на него не вставит ваш реселлер сертификатов.
Единственная проблема с SNI в том, что более старые устройства не поддерживают SNI. В тех случаях, когда они не поддерживают SNI, они попадают под стандартную привязку к вашему устройству.
Если быть более точным, то сертификаты с подстановочными знаками защищают один уровень поддомена, e. g:
*.example.com
будет охватывать
foo.example.com
bar.example.com
autodiscover.example.com
Это будет а не охватывать
foo.bar.example.com
autodiscover.example.net
Так что если каждый домен, который вам нужно охватить, является одним уровнем под определенным доменом, то шаблонный сертификат, безусловно, простой и дешевый(ish) способ.
Сертификат с SAN позволяет охватить столько различных доменов, сколько вы можете себе представить. Он даже может включать подстановочные знаки в SAN, так что вы можете иметь:
*.example.com
*.example.net
*.example.org
все в одном сертификате. Просто посмотрите на сертификат для этого сайта:
Возможно, вы захотите сохранить небольшую цепочку сертификатов, чтобы можно было обменивать все сертификаты и цепочки в одном пакете. В зависимости от длины цепочки сертификатов, это может ограничить количество SAN, которые вы можете поместить в один сертификат, прежде чем он перейдет границу.
Как вы правильно заметили, те же самые проблемы безопасности применимы и к подстановочным знакам или к SAN. На самом деле все сводится к тому, что вам нужно, и что легче поддерживать.
Если вы можете поддерживать десятки отдельных сертификатов и счастливы использовать SNI (и потенциальные ловушки), то сделайте это. Если вы не хотите использовать SNI или не хотите управлять десятками сертификатов, пойдите по шаблону и/или SAN и возьмите вместо этого компромисс.
Нет правильного или неправильного ответа, есть только то, что работает для вас.
.Единственная проблема с сертификатами wildcard - это Microsoft Lync Server 2013, который не поддерживал сертификаты wildcard для некоторых служб, так как клиенты использовали проверку сертификатов, которые не работали со специальными символами подстановки. Я не уверен, что последняя версия Lync 2016 (также известная как Skype для бизнеса) все еще имеет это ограничение, или действительно, почему оно существует - предположительно, какая-то мера безопасности
.