Как посмотреть цепочку сертификатов в браузере
На 4-м сертификате дёргать их вручную стало лень (а я ленив по натуре), поэтому набросал «самокат» выцепляющий издателя и формирующий chain-файл для скармливания nginx'у.
Наверняка он не идеален и проверен лишь на полуторадесятках сертификатов, но чем богаты.
Об устройстве x.509 много сказано (в том числе на хабре), поэтому повторяться не буду.
Ниже просто пошаговая инструкция получения цепочки вперемешку с небольшой выжимкой из теории и не более того.
Всё нижесказанное актуально для:
Помимо самого кодированного запроса, версии, подписи и т.п. в нём имеется ряд расширений. Одно из которых Authority Information Access нас и интересует:
Параметр CA Issuers как раз и содержит следующий в цепочке сертификат. Как правило, данный сертификат либо в PEM, либо в DER(как в нашем случае) форматах.
На деле PEM формат не более чем base64 представление DER и получить PEM из DER можно сделав base64 ./ycasha2.cer ./ycasha2.pem и обрамив кодированный текст "-----BEGIN CERTIFICATE-----","-----END CERTIFICATE-----". Однако, логичнее и проще сделать это преобразование средствами openssl:
Едем дальше и смотрим следующий сертификат в цепочке:
Преобразовываем и его:
В данном сертификате (т.к. он корневой) отсутствует расширение Authority Information Access:
То есть на нём и закончим вытягивание цепочки. Осталось собрать это всё в chain-файл:
Вроде бы теперь можно ставить (если есть Private Key), но остановлюсь ещё на паре нюансов.
Установив свой сертификат на свой Яндекс проверяем его:
Всё хорошо, но это лишь потому, что в дефолтных путях -CApath, -CAfile моего openssl нашлись нужные хеши сертификатов. Если мы их изменим, либо по дефолтным путям их нет, либо они просто устарели, либо у кого-то версия openssl с багом, в которой не «цеплялись» default CApath (если не ошибаюсь с 1.0.1с по 1.0.1e), то получим неприятность в виде:
Понятно, что корневой сертификат подписать некому, поэтому нужно нашей системе разрешить доверять ему. Для этого можно создать кусочек хранилища. При поиске требуемого сертифката openssl пытается отыскать его по хешу сертификата.
Разумеется делать руками каждый раз лень, потому слегка автоматизируем:
Как-то так… Разумеется скрипт не универсален, всё на скорую руку в предверии грандиозного шухера. Комментарии/пожелания приветствуются, но отвечать вряд ли смогу — у нас тут (в Беларуси) дурдом деноминация.
Если электронную подпись нужно использовать на нескольких компьютерах или скопировать сертификат на запасной носитель, то необходимо знать, где ее искать. Обычно сертификаты хранятся в одном месте, но в зависимости от типа используемой операционной системы путь к хранилищу может быть разным.
Где хранится ЭЦП на компьютере
Найти сертификат ключа электронной подписи на ОС Windows Vista и выше можно по адресу: C:Users/ПОЛЬЗОВАТЕЛЬ/App/Data/Roaming/MicrosoftSystem/Certificates. Где «Пользователь» — это название учетной записи ПК. В целях безопасности система сохраняет в данной папке только открытый, т.е. доступный всем, ключ ЭЦП. Закрытый ключ не копируется на жесткий диск и хранится на токене. Используется он для генерации открытых ключей.
Для программного пользования открытый ключ хранится в папке Windows в зашифрованном виде. Скопировать этот файл не получится, т.к. система не дает права доступа к нему. Просмотр установленных сертификатов возможен только администратор ПК.
Сертификат ЭЦП имеет формат .cer или .csr, и занимает несколько КВ памяти. В операционных системах MacOS и Linux формат файла не меняется, поскольку является единым для использования на территории РФ.
Как посмотреть сертификат ЭЦП
Посмотреть установленные сертификаты можно при помощи Internet Explorer, Certmgr, консоль управления или КриптоПро. Пользоваться другими компьютерными программами не рекомендуется: они могут иметь встроенную команду отправки ключа ЭЦП на сторонний сервер, что приведет к компрометации подписи и невозможности ее использования.
Через КриптоПро
Как найти сертификат ЭЦП на компьютере при помощи КриптоПро:
- открыть «Пуск»;
- через вкладку «Все программы» перейти в «КриптоПро»;
- выбрать вкладку «Сертификаты».
Этим способом могут воспользоваться пользователи или администраторы ПК (если пользователю будет отказано в доступе, необходимо дополнительно запросить права администратора). В открывшемся окне будет список всех сертификатов, установленных на данном ПК. В содержащем сертификаты хранилище, можно посмотреть информацию по каждому, скопировать контейнер закрытых ключей КриптоПро на другой компьютер, внешний носитель или удалить недействительный ключ ЭЦП.
Через Certmgr
Найти файл сертификата можно и при помощи встроенного менеджера, который присутствует во всех ОС Windows. Через него можно не только посмотреть все личные сертификаты, но и сертификаты УЦ и партнеров Microsoft.
Метод может использоваться только администратором ПК. Для просмотра нужно:
- открыть «Пуск»;
- ввести команду certmgr.msc в строку поиска и нажать Enter;
- в левой колонке открывшегося окна будет список личных и корневых сертификатов.
С шифрованными сертификатами приложение работает ограниченно и не всегда корректно отражает все электронные подписи, установленные пользователем.
Через Internet Explorer
Интернет-браузер IE входит в комплектацию всех ОС семейства Windows XP и выше и позволяет также найти сертификаты ЭЦП на компьютере. Для просмотра нужно:
- запустить браузер;
- через «Меню» перейти в «Свойства браузера»;
- в новом окне выбрать вкладку «Содержание»;
- выбрать «Сертификаты».
Далее откроется окно с перечнем всех сертификатов, установленных пользователем и сторонними поставщиками ПО. В данном меню возможен перенос ключей и сертификатов на внешний носитель, удаление открытых ключей. Удаление корневых сертификатов УЦ через меню IE невозможно.
Через консоль управления
Просмотр сертификатов в ОС Windows через консоль управления запускается в несколько этапов:
- пользователь открывает командную строку;
- вводит команду mmc и нажимает Enter;
- нажимает на «Файл» и «Добавить/удалить оснастку cryptopro»;
- выбирает последовательно «Добавить» и «Добавить изолированную оснастку»;
- выбирает «Сертификаты».
Дополнительно можно просмотреть ключи ЭЦП по конкретной учетной записи. Способ также доступен только пользователям с правами администратора ПК. Через консоль можно не только просматривать информация, но и удалять, копировать, добавлять контейнеры с ключами ЭЦП. Неудобство метода в том, что все команды необходимо вводить вручную. Обычны работа через консоль осуществляется на windows server для настройки прав доступа всех пользователей.
Где в реестре хранится ЭЦП
Иногда реестр используется как ключевой носитель, т.е. он подходит для импорта и экспорта сертификатов. Где находится сертификат ЭЦП зависит от битности системы:
- для 32-битной ОС путь выглядит так: HKEY_LOCAL_MACHINESOFTWARECryptoProSettings Users(идентификатор пользователя)Keys(Название контейнера)
- для 64-битной ОС путь к ключам такой: HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCrypto ProSettings USERS(идентификатор пользователя)Keys(Название хранилища)
- реже ключи электронной подписи можно найти тут: HKEY_USERSS-1-5-21- _ClassesVirtualStoreMACHINESOFTWARE [Wow6432Node]Crypto ProSettingsUSERSS-1-5-21- Keys
SID — это идентификатор пользователя, который идентифицирует данную учетную запись. Узнать его можно через командную строку и команду WHOAMI/USER.
Где хранится сертификат ЭЦП в ОС Windows XP
К базовым компонентам ОС Windows XP относятся службы сертификации, а XP Professional уже поддерживает многоуровневые иерархии центра сертификации (ЦС) как с изолированными и интерактивными ЦС, так и сети ЦС с доверительными перекрестными отношениями.
Открытые ключи ЭЦП Windows XP хранит в личном хранилище, а т.к. они представляют собой общедоступную информацию, то хранятся в виде открытого текста. Сертификаты пользователя находятся по адресу:
Documents and Settings ApplicationDataMicrosoft SystemCertificatesMyCertificates. Они автоматически вносятся в локальный реестр при каждом входе в систему. Если профиль перемещаемый, то открытые ключи хранятся обычно не на ПК, а следуют за пользователем при каждом входе в систему с внешнего носителя.
Такие поставщики услуг криптографии, как Enchanced CSP и Base CSP хранят закрытые ключи электронной подписи в папке %SystemRoot%Documents and Settings Application DataMicrosoftCryptoRSA. Если профиль перемещаемый, то они расположены в папке RSA на контроллере домена. В этом случае на ПК они загружаются только на время работы профиля. Все файлы в данной папке шифруются случайным симметричным ключом автоматически. Основной ключ пользователя имеет длину в 64 символа и создается проверенным генератором случайных чисел.
Где хранится ЭЦП в системах Linux
В Linux системах список контейнеров с закрытыми ключами можно найти при помощи утилиты csptest. Находится она в директории: /opt/cprocsp/bin/ .
Список контейнеров компьютера: csptest -keyset -enum_cont -verifycontext -fqcn -machinekeys. Список контейнеров пользователя: csptest -keyset -enum_cont -verifycontext -fqcn. В списках имена контейнеров даются в виде, понятном для бинарных утилит, входящих в состав дистрибутива CSP.
Закрытые ключи хранятся в хранилище HDImageStore на жестком диске, и доступны они и для CSP, и для JCP.
Просмотреть список ключей электронной подписи на ОС Windows может только пользователь с правами администратора. Обычно ключи хранятся в системных папках и имеют расширение .cer или .csr. Чтобы посмотреть список, удалить ненужные элементы или скопировать их на внешний носитель можно воспользоваться программой КриптоПро, браузером Internet Explorer, консолью управления или специальной утилитой certmgr. В Windows XP открытые и закрытые ключи хранятся в разных папках, а закрытые дополнительно шифруются паролем, состоящим из комбинации случайных чисел. Системы Linux хранят все сертификаты в отдельной директории, а пусть к ним задается вручную при помощи команд.
На 4-м сертификате дёргать их вручную стало лень (а я ленив по натуре), поэтому набросал «самокат» выцепляющий издателя и формирующий chain-файл для скармливания nginx’у.
Наверняка он не идеален и проверен лишь на полуторадесятках сертификатов, но чем богаты.
Об устройстве x.509 много сказано (в том числе на хабре), поэтому повторяться не буду.
Ниже просто пошаговая инструкция получения цепочки вперемешку с небольшой выжимкой из теории и не более того.
Всё нижесказанное актуально для:
Помимо самого кодированного запроса, версии, подписи и т.п. в нём имеется ряд расширений. Одно из которых Authority Information Access нас и интересует:
Параметр CA Issuers как раз и содержит следующий в цепочке сертификат. Как правило, данный сертификат либо в PEM, либо в DER(как в нашем случае) форматах.
На деле PEM формат не более чем base64 представление DER и получить PEM из DER можно сделав base64 ./ycasha2.cer ./ycasha2.pem и обрамив кодированный текст "——BEGIN CERTIFICATE——","——END CERTIFICATE——". Однако, логичнее и проще сделать это преобразование средствами openssl:
Едем дальше и смотрим следующий сертификат в цепочке:
Преобразовываем и его:
В данном сертификате (т.к. он корневой) отсутствует расширение Authority Information Access:
То есть на нём и закончим вытягивание цепочки. Осталось собрать это всё в chain-файл:
Вроде бы теперь можно ставить (если есть Private Key), но остановлюсь ещё на паре нюансов.
Установив свой сертификат на свой Яндекс проверяем его:
Всё хорошо, но это лишь потому, что в дефолтных путях -CApath, -CAfile моего openssl нашлись нужные хеши сертификатов. Если мы их изменим, либо по дефолтным путям их нет, либо они просто устарели, либо у кого-то версия openssl с багом, в которой не «цеплялись» default CApath (если не ошибаюсь с 1.0.1с по 1.0.1e), то получим неприятность в виде:
Понятно, что корневой сертификат подписать некому, поэтому нужно нашей системе разрешить доверять ему. Для этого можно создать кусочек хранилища. При поиске требуемого сертифката openssl пытается отыскать его по хешу сертификата.
Разумеется делать руками каждый раз лень, потому слегка автоматизируем:
Как-то так… Разумеется скрипт не универсален, всё на скорую руку в предверии грандиозного шухера. Комментарии/пожелания приветствуются, но отвечать вряд ли смогу — у нас тут (в Беларуси) дурдом деноминация.
Сертификаты являются одним из вариантов безопасности для Виндовс 7. Это цифровая подпись, которая проверяет достоверность и подлинность различных веб-узлов, служб и всевозможных устройств. Выдача сертификатов осуществляется сертификационным центром. Они хранятся в специализированном месте системы. В данной статье мы рассмотрим, где находится «Хранилище сертификатов» в ОС Windows 7.
Открываем «Хранилище сертификатов»
Чтобы просмотреть сертификаты в Виндовс 7, заходим в ОС с правами администратора.
Необходимость в доступе к сертификатам особенно важна для пользователей, которые часто совершают платежи в интернете. Все сертификаты хранятся в одном месте, так называемом Хранилище, которое разбито на две части.
Способ 1: Окно «Выполнить»
- При помощи нажатия комбинации клавиш «Win+R» попадаем в окошко «Выполнить». Вводим в командную строку certmgr.msc .
Цифровые подписи хранятся в папке, которая находятся в директории «Сертификаты – текущий пользователь». Здесь сертификаты находятся в логических хранилищах, которые разделены по свойствам.
В папках «Доверенные корневые центры сертификации» и «Промежуточные центры сертификации» находится основной массив сертификатов Виндовс 7.
Чтобы посмотреть информацию о каждом цифровом документе, наводим на него и кликаем ПКМ. В открывшемся меню выбираем «Открыть».
Переходим во вкладку «Общие». В разделе «Сведения о сертификате» будет отображено предназначение каждой цифровой подписи. Также представлена информация «Кому выдан», «Кем выдан» и сроки действия.
Способ 2: Панель управления
Также есть возможность посмотреть сертификаты в Windows 7 через «Панель управления».
В открывшемся окне переходим во вкладку «Содержание» и щелкаем по надписи «Сертификаты».
В открывшемся окошке предоставлен перечень различных сертификатов. Чтобы посмотреть подробную информацию об определённой цифровой подписи, жмём по кнопке «Просмотр».
После прочтения данной статьи вам не составит никакого труда открыть «Хранилище сертификатов» Windows 7 и узнать подробную информацию о свойствах каждой цифровой подписи в вашей системе.
Проверяйте SSL, TLS и шифрование
Проверка SSL необходима для обеспечения правильного отображения параметров сертификата. Существует множество способов проверки SSL-сертификатов. Проверка с помощью инструментов в сети позволяет получить полезную информацию, находящуюся ниже. Она также поможет вам выявить угрозы на ранних стадиях, а не после получения жалобы клиента.
Я получил ряд вопросов после своей последней публикации «Усиление защиты Apache. Гид по безопасности» о проверке TLS и SSL. В этой статье я расскажу вам о некоторых полезных инструментах для проверки SSL-сертификатов в сети.
Symantec SSL Toolbox
Проверка CSR — очень важно проверить CSR перед отправкой для подписи запроса. Вы сможете удостовериться в том, что CSR содержит все требуемые параметры, например, CN, DN, O, OU, алгоритм и др.
Проверка установки сертификата — после установки всегда полезно удостовериться в том, что сертификат действителен и содержит необходимую информацию. Этот онлайн инструмент позволит вам проверить CN, SAN, название организации, OU, город, серийный номер, тип применяемого алгоритма, длину ключа и подробности о цепочке сертификата.
Wormly Web Server Tester
Тестирование web сервера от Wormly позволяет получить подробный обзор параметров ссылки. Обзор включает в себя данные о сертификате (CN, срок действия, цепочка сертификата), шифровании, длине открытого ключа, безопасности повторного согласования, протоколах типа SSLv3/v2, TLSv1/1.2.
DigiCert SSL Certificate Checker
Инструмент для проверки установки SSL сертификатов от DigiCert — еще один прекрасный инструмент, который позволит вам преобразовать DNS в IP адрес, узнать кто выдал сертификат, его серийный номер, длину ключа, алгоритм подписи, SSL-шифрование, поддерживаемое сервером и срок действия сертификата.
SSL Shopper
Проверка SSL от SSL Shopper — подойдет для быстрой проверки типа сервера, срока действия, SAN и цепочки доверия. Вы сможете оперативно найти ошибку в цепочке сертификата или узнать, что он не работает должным образом. Инструмент отлично подходит для устранения неполадок в работе.
GlobalSign SSL Check
Проверка конфигурации SSL от GlobalSign предоставляет очень подробную информацию о веб-сервере и SSL. Инструмент ставит баллы в зависимости от данных сертификата, поддержки протоколов, обмена ключами и надёжности шифра. Это незаменимый инструмент при настройке нового безопасного URL или проведении аудита. Обязательно попробуйте!
Qualys SSL Labs
Позволяет оценить ваш сайт в отношении безопасности SSL-сертификата. Предоставляет очень подробную техническую информацию. Советую системным администраторам, аудиторам, инженерам по интернет-безопасности для выявления и наладки “слабых” параметров.
Free SSL Server Test
- Совместимость PCI DSS
- Соответствие принципам NIST
- Размер DH
- Поддержка протоколов
- Поддержка шифров
- Откат TLS соединения
- Поддержка повторного согласования
- Основные наборы шифров
- Контент третьих лиц
COMODO SSL Analyzer
- Серийный номер
- Отпечаток
- Действительность SSL-сертификата
- Эмитент
- Поддержка протокола (SSL/TLS)
- Защита от атак Downgrade
- Безопасность повторного согласования (по инициативе сервиса или клиента)
- Сжатие
- Session tickets
- Активные наборы шифрования
SSL Checker
Что действительно хорошо в SSL Checker, так это то, что инструмент позволяет настроить напоминание (за 30 дней) об истечении срока действия сертификата. Это отлично, мне кажется, что бесплатно эту услугу больше нигде получить нельзя. Кроме того, инструмент позволяет выполнить базовую проверку таких параметров, как:
- Цепочка сертификата
- Корневой сертификат
- Алгоритм подписи
- Отпечаток
- Элементы цепочки
- SAN
HowsMySSL
Этот инструмент отличается от остальных. Он позволяет проверить клиента (браузер) и получить оценку состояния по следующим параметрам:
- Поддерживаемая версия протокола
- Сжатие
- Поддержка session ticket
- Поддерживаемое шифрование
Другие инструменты онлайн-проверки
Проверка уязвимости POODLE:
Проверка уязвимости LogJam:
Проверка уязвимости SHA-1:
Я считаю, что перечислил все бесплатные онлайн-инструменты для проверки параметров SSL-сертификата и получения достоверной технической информации для проведения аудита и обеспечения безопасности веб-приложений. Если вам понравилось, поделитесь с друзьями.
P. S. Приглашаем в наше Хостинг Кафе. Работают и активно развиваются 6 сайтов для поиска хостинговых услуг:
В нашей предыдущей статье были описаны основные механизмы проверки статуса сертификатов (проверки, является ли сертификат отозванным). В этой статье мы ответим на следующие вопросы:
1. Как механизмы проверки статуса сертификатов реализованы в современных Веб-браузерах?
2. Кто виноват? Почему они реализованы именно так?
3. Что делать? Какие есть перспективы?
Эта статья будет полезна тем, кому интересно разобраться в применяющихся на практике механизмах проверки статуса сертификатов.
Проверки статуса сертификатов, реализованные в Веб-браузерах
Механизмы проверки статуса сертификатов, реализованные в современных Веб браузерах, представляют собой комбинацию описанных ранее базовых механизмов (CRL, OCSP, OCSP stapling) и их модификаций. Комбинирование базовых механизмов осуществляется с целью обеспечения резервирования: если один из источников информации о статусе сертификата становится недоступным, то используется резервный. Например, в качестве основного механизма проверки статуса сертификатов может использоваться протокол OCSP, однако в случае недоступности или отказа OCSP-сервера будет выполнена более трудоёмкая для клиента загрузка CRL.
Для понимания основной проблемы проверок статуса сертификатов, реализованных в современных браузерах, достаточно рассмотреть следующий сценарий атаки «человек посередине».
Закрытый ключ сервера был скомпрометирован. Владелец сервера отозвал сертификат скомпрометированного ключа, сгенерировал новую пару ключей и получил новый сертификат.
Нарушитель завладел отозванным закрытым ключом и сертификатом сервера. В данном сценарии мы намеренно не говорим, каким образом он это осуществил: в результате компрометации самого сервера или в результате компрометации удостоверяющего центра (УЦ). Это сделано для того, чтобы продемонстрировать, как браузеры поведут себя в обеих ситуациях.
Нарушитель, «человек посередине», контролирует весь трафик, идущий от клиента. Он может перехватывать или блокировать этот трафик, может пытаться отвечать клиенту от имени других сетевых сервисов.
Веб-браузер клиента при попытке установки TLS-соединения с сервером подключается к «человеку посередине». «Человек посередине» представляется сервером, используя отозванный сертификат без прикреплённого OCSP-ответа (a.k.a. OCSP stapling). Нарушитель блокирует запросы, идущие от клиента ко всем OCSP-серверам и точкам распространения CRL (a.k.a. CDP). Также нарушитель блокирует попытки клиента обновить Веб-браузер или его компоненты (например, чёрные списки «CRLSets» или «OneCRL», речь о которых пойдёт позже).
Блокирование «человеком посередине» запросов ко всем OCSP-серверам и точкам распространения CRL, во-первых, поддерживает начальное условие, согласно которому нарушитель мог скомпрометировать, как сервер, так и УЦ, и, во-вторых, наиболее полно демонстрирует проверки статуса сертификатов, выполняемые современными браузерами.
Ниже приводится описание проверок статуса сертификатов, выполняемых различными Веб-браузерами под Windows. Для других платформ детали проверок могут незначительно отличаться.
Mozilla Firefox
Поведение браузера Mozilla Firefox версии 54 (наиболее актуальной на момент написания статьи) при такой атаке отличается в зависимости от типа сертификата сервера: DV или EV. Выпуская DV-сертификат (domain validated), УЦ лишь подтверждает, что владелец ключа, указанного в сертификате, контролирует указанный в сертификате домен. Большинство сертификатов являются DV. EV-сертификат (extended validation) подтверждает не только владение доменом, но и личность владельца домена. Такие сертификаты требуют дополнительных проверок со стороны УЦ, потому они значительно дороже и встречаются реже.
Проверка статуса DV-сертификатов, выполняемая Firefox, описывается следующей диаграммой:
Итак, браузер проверяет статус цепочки сертификатов сервера (сертификатов промежуточных УЦ и сертификата самого сервера). Для проверки статуса сертификатов промежуточных УЦ используется хранящуюся локально на клиенте черный список «OneCRL», содержащий информацию об отозванных сертификатах, собранную из различных точек распространения CRL. Актуальность состояния чёрного списка поддерживается с помощью агрегатора CRL, отдельного удалённого сервиса, работающего следующим образом:
1. Агрегатор периодически опрашивает некоторый набор точек распространения CRL.
2. Из полученных CRL выбирает наиболее критичную информацию об отозванных сертификатах (например, сертификаты, отозванные из-за компрометации закрытого ключа).
3. Обновляет на основе этой информации в чёрные списки в браузерах.
Агрегатор CRL и, как следствие, содержимое чёрного списка «OneCRL» контролируется Mozilla. «OneCRL» не покрывает все отозванные сертификаты, а лишь сертификаты некоторых промежуточных УЦ и небольшое количество сертификатов серверов. Это делается с целью сокращения размера чёрного списка. Текущий список «OneCRL» можно посмотреть тут.
Важно, что если ни один из источников информации о статусе сертификата не доступен, то сертификат не считается отозванным. Иначе говоря, проверка осуществляется в режиме soft fail. Таким образом, атака «человек посередине» проходит успешно. При этом не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.
В дополнение стоит отметить, что клиентская часть протокола OCSP, реализованная в Firefox, не поддерживает одноразовые случайные коды (nonce) и, следовательно, OCSP-ответы не защищены от атак повторного воспроизведения.
Аналогичная ситуация возникает и при проверке EV-сертификатов. Разница заключается лишь в том, что браузер дополнительно выполняет OCSP-запросы и для сертификатов промежуточных УЦ:
Изменить поведение браузера и включить режим hard fail (т.е., запрет установки TLS-соединения в случаях, когда информация о статусе сертификата недоступна) можно, установив в настройках браузера («about:config») параметр «security.OCSP.require» в значение «true»:
Следует отметить, что данная настройка не активирует использование протокола OCSP для сертификатов промежуточных УЦ в случаях, когда сервер предъявляет DV-сертификат.
Для конечного пользователя hard fail в Firefox выглядит так:
Отметим, что атака «человек посередине» всё ещё возможна. Нарушителю требуется провести атаку повторного воспроизведения OCSP-ответа, переслав «старый» OCSP-ответ, сгенерированный ещё до того, как сертификат был отозван. Однако проводить эту атаку можно только до тех пор, пока срок действия «старого» OCSP-ответа не истечёт. При этом срок действия OCSP-ответа может быть достаточно велик. Нередко он бывает равен неделе.
Microsoft Internet Explorer/Edge
Браузеры Microsoft Internet Explorer версии 11 и Microsoft Edge версии 40 ведут себя одинаково для DV- и EV-сертификатов:
Проверка также выполняется в режиме soft fail. Таким образом, атака «человек посередине» также проходит успешно и также не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.
Изменить поведение Internet Explorer возможно, например, установив значение ключа реестра «HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet Explorer \ Main \ FeatureControl \ FEATURE_WARN_ON_SEC_CERT_REV_FAILED \ iexplore.exe» равным 1. Тогда при отсутствии информации о статусе сертификата соединение всё равно будет разрешено, однако в адресной строке будет появляться небольшое предупреждение:
Для Edge подобных настроек не нашли.
Google Chrome/Cromium
Браузеры Google Chrome и Chromium версии 59 при проверке DV-сертификатов ведут себя следующим образом:
Проверки, выполняемые Chrome похожи, на те, что выполняет Firefox, с тем исключением, что в Chrome вообще отказались от выполнения OCSP-запросов при проверке DV-сертификатов. «CRLSets» в Chrome является аналогом «OneCRL» в Firefox (строго говоря, механизм «CRLSets» появился даже раньше) и обладает теми же проблемами неполноты и неподконтрольности конечному пользователю.
OCSP-запросы используются при проверке EV-сертификатов (тут картина становится практически идентичной той, что мы наблюдали для Firefox):
Изменить поведение Chrome и Chromium возможно внесением изменений в групповую политику (инструкция здесь) и включением следующих опций:
Эквивалентная настройка возможна и под Linux (здесь).
Прочие браузеры и платформы
Для других популярных браузеров и платформ ситуация такая же: везде проверки статуса сертификатов выполняются в режиме soft fail, либо не выполняются вовсе. Подробнее можно почитать тут или тут.
Почему сейчас всё работает именно так?
Об этом хорошо написано в блоге Адама Лэнгли. Отсутствие hard fail и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:
Какие есть перспективы?
Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на hard fail нельзя по объективным причинам.
Есть ли применимое на практике решение данной проблемы? Проанализировав и собрав воедино множество уже предложенных частичных решений данной проблемы (в частности расширение сертификатов «TLS feature», сертификаты с коротким сроком действия, агрегаторы CRL и др., о чём подробно будет рассказано ниже), предлагаем вашему вниманию наше представление о том, как проверка статуса сертификатов должна происходить на практике.
В основе лежит утверждение о том, что не для всех сервисов требуется онлайн-проверки статуса сертификатов. Для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски, связанные с атакой «человек посередине» с использованием отозванных сертификатов. Иначе говоря, с точки зрения проверки статуса сертификатов, сервисы делятся на два типа:
1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.
2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).
Браузеры могут различать такие сервисы по наличию специального расширения в сертификате сервера. В зависимости от типа сервиса клиент либо будет выполнять «параноидальную» проверку статуса сертификатов, либо не будет выполнять её вовсе. Теперь подробнее о каждой из этих двух схем.
Параноидальная схема проверки статуса сертификатов для меньшинства
В 2015 году вышла спецификация нового расширения сертификатов стандарта X.509, называемого «TLS feature» (на ранних этапах разработки стандарта также известное, как «OCSP must staple»). Это расширение сертификата позволяет зафиксировать в сертификате те опции протокола TLS, которые TLS-сервер, предъявляющий данный сертификат, обязуется поддерживать. Такой опцией протокола TLS в частности являются прикреплённые OCSP-ответы. Пример сертификата с таким расширением схематически изображён ниже:
В сертификате присутствует расширение «TLS Feature» (выделено красным), сообщающее о том, что TLS-сервер обязан поддерживать прикреплённые OCSP-ответы, специфицированные в RFC 6066 («Status Request (Version 1)»), и более новую версию данной опции («Status Request (Version 2)»), специфицированную в RFC 6961 — множественные прикреплённые OCSP-ответы. Новая версия данной опции протокола TLS позволяет прикреплять OCSP-ответы и для сертификатов промежуточных УЦ.
Поскольку мы строим «параноидальную» схему проверки статуса сертификатов, то в дополнение к использованию сертификатов с расширением «TLS Feature», следует также отметить следующее:
1. Прикреплённые OCSP-ответы должны быть защищены от атаки повторного воспроизведения (должны использоваться случайные одноразовые коды). Даже при использовании сертификатов с таким расширением у нарушителя остаётся окно для атаки, определяемое сроком действия OCSP-ответа: всё ещё возможно провести атаку повторного воспроизведения и прислать клиенту старый OCSP-ответ, полученный ещё до того как сертификат был отозван.
2. Должна использоваться опция «Status Request (Version 2)». Эта опция позволяет прикреплять OCSP-ответы для всех сертификатов в цепочке, а не только для сертификата сервера. Это позволяет вовсе отказаться от явного выполнения OCSP-запросов на стороне клиента и всех присущих ему и описанных ранее недостатков.
Итак, в сухом остатке, «параноидальная» схема проверки статуса сертификатов основана на следующем:
- TLS-сервер использует сертификат с расширением «TLS Feature», обязывающем сервер поддерживать опции протокола TLS «Status Request (Version 1)» и «Status Request (Version 2)»;
- TLS-клиент и TLS-сервер должны использовать прикреплённые OCSP-ответы, защищённые случайными одноразовыми кодами от атаки повторного воспроизведения;
- если TLS-клиент поддерживает опцию «Status Request (Version 1)», но не поддерживает опцию «Status Request (Version 2)», то получив от сервера сертификат с расширением «TLS Feature», он должен явно выполнить OCSP-запросы (с использованием случайных одноразовых кодов) для сертификатов промежуточных УЦ в режиме hard fail.
- увеличение нагрузки на OCSP-серверы УЦ;
- уязвимость к DDoS атакам на серверы УЦ.
В качестве решения второй проблемы на сервере можно попеременно использовать несколько сертификатов, выпущенных независимыми УЦ. В таком случае пока OCSP-серверы одного УЦ будут «лежать» из-за DDoS, TLS-сервер будет использовать альтернативный сертификат, выпущенный другим УЦ, не находящимся под атакой. Использование нескольких сертификатов также позволит балансировать нагрузку между УЦ.
Для того, чтобы оценить, насколько клиентская сторона (под Windows) готова к переходу в светлое будущее, можно взглянуть на следующую таблицу:
Схема для большинства
Как было сказано ранее, для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).
Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.
Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е. OCSP-ответами, кэшируемыми на стороне TLS-сервера). При этом сертификаты с коротким сроком действия чуть более эффективны с точки зрения экономии трафика и количества операций, необходимых для проверки сертификата.
Подход с использованием сертификатов с коротким сроком действия обладает целым рядом достоинств, однако малопригоден для сертификатов УЦ. Для проверки статуса таких сертификатов можно использовать периодически обновляемые чёрные списки аналогичные «CRLSets» и «OneCRL», но предоставляющие пользователям больший контроль на агрегаторами CRL. Пользователи, например, должны иметь возможность добавлять новые опрашиваемые точки распространения CRL. Это важно, поскольку некоторые организации разворачивают собственные не публичные УЦ для внутреннего использования. Решением может стать возможность использования приватных агрегаторов CRL. При этом понадобится разработать открытый протокол взаимодействия клиента и агрегатора CRL, обеспечивающий совместимость клиентов и агрегаторов различных вендоров.
Итог
Что ж, пока что всё не очень хорошо: проверки статуса сертификатов в современных браузерах действительно не работают.
Однако свет в конце тоннеля всё же есть, и ситуация постепенно, хотя и медленно, движется к лучшему.
В данной статье речь пойдёт о том как проверить и собрать цепочку сертификатов с помощью консоли. О том что такое SSL сертификат Вы можете узнать из нашей статьи «SSL сертификаты — особенности и отличия».
Примеры описанные в данной статье выполнены на OS семейства Debian / Ubuntu.
Все описанные ниже команды выполняются в терминале (консоле), из директории в которой расположены все необходимые нам файлы.
Обязательным условием для проверки является наличие установленного пакета openssl, проверить наличие очень легко, достаточно ввести команду:
При наличии пакетов Вы получите следующий вывод на экран:
В ином случае Вам стоит установить данный пакет, для этого выполните команду
apt install openssl
Итак, сперва проверим корректность содержимого CSR, выполняем команду
openssl req -text -noout -verify -in server.csr
Стоит обратить внимание на строку
verify — статус корректного файла должен иметь значение «OK»
Немнго о значениях поля Subject:
- C — сокращённое название страны
- ST — область, в которой расположена организация
- L — город, в которой расположена организация
- O — наименование организации
- OU — обозначение отрасли в которой работает компания
- CN — адрес сайта (доменное имя) Вашей компании
- emailAddress — это поле думаю понятно всем, это контактный адрес электронной почты
Далее необходимо проверить корректность ключа, для этого требуется выполнить
openssl rsa -in server.key -check
Опять таки для нас наиболее важной информацией является статус в поле RSA key, если
статус «ok» - с ключом всё в порядке.
Проверяем SSL сертификат:
openssl x509 -in crt.crt -text -noout
В листинге вывода мы видим данные сертификата:
- срок действия сертификата описан в блоке периода действия (Validity)
- Not Before обозначают дату начала действия (не ранее чем)
- Not After дату конца действия (не позже)
После проделанных действий необходимо сравнить соответствие полученных ключа,
сертификата и CSR.Выполняется это сравнением MD5 сумм.
openssl x509 -noout -modulus -in crt.crt |md5sum
openssl rsa -noout -modulus -in key.key |md5sum
openssl req -noout -modulus -in csr.csr | md5sum
Если ключ, сертификат и CSR созданы друг для друга — хешсуммы будут одинаковыми.
Соберем цепочку сертификатов.
Чтобы понять в какой последовательности должны быть добавлены данные необходимо
выполнить команду :openssl x509 -in имя_сертификата.crt -noout -text | egrep "Subject:|Issuer:"
для каждого сертификата, который был прислан в архиве.
Вывод на экран получается следующего вида:
Сопоставив полученные данные делаем вывод о том, что сертификаты должны идти в
следующем порядке, ссразу добавляем их в bundle.cat sics_com_ua.crt > ./bundle.bundle
cat SectigoRSADomainValidationSecureServerCA.crt >> ./bundle.bundle
cat USERTrustRSAAddTrustCA.crt >> ./bundle.bundle
cat AddTrustExternalCARoot.crt >> ./bundle.bundle
Стоит обратить внимание на символы > и >>.
Одинарный знак будет перезаписывать файл в то время как двойной дописывать.
После проведённых действий производим проверку сертификатов и bundle на соответствие
по хешсумме.В том случае если цепочка будет собрана не верно, сумма совпадать не будет.
Для проверки полной цепочки установленной на сайте необходимо выполнить команду:
В разделе Certificate chain описывается цепочка.
У нас Вы можете заказать VPS c ОС Debian и Ubuntu. Если во время использования инструкции у Вас возникнут вопросы, наша техническая поддержка готова прийти на помощь в любое время.
Читайте также: