Установка корневых сертификатов и списка отозванных сертификатов Удостоверяющего центра

Перенаправление ссылок (Redirect)

УЦ опубликовал в сертификате конкретный URL, но на сервере, где этот ресурс опубликован, происходит перенаправление клиента на другой URL.

Вызывающая система на Java может легко определить, что включено перенаправление следующим образом:

private static final String ATTENTION_CRL_REDIRECT_DETECTED = "Attention CRL redirect detected: ";
    private static final String LOCATION = "Location";
   URL url = new URL(crlURL);
        InputStream crlStream = null;
        URLConnection connection = url.openConnection();
        String redirect = connection.getHeaderField(LOCATION);
        if (redirect != null) {
            throw new DownloadCRLException(
                    ATTENTION_CRL_REDIRECT_DETECTED   crlURL   STRING_DIRECTION   redirect);
        }

Просроченный CRL

Сертификат может содержать несколько ссылок на списки отзыва. Внутри каждого CRL могут быть вложены ссылки на его дельты с иными, более короткими сроками жизни, а следовательно, обновляемые чаще.

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

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

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

Были случаи, когда по каким-то причинам УЦ своевременно не обновлял CRL.

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

Сбои на сетевом и транспортном уровне

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

Запрос на сертификат на открытый ключ

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

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

Возможные случаи возникновения необходимости получения сертификата:

• У пользователя еще нет ключей. В этой ситуации перед
  формированием запроса ему необходимо создать ключи.
• У пользователя есть ключи, но срок действия
  соответствующего сертификата истек. В этой ситуации можно:
  • Создать запрос на новый сертификат на имеющиеся ключи. Новых
    ключей создавать не надо;
  • Создать новые ключи и сформировать запрос на сертификат на эти
    ключи.

  Как именно поступать в такой ситуации, определяется регламентом
  удостоверяющего центра.

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

Корневые сертификаты удостоверяющих центров

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

Такие сертификаты называются корневыми.

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

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

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

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

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

Криптографические операции и цепочки доверия

Понятие «Проверка подписи» подразумевает проверку соответствия подписи
документу, который подписан этой подписью. Если подпись соответствует
документу, документ считается подлинным и корректным.

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

Для этого проводится проверка сертификата на этот ключ. Понятие
«проверка сертификата» означает проверку подписи под этим
сертификатом. Подпись под сертификатом проверяется на открытом ключе
того, кто создал и подписал сертификат — т.е. на открытом ключе
удостоверяющего центра.

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

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

Обязательные атрибуты квалифицированных сертификатов

Состав квалифицированного сертификата регулируется Федеральным законом “Об электронной подписи” от 06.04.2021 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2021 г. N 795 “Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи”.

Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject – субъект сертификации отсутствовал атрибут L – Местоположение.

Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.

Удостоверяющий центр данную ситуацию комментировал так:

атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа №795

На конкретный пункты Закона и Приказа в УЦ не ссылались.

Собственный повторный анализ юридических аспектов показал:

63-ФЗ от 06.04.2021 “Об электронной подписи”

Статья 14. Сертификат ключа проверки электронной подписи

2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:

2) фамилия, имя и отчество (если имеется) – для физических лиц, наименование и место нахождения – для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;

Статья 17. Квалифицированный сертификат

2. Квалифицированный сертификат должен содержать следующую информацию:

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

Приказ ФСБ РФ от 27 декабря 2021 г. № 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)

После данного разбора удалось найти документ ФСБ РФ «ИЗВЕЩЕНИЕ ОБ ИСПОЛЬЗОВАНИИ АТРИБУТА ИМЕНИ «LOCALITYNAME» ПОЛЯ «SUBJECT» В СТРУКТУРЕ КВАЛИФИЦИРОВАННОГО СЕРТИФИКАТА КЛЮЧА ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ»

Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя ‑ юридического лица.

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

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

Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.

Прошу использовать данную информацию в работе.

Желаю всем участникам PKI удачи и успехов!

Промежуточные сертификаты удостоверяющих центров

Промежуточные сертификаты удостоверяющих центров—это сертификаты на
ключи удостоверяющих центров, не являющиеся корневыми. Т.е. это
сертификаты удостоверяющих центров, подписанные на других сертификатах
удостоверяющих центров.

Промежуточные сертификаты могут возникнуть, к примеру:

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

Если в цепочке доверия присутствует промежуточный сертификат
удостоверяющего центра, она оказывается трехзвенной:

Корневой сертификат УЦ—промежуточный сертификат УЦ—сертификат
пользователя.

Более длинные цепочки (с несколькими промежуточными сертификатами) возможны, но встречаются очень редко.

Сертификаты

Необходимо обеспечить возможность любому пользователю в любой момент:

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

Для того, чтобы обеспечить эти требования, все открытые ключи хранятся и
передаются в виде сертификатов.

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

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

Удостоверяющие центры

Создает (выпускает) сертификаты специальный административный центр,
называемый удостоверяющим центром (УЦ) или центром сертификации (ЦС).

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

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

Удостоверяющий центр имеет собственные ключи подписи и подписывает на
них все электронные документы, которые он выпускает.

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

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

Взаимодействие пользователя с удостоверяющим центром происходит следующим образом:

1. Пользователь создает ключевую пару (открытый и закрытый ключи).
2. Пользователь отправляет в удостоверяющий центр запрос на
   сертификат, в который включает открытый ключ и всю необходимую
   информацию о себе и о ключах. Набор необходимых сведений определяется
   регламентом удостоверяющего центра, но всегда необходимо
   указывать имя владельца, назначение ключей, дату создания.
3. Удостоверяющий центр получает запрос и проверяет его подлинность и
   корректность. Как именно это делается, определяется регламентом
   удостоверяющего центра.
4. Если результат проверки запроса положительный, удостоверяющий
   центр создает сертификат на открытый ключ, подписывает его, заносит в
   свою базу данных и отправляет пользователю.
5. Пользователь получает сертификат и устанавливает его у себя в
   системе.

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

Установка корневых сертификатов и списка отозванных сертификатов удостоверяющего центра

Чем должны руководствоваться уц при публикации crl

RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Спецификацией RFC 5280 IETF и стандартом X.509 ITU-T, разработанными Инженерным советом Интернета и Международным консультационным комитетом по телефонии и телеграфии.

В частности, пунктом 8. Security Considerations из RFC 5280

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

Существует ряд причин, по которым действие сертификата бывает необходимо
прекратить до окончания его срока действия.

Такими причинами, в частности, могут быть:

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

В таких ситуациях удостоверяющий центр отзывает соответствующий
сертификат.

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

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

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

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

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

Конец срока действия сертификата

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

По истечении срока действия сертификат становится недействительным.

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

По истечении срока действия сертификата на открытый ключ пользователя
необходимо сформировать запрос на новый сертификат.

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