Ошибка чтения файла сертификата запроса на сертификат или crl
Типовые ошибки при попытке создания запроса на сертификат в веб-интерфейсе сервиса подписи.
1. На сервисе подписи нет доступных провайдеров
Возможные причины возникновения ошибки:
На сервисе подписи нет провайдеров в статусе "Enabled", которые могут использоваться для создания новых ключей.
2. Message: invalid_license MessageDetail: Превышено количество пользователей, разрешенных лицензией
Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> SignServer-> Admins».
Пример:
CertificateRequestValidator Message: CertificateRequestValidator. Ошибка: invalid_license;
Описание: Превышено количество пользователей, разрешённых лицензией.;
Возможные причины возникновения ошибки:
Превышен лимит пользователей, для которых разрешено создавать запросы на сертификат, в соответствие с условиями введенных на сервис подписи лицензий.
Рекомендуемое решение:
- Выполнить командлет: Get-DssLicense -AssignedUsersInfo
- Если число пользователей, указанных в параметре "AssignedUsersNumber", равно или превышает число пользователей в параметре "TotalUsersNumberLimit" - ввести дополнительную лицензию на сервис подписи, в соответствие с руководством.
3. Message: An error has occured
Диагностика:
Ошибки в «Журналы приложений и служб -> CryptoPro-> DSS-> SignServer-> Admins».
Возможные причины возникновения ошибки:
- На сервере DSS не запущена служба "Крипто Про HSM 2.0";
- УЗ пула приложений сервиса подписи не добавлена в группу "Привилегированные пользователи КриптоПро HSM";
- Истек срок действия закрытого ключа сертификата доступа к сервисному провайдеру КриптоПро HSM.
Рекомендуемое решение:
- Запустить службу "Крипто Про HSM 2.0";
- Убедиться, что на сервере DSS создана группа пользователей "Привилегированные пользователи КриптоПро HSM" и что в данную группу добавлена УЗ пула приложений сервиса подписи;
- Протестировать срок действия закрытого ключа сертификата доступа к сервисному провайдеру КриптоПро HSM средствами КриптоПро CSP. Если срок действия закрытого ключа истек - перевыпустить сертификат доступа к сервисному провайдеру КриптоПро HSM, перенести его на сервер КриптоПро DSS и перезапустить службу "Крипто Про HSM 2.0".
4. Сервис подписи не настроен на взаимодействие ни с одним УЦ или нет ни одного обработчика УЦ, доступного через веб-интерфейс
Диагностика:
Ошибки в «Журналы приложений и служб -> CryptoPro-> DSS-> SignServer-> Admins».
А) Идентификатор УЦ: 1 Произошла ошибка при создании экземпляра обработчика УЦ: Exception occured while creating enroll with ID 1, Name Тестовый УЦ
System.ServiceModel.Security.SecurityNegotiationException: Не удалось установить безопасный канал для SSL/TLS с полномочиями "testuc".
В) Идентификатор УЦ: 1 Произошла ошибка при создании экземпляра обработчика УЦ: Exception occured while creating enroll with ID 1, Name Тестовый УЦ
System.InvalidOperationException: Сертификат оператора не найден в хранилище Локального компьютера либо недействителен. Отпечаток 56F8AA130B25C82173951E6F7C8C4E9B535904DB
Возможные причины возникновения ошибки:
- Не выполнена настройка для обеспечения взаимодействия DSS с УЦ;
- УЗ пула приложений сервиса подписи не выданы права на доступ к закрытому ключу сертификата привилегированного пользователя ЦР, указанного в настройках обработчика УЦ (OperatorCertThumbprint);
- Возникли проблемы на стороне самого УЦ (например, остановилась служба ЦР);
- В настройках обработчика УЦ указано некорректное имя ЦС (AuthorityName);
- В настройках обработчика УЦ указан отпечаток сертификата привилегированного пользователя ЦР, который не был установлен в хранилище "Личные" локального компьютера сервера DSS, с привязкой к закрытому ключу (OperatorCertThumbprint);
- В настройках обработчика УЦ указан некорректный адрес ЦР (CAServiceUrl);
- В настройках обработчика УЦ указан некорректный идентификатор папки ЦР (FolderId).
Рекомендуемое решение:
- Выполнить настройку обеспечения взаимодействия DSS c УЦ, в соответствие с руководством;
- Установить сертификат привилегированного пользователя ЦР, указанный в настройках обработчика УЦ (OperatorCertThumbprint), в хранилище "Личные" локального компьютера сервера DSS, с привязкой к закрытому ключу;
- Выдать УЗ пула приложений сервиса подписи права на доступ к закрытому ключу сертификата привилегированного пользователя ЦР, указанного в настройках обработчика УЦ (OperatorCertThumbprint);
- Указать в настройках обработчика УЦ корректные credentials-ы для подключения - сертификат привилегированного пользователя ЦР (OperatorCertThumbprint), адрес ЦР (CAServiceUrl), имя ЦС (AuthorityName), идентификатор папки ЦР (FolderId). Полный список параметров и их описание представлены в руководстве;
- Убедиться в том, что компоненты ЦР и ЦС функционируют в штатном режиме.
Сегодня особенный привет работникам бюджетной сферы. Поговорим о наболевшем. О работе в системе ГИС «Электронный бюджет». Который просто кишит ошибками.
Вот эта ошибка: «crl сертификата сервера не загружен или устарел» , по запросу на которую вы сюда и пришли, она тянется с августа 2020г. Тогда в электронном бюджете произошли большие изменения, и вместе с ними, например, «приклеились» и всякие ошибки, которые до сих пор не могут быть устранены в автоматическом режиме в «полюбившемся» вам континент tls 2.0. Уж извините за сарказм.
Однако, вернёмся к нашим баранам… Такая у вас сейчас ошибка?
ЭБ: crl сертификата сервера не загружен или устарел
СПИСОК ТЕРМИНОВ И СОКРАЩЕНИЙ
В документе используются следующие термины и сокращения:
Если вы видите такую ошибку в своём TLS — клиенте, значит нужно установить «список отзыва» вручную
Проблема в том, что ещё 2 года назад программисты УФК говорили, что обычные пользователи не должны выискивать вручную в интернете «рецепты», и всё должно делаться автоматически в Континент TLS 2.0 «по кнопке»:
рис. 2 . Континент TLS 2.0
На этом скрине по задумке авторов — создателей ПО Континент TLS 2.0, мы, пользователи системы «Электронный бюджет», должны при возникновении подобных проблем лишь нажимать кнопку «обновить». Но .. реальность как всегда несколько иная… чем ожидания.
Продолжение следует… А пока — отличная новость!
В этой статье мы рассмотрели три основных механизма проверки статуса сертификатов. Проверки, осуществляемые на практике, являются надстройками над этими механизмами или их комбинацией. Тема дальнейшего обсуждения и следующей статьи — каким образом проверки статуса сертификатов реализованы в Веб-браузерах?
Про проблему отозванных сертификатов и «Кошмар скомпрометированных ключей» мы говорили на «очной ставке» NeoQUEST-2016. У нас даже есть отличное видео, в котором автор статьи рассказывает про отозванные сертификаты:
Пока у нас активно ведется подготовка к очередной «очной ставке» NeoQUEST-2017, которая пройдет в Питере 29 июня (и на которую мы ждём ВСЕХ желающих!), рассказываем интересную новость:
Мы объявляем конкурс докладов на «очную ставку» NeoQUEST-2017!
Удостоверяющий центр, в чьи функции входит поддержание жизненного цикла сертификатов открытых ключей проверки электронной подписи, шифрования, аутентификации и защиты каналов передачи данных, их выпуск, распределение, депонирование, резервное копирование, восстановление, отзыв и ведение списка отозванных сертификатов, является важнейшим участником и арбитром инфраструктуры открытых ключей.
УЦ должен работать, как часы. От его правильного функционирования зависит электронный документооборот множества клиентов и систем.
Некорректная работа или сбой удостоверяющего центра может привести к санкциям регуляторов, искам недовольных клиентов для самого УЦ и значительным финансовым и репутационным потерям всех участников электронного обмена.
Для удостоверяющих центров, аккредитованных в Министерстве цифрового развития, связи и массовых коммуникаций, выпускающих квалифицированные сертификаты и обеспечивающих безусловно юридически значимый электронный документооборот, такой вопрос стоит еще более остро.
В этом посте я хочу рассказать, с какими критическими проблемами и нарушениями в работе УЦ часто приходится сталкиваться, а также о том, как их избежать.
У полноправного участника Public Key Infrastructure, должна быть информационная система со встроенными СКЗИ, которая позволяет вести электронный документооборот с клиентами и партнерами, обмениваясь с ними документами с электронной подписью (ЭП) или зашифрованными данными.
Когда партнер присылает документы с ЭП, система выполняет ряд действий. Она проверяет электронную подпись на документе и партнерский сертификат открытого ключа проверки этой подписи.
В частности, для сертификата партнера строится путь сертификации - цепочка сертификатов, от его конечного пользовательского, на котором проверилась ЭП, до корневого центра сертификации.
В случае с квалифицированными сертификатами корневым будет сертификат Министерства цифрового развития, связи и массовых коммуникаций, а промежуточным между корневым и конечным пользовательским – сертификат аккредитованного УЦ, выданный головным УЦ Министерства цифрового развития.
Для квалифицированных сертификатов также выполняются проверки согласно 63-ФЗ «Об электронной подписи» и Приказа ФСБ РФ №795. Контролируется наличие и правильность заполнения всех необходимых атрибутов в сертификате пользователя.
Одна из главных задач контроля и ключевых фишек PKI в автоматическом электронном обмене документами – это необходимость и возможность убедиться, что сертификат не был отозван партнером и УЦ подтверждает, что сертификат действующий.
ОПИСАНИЕ ОПЕРАЦИЙ
Кратко о протоколе TLS и инфраструктуре открытых ключей X.509
Современный защищённый Веб стоит на двух китах: протоколе TLS и инфраструктуре открытых ключей X.509. Для установки защищённого TLS-соединения сервер должен передать клиенту свой открытый ключ. Аутентичность ключа сервера, пересылаемого через незащищённые публичные сети, обеспечивается цепочкой сертификатов открытых ключей инфраструктуры X.509.
Удостоверяющий центр (УЦ, certification authority, CA) может отозвать подписанный (изданный) им ранее сертификат, например, в случае компрометации закрытого ключа, соответствующего этому сертификату. Поэтому, чтобы исключить возможность подключения к «человеку посередине», при установке TLS-соединения клиент должен не только проверять корректность подписей всей предоставленной сервером цепочки сертификатов, но и проверять статус предоставленных ему сертификатов (сертификат действителен или отозван).
Чем должны руководствоваться УЦ при публикации CRL
Спецификацией RFC 5280 IETF и стандартом X.509 ITU-T, разработанными Инженерным советом Интернета и Международным консультационным комитетом по телефонии и телеграфии.
В частности, пунктом 8. Security Considerations из RFC 5280
Если УЦ все же включают такие ссылки, то они должны убедиться, что серверные сертификаты могут быть проверены без использования этих ссылок.
Следует упомянуть, что существует иной способ проверки сертификата на отзыв.
Протокол онлайн-проверки статуса сертификата OCSP - Online Certificate Status Protocol.
Такие сертификаты также включают в себя стандартный атрибут CDP и могут проверяться обычным способом.
А для работы с сервером OCSP они должны включать еще и расширение OCSP Server Client.
Но это материал для отдельной статьи.
OCSP stapling
Для решения этих проблем было предложено расширение протокола TLS, позволяющее прикреплять OCSP-ответы к сертификатам (OCSP stapling) и переносящее ответственность за выполнение OCSP на TLS-сервер.
На рисунке изображена схема использования OCSP stapling:
Схема описывает следующие шаги:
- TLS-сервер, выступая в роли OCSP-клиента, собирает информацию о статусе своей цепочки сертификатов, обращаясь к OCSP-серверам соответствующих УЦ;
- TLS-сервер кэширует полученные OCSP-ответы;
- При установке TLS-соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами.
- время установки TLS-соединения не увеличивается, поскольку в момент установки соединения OCSP не выполняется ни клиентом, ни сервером;
- снижается нагрузка на OCSP-серверы УЦ;
- клиент не раскрывает УЦ используемые им сетевые ресурсы.
Такой вариант использования OCSP stapling не позволяет кэшировать OCSP-ответы на сервере, из-за чего растёт время установки TLS-соединения и увеличивается нагрузка на серверы УЦ.
Следует отметить, что существует две версии OCSP stapling. Первая версия по неясной причине позволяет прикреплять OCSP-ответ только для сертификата самого сервера. При использовании этой версии ответственность за получение информации о статусе остальных сертификатов цепочки лежит на клиенте. Этот недостаток исправлен в новой версии.
Механизм CRL
УЦ публикуют CRL, в которые вносятся серийные номера отозванных сертификатов, в точках распространения CRL (CRL distribution point, CDP). Адреса (URL) точек распространения CRL, к которым следует обращаться для получения информации о статусе проверяемого сертификата, как правило, указываются в самом сертификате.
На рисунке приведено схематическое изображение загруженного CRL.
В нём сообщается, что УЦ «Example Certification Authority» были отозваны три сертификата c серийными номерами 00:C9:79:0E, 46:35:AC:5F и 50:4E:6F:C7. Проверяемый сертификат является отозванным, поскольку его серийный номер находится в этом списке.
Клиенты получают свежие CRL одним из следующих способов:
- (условно в «пассивном» или оффлайн режиме) с помощью периодических обновлений. CRL в базе клиента могут обновляться автоматически, например, при обновлении клиентского ПО или в ручную администратором;
- (в «активном» или онлайн режиме) самостоятельно подгружая их по мере необходимости из CDP.
- CRL избыточны и плохо подходят для частых повторяющихся загрузок. Иногда их размеры приближаются к 1 МБ;
- CRL не защищены от атак повторного воспроизведения и позволяют «человеку посередине» подсовывать жертве неактуальные CRL, ещё не содержащие информацию о скомпрометированных ключах.
Как установить CRL список отзыва ВРУЧНУЮ
Да, кстати, если при попытке войти в электронный бюджет ПОСЛЕ выбора сертификата пользователя вылезает ошибка вида: « Необходимо обновить CRL серверного сертификата», то рецепт избавления тот же. Читаем внимательно текст НИЖЕ:
1. Перед тем как устанавливать список отзыва, необходимо вручную скачать и установить новый серверный сертификат для сервера «Континент TLS VPN» Инструкция с официального сайта Федерального казначейства . На рис.2 стрелочками указано как это сделать.
2. Теперь переходим к процедуре установки «списка отзыва»
По ней надо пройти, и вы увидите заголовок:
Сертификаты и Списки аннулированных сертификатов Удостоверяющего центра Федерального казначейства:
Сертификаты и Списки аннулированных сертификатов Удостоверяющего центра Федерального казначейства
Список этот будет меняться с течением времени. Но ссылка работает пока. Это файлы с расширением .CRL на текущий момент их 6. Но не суть важно. Главное понять как их устанавливать. Итак, скачиваем все .CRL — файлы с этой страницы в какую-либо папку:
Установка списка отзыва вручную
И правой мышкой, по очереди на каждом файле, нажимаем и выбираем в меню «Установить список отзыва CRL». Следуйте несложным инструкциям после этого (грубо говоря жмём на все вопросы «ОК», «далее» и т.п.)
После этого в TLS — клиенте на закладке «СЕРВЕРНЫЕ СЕРТИФИКАТЫ» вместо зловещего «требуется обновление» или «не найден» , «не действителен» изменится тут же на «Действителен», и можно работать. Вот такой вот он… Электронный бюджет… Желаю всем, чтобы это шаманство и вам помогло, ибо мне оно помогло..)
crl не прошел проверку — такую ошибку стало выдавать у моих специалистов при входе в Электронный Бюджет.
Лечится довольно просто, перезапуском службы Континент ТЛСа.
Перезапускаем службу, перезаходим в ЭБ, выбираем нужный сертификат для входа и работаем дальше.
Для тех кто не хочет делать это в ручную или незнает как перезапустить службу — в этой статье есть сам батник (который можно скачать), а так же его содержимое.
Государственная интегрированная информационная система управления
общественными финансами «Электронный бюджет»
Подсистема обеспечения информационной безопасности подсистем
Инструкция по обновлению сертификата сервера TLS на автоматизированном рабочем месте пользователя системы «Электронный бюджет»
Содержание
Обязательные атрибуты квалифицированных сертификатов
Состав квалифицированного сертификата регулируется Федеральным законом "Об электронной подписи" от 06.04.2011 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2011 г. N 795 "Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи".
Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject - субъект сертификации отсутствовал атрибут L – Местоположение.
Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.
Удостоверяющий центр данную ситуацию комментировал так:
На конкретный пункты Закона и Приказа в УЦ не ссылались.
Собственный повторный анализ юридических аспектов показал:
63-ФЗ от 06.04.2011 "Об электронной подписи"
Статья 14. Сертификат ключа проверки электронной подписи
2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:
2) фамилия, имя и отчество (если имеется) - для физических лиц, наименование и место нахождения - для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;
Статья 17. Квалифицированный сертификат
2. Квалифицированный сертификат должен содержать следующую информацию:
2) фамилия, имя, отчество (если имеется) владельца квалифицированного сертификата - для физического лица, не являющегося индивидуальным предпринимателем, либо фамилия, имя, отчество (если имеется) и основной государственный регистрационный номер индивидуального предпринимателя - владельца квалифицированного сертификата - для физического лица, являющегося индивидуальным предпринимателем, либо наименование, место нахождения и основной государственный регистрационный номер владельца квалифицированного сертификата - для российского юридического лица, либо наименование, место нахождения владельца квалифицированного сертификата, а также идентификационный номер налогоплательщика (при наличии) - для иностранной организации (в том числе филиалов, представительств и иных обособленных подразделений иностранной организации);
Приказ ФСБ РФ от 27 декабря 2011 г. № 795
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 (наименование населенного пункта).
locality - Местонахождение
В Законе 63-ФЗ и Приказе №795 нет информации, что для города Москва не нужно заполнять атрибут locality - Местонахождение.
Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)
Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя ‑ юридического лица.
Таким образом, в случае отсутствия в выписке из единого государственного реестра юридических лиц информации о наименовании населенного пункта, но при наличии информации о наименовании муниципального образования, аккредитованному удостоверяющему центру для заполнения квалифицированного сертификата вместо наименования соответствующего населенного пункта следует использовать наименование соответствующего муниципального образования.
На основании изложенного в качестве значения атрибута имени «localityName» поля «subject» в структуре квалифицированного сертификата следует указывать текстовую строку, содержащую наименование соответствующего населенного пункта или соответствующего муниципального образования.
Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.
Замена сертификата сервера TLS в ПО «Континент TLS Клиент»
Внимание: Настройки внешнего прокси-сервера могут отличаться от настроек, приведенных в настоящей инструкции. Настройки внешнего прокси-сервера не изменяются в рамках работ по замене сертификата сервера TLS, и должны соответствовать настройкам, используемым в организации пользователя.
-
Для замены сертификата сервера TLS в ПО «Континент TLS Клиент» на АРМ пользователя необходимо:
- Выполнить запуск диалога «Континент TLS Клиент: настройка сервиса». Для этого в меню «Пуск» ввести «Континент TLS клиент» и щелкнуть по найденному элементу.
- В разделе «Настройки защищаемого сервера» в поле «Сертификат» указать файл сертификата сервера TLS, скопированный в локальную директорию в п.4 раздела 2.1 настоящего Руководства.
Решение проблемы CRL не прошел проверку в Электронном бюджете состоит в том, что не установлены новые корневые сертификаты.
Устанавливаем скаченные корневые сертификаты в Доверенные корневые центры сертификации.
Что делать, если у вашего сервера утёк закрытый ключ? Вопрос, ставший особенно актуальным после Heartbleed.
Последовательность действий, сразу приходящая в голову:
1. Связаться с удостоверяющим центром.
2. Отозвать сертификат сервера.
3. Перегенерировать ключи.
4. Запросить для сервера новый сертификат.
5. Поднять бокал за успех операции и попытаться жить дальше.
К сожалению, всё не так просто. В этой и следующей статьях мы подробно ответим на следующие вопросы:
- Какие механизмы проверки статуса сертификатов бывают?
- Как они реализованы в современных Веб-браузерах?
Кто виноват?Почему они реализованы именно так?Что делать?Какие есть перспективы?
UPD: добавили вторую часть статьи! Прочитать можно тут.
Механизм OCSP
OCSP, как следует из его названия, предназначен для получения наиболее актуальной информации о статусе сертификата в режиме онлайн и не обладает приведёнными выше недостатками CRL.
В запросе указывается серийный номер проверяемого сертификата (46:35:AC:5F). Также в запросе опционально может быть передан случайный одноразовый код (nonce), предназначенный для защиты ответа OCSP-сервера от атаки повторного воспроизведения. В ответе OCSP-сервера сообщается, что сертификат с серийным номером 46:35:AC:5F был отозван, поскольку соответствующий ему закрытый ключ был скомпрометирован. OCSP-ответ защищён от подделывания и атаки повторного воспроизведения, поскольку подписан доверенным ключом OCSP-сервера и содержит полученный от клиента случайный одноразовый код.
Следует отметить, что защита от атаки повторного воспроизведения в OCSP является опциональной и её отсутствие имеет свои преимущества. Отключение проверки значения случайного одноразового кода на клиенте позволяет кэшировать OCSP-ответы на стороне сервера, снижая накладные расходы на функционирование протокола.
Проблемами OCSP являются:
- увеличение времени установки TLS-соединения;
- раскрытие истории подключений клиента третьей стороне (УЦ).
Если вы видите такую ошибку в своём TLS — клиенте, значит нужно установить «список отзыва» вручную
Проблема в том, что ещё 2 года назад программисты УФК говорили, что обычные пользователи не должны выискивать вручную в интернете «рецепты», и всё должно делаться автоматически в Континент TLS 2.0 «по кнопке»:
рис. 2 . Континент TLS 2.0
На этом скрине по задумке авторов — создателей ПО Континент TLS 2.0, мы, пользователи системы «Электронный бюджет», должны при возникновении подобных проблем лишь нажимать кнопку «обновить». Но .. реальность как всегда несколько иная… чем ожидания.
Сбои и некорректная работа УЦ в части публикации CRL
В сертификатах есть атрибут CDP - CRL Distribution Points, в нем УЦ публикует ссылки на свой список отозванных сертификатов - Certificate Revocation List
Сам по себе сертификат тоже является электронным документом с электронной подписью, которую ставит УЦ при его выпуске. Таким образом все атрибуты внутри сертификата, в том числе открытый ключ и ссылки на списки отзыва, заверены удостоверяющим центром и защищены от подмены.
CRL тоже подписан ЭП удостоверяющего центра, что дает дополнительную защиту от подмены и атак посредника «Man in the middle» при его загрузке по открытому каналу. Он содержит атрибуты с периодом своего действия и серийные номера отозванных сертификатов.
Процедура полной проверки сертификата на отзыв сводится к необходимости загрузить список с указанного URL, проверить срок его действия, проверить ЭП, убедиться, что серийного номера данного сертификата в нем нет.
Невозможность по тем или иным причинам убедиться, что сертификат пользователя не отозван, приводит к отрицательному результату проверки как самого сертификата, так и электронной подписи на поступивших от этого пользователя документах.
Такие документы будут отвергнуты до восстановления возможности проверить сертификат на отзыв.
Какие сбои и нарушения здесь может допустить УЦ?
1. Перенаправление ссылок (Redirect)
УЦ опубликовал в сертификате конкретный URL, но на сервере, где этот ресурс опубликован, происходит перенаправление клиента на другой URL.
Вызывающая система на Java может легко определить, что включено перенаправление следующим образом:
Приходилось встречать даже квалифицированные сертификаты, где не было ни одной ссылки, по которой система могла бы свободно загрузить список отзыва.
Просто невозможно во все системы установить все корни для всего многообразия УЦ, выпускающих SSL/TLS-сертификаты.
По понятным причинам информационные системы также не могут знать логин и пароль от FTP и не будут иметь доступ к внутренней службе Active Directory по LDAP-протоколу.
Поэтому принято, что CRL публикуется в свободном доступе.
Это гибридная ситуация, с которой приходилось сталкиваться, состоящая из приведенных выше пунктов 1 и 2.
Как такое возможно?
Сайт компании, где УЦ публикует свои списки отзыва, или просто веб-сервер, который используется удостоверяющим центром для этих целей, запущен, например, на Nginx.
4. Фильтрация по User Agent
Данная проблема и нарушение доступа к спискам отзыва сильно перекликается с приведенной в пункте 3.
Администратор забывает про то, что совершенно любая система должна иметь доступ к спискам отзыва в соответствии со стандартами группы PKIX.
Еще администратор сайта, где публикуются списки отзыва, может включить redirect на основе User Agent.
5. Просроченный CRL
Сертификат может содержать несколько ссылок на списки отзыва. Внутри каждого CRL могут быть вложены ссылки на его дельты с иными, более короткими сроками жизни, а следовательно, обновляемые чаще.
Хорошая информационная система должна загрузить список по каждой доступной ссылке, загрузить все вложенные дельты и убедиться, что серийный номер проверяемого сертификата не встречается ни в одном из них.
Рекурсивный алгоритм поиска в коробках, вложенных друг в друга, хорошо подходит для решения этой задачи.
А чтобы не загружать CRL каждый раз при интенсивном обмене в автоматических информационных системах, списки отзыва можно кэшировать на заданное разумное время, но не больше срока их жизни.
Были случаи, когда по каким-то причинам УЦ своевременно не обновлял CRL.
Список отзыва с истекшим сроком действия, естественно, не принимается. И если для сертификата нет или не удается загрузить по другим ссылкам действующий список, то общий результат будет отрицательным, а документ с ЭП отвергнут.
6. Сбои на сетевом и транспортном уровне
В качестве примера можно привести ситуацию со сбоем или некорректными настройками и состоянием на оборудовании удостоверяющего центра или сайта организации.
Но вот незадача. Вызывающая система вдруг начинает получать IOException: ConnectionTimeOut при попытке подключения к одной из ссылок. Вторая ссылка при этом работает и отдает CRL. А вызывающая система все равно начинает замедляться на настроенное в ней время, например, ConnectionTimeOut=15000 mSec, потому что проверяет обе ссылки, и ей приходится ждать ответа от недоступной в настоящий момент.
А если в CDP сертификата четыре, пять разных ссылок на CRL и при этом две или три из них оказываются недоступны с ConnectionTimeOut?
В этом случае время проверки сертификата возрастает до неприличной величины, равной времени таймаута, умноженному на количество таких ссылок.
А что, если обмен нашей информационной системы идет с этим УЦ или партнером, организацией, аффилированной с данным УЦ? И система партнера имеет свой таймаут на вызов нашей информационной системы, который заведомо меньше того времени, которое наша система тратит на проверку их сертификата?
Партнеры говорят нам, что не получают ответ от нашей системы и отключаются по таймауту, а происходит это на самом деле из-за регламентных работ на их УЦ.
Почему может происходить ConnectionTimeOut?
Как вариант, это регламентные работы, сетевая атака или повышенная нагрузка на сайт УЦ, что привело к неконсистентному состоянию:
какой-то брандмауэр, файрвол на пути, который просто начал съедать сетевые пакеты, не сообщая отправителю такие вещи, как "No Route to host"
началась потеря пакетов из-за неправильной конфигурации сети или перегрузки линии
слишком много запросов, перегружающих сервер
небольшое количество одновременно доступных потоков / процессов на сервере, что приводит к их блокировке. Это происходит особенно с запросами, выполнение которых занимает много времени и может сочетаться с предыдущим пунктом
Как с этим справляться?
Удостоверяющим центрам следует мониторить нагрузку на точки публикации списков отзыва, применять средства защиты от сетевых атак.
А в случае регламентных работ необходимо следить за тем, чтобы сервер, слушающий данный сокет, был корректно погашен, а не оставался в некоем подвешенном состоянии.
Если точка публикации будет корректно отключена, то вызывающая система, мгновенно получив от этой ссылки, например, IOException Connection Refused: connect, сразу перейдет к загрузке по следующему URL.
Вызывающая система для купирования таких ситуаций может выполнять кэширование «битых» ссылок на непродолжительный интервал, например 5 минут. Это позволит при интенсивном обмене практически не потерять скорость обработки запросов и одновременно сохранить актуальность результатов проверки сертификатов.
Механизмы проверки статуса сертификатов
Применяющиеся на практике механизмы проверки статуса сертификатов основаны на списках отозванных сертификатов (certificate revocation list, CRL) и протоколе онлайн-проверки статуса сертификатов (online certificate status protocol, OCSP).
Копирование нового сертификата сервера TLS на АРМ пользователя
Для копирования файла сертификата сервера TLS в локальную директорию АРМ пользователя необходимо:
Читайте также: