No Image

Список отзыва сертификатов crl

СОДЕРЖАНИЕ
531 просмотров
10 марта 2020

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

Содержание

История [ править | править код ]

История создания PKI (Инфраструктура открытых ключей) восходит к оригинальной работе Уитфилда Диффи и Мартина Хеллмана по криптографии с открытым ключом, в которой предлагается каталог открытых файлов, который пользователи могли бы использовать, чтобы найти открытые ключи других пользователей.

Понимая некоторые недостатки этого подхода, в том числе то, что отключение доступа к каталогу не позволит пользователям безопасно общаться, Лорен Конфельдер [en] предложил концепцию сертификатов в 1978 году. Сертификаты разделяют функции подписи и поиска, позволяя центру сертификации связывать имя с ключом с помощью цифровой подписи, а затем хранить полученный сертификат в репозитории. Поскольку хранилище можно реплицировать и сделать отказоустойчивым, подход CA устраняет многие проблемы, связанные с надёжностью каталогов.

Спустя несколько лет после того, как Конфельдер опубликовал свою диссертацию, разработчики включили использование сертификата в X.500, глобальный каталог названных объектов, управляемых монопольными телекоммуникационными компаниями. В каталоге X.500 предлагается иерархическая модель базы данных, причём путь через каталог определяется рядом компонентов относительного отличительного имени (RDN), которые вместе образуют отличительное имя (DN). Чтобы защитить доступ к каталогу, его разработчики предложили различные механизмы контроля доступа, начиная от простых основанных на пароле мер и заканчивая относительно новым подходом к использованию цифровых подписей. Этим стандартом, включённым в X.500, был стандарт X.509v1. На данный момент существует версия x.509v3.

Разработчики основывали концепцию СОС на чёрных списках кредитных карт, которые использовались в 1970-х годах. Компании, выпускающие кредитные карты, периодически печатали буклеты с номерами аннулированных карт и распространяли их среди продавцов, ожидая, что они проверят все карты, с которыми взаимодействуют, в чёрном списке, прежде чем их принять. Те же проблемы, которые затрагивали чёрные списки кредитных карт, сегодня влияют на СОС.

Принцип работы [ править | править код ]

Удостоверяющий центр периодически выдаёт список, который он публикует в хранилище. Каждый СОС включает поле nextUpdate, которое указывает время, когда будет выпущен следующий СОС. Любая проверяющая сторона, которой требуется информация о статусе сертификата и у которой ещё нет текущего СОС, получает текущий список из хранилища. Если сертификат, который проверяет клиент, не находится в списке, то работа продолжается в нормальном режиме и ключ считается подтверждённым сертификатом. Если же сертификат присутствует, то ключ считается недействительным и ему нельзя доверять.

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

Существует также механизм дельта-СОС, который является необязательным механизмом, указанным в RFC 2459, который может использоваться для улучшения распространения информации об аннулировании. Списки дельта-СОС являются сравнительно небольшими по объёму, содержащими только те изменения в перечнях аннулированных сертификатов, которые имели место с момента формирования центром CA последней версии абсолютного списка (complete CRL). Поскольку списки дельта-СОС невелики, клиенты PKI могут загружать их чаще, чем списки complete CRL, соответственно, при этом центр УЦ обеспечивает своих клиентов более точной информацией об аннулированных сертификатах.

Недостатки [ править | править код ]

Некоторые проблемы затрудняют работу с СОС. СОС в некоторых случаях оказывается ненадежным в качестве механизма распространения статуса сертификата. Критические приложения требуют немедленного отзыва — или, точнее, информации о статусе сертификата в реальном времени — и списки отзыва сертификатов не всегда решают эту основную проблему по нескольким причинам.

Читайте также:  Фильтры в сводной таблице в excel

Основные проблемы СОС:

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

СОС страдают от нескольких других практических проблем. Чтобы гарантировать своевременное обновление статуса, сервер должен выдавать СОС как можно чаще. Тем не менее, выдача СОС увеличивает нагрузку на сервер и сеть, которая его передает, и, в меньшей степени, на клиента, который его получает. Например 10 млн клиентов загружают 1 МБ СОС, выдаваемых раз в минуту, = трафик

150 ГБ/с. Следовательно это дорогая операция. Выдача СОС раз в минуту обеспечивает умеренно своевременный отзыв за счет огромных накладных расходов, поскольку каждая проверяющая сторона загружает новый СОС (во многих случаях эта задача ложится на Дельта-СОС и проблема решается). С другой стороны, задержка выдачи до одного раза в час или день не обеспечивает своевременного отзыва при условии, что в этот период некоторые сертификаты были отозваны.

В списках отзыва сертификатов также отсутствуют механизмы взимания с проверяющих сторон платы за проверку отзыва. Когда центр сертификации выдаёт сертификат, он взимает с пользователя плату. Сумма, которую взимает ЦС, обычно зависит от того, сколько он проверяет перед выдачей сертификата. С другой стороны, пользователи ожидают, что УЦ будут создавать и выдавать СОС бесплатно. Ни пользователь, ни центр сертификации не могут однозначно сказать, кто будет проверять сертификат, как часто он будет проверяться или какая задержка будет приемлемой. Эта ситуация служит активным сдерживающим фактором для УЦ, чтобы уделять большое внимание СОС, поскольку для их создания и распределения требуется время обработки, один или несколько серверов и значительная пропускная способность сети.

Аналоги [ править | править код ]

На данный момент существует несколько аналогов СОС, которые не имеют недостатков СОС, но при этом имеют собственные.

Одним из аналогов является OCSP — Online Certificate Status Protocol. Данное решение проблемы предоставляет ответ сервера о данном конкретном запрашиваемом сертификате в режиме реального времени. Этот подход решает многие проблемы, присущие СОС, создавая одноразовый, свежий СОС с одиночной записью в ответ на запрос. В отличие от этого модель на основе СОС требует, чтобы проверяющие стороны неоднократно получали огромное количество не относящихся к делу записей, чтобы получить информацию о состоянии для одного сертификата, который им нужен. Однако OCSP имеет свою стоимость. Вместо подготовки СОС в качестве фоновой автономной операции УЦ теперь должен выполнять поиск сертификата и операцию создания псевдо-СОС для каждого запроса. Чтобы сделать OCSP экономически целесообразным, УЦ должен взимать плату за каждую проверку отзыва. OCSP решает эту проблему, подписывая запросы на идентификацию отправителя для выставления счетов.

Данный метод также имеет свои недостатки. Основной недостаток OCSP заключается в том, что вместо простого ответа «да» или «нет» на запрос о достоверности он использует несколько неортогональных значений состояния сертификата, поскольку не может дать действительно точный ответ. Эта неопределённость проистекает, по крайней мере, частично из исходного механизма статуса сертификата на основе СОС. Поскольку СОС может предоставить только отрицательный результат, тот факт, что сертификат не присутствует в СОС, не означает, что он когда-либо был выпущен или все ещё действителен.

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

Также OCSP раскрывает историю подключений клиента третьей стороне (УЦ).

Обновление OCSP — это OCSP stapling [en] . Он избавляет от необходимости повторно отправлять запрос OCSP, выдавая ответ OCSP вместе с самим сертификатом. Это называется OCSP Stapling, потому что сервер должен «скрепить» (staple) ответ OCSP с сертификатом и выдать их вместе. При установке соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами. Ответ OCSP действует только короткий промежуток времени и подписан УЦ точно так же, как сертификат. Это также устраняет проблему конфиденциальности OCSP, поскольку респондент не имеет доступа к сведениям о посетителях веб-сайта. К сожалению, это широко не реализовано, только 3 % серверов поддерживают OCSP Stapling.

Читайте также:  Python работа с sql

Использование [ править | править код ]

Одним из возможных применений инфраструктуры открытых ключей является HTTPS. Многие браузеры используют 2 основных подхода: СОС и OCSP. Mozilla Firefox не загружает СОС автоматически. Браузер использует OCSP для проверки того, был ли сертификат отозван. Internet Explorer, и Opera делают гораздо более тщательную работу; они оба поддерживают OCSP и CRL и выполняют подходящие проверки для всех типов сертификатов. Но СОС применяется, в основном, как запасной вариант в данной проверке.

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

Алгоритм проверки заключается в следующем:

  • Получатель принимает сообщение, электронную подпись и ссылку на сертификат, которая в большинстве своём является частью электронной подписи.
  • С помощью открытого ключа субъекта получатель расшифровывает электронную подпись, а также сам вычисляет контрольную сумму сообщения. Получатель сравнивает контрольные суммы.
  • Далее получатель находит сертификат автора электронной подписи, по цепочке сертификатов (далее, переходим к издателю сертификата и его сертификату) происходит спуск вниз, до УЦ, которому доверяет получатель ЭП.
  • Происходит проверка всех сертификатов в цепочке в СОС. Если хеши совпадают и все сертификаты в цепочке действительны, происходит подтверждение целостности и авторства документа.

Опубликовано:
22 мая 2012 в 15:33

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:  Что такое ram в компьютере в процентах

Итак, что же нам прежде всего необходимо сделать, чтобы мы могли полноценно использовать 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, а также необходимых команд, вы можете найти на следующем ресурсе:

Автоматическая установка сертификатов производится с помощью программы CertsUniv.exe.
Сохраните на компьютер CertsUniv.exe по следующей ссылке и запустите его. Программа автоматически установит сертификаты.

Загрузить актуальный список отозванных сертификатов Головного УЦ ФГУП "ЦентрИнформ" файл CenterInform.crl

В окне Сохранить как в указанном Вами месте, например на Рабочем столе, сохраните файл CenterInformMskf.crl

Наведите курсор на ранее сохраненный файл и в контекстном меню (по нажатии правой кнопки мыши) выберите пункт Установить список отзыва (CRL).

Для завершения установки нажмите кнопки ДалееДалееГотово.

При появлении окна Мастер импорта сертификатов нажать Да.

Комментировать
531 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock
detector