Работа с квалифицированными сертификатами в свете новой редакции Приказа №795 ФСБ РФ от 21.01.2021. Часть II

После опубликования статьи, посвящённой требованиям Приказа №795 ФСБ России в редакции от 29 января 2021 года, меня не покидало чувство её незавершённости. Это чувство было связано с тем, что в статье ни слова не было сказано про утилиту CAFL63, которая позволяет разворачивать удостоверяющие центры. И естественным является то, что её тоже необходимо привести в соответствие с новыми требованиями. На эту незавершённость обратили внимание и читатели:

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

И такая доработка утилиты CAFL63 была проведена. Доработанную утилиту для разных платформ можно скачать здесь:

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

• OS X
• Linux64
• Linux32
• Win64
• Win32

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

Поскольку утилита CAFL63 написана на tcl/tk, то основные изменения, с точки зрения просмотра сертификатов выпущенных по новым требованиям, аналогичны изменениям, сделанным в утилите cryptoarmpkcs. Это касается и включения новых oid-ов в пакет pki и функции разбора расширения identificationKind.

Более серьёзная проблема связана с выпуском самих сертификатов, поскольку здесь задействуется утилита openssl или утилита, сделанная на её основе.

Расширение identificationKind без проблем можно добавить для новых сертификатов через секцию расширений cert_ext (параметр –extentions cert_ext) конфигурационного файла config.cfg (параметр –config config.cfg):

openssl x509 -req -inform PEM -outform PEM -CA rootca.pem -CAkey rootca.key -passin pass:01234567 -extfile config.cfg -extensions cert_ext -days 366 -set_serial 4100 –in req.csr

Эта команда предписывает утилите openssl создать сертификат из запроса (x509 -req), находящего в файле req.csr (-in req.csr), добавив в сертификат расширения из секции cert_ext (-extensions cert_ext) конфигурационного файла config.cfg (-extfile config.cfg)

Если мы хотим указать, что идентификация владельца сертификата проводилась в его личном присутствии, то в секции cert_ext будет записан код:

[cert_ext]
1.2.643.100.114 = DER:02:01:00

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

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

OID.1.2.643.100.114 = DER:02:01:01

И т.д.

Хотелось, чтобы и атрибут INNLE (oid — 1.2.643.100.4) для юридических лиц можно было бы также легко добавлять в запрос и сертификат. И на первый взгляд это так, вместо имени INNLE будем задействовать его oid в секции req_distinguished_name при создании запроса:

[ req ]
distinguished_name		= req_distinguished_name
. . .
[ req_distinguished_name ]
C		= RU
ST		= Московская область
O		= Тест юридического лица
CN		= urlitzo
#INNLE	= 8765432109
#Атрибут INNLE имеет oid  1.2.643.100.4
#OID.1.2.643.100.4 = <10 цифр INNLE>
OID.1.2.643.100.4 = 8765432109
emailAddress		= [e-mail]

После внесения этих изменений в конфигурационный файл config.cfg и выполнения команды:

openssl req -new -utf8 -config config.cfg -key urlitzo.key -passin pass:01234567 -outform PEM

мы получаем запрос с атрибутом INNLE (для просмотра мы использовали утилиту cryptoarmpkcs):



И на первый взгляд всё хорошо, но если посмотреть asn1-структуру запроса, то окажется что атрибут INNLE имеет тип кодирования UTF8:



Это противоречит новым требованиям, в которых для INNLE определён другой тип кодирования:

INNLE (ИНН юридического лица).

Значением атрибута INNLE является строка, состоящая из 10 цифр и представляющая ИНН владельца квалифицированного сертификата — юридического лица. Объектный идентификатор типа атрибута INNLE имеет вид 1.2.643.100.4, тип атрибута INNLE описывается следующим образом:

INNLE::= NUMERIC STRING SIZE 10;

В итоге становится ясным, что требуется внесение изменений в основной код проекта openssl для поддержки в нём новых oid-ов и в первую очередь INNLE и OGRNIP. Тем более, что oid-ы INN и OGRN в проект openssl уже внесены.

Исходя из этих реалий, было решено добавить в проект CAFL63 встроенный модуль openssl, который доработан с учетом Приказа №795 ФСБ России в редакции от 29.01.2021 года. Это позволяет использовать утилиту CAFL63 для развёртывания учебного или корпоративного удостоверяющего центра независимо от наличия у пользователя openssl с поддержкой последних требований.

Начав работу с утилитой CAFL63 с нажатия кнопки «Создать БД», пользователь, пройдя несколько шагов, попадёт на вкладку выбора модуля OpenSSL:



Здесь можно либо выбрать собственный модуль openssl, либо ввести текст «internalModule» для использования встроенного модуля. Оставляем internalModule и нажимаем кнопку «След>»:



После создания базы данных УЦ начинаем работу на УЦ с нажатия кнопки «Открыть БД». После открытия базы данных следует настроить шаблоны для сертификатов которые будут выпускаться на УЦ (Средства → Настройки → Типы сертификатов → Юридическое лицо → Редактировать):



И начнём мы, как вы уже догадались, с профиля сертификатов для юридических лиц:



Этот механизм позволяет редактировать существующие профили и создавать новые. Для каждого профиля (вкладка «KeyPair») указывается тип ключ, который будет создаваться при генерации запроса. Для генерации ключей помимо утилиты openssl могут используются и криптографические токены PKCS#11 с поддержкой российской криптографии. В этом случае указывается библиотека для доступа к токенам:



Получить сертификат на УЦ CAFL63 пользователь может одним из двух способов.

Первый: прийти на УЦ с готовым запросом в формате PKCS#10, в котором содержатся все необходимые о нём сведения, подписанные его закрытым ключом. Это самый безопасный способ. Сотрудники УЦ в этом случае никак не пересекаются с закрытым ключом заявителя. В будущем им нельзя будет предъявить никаких претензий, что они могли что-то подписать за владельца сертификата. В этом случае запрос пользователя импортируется в систему и помечается как созданный пользователем за пределами УЦ:



Во втором случае запрос создается на УЦ. При его создании, помимо выбора профиля сертификата, будет предложено определиться с механизмом генерации закрытого ключа. Для генерации ключа может быть использован как токен PKCS#11, так и утилита openssl:



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

При генерации закрытого ключа утилитой openssl он вместе с сертификатом упаковывается в защищенный контейнер PKCS#12 и передаётся заявителю. В последнем случае заявитель должен как-то удостовериться, что на УЦ не осталось дубликата ключа.

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



После утверждения запроса можно выпускать сертификат. В процессе выпуска сертификата будет предложено еще раз просмотреть запрос, а также указать способ идентификации заявителя:



Это последнее требование из новой редакции Приказа №795, реализация которого была добавлена в утилиту CAFL63.

После нужно перейти на вкладку «Сертификаты», где проводится основная работа с сертификатами, и выгрузить сертификат заявители. Сертификат передается либо просто как файл, если заявитель пришёл с готовым запросом. Если заявитель использовал при генерации токен PKCS#11, то вместе с сертификатом ему передаётся и сам токен. При генерации ключевой пары модулем openssl, пользователю передаётся защищенный контейнер PKCS#12, в котором находится и сам ключ, и сертификат пользователя и корневой сертификат УЦ:



Скоро будем отмечать 10-летний Юбилей Приказа ФСБ России от 27.12.2011 №795. И ждём новой редакции.