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