Что такое CRL или список аннулированных сертификатов?
Что такое CRL или список аннулированных сертификатов?
CRL или CAC — списки SSL-сертификатов, отозванных центром выдачи (CA). На 2017 год происходит отказ от использования CRL (САС) в пользу OCSP (Онлайн Протокол Состояния Сертификата).
SSL обеспечивает защищённое HTTPS-соединение с сайтом, но существуют угрозы безопасности даже при действующем сертификате. Самая распространённая – секретный ключ скомпрометирован. Передача данных становится небезопасна. Чтобы номера кредитных карт и пароли пользователей не попали к мошенникам, сертификат нужно отозвать.
Основные причины аннулирования SSL:
Как работают списки CRL?
Список аннулированных сертификатов публикует Certificate Authority (CA), выдавший сертификат:
1) Владелец домена или посетитель сайта, заметивший проблему, обращается в CA и просит аннулировать действующий SSL.
2) CA заносит уникальный серийный номер сертификата в список CAC, который:
3) Каждый раз при соединении с ресурсом браузер посетителя проверяет, аннулирован ли SSL-сертификат. Смотрит в загруженных списках CRL или по протоколу OCSP — через запрос к CA. Если находит сертификат в списке CRL или получает от CA ответ, что сертификат отозван — показывает предупреждение об ошибке.
Не все браузеры загружают списки CAC и пользуются OCSP
Firefox проверяет статус только для сертификатов с расширенной проверкой EV. Пользователи этого браузера не узнают об отзыве SSL DV и OV. Так же как и мобильные пользователи Safari в iOS. Chrome определяет статус сертификата для Windows, но не для Linux и Android.
Internet Explorer и Opera — самые безопасные в этом отношении браузеры. Они используют OCSP и CRL в зависимости от того, что предлагает CA.
Аннулированный сертификат нельзя восстановить, только купить новый. Берегите секретный ключ — его утеря или компрометация чаще всего приводит к отзыву SSL-сертификата.
Проверка SSL-сертификатов на предмет отзыва
В наше время одним из самых важных аспектов безопасной передачи информации является шифрование. Данные при передаче от клиента к серверу зашифровываются с помощью SSL-сертификата. Сертификат – это публичный ключ, заверенный удостоверяющим центром.
Все SSL-сертификаты, как правило, выдаются на ограниченный срок, по окончании которого они теряют силу и должны быть переизданы. Однако бывают случаи, когда сертификат может быть отозван ещё до окончания срока действия. Причин на отзыв SSL-сертификата довольно много, самые распространённые из них – закрытый ключ был утерян или скомпрометирован, изменились регистрационные данные компании и т.п.
Существует 2 альтернативных способа проверить, находится ли SSL-сертификат в списках отзыва:
Скачаем сертификат интересующего нас домена:
Спасибо legioner за подсказку добавить параметр -servername — он необходим для правильного выбора сертификата, если на один IP-адрес их установлено несколько (SNI).
Смотрим детали сертификата:
Здесь нас интересует в разделе «X509v3 CRL Distribution Points» пункт «Full Name».
Скачиваем по этой ссылке список CLR:
Выдираем серийный номер сертификата:
Смотрим, есть ли этот номер в списке CRL:
Если ничего не нашлось, значит сертификат не является отозванным.
Выведем на экран сертификат интересующего нас домена и цепочки промежуточных (Intermediate) сертификатов:
Отправим запрос OCSP-серверу проверить сертификат на предмет отзыва:
Если всё указали правильно, то OCSP-сервер должен вернуть информацию по сертификату.
Здесь интерес представляют последние строчки:
Об отсутствии сертификата в списке отозванных говорит значение «good», если же сертификат отозвали, то значение будет «revoked».
Автоматизация
Проверять SSL-сертификаты на предмет отзыва вручную не всегда удобно, поэтому процесс проверки можно автоматизировать.
Для этого берём с Github готовый скрипт ssl-check-revoc.sh, который осуществляет проверку сертификатов методом CRL:
Далее делаем скрипт исполняемым:
Zabbix
Скрипт ssl-check-revoc.sh может проверять сертификаты не только из консоли, он также вполне подходит в качестве чекера для Zabbix, поэтому всю грязную работу по отслеживанию попадания сертификатов в список отзыва можно поручить системе мониторинга.
Заходим в конфиг Zabbix /etc/zabbix/zabbix_server.conf и смотрим, где лежат скрипты для внешних проверок:
Копируем в этот каталог наш скрипт и рестартуем Zabbix:
Заходим в веб-интерфейс и создаём шаблон (Configuration >> Templates >> Create template). В качестве имени шаблона указываем «Template SSL Checking». Затем внутри шаблона создаём элемент данных (Item) «SSL Certificate in Revocation List», в качестве ключа указываем «ssl-check-revoc.sh[
Также понадобятся два триггера:
1. Для сигнализации отзыва сертификата «Certificate for domain
Expression: «].last()>=1″
2. Для сигнализации об ошибке на случай, если что-то пойдёт не так (например возникнут проблемы с CLR-сервером и т.п.) «Error to check certificate for domain
Expression: «].last()>=2″
Не забываем в экшенах (Configuration >> Actions) настроить способ оповещения в случае срабатывания триггеров.
Теперь осталось создать хосты, сертификаты которых будем регулярно проверять (Configuration >> Hosts >> Create host). На вкладке Templates прилинковываем наш темплейт «Template SSL Checking».
И всё! Можно спать спокойно: если SSL-сертификат вашего домена по какой-либо причине попадёт в список отозванных, Zabbix сразу же вам сообщит.
Памятка для удостоверяющих центров и других участников PKI
Удостоверяющий центр, в чьи функции входит поддержание жизненного цикла сертификатов открытых ключей проверки электронной подписи, шифрования, аутентификации и защиты каналов передачи данных, их выпуск, распределение, депонирование, резервное копирование, восстановление, отзыв и ведение списка отозванных сертификатов, является важнейшим участником и арбитром инфраструктуры открытых ключей.
УЦ должен работать, как часы. От его правильного функционирования зависит электронный документооборот множества клиентов и систем.
Некорректная работа или сбой удостоверяющего центра может привести к санкциям регуляторов, искам недовольных клиентов для самого УЦ и значительным финансовым и репутационным потерям всех участников электронного обмена.
Для удостоверяющих центров, аккредитованных в Министерстве цифрового развития, связи и массовых коммуникаций, выпускающих квалифицированные сертификаты и обеспечивающих безусловно юридически значимый электронный документооборот, такой вопрос стоит еще более остро.
В этом посте я хочу рассказать, с какими критическими проблемами и нарушениями в работе УЦ часто приходится сталкиваться, а также о том, как их избежать.
У полноправного участника Public Key Infrastructure, должна быть информационная система со встроенными СКЗИ, которая позволяет вести электронный документооборот с клиентами и партнерами, обмениваясь с ними документами с электронной подписью (ЭП) или зашифрованными данными.
Когда партнер присылает документы с ЭП, система выполняет ряд действий. Она проверяет электронную подпись на документе и партнерский сертификат открытого ключа проверки этой подписи.
В случае с квалифицированными сертификатами корневым будет сертификат Министерства цифрового развития, связи и массовых коммуникаций, а промежуточным между корневым и конечным пользовательским – сертификат аккредитованного УЦ, выданный головным УЦ Министерства цифрового развития.
Одна из главных задач контроля и ключевых фишек PKI в автоматическом электронном обмене документами – это необходимость и возможность убедиться, что сертификат не был отозван партнером и УЦ подтверждает, что сертификат действующий.
Сбои и некорректная работа УЦ в части публикации CRL
Сам по себе сертификат тоже является электронным документом с электронной подписью, которую ставит УЦ при его выпуске. Таким образом все атрибуты внутри сертификата, в том числе открытый ключ и ссылки на списки отзыва, заверены удостоверяющим центром и защищены от подмены.
CRL тоже подписан ЭП удостоверяющего центра, что дает дополнительную защиту от подмены и атак посредника «Man in the middle» при его загрузке по открытому каналу. Он содержит атрибуты с периодом своего действия и серийные номера отозванных сертификатов.
Процедура полной проверки сертификата на отзыв сводится к необходимости загрузить список с указанного URL, проверить срок его действия, проверить ЭП, убедиться, что серийного номера данного сертификата в нем нет.
Невозможность по тем или иным причинам убедиться, что сертификат пользователя не отозван, приводит к отрицательному результату проверки как самого сертификата, так и электронной подписи на поступивших от этого пользователя документах.
Такие документы будут отвергнуты до восстановления возможности проверить сертификат на отзыв.
То же самое касается контроля клиентских и серверных сертификатов, которые используются для построения защищенного канала связи TLS ГОСТ или TLS RSA по протоколу HTTPS. Если системам партнеров не удается проверить их на отзыв, то защищенное и 100% доверенное соединение партнеры установить между собой не смогут.
Какие сбои и нарушения здесь может допустить УЦ?
1. Перенаправление ссылок (Redirect)
УЦ опубликовал в сертификате конкретный URL, но на сервере, где этот ресурс опубликован, происходит перенаправление клиента на другой URL.
Вызывающая система на Java может легко определить, что включено перенаправление следующим образом:
2. HTTPS в CDP атрибуте сертификата и ни одной общедоступной ссылки
Приходилось встречать даже квалифицированные сертификаты, где не было ни одной ссылки, по которой система могла бы свободно загрузить список отзыва.
Попадались сертификаты с https://, ldap:// или защищенный SFTP, также были просто URL с IP адресами из внутренней подсети. Все эти ссылки допустимы при наличии хотя бы одной ссылки HTTP или FTP (без логина и пароля) доступной из сети Internet всем.
Почему HTTPS к свободным не относится?
За списками отзыва могут обращаться далеко не только интернет-браузеры, имеющие обширное хранилище корневых доверенных сертификатов международных УЦ, которое позволяет им поднимать защищенное соединение по HTTPS-ссылке и принимать ресурс как доверенный.
Другие информационные системы могут не иметь такого хранилища с предустановленными корневыми сертификатами и не обязаны поднимать контекст защищенного соединения к HTTPS-ссылкам.
Просто невозможно во все системы установить все корни для всего многообразия УЦ, выпускающих SSL/TLS-сертификаты.
По понятным причинам информационные системы также не могут знать логин и пароль от FTP и не будут иметь доступ к внутренней службе Active Directory по LDAP-протоколу.
Поэтому принято, что CRL публикуется в свободном доступе.
3. HTTP перенаправление (redirect) на HTTPS
Это гибридная ситуация, с которой приходилось сталкиваться, состоящая из приведенных выше пунктов 1 и 2.
Как такое возможно?
Сайт компании, где УЦ публикует свои списки отзыва, или просто веб-сервер, который используется удостоверяющим центром для этих целей, запущен, например, на Nginx.
Администратор сайта, желающий исключительно добра и защитить сайт и пользователей, совершенно забыв, а может, и не зная про публикацию CRL, включает безусловный redirect всего сайта на HTTPS.
Получается, что в сертификате приведен URL с http://, а системы, которые чувствительны к такому факту подмены подписанной информации из сертификата и справедливо защищаются от атак посредников, перестают загружать списки отзыва данного УЦ, пока администратор не настроит на сайте исключения для CRL.
4. Фильтрация по User Agent
Данная проблема и нарушение доступа к спискам отзыва сильно перекликается с приведенной в пункте 3.
Тот же администратор сайта, на том же Nginx включает фильтрацию по User Agent. Например, все системы на Java будут получать ошибку HTTP 403 при обращении к ресурсу.
Администратор забывает про то, что совершенно любая система должна иметь доступ к спискам отзыва в соответствии со стандартами группы PKIX.
Еще администратор сайта, где публикуются списки отзыва, может включить redirect на основе User Agent.
5. Просроченный CRL
Сертификат может содержать несколько ссылок на списки отзыва. Внутри каждого CRL могут быть вложены ссылки на его дельты с иными, более короткими сроками жизни, а следовательно, обновляемые чаще.
Хорошая информационная система должна загрузить список по каждой доступной ссылке, загрузить все вложенные дельты и убедиться, что серийный номер проверяемого сертификата не встречается ни в одном из них.
Рекурсивный алгоритм поиска в коробках, вложенных друг в друга, хорошо подходит для решения этой задачи.
А чтобы не загружать CRL каждый раз при интенсивном обмене в автоматических информационных системах, списки отзыва можно кэшировать на заданное разумное время, но не больше срока их жизни.
Были случаи, когда по каким-то причинам УЦ своевременно не обновлял CRL.
Список отзыва с истекшим сроком действия, естественно, не принимается. И если для сертификата нет или не удается загрузить по другим ссылкам действующий список, то общий результат будет отрицательным, а документ с ЭП отвергнут.
6. Сбои на сетевом и транспортном уровне
В качестве примера можно привести ситуацию со сбоем или некорректными настройками и состоянием на оборудовании удостоверяющего центра или сайта организации.
В сертификате, выпущенном УЦ, может быть прописано два URL с http:// и разными host именами. Такой подход правильный, он позволяет иметь резерв и всегда держать одну ссылку в доступе, если требуется провести какие-то работы на другом сервере.
Но вот незадача. Вызывающая система вдруг начинает получать IOException: ConnectionTimeOut при попытке подключения к одной из ссылок. Вторая ссылка при этом работает и отдает CRL. А вызывающая система все равно начинает замедляться на настроенное в ней время, например, ConnectionTimeOut=15000 mSec, потому что проверяет обе ссылки, и ей приходится ждать ответа от недоступной в настоящий момент.
А если в CDP сертификата четыре, пять разных ссылок на CRL и при этом две или три из них оказываются недоступны с ConnectionTimeOut?
В этом случае время проверки сертификата возрастает до неприличной величины, равной времени таймаута, умноженному на количество таких ссылок.
А что, если обмен нашей информационной системы идет с этим УЦ или партнером, организацией, аффилированной с данным УЦ? И система партнера имеет свой таймаут на вызов нашей информационной системы, который заведомо меньше того времени, которое наша система тратит на проверку их сертификата?
Партнеры говорят нам, что не получают ответ от нашей системы и отключаются по таймауту, а происходит это на самом деле из-за регламентных работ на их УЦ.
Почему может происходить ConnectionTimeOut?
Как вариант, это регламентные работы, сетевая атака или повышенная нагрузка на сайт УЦ, что привело к неконсистентному состоянию:
какой-то брандмауэр, файрвол на пути, который просто начал съедать сетевые пакеты, не сообщая отправителю такие вещи, как «No Route to host»
началась потеря пакетов из-за неправильной конфигурации сети или перегрузки линии
слишком много запросов, перегружающих сервер
небольшое количество одновременно доступных потоков / процессов на сервере, что приводит к их блокировке. Это происходит особенно с запросами, выполнение которых занимает много времени и может сочетаться с предыдущим пунктом
Как с этим справляться?
Удостоверяющим центрам следует мониторить нагрузку на точки публикации списков отзыва, применять средства защиты от сетевых атак.
А в случае регламентных работ необходимо следить за тем, чтобы сервер, слушающий данный сокет, был корректно погашен, а не оставался в некоем подвешенном состоянии.
Если точка публикации будет корректно отключена, то вызывающая система, мгновенно получив от этой ссылки, например, IOException Connection Refused: connect, сразу перейдет к загрузке по следующему URL.
Вызывающая система для купирования таких ситуаций может выполнять кэширование «битых» ссылок на непродолжительный интервал, например 5 минут. Это позволит при интенсивном обмене практически не потерять скорость обработки запросов и одновременно сохранить актуальность результатов проверки сертификатов.
Чем должны руководствоваться УЦ при публикации CRL
Спецификацией RFC 5280 IETF и стандартом X.509 ITU-T, разработанными Инженерным советом Интернета и Международным консультационным комитетом по телефонии и телеграфии.
В частности, пунктом 8. Security Considerations из RFC 5280
When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.
CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server’s certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server’s certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.
УЦ не должны включать HTTPS или LDAP-ссылки для публикации своих списков отзыва.
Если УЦ все же включают такие ссылки, то они должны убедиться, что серверные сертификаты могут быть проверены без использования этих ссылок.
Также удостоверяющим центрам следует знать и помнить, что включение HTTPS-ссылок на свои списки отзыва, в том числе в серверные сертификаты для того же HTTPS-канала, может создавать циклические неразрешимые зависимости и привести к неограниченной рекурсии в попытках проверить сертификат на отзыв и установить защищенное соединение с применением этого же сертификата.
Другими словами, клиент и сервер будут пытаться поднять защищенное HTTPS-соединение друг с другом. Для этого им потребуется проверить сертификаты на отзыв. А чтобы это сделать, тоже нужно поднять защищенное соединение по HTTPS-ссылке к CRL, которую УЦ неосмотрительно опубликовал в атрибуте сертификата.
Следует упомянуть, что существует иной способ проверки сертификата на отзыв.
Такие сертификаты также включают в себя стандартный атрибут CDP и могут проверяться обычным способом.
А для работы с сервером OCSP они должны включать еще и расширение OCSP Server Client.
Но это материал для отдельной статьи.
Обязательные атрибуты квалифицированных сертификатов
Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.
Удостоверяющий центр данную ситуацию комментировал так:
атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа №795
На конкретный пункты Закона и Приказа в УЦ не ссылались.
Собственный повторный анализ юридических аспектов показал:
63-ФЗ от 06.04.2011 «Об электронной подписи»
Статья 14. Сертификат ключа проверки электронной подписи
2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:
Статья 17. Квалифицированный сертификат
2. Квалифицированный сертификат должен содержать следующую информацию:
III. Требования к порядку расположения полей квалифицированного сертификата
5) stateOrProvinceName (наименование штата или области).
В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;
6) localityName (наименование населенного пункта).
В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего населенного пункта. Объектный идентификатор типа атрибута localityName имеет вид 2.5.4.7;
7) streetAddress (название улицы, номер дома).
В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую часть адреса места нахождения соответствующего лица, включающую наименование улицы, номер дома, а также корпуса, строения, квартиры, помещения (если имеется). Объектный идентификатор типа атрибута streetAddress имеет вид 2.5.4.9;
В сертификате партнера в имени субъекта сертификации были указаны: stateOrProvinceName (наименование штата или области), streetAddress (название улицы, номер дома).
И не указано localityName (наименование населенного пункта).
Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)
Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя ‑ юридического лица.
Таким образом, в случае отсутствия в выписке из единого государственного реестра юридических лиц информации о наименовании населенного пункта, но при наличии информации о наименовании муниципального образования, аккредитованному удостоверяющему центру для заполнения квалифицированного сертификата вместо наименования соответствующего населенного пункта следует использовать наименование соответствующего муниципального образования.
На основании изложенного в качестве значения атрибута имени «localityName» поля «subject» в структуре квалифицированного сертификата следует указывать текстовую строку, содержащую наименование соответствующего населенного пункта или соответствующего муниципального образования.
Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.
Прошу использовать данную информацию в работе.
Желаю всем участникам PKI удачи и успехов!
Шпоры по сертификатам X.509
Чудище обло, озорно, огромно, стозевно и лаяй.
Кстати что общего между LDAP, SNMP и X.509 ну кроме того, что им еще не скоро предстоит собрать стадионы фанатов? Их объединяет ASN.1 — мета-язык описания объектов древности. Если бы эти технологии создавали сейчас, в ход бы пошли XML, DTD или какой-нибудь другой ML. Но в то время стандарты создавались титанами, для которых даже SNMP был простым делом.
Словарный запас
Определение X.509 сертификатов есть в архиве ITU-T
Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1 SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.
Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.
Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.
Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией. Полгода назад Гугл пригрозил компании Симантек, что перестанет доверять их сертификатам из-за того, что те выпустили аж 30,000 неисправных сертификатов.
Номенклатура сертификатов
Давайте рассмотрим, какие сертификаты X.509 встречаются в природе, если рассматривать их по расположению в пищевой цепочке доверия.
По степени крутизны дороговизны и надежности сертификаты делятся на 3 вида: DV, OV и EV.
Редко, кто на это готов раскошелиться. Навскидку Яндекс, StackOverflow.com и Хабр могут жить и без него. Но те, кто готов пойти ради этого на жертвы должны выполнить следующие требования:
По свои свойствам сертификаты бывают следующих типов.
В России понятие КС квалифицированного сертификата определено законодательно в связи с доступом к ГосУслугам. По ссыске Хабрапост с былиной об извлечении персональных данных из КС.
Откуда берутся сертификаты?
Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.
Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:
Следует серия вопросов, чтобы было чем запомнить поля owner и issuer
Конвертируем связку ключей из проприетарного формата в PKCS12.
Смотрим на результат:
LetsEncrypt
Сценарий №1 — найти следующего в связке
Так и есть, SKI сертификат DigiCert имеет то же значение.
Сценарий №2 — используй subjectAltnName, Люк
Откройте файл openssl.cnf и в секции req добавьте следующие линии.
Далее, в секции [ v3_ca ] укажите.
А дальше все как обычно, создаем закрытый ключ и подписываем сертификат.
