Отозвали сертификат что делать

Обновлено: 13.05.2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Установка CRL

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

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

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

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

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

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

Когда отзывается ЭЦП

В Приказе Федерального казначейства № 261 от 14.09.2018 перечислено, по какой причине удостоверяющий центр отзывает сертификат:

По инициативе организации-заказчика. Причина — увольнение или лишение полномочий сотрудника или изменение персональных данных владельца. Ликвидация заказчика и последующее прекращение работы самого заказчика обязывает пользователя отозвать ЭЦП.
По инициативе территориального отделения Федерального казначейства. Специалисты ТОФК основываются на увольнении или снятии полномочий с владельца сертификата, смене регистрационных данных и прекращении функционирования заказчика. Причина — компрометация самого ключа электронной подписи.
При прекращении работы ТОФК.
При повреждении или поломке носителя ЭЦП.
При окончании срока действия.

Правила, как отозвать ЭЦП при увольнении сотрудника, закреплены в регламенте удостоверяющего центра (Приказ ФК № 261 от 14.09.2018). В некоторых случаях заказчик не отзывает, а аннулирует ключ:

если владелец не владеет ключом электронной подписи;
если ЭЦП уже содержится в другом сертификате;
если суд постановил прекратить действие из-за наличия недостоверных сведений на носителе.

Заказчик обязан уведомить представителей ТОФК о возникновении компрометирующих ситуаций, после чего ключ подписи аннулируют в течение 12 часов. Запись об аннулированных носителях вносится и в реестр, и в САС — список аннулированных подписей.

Как отозвать

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

Шаг 1. Написать заявление на сайте Казначейства.

Если по каким-либо техническим причинам организация-заказчик не имеет возможности отозвать сертификат через интернет, представители учреждения лично обращаются в удостоверяющий центр территориального отделения Федерального казначейства и подают заявление об изменении статуса ключа. Заявление составляется в строгом формате, утвержденном Приказом № 261 (Приложение № 3 к Регламенту). Обратиться в ТОФК вправе как сам владелец ключа, так и его представитель на основании доверенности.

Шаг 4. Заполняем пустые поля электронной заявки. Понадобится указать вид и причину изменения.

Шаг 5. Когда все ячейки заполнены, подписываем бланк и направляем его в удостоверяющий центр на рассмотрение.

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

Какие нужны документы

Чтобы Казначейством был отозван сертификат электронной подписи, понадобится всего лишь один документ — паспорт или иное удостоверение личности заявителя.

Отзыв подписи для отчетности ИФНС

В ч. 6-7, 9 ст. 14 63-ФЗ, Приказе ФНС № СА-7-6/364@ от 20.08.2015 сказано, можно ли отозвать электронную подпись для передачи финансовой и налоговой отчетности, и что понадобится для этого сделать. Пользователь вправе отзывать свою ЭЦП, процедура эта достаточно проста. Отзыв производится в программе передачи отчетности, то есть через СБИС.

Вот инструкция, как отозвать сертификат ЭЦП налоговой:

В нашей предыдущей статье были описаны основные механизмы проверки статуса сертификатов (проверки, является ли сертификат отозванным). В этой статье мы ответим на следующие вопросы:

1. Как механизмы проверки статуса сертификатов реализованы в современных Веб-браузерах?
2. ~~Кто виноват?~~ Почему они реализованы именно так?
3. ~~Что делать~~? Какие есть перспективы?

Эта статья будет полезна тем, кому интересно разобраться в применяющихся на практике механизмах проверки статуса сертификатов.

Проверки статуса сертификатов, реализованные в Веб-браузерах

Механизмы проверки статуса сертификатов, реализованные в современных Веб браузерах, представляют собой комбинацию описанных ранее базовых механизмов (CRL, OCSP, OCSP stapling) и их модификаций. Комбинирование базовых механизмов осуществляется с целью обеспечения резервирования: если один из источников информации о статусе сертификата становится недоступным, то используется резервный. Например, в качестве основного механизма проверки статуса сертификатов может использоваться протокол OCSP, однако в случае недоступности или отказа OCSP-сервера будет выполнена более трудоёмкая для клиента загрузка CRL.

Закрытый ключ сервера был скомпрометирован. Владелец сервера отозвал сертификат скомпрометированного ключа, сгенерировал новую пару ключей и получил новый сертификат.
Нарушитель завладел отозванным закрытым ключом и сертификатом сервера. В данном сценарии мы намеренно не говорим, каким образом он это осуществил: в результате компрометации самого сервера или в результате компрометации удостоверяющего центра (УЦ). Это сделано для того, чтобы продемонстрировать, как браузеры поведут себя в обеих ситуациях.

Ниже приводится описание проверок статуса сертификатов, выполняемых различными Веб-браузерами под Windows. Для других платформ детали проверок могут незначительно отличаться.

Mozilla Firefox

Поведение браузера Mozilla Firefox версии 54 (наиболее актуальной на момент написания статьи) при такой атаке отличается в зависимости от типа сертификата сервера: DV или EV. Выпуская DV-сертификат (domain validated), УЦ лишь подтверждает, что владелец ключа, указанного в сертификате, контролирует указанный в сертификате домен. Большинство сертификатов являются DV. EV-сертификат (extended validation) подтверждает не только владение доменом, но и личность владельца домена. Такие сертификаты требуют дополнительных проверок со стороны УЦ, потому они значительно дороже и встречаются реже.

Проверка статуса DV-сертификатов, выполняемая Firefox, описывается следующей диаграммой:

1. Агрегатор периодически опрашивает некоторый набор точек распространения CRL.
2. Из полученных CRL выбирает наиболее критичную информацию об отозванных сертификатах (например, сертификаты, отозванные из-за компрометации закрытого ключа).
3. Обновляет на основе этой информации в чёрные списки в браузерах.

В дополнение стоит отметить, что клиентская часть протокола OCSP, реализованная в Firefox, не поддерживает одноразовые случайные коды (nonce) и, следовательно, OCSP-ответы не защищены от атак повторного воспроизведения.

Аналогичная ситуация возникает и при проверке EV-сертификатов. Разница заключается лишь в том, что браузер дополнительно выполняет OCSP-запросы и для сертификатов промежуточных УЦ:

Следует отметить, что данная настройка не активирует использование протокола OCSP для сертификатов промежуточных УЦ в случаях, когда сервер предъявляет DV-сертификат.

Для конечного пользователя hard fail в Firefox выглядит так:

Microsoft Internet Explorer/Edge

Браузеры Microsoft Internet Explorer версии 11 и Microsoft Edge версии 40 ведут себя одинаково для DV- и EV-сертификатов:

Для Edge подобных настроек не нашли.

Google Chrome/Cromium

Браузеры Google Chrome и Chromium версии 59 при проверке DV-сертификатов ведут себя следующим образом:

OCSP-запросы используются при проверке EV-сертификатов (тут картина становится практически идентичной той, что мы наблюдали для Firefox):

Изменить поведение Chrome и Chromium возможно внесением изменений в групповую политику (инструкция здесь) и включением следующих опций:

Эквивалентная настройка возможна и под Linux (здесь).

Прочие браузеры и платформы

Для других популярных браузеров и платформ ситуация такая же: везде проверки статуса сертификатов выполняются в режиме soft fail, либо не выполняются вовсе. Подробнее можно почитать тут или тут.

Почему сейчас всё работает именно так?

Об этом хорошо написано в блоге Адама Лэнгли. Отсутствие hard fail и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:

Какие есть перспективы?

Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на hard fail нельзя по объективным причинам.

1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.
2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).

Параноидальная схема проверки статуса сертификатов для меньшинства

увеличение нагрузки на OCSP-серверы УЦ;
уязвимость к DDoS атакам на серверы УЦ.

Для того, чтобы оценить, насколько клиентская сторона (под Windows) готова к переходу в светлое будущее, можно взглянуть на следующую таблицу:

Схема для большинства

Итог

Что ж, пока что всё не очень хорошо: проверки статуса сертификатов в современных браузерах действительно не работают.

Однако свет в конце тоннеля всё же есть, и ситуация постепенно, хотя и медленно, движется к лучшему.

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

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

Чтобы воспользоваться квалифицированной электронно-цифровой подписью (далее — КЭЦП, КЭП, ЭЦП), криптопровайдер должен признать сертификат пользователя доверенным, то есть надежным. Это возможно, если правильно выстроена цепочка доверия сертификации, которая состоит из трех звеньев:

сертификат ключа проверки электронной подписи (далее — СЭП, СКПЭП, СКЭП);
промежуточный сертификат (ПС) удостоверяющего центра;
корневой сертификат (КС) от головного центра, то есть от Минкомсвязи.

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

При корректно настроенном пути сертификации состояние было бы таким:

Системное оповещение о сбое может возникать по ряду причин:

нарушена цепочка доверия (неверный путь сертификации), поврежден один из сертификатов или все три (шифрованное соединение между браузером клиента и сервером будет недоверенным или вовсе не будет работать);
неправильно установлен криптопровайдер КриптоПро;
неактивны алгоритмы шифрования СКЗИ;
заблокирован доступ к файлам из реестра;
старые версии браузеров;
на ПК установлены неактуальные дата и время и т. д.

Таким образом, ошибка может быть связана непосредственно с сертификатами, криптопровайдером или настройками ПК. Для каждого варианта придется пробовать разные способы решения.

Этот сертификат содержит недействительную цифровую подпись : цепочка доверия от Минкомсвязи до пользователя

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

Как строится путь доверия

Следующее звено — КС удостоверяющего центра (промежуточный). Файл выдается в комплекте с ключами и содержит в себе:

сведения об УЦ с указанием даты его действия;
сервисный интернет-адрес (через который можно связаться с реестром компании).

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

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

Головной КС Минкомсвязи действует до 2036 года, а ПС удостоверяющих центров ликвидны в течение 12 месяцев, после чего необходимо скачать (или получить в УЦ) новый и переустановить его на свой ПК. Сертификат КЭЦП тоже действует не более 1 года, по истечении этого срока клиенту требуется получить новый.

Как решить проблему

Файл выдается удостоверяющим центром вместе с другими средствами для формирования ЭЦП. Если он утерян или удален, следует обратиться в УЦ, в котором был получен СКПЭП.

Не все ветки могут быть в наличии. Удалите те, что есть, предварительно сохранив их резервные копии в отдельный файл. Перезагрузите ПК и проверьте статус СКЭП — он должен стать действительным.

Этот сертификат содержит недействительную цифровую подпись : устранение ошибки на примере казначейства

Самая распространенная причина недействительности сертификата заключается в нарушенных путях сертификации. Причем проблема может быть не только в файле Минкомсвязи, о котором было сказано ранее, но также в промежуточных и личных СКЭП. Рассмотрим эту причину на примере Управления Федерального казначейства (УФК), которое, среди прочего, тоже занимается выдачей КЭЦП.

Этот сертификат содержит недействительную цифровую подпись: изменение, повреждение файла УФК

Функции УЦ выполняются в территориальных органах Росказны по всей России. Для организации аукционов и размещения информации по закупкам для госнужд в интернете муниципальные и госзаказчики должны заверять отчеты ЭП, полученной в УФК.

Истечение срока

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

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

Этот сертификат содержит недействительную цифровую подпись: проблема с отображением в КриптоПро

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

Некорректная работа КриптоПро

Для переустановки нужно специальное ПО — утилита очистки следов КриптоПро, которую можно скачать на сайте разработчика . Она предназначена для аварийного удаления криптопровайдера. Такой способ позволяет полностью очистить ПК от следов CryptoPro и выполнить корректную переустановку.

Службы инициализации

СЭП может отражаться как недействительный, если не запущена служба инициализации КриптоПро CSP. Это можно проверить следующим образом:

Если все выполнено верно, после перезагрузки компьютера КЭЦП снова будет работать корректно.

Права доступа к реестру

Сбой возможен при отсутствии прав на некоторые файлы в реестре Windows. Для проверки необходимо открыть строку ввода комбинацией Win+R, ввести команду regedit, нажать Enter и перейти по пути для настройки прав в реестре Windows:

У пользователя должны быть права на конечные папки этих веток. Проверить это можно следующим образом:

Эта же проблема решается переустановкой криптопровайдера с помощью описанной выше утилиты для очистки следов.

Сертификат содержит недействительную цифровую подпись : что делать , если сбой связан с браузером

Если пользователь настроил путь доверия и устранил неполадки криптопровайдера, но проблема не решилась, есть вероятность, что она кроется в браузере. В первую очередь это касается подписания документов непосредственно на сайтах государственных систем и контролирующих органов (ЕГАИС, ПФР, ФНС и др.).

Разработчик CryptoPro рекомендует использовать для работы с КЭП только Internet Explorer, так как он встроен в Windows. Но и с этим веб-обозревателем случаются сбои.

Обычно после входа под правами администратора все становится на свои места, и ключи работают в привычном режиме. Что предпринять:

Если ошибка устранена, рекомендуется:

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

Если используется старая версия веб-обозревателя, рекомендуется обновить ее до последнего релиза.

Отключение антивирусной программы

Читайте также: