Как проверить подлинность сертификата? | УЦЭПС АТ Группа компаний | УЦЭПС АТ

*хочу отметить, что во всех вышеуказанных реестрах можно проверить сертификаты на продукцию, которая подлежит обязательной сертификации. реестра добровольных сертификатов в открытом доступе не существует!!!!!

Итак, мы разобрались в какой из реестров нам нужно обратиться. Нажимаем на нужный нам реестр, и открывается страница с формой поиска сертификатов (эта страница выглядит одинаково для всех трёх реестров). Далее, для примера, я буду искать в реестре под цифрой 2.

Самое простое, это искать не по номеру сертификата !!!!!, а по заявителю и наименованию продукции. Дело в том, что в номере сертификата содержаться как русские так и латинские буквы, и если перепутать хотя бы одну букву (например вместо русской «М», поставить английскую «М»), то нужный сертификат вы в реестре не найдёте, или можете потратить много времени на поиск нужной комбинации русских и английских букв.

Ocsp stapling

Для решения этих проблем было предложено расширение протокола TLS, позволяющее прикреплять OCSP-ответы к сертификатам (

) и переносящее ответственность за выполнение OCSP на TLS-сервер.

На рисунке изображена схема использования OCSP stapling:

Схема описывает следующие шаги:

1. TLS-сервер, выступая в роли OCSP-клиента, собирает информацию о статусе своей цепочки сертификатов, обращаясь к OCSP-серверам соответствующих УЦ;
2. TLS-сервер кэширует полученные OCSP-ответы;
3. При установке TLS-соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами.

Таким образом:

«Но где же тут защита от атаки повторного воспроизведения?» — спросите вы. Тут её действительно нет, однако рассматриваемое расширение протокола TLS позволяет клиентам пересылать случайный одноразовый код при установке соединения:

Такой вариант использования OCSP stapling не позволяет кэшировать OCSP-ответы на сервере, из-за чего растёт время установки TLS-соединения и увеличивается нагрузка на серверы УЦ.

Следует отметить, что существует две версии OCSP stapling. Первая версия по неясной причине позволяет прикреплять OCSP-ответ только для сертификата самого сервера. При использовании этой версии ответственность за получение информации о статусе остальных сертификатов цепочки лежит на клиенте. Этот недостаток исправлен в новой версии.

Базовая реализация pki

1. У Алисы и Боба есть сертификаты открытого ключа, выданные Кэрол, центром сертификации (CA).
2. Алиса желает выполнить транзакцию с Бобом и отправляет ему свой сертификат открытого ключа.
3. Боб, обеспокоенный тем, что закрытый ключ Алисы мог быть скомпрометирован, создает «запрос OCSP», содержащий серийный номер сертификата Алисы, и отправляет его Кэрол.
4. Ответчик Кэрол OCSP считывает серийный номер сертификата из запроса Боба. Ответчик OCSP использует серийный номер сертификата для поиска статуса отзыва сертификата Алисы. Ответчик OCSP просматривает базу данных CA, которую поддерживает Кэрол. В этом сценарии база данных CA Кэрол – единственное надежное место, где будет записана компрометация сертификата Алисы.
5. Ответчик OCSP Кэрол подтверждает, что сертификат Алисы все еще в порядке, и возвращает Бобу подписанный успешный «ответ OCSP».
6. Боб криптографически проверяет подписанный ответ Кэрол. Боб сохранил открытый ключ Кэрол незадолго до этой транзакции. Боб использует открытый ключ Кэрол, чтобы проверить ответ Кэрол.
7. Боб завершает транзакцию с Алисой.

Давайте рассмотрим пример. у нас на руках есть сертификат под номером тс ru с-ru.мт40.а.00049, оформленный на продукцию – снегоболотоход «медведь», заявитель – индивидуальный предприниматель санто наталья владимировна.

Заполняем поле «Заявитель» – пишем Санто и нажимаем поиск:

Видим, что в реестре нашлось 289 сертификатов.

Теперь добавляем в поле «Продукция» слово Медведь.

И видим, что поиск сократился всего лишь до двух сертификатов, из которых мы выбираем нужный нам.

Далее открываем в реестре нужный нам сертификат и видим всю информацию по этому сертификату:

Номер, срок действия, когда и кем выдан, на основании чего он выдан, кто является изготовителем данной продукции и т.д., в том числе статус сертификата, и в случае, если сертификат имеет статус «приостановлен» или «аннулирован», то будет запись на основании чего принято такое решение.

Детали протокола

Ответчик OCSP (сервер, обычно запускаемый издателем сертификата) может вернуть подписанный ответ, означающий, что сертификат, указанный в запросе, является «хорошим», «отозванным» или «неизвестным». Если он не может обработать запрос, он может вернуть код ошибки.

Формат запроса OCSP поддерживает дополнительные расширения. Это дает возможность обширной настройки конкретной схемы PKI.

OCSP может быть уязвим для атак повторного воспроизведения , когда подписанный «хороший» ответ перехватывается злонамеренным посредником и воспроизводится клиенту позже, после того, как субъектный сертификат мог быть отозван. OCSP позволяет включать одноразовый номер в запрос, который может быть включен в соответствующий ответ.

Из-за высокой нагрузки большинство респондентов OCSP не используют расширение nonce для создания разных ответов на каждый запрос, вместо этого используют заранее подписанные ответы с периодом действия в несколько дней. Таким образом, атака воспроизведения представляет собой серьезную угрозу для систем проверки.

OCSP может поддерживать более одного уровня CA. Запросы OCSP могут быть связаны между одноранговыми ответчиками для запроса выдающего ЦС, соответствующего сертификату субъекта, при этом респонденты проверяют ответы друг друга в отношении корневого ЦС, используя свои собственные запросы OCSP.

У респондента OCSP может быть запрошена информация об отзыве серверами проверки делегированного пути (DPV). OCSP сам по себе не выполняет DPV предоставленных сертификатов.

Ключ, которым подписывается ответ, не обязательно должен быть тем же ключом, который подписал сертификат. Издатель сертификата может делегировать другой орган в качестве ответчика OCSP. В этом случае сертификат респондента (тот, который используется для подписи ответа) должен быть выпущен эмитентом соответствующего сертификата и должен включать определенное расширение, которое отмечает его как подписывающий орган OCSP (точнее, расширенный расширение использования ключа с OID {iso (1) идентифицированная организация (3) dod (6) Интернет (1) безопасность (5) механизмы (5) pkix (7) keyPurpose (3) ocspSigning (9)})

И, последнее, о чем ещё хочу рассказать – это статус сертификата в реестре. когда вы найдете нужный вам сертификат, напротив него будет один из четырех кружков определенного цвета.

Статус «действует» (зеленый кружок) – означает, что сертификат действует. Всё нормально.

Статус «Приостановлен» (оранжевый кружок)- означает, что действие сертификата на данный момент приостановлено по каким либо причинам. Причина и дата приостановления будет указана внутри описания сертификата. Возможно, после устранения причин, послуживших для приостановки действия сертификата, его действие будет возобновлено.

Статус «Аннулирован» (красный кружок) – означает, что действие сертификата прекращено навсегда. Причина и дата аннулирования будет указана внутри описания сертификата.

Статус «Архивный» (розовый кружок) – означает, что сертификат не действует в настоящее время, потому что истёк срок действия сертификата.

Кратко о протоколе tls и инфраструктуре открытых ключей x.509

Современный защищённый Веб стоит на двух китах:

. Для установки защищённого TLS-соединения сервер должен передать клиенту свой открытый ключ. Аутентичность ключа сервера, пересылаемого через незащищённые публичные сети, обеспечивается цепочкой сертификатов открытых ключей инфраструктуры

Удостоверяющий центр (УЦ, certification authority, CA) может отозвать подписанный (изданный) им ранее сертификат, например, в случае компрометации закрытого ключа, соответствующего этому сертификату. Поэтому, чтобы исключить возможность подключения к «человеку посередине», при установке TLS-соединения клиент должен не только проверять корректность подписей всей предоставленной сервером цепочки сертификатов, но и проверять статус предоставленных ему сертификатов (сертификат действителен или отозван).

Механизм crl

УЦ публикуют CRL, в которые вносятся серийные номера отозванных сертификатов, в точках распространения CRL (CRL distribution point, CDP). Адреса (URL) точек распространения CRL, к которым следует обращаться для получения информации о статусе проверяемого сертификата, как правило, указываются в самом сертификате.

Механизм ocsp

OCSP, как следует из его названия, предназначен для получения наиболее актуальной информации о статусе сертификата в режиме онлайн и не обладает приведёнными выше недостатками CRL.

Механизмы проверки статуса сертификатов

Применяющиеся на практике механизмы проверки статуса сертификатов основаны на

(certificate revocation list, CRL) и

(online certificate status protocol, OCSP).

Поддержка браузера

Информация OCSP в Firefox 89

OCSP широко поддерживается большинством основных браузеров:

Однако Google Chrome – особый случай. Google отключил проверки OCSP по умолчанию в 2021 году, сославшись на проблемы с задержкой и конфиденциальностью, и вместо этого использует собственный механизм обновления для отправки отозванных сертификатов в браузер.

Попадаем в раздел «сертификаты соответствия», в котором содержится три подраздела:

1. Единый реестр сертификатов соответствия – в этом реестре содержатся сертификаты, оформленные по требованиям технических регламентов Российской Федерации. Номера таких сертификатов начинаются с символа «С-» и имеют следующий вид: «С-CN.МТ40.А.00001».

2. Национальная часть единого реестра выданных сертификатов соответствия, оформленных по единой форме – в этом реестре содержатся сертификаты, оформленные по требованиям технических регламентов Таможенного союза, а также сертификаты, оформленные на продукцию, включенную в единый перечень продукции в рамках Таможенного союза.

3. Реестр сертификатов соответствия продукции, включенной в Единый перечень продукции РФ – в этом реестре содержатся сертификаты, выданные на продукцию, которая не попадает под действие Технических регламентов, но подлежащая обязательной сертификации. Номера таких сертификатов начинаются с символов «РОСС» и имеют следующий вид: «РОСС RU.МТ40.B00001»

Проблемы конфиденциальности

Проверка OCSP создает проблему конфиденциальности для некоторых пользователей, так как она требует, чтобы клиент связался с третьей стороной (хотя и стороной, которой доверяет поставщик клиентского программного обеспечения), чтобы подтвердить действительность сертификата. Сшивание OCSP – это способ проверки действительности без раскрытия информации о поведении при просмотре в ЦС.

Продолжение следует… а пока — отличная новость!

В этой статье мы рассмотрели три основных механизма проверки статуса сертификатов. Проверки, осуществляемые на практике, являются надстройками над этими механизмами или их комбинацией. Тема дальнейшего обсуждения и следующей статьи — каким образом проверки статуса сертификатов реализованы в Веб-браузерах?

Про проблему отозванных сертификатов и «Кошмар скомпрометированных ключей» мы говорили на «очной ставке» NeoQUEST-2021. У нас даже есть отличное видео, в котором автор статьи рассказывает про отозванные сертификаты:

Пока у нас активно ведется подготовка к очередной «очной ставке» NeoQUEST-2021, которая пройдет в Питере 29 июня (и на которую мы ждём ВСЕХ желающих!), рассказываем интересную новость:

Мы объявляем конкурс докладов на «очную ставку» NeoQUEST-2021!

Сравнение с crl

• Поскольку ответ OCSP содержит меньше данных, чем типичный список отзыва сертификатов (CRL), он создает меньшую нагрузку на сетевые и клиентские ресурсы.
• Поскольку в ответе OCSP содержится меньше данных для анализа , клиентские библиотеки, которые его обрабатывают, могут быть менее сложными, чем те, которые обрабатывают CRL.
• OCSP сообщает ответчику, что конкретный сетевой хост использовал определенный сертификат в определенное время. OCSP не требует шифрования, поэтому другие стороны могут перехватить эту информацию.