Как найти в crl сертификат

Теория. Для чего нужен CRL

Список отзывов сертификатов (Certificate revocation list) — представляет собой файл указывающий на список сертификатов с указанием серийного номера сертификата, даты отзыва, причина отзыва. В целом списки отзыва сертификатов (CRL)
используются для передачи сведений об отзыве сертификатов пользователям, компьютерам и приложениям, пытающимся проверить подлинность сертификата. 

При каких ситуациях ваш сертификат может попасть в указанный список:

1. При выдаче сертификата УЦ ошибся в части реквизитов, поэтому был выдан новый сертификат.

2. Сертификатом завладело третье лицо, кто мог бы подписывать за вас (т.н. компрометация ключа).

3. Сертификат был отозван по заявлению владельца сертификата.

4. Сменилось уполномоченное лицо, владеющее сертификатом;

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

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

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

Предположим, что кому-то (или чему-то) сертификат больше не нужен (человек уволился, скомпрометирован секретный ключ и т.п.). Срок действия сертификата ещё не кончился, но нужно, чтобы он не работал. Для этого администратор CA
обновляет список отозванных сертификатов и размещает его в доступном для всех месте.

Петя уволился (сам или нет..)
1. На место Пети посадили Колю, который получил полный доступ к всей информации Пети. При этом ещё не все знают, что Пети нет.
2. Маша (которая ещё не знает, что случилось) шлёт Пете файл (что-то личное?!), зашифровав его Петиним открытым ключом.
3. Коля имеет доступ к секретному ключу Пети и может прочитать информацию от Маши. Так же не забываем, что он может ставить ЭЦП от имени Пети.

Если бы Маша проверила Петин сертификат по CRL, то она бы узнала, что сертификатом Пети шифровать уже нельзя. Да и другие люди должны знать, что Петя ничего больше подписывать не должен. Т.е. все должны регулярно обновлять CRL
(если это не делается автоматически или ПО само не производит on-line проверку сертификата). 

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

Практическое применение CRL

Итак, что же нам прежде всего необходимо сделать, чтобы мы могли полноценно использовать CRL в практических целях организации? Во-первых, если ЦС не развернут в вашей организации, то желательно запрашивать раз в неделю (т.к. CRL
во внешних организациях, зачастую формируются именно раз в неделю), и проводить его установку на локальные машины в профиль пользователя. Если же в вашей организации развернут ЦС, то формирование crl и его применение в дальнейшем лежит на ваших плечах. Подробнее
опишем ситуацию ниже.

Ситуация: ЦС был выдан сертификат. В DIRECTUM указанным сертификатом даже было подписано задание, задачи, документы. Выданным сертификатом завладело третье лицо, нам необходимо обеспечить, чтобы в рамках системы DIRECTUM, указанный
сертификат уже не мог использоваться.

В дальнейшем будем иметь дело со следующим сертификатом:

А вот и подписанное задание данным сертификатом.

Отзыв сертификата

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

1. Заходим в консоль ЦС. Открываем раздел «Выданные сертификаты».

2. Вызываем контекстное меню на необходимом нам сертификате, выбираем пункт «Все задачи» -> «Отзыв сертификата».

3. Проверяем, что сертификат отозван. На рисунке будет также видно, что серийный номер совпадает с тем, что был изначально указан в задаче.

На этом операции по отзыву сертификата окончены. Сейчас переходим к следующему пункту

Формирование CRL

CRL формируется также на самом ЦС довольно нехитрыми действиями.

1. Зайдите в консоль ЦС. Выбираем раздел «Отозванные сертификаты. Вызовем контекстное меню и выберем пункт «Все задачи» -> «Публикация».

Выберите тип публикуемого CRL: полный или разностный. Основное отличие это формирование полного списка или за выбранный при настройке период публикации. Если в вашей организации выдачей сертификатов не занимаются каждый день, и
список формируемых сертификатов не велик, то лучше выбрать тип «Полный». После выполнения указанных действий, получаем список отозванных сертификатов.

Также сформировать список CRL можно и при помощи командной строки вызвав команду certutil -crl.

2. После публикации указанного списка, необходимо его сформировать в файл. Для этого зайдите в веб-форму ЦС. Выберите действие «Загрузка сертификата ЦС, цепочки сертификатов или CRL» -> «Загрузка сертификата ЦС, цепочки сертификатов
или CRL». Сохраните указанный файл на компьютере.

После проделанных операций мы получаем список отзывов сертификата. Выглядит он следующим образом:

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

Установка CRL

Установка CRL проводится на каждом локальном профиле. При этом устанавливается указанный список, как обычный сертификат:

Далее знакомый интерфейс по установке сертификатов предложит нам установить сертификат. Особенностей в этом случае нет: выбираем «Автоматический выбор хранилища». После установки списка отзывов, можно проверять работает ли он,
и можем ли мы подписать, что-либо после указанных операций.

Проверка работоспособности CRL

Итак, наступает ответственный момент, в котором нам необходимо проверить работает ли список отозванных сертификатов в нашем случае. Для этого после установки CRL зайдите в систему DIRECTUM и попытайтесь подписать какой-либо объект системы отозванным сертификатом.
Если все действия были проделаны верно, то мы получим сообщение следующего вида:

А теперь проверим данные в компоненте «Пользователи», действительно ли ИД сертификата в сообщении равен тому, что указан в карточке пользователя:

Как видно из скриншота, информация совпадает, выполнять подписание указанным сертификатом мы больше не можем. Главное предназначение списка отзыва сертификатов выполняется.

Дополнительную информацию о процедуре формирования CRL, а также необходимых команд, вы можете найти на следующем ресурсе:

1.
http://technet.microsoft.com/ru-ru/library/cc739815(v=ws.10).aspx

2. http://technet.microsoft.com/ru-ru/library/cc778151(v=ws.10).aspx

3. http://technet.microsoft.com/ru-ru/library/cc782162(v=ws.10).aspx

4. http://technet.microsoft.com/ru-ru/library/cc772629(v=ws.10)

WildTuna	#1 Оставлено : 30 сентября 2020 г. 15:53:35(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 30.09.2020(UTC) Сообщений: 12 Сказал(а) «Спасибо»: 7 раз	Добрый день, Есть ПО cryptopro csp 4 и УЦ NotaryPRO. Есть корневой сертификат УЦ, X509 CRL файл и пользовательский сертификат выпущенный УЦ на основе запроса из Рутокен Plugin. Задача: Проверить сертификатом пользователя CMS подпись сообщеиня. Правильно ли я понимаю, что для решения этой задачи мне нужно выполнить следующие шаги? Список шагов: Установить корневой сертификат УЦ: /opt/cprocsp/bin/amd64/certmgr -inst -store root -f ca.cer Установить список отозванных сертификатов: /opt/cprocsp/bin/amd64/certmgr -inst -crl -f ca.crl Проверка прикрепленной подписи с токена (без сертификата) с учетом цепочки сертификатов и проверкой не отозван ли сертификат: /opt/cprocsp/bin/amd64/cryptcp -verify -f user.cer msg.txt.sgn Где user.cer — пользовательский сертификат, msg.txt.sgn — подпись полученная из rutoken plugin. При такой последовательности будет выполнена проверка подписи с учетом проверки сертификата на признак отозванного + проверка корневым сертификатом?

Михаил Селезнёв	#2 Оставлено : 1 октября 2020 г. 13:03:10(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 05.04.2017(UTC) Сообщений: 357 Сказал «Спасибо»: 3 раз Поблагодарили: 49 раз в 49 постах	Добрый день! Что Вы подразумеваете под «проверкой корневым сертификатом»?
1 пользователь поблагодарил Михаил Селезнёв за этот пост.	WildTuna оставлено 05.10.2020(UTC)

WildTuna	#3 Оставлено : 1 октября 2020 г. 15:20:55(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 30.09.2020(UTC) Сообщений: 12 Сказал(а) «Спасибо»: 7 раз	Добрый день. Проверка связи сертификатов (могу ошибаться в терминологии), что пользовательский сертификат действительно выпущен этим УЦ, в нем же, насколько я знаю, присутствует ссылка на корневой сертификат УЦ, который выпустил этот пользовательский сертификат.

Михаил Селезнёв	#4 Оставлено : 1 октября 2020 г. 15:36:58(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 05.04.2017(UTC) Сообщений: 357 Сказал «Спасибо»: 3 раз Поблагодарили: 49 раз в 49 постах	Понял, тогда да, Вы всё правильно описали в первом сообщении.
1 пользователь поблагодарил Михаил Селезнёв за этот пост.	WildTuna оставлено 05.10.2020(UTC)

WildTuna	#5 Оставлено : 1 октября 2020 г. 18:38:06(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 30.09.2020(UTC) Сообщений: 12 Сказал(а) «Спасибо»: 7 раз	Понял, спасибо за ответ. Михаил еще вопрос такой. Если в сертификате указаны ссылки для CRL в параметре CDP, возможно каким-то флагом утилите cryptcp указать не проверять CRL по ссылкам CDP, а только из собственного хранилища CRL (вопрос больше для отладки, в тестовой среде эти ссылки не рабочие, понятно, что в продуктовой среде обращение к ним будет)?

Михаил Селезнёв	#6 Оставлено : 2 октября 2020 г. 13:03:41(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 05.04.2017(UTC) Сообщений: 357 Сказал «Спасибо»: 3 раз Поблагодарили: 49 раз в 49 постах	Если crl установлен локально, то проверка осуществляется по нему.
1 пользователь поблагодарил Михаил Селезнёв за этот пост.	WildTuna оставлено 05.10.2020(UTC)

WildTuna	#7 Оставлено : 2 октября 2020 г. 14:50:20(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 30.09.2020(UTC) Сообщений: 12 Сказал(а) «Спасибо»: 7 раз	Установил список так /opt/cprocsp/bin/amd64/certmgr -inst -crl -f ca.crl Но при verify cryptcp подписает секунд на 60 (явно таймаут) и выдает сообщение (привел вставку ниже). Я так подозреваю, что он все-таки пытается достучаться до CRL списка по ссылкам из CDP в сертификатах УЦ и пользователя. Код: -bash-4.2$ /opt/cprocsp/bin/amd64/cryptcp -verify -f user3.cer link.txt.sgn CryptCP 4.0 (c) "Crypto-Pro", 2002-2017. Command prompt Utility for file signature and encryption. The following certificate will be used: RDN:street, given name, Андреев, pseudonym, test4@test4.com, Андреев Игорь Степанович, должность, IT, Aktiv, msk, Moscow, RU Valid from 02.10.2020 10:11:21 to 19.03.2021 12:33:33 Certificate chain is not checked for this certificate: RDN:street, given name, Андреев, pseudonym, test4@test4.com, Андреев Игорь Степанович, должность, IT, Aktiv, msk, Moscow, RU Valid from 02.10.2020 10:11:21 to 19.03.2021 12:33:33 The certificate revocation status or one of the certificates in the certificate chain is unknown. Do you want to use this certificate ([Y]es, [N]o, [C]ancel)?N Certificate chains are checked. Error: No certificate to use. /dailybuildsbranches/CSP_4_0/CSPbuild/CSP/samples/CPCrypt/Certs.cpp:340: 0x20000131 Отредактировано пользователем 2 октября 2020 г. 14:50:52(UTC)  | Причина: Не указана

Михаил Селезнёв	#8 Оставлено : 5 октября 2020 г. 11:33:44(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 05.04.2017(UTC) Сообщений: 357 Сказал «Спасибо»: 3 раз Поблагодарили: 49 раз в 49 постах	А вы crl только от личного сертификата устанавливаете? Проверяется вся цепочка, соответственно и crl нужно устанавливать от всех сертификатов в ней.
1 пользователь поблагодарил Михаил Селезнёв за этот пост.	WildTuna оставлено 05.10.2020(UTC)

WildTuna	#9 Оставлено : 5 октября 2020 г. 12:17:19(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 30.09.2020(UTC) Сообщений: 12 Сказал(а) «Спасибо»: 7 раз	Не очень понял про установку CRL от личного сертификата. Что значит установить CRL от всех сертификатов в цепочке? CRL разве не один файл со всеми отозванными сертификатами?

Михаил Селезнёв	#10 Оставлено : 5 октября 2020 г. 12:24:07(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 05.04.2017(UTC) Сообщений: 357 Сказал «Спасибо»: 3 раз Поблагодарили: 49 раз в 49 постах	Пришлите пожалуйста личный сертификат в директ.
1 пользователь поблагодарил Михаил Селезнёв за этот пост.	WildTuna оставлено 05.10.2020(UTC)

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Одним из важных аспектов безопасности сайта является процедура аннулирования SSL сертификатов и их внесения в списки CRL. Как известно, центры сертификации выписывают SSL сертификаты безопасности только после валидации доменного имени и в некоторых случаях после тщательной проверки компании, которой принадлежит этот домен. Благодаря данной процедуре сертификационный центр может обеспечить достоверность информации в SSL сертификате и соответственно гарантирует безопасность защищенного веб-сайта. Все же иногда случается, что безопасность сайта может оказаться под угрозой даже с действующим SSL сертификатом, например, если специальный ключ доступа был утерян или украден. В таких случаях он должен быть аннулирован (отозван). Аннулированные SSL сертификаты заносятся в специальные списки CRL.

Причины аннулирования SSL

Существует множество причин для внесения SSL сертификатов в списки CRL до истечения срока их действия. Вот некоторые из них:

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

К этому перечню можно отнести любые факторы, которые могут способствовать утечке информации во время ее передачи по защищенному каналу. Дабы этого избежать, необходимо запросить отзыв SSL сертификата.

Статус SSL сертификата

Статус SSL сертификата на предмет его аннулирования проверяется браузером перед каждым установлением безопасного соединения по протоколу https. Существует два типа статусов:

1. Аннулирован или же отозван. Процедура аннулирования безвозвратна. Если статус гласит «аннулирован», то чтобы снова защитить Ваш сайт необходимо заново купить SSL сертификат.
2. Временно недоступен. Если же владелец домена, например, не уверен, потерял ли он ключ, он может использовать второй статус — «временно недоступен» — до установления места нахождения секретного ключа. В таком случае, если он нашелся и не был доступен для третьих лиц, этот статус можно отозвать и SSL снова станет действительным.

CRL или списки САС

Как же пользователи веб-ресурса узнают, что SSL аннулирован и защита сайта нарушена? Как раз для этого существуют списки аннулированных сертификатов (в международном варианте — Certificate Revocation Lists, сокращенно CRL), которые содержат следующие данные:

• уникальные серийные номера всех отозванных SSL сертификатов
• название ответственного центра сертификации,
• дату аннулирования,
• актуальную дату,
• дату публикации нового списка CRL.

Каждый список CRL защищен цифровой подписью, которая обеспечивает целостность информации в них и не позволяет третьим лицам внести изменения. Списки CRL регулярно обновляются и публикуются, обеспечивая актуальную информацию о статусе каждого SSL сертификата. Таким образом, браузер пользователя всегда будет знать, можно ли доверять указанному сайту с https соединением и соответственно, разрешать или блокировать доступ к нему.

Публикация списков CRL

Списки CRL создаются и публикуются с определенной периодичностью. Тем не менее в некоторых случаях, CRL могут опубликовать сразу после проведения операции по отзыву. Аннулирование SSL сертификатов и их внесение в списки CRL производит выдавший их центр сертификации. Срок действия списка CRL может колебаться от 1 до 24 часов.

В каких случаях используются списки CRL?

Когда мы имеем дело с сертификатами, мы используем CRL. Например, когда браузер пытается установить https соединение с сайтом, он верифицирует сертификат сервера. В процессе верификации, браузер выбирает способ проверить, не отозван ли SSL сертификат. Если выбран способ проверки по списку отозванных сертификатов CRL, браузер загружает соответствующий файл CRL по адресу, указанному в SSL сертификате и производит его проверку. Если Центр сертификации указал, что данный SSL сертификат отозван, доступ пользователя к сайту будет закрыт. Альтернативным методом спискам CRL является протокол валидации сертификатов, известный под аббревиатурой OCSP (Online Certificate Status Protocol).

Where is CRL? Is it a file in my system that updated after OCSP requests or it is a list in the web server that I’m trying to connect to?

CRL is a list provided by the certificate issuer. The list contains the serial numbers and the reason for revocation of the revoked certificates and is signed by the issuer (or some other directly or indirectly trusted CA). The original CRL file is created and stored at the issuer. It gets provided usually via http/https but other mechanism exists. To know which URL provides the CRL for a specific certificate look at the ‘CRL Distribution Points’ property of the certificate. Note that lots of certificates issued by the same CA share the same CRL distribution point.

Where the local copy of the CRL is on your system, in which format it is stored there etc depends on the OS, browser, libraries… I doubt that it will be updated based on OCSP responses because OCSP and CRL are independent mechanism to check for revocation and a client usually only uses one of these to check for revocation of specific certificates. But it might use OCSP in some cases and CRL in other cases (where no OCSP is provided).

Who it updates?

It depends. Browsers usually don’t use CRL’s anymore but moved to OCSP, skip revocation checks completely or moved to some other mechanism like CRLSets. If any other application use CRL for the certificates — it probably depends on the application.

How OCSP server check revocation? (I mean how it update its database of revoked certificates?)

It does not check for revocation. Either the OCSP server is provided by the certificate issuer itself which already has the list of revoked certificates (since the issuer revoked these itself) or in case of OCSP stapling the web server gets the (signed) OCSP response from the issuer and includes it unchanged inside the TLS handshake.

In theory one could build some OCSP proxy which provides OCSP responses based on existing CRL files but since the OCSP responses are signed too this proxy must have a certificate which is explicitly trusted for signing OCSP responses.