После опубликования статьи, посвящённой требованиям Приказа №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 = ul@ul.ca
После внесения этих изменений в конфигурационный файл config.cfg и выполнения команды
openssl req -new -utf8 -config config.cfg -key urlitzo.key -passin pass:01234567 -outform PEM
И на первый взгляд всё хорошо, но если посмотреть 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. И ждём новой редакции.
