Визуализация состояния сертификатов на веб-сайтах

Всего лишь еще один забавный инструмент. Если Вы не используете wildcard-сертификаты, то возможно у Вас много сертификатов. Обычно в таких условиях их состояние мониторится какой-нибудь автоматизированной системой (OpsMgr, nagios, собственная разработка), но иной раз нужно просто быстро окинуть взглядом ситуацию, чтобы понять текущее состояние дел. Вы можете использовать для этого опять же встроенные или самодельные отчеты или использовать вот этот инструмент: VerifySSLSertificate. Он маленький, простой, но имеет практически все, что нужно для описанной выше задачи. Вы можете сохранить или загрузить список серверов, сохранить сертификат сервера и установить порог тревоги. То, что надо. Или Вам нужно что-то большее, чтобы просто получить представление о состоянии дел? Я сомневаюсь, если честно:

 

Так что спасибо Chris Blankenshipза эту утилиту и несколько других.

Недостатки wildcard-сертификатов

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

Чтобы защитить коммуникации с веб-страницами или веб-сервисами (это к примеру, список больше, разумеется) мы используем SSL-сертификаты. Должен сказать, что на самом деле это не означает, что увидев префикс https и валидный сертификат мы можем быть уверены в том, что это настоящий сайт, настоящий сертификат и что общение с сайтом действительно защищены, но это тема отдельной дискуссии. В любом случае, прекрасны сертификаты или ужасны, это наша реальность, с которой нужно жить. Поэтому, как только Вы оказываетесь владельцем хоть сколько-нибудь большой инфраструктуры с множеством веб-сайтов, сервисов и тому подобного, и каждый из таких сервисов должен защищаться своим собственным сертификатом. Почему? Думаю, не раскрою никакого секрета, напомнив, что сертификат выписывается в таких случаях на определенное доменное имя, то есть microsoft.com, www.microsoft.com и technet.microsoft.com должны иметь разные сертификаты. Так что в вышеописанной ситуации Вы оказываетесь погребены под десятками и сотнями сертификатов, которые истекают, их нужно обновлять, наблюдать за их состоянием и так далее. Чертова прорва работы, иной раз, однако “безопасность должна быть безопасной” и все такое.

Впрочем, мир остался бы в каменном веке без ленивых людей, знаете ли. Так что эти лентяи изобрели wildcard-сертификаты. Они выпускаются на имена типа *.microsoft.com и могут таким образом быть использованы с любым поддоменом домена microsoft.com. Это как бы решает все описанные выше проьлемы. Правда ведь? На самом деле это действительно так, но ничто не бывает бесплатным и данный случай вовсе не исключение. Если Вы используете один такой сертификат в своей организации, то его секретный ключ лежит везде, где используется сертификат (существуют сервисы, которые могут выдавать разные сертификаты с одним именем, но тогда зачем вообще заморачиваться?). Статистически это означает, что риск скомпрометировать этот конкретный сертификат возрастает многократно. А сменить его после компрометации придется на всех узлах. Некоторые думают, что это вовсе и не проблема, но тогда зачем использовать сертификаты? =) Предположим, что мы считаем это все-таки проблемой, но не слишком большой, тогда, как я уже говорил выше, добавьте к этой проблеме стоимость аудита всех скомпрометированных систем (а мы ведь можем считать во многих случаях, что все, что работало на этом сертификате - скомпрометировано). Поверьте мне, аудит нескольких систем – вовсе не дешевое занятие. И не дающее стопроцентного результата, зачастую.

Таким образом, безопасность Вашей инфраструктуры определенно пострадает (как минимум, статистически, но безопасность сама по себе чаще всего оперирует вероятностями). Но и это не максимум Ваших неприятностей.

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

IE7 & SSL

Давеча на форуме TechNet был мне задан вопрос, ответом на который нельзя не поделиться. Дело в том, что в IE7 изменена логика проверки CRL в случае отсутствия последнего. Если в IE6 при отсутствии CRL в указанном месте приводило к выводу предупреждения, то теперь по-умолчанию все прекрасно работает без всяких предупреждений. Легко придумать ситуацию (к счастью реализовать сложнее), в которой такое поведение браузера приведет к проблемам.
Решается все очень просто: в реестре нужно добавить такой вот ключик:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WARN_ON_SEC_CERT_REV_FAILED]
"iexplore.exe"=dword:00000001»

После чего получим прекрасную, невыносимо радующую желтую строку =)




И конечно же я должен предупредить о необходимости сохранить резервную копию реестра перед этой процедурой.