в начало  предыдущее  закрыть  следущее  в конец
141090, Московская область, г.Королев, мкр.Юбилейный, ул. Ленинская, д.4, пом.7
Тел: +7(495)589-99-53 Тех.поддержка:+7(499)110-90-40 e-mail: support@lissi.ru
Главная страница / Решения / CAFL63 - Удостоверяющий Центр на базе СКЗИ «ЛИРССЛ-CSP», SQLite3 и Tcl/Tk

CAFL63 - Удостоверяющий Центр на базе СКЗИ «ЛИРССЛ-CSP», SQLite3 и Tcl/Tk


Удостоверяющий Центр CAFL63 создан на базе СКЗИ «ЛИРССЛ-CSP». Для хранения данных (запросы, сертификаты, настройки и т.п.) используется СУБД SQLite3. Удостоверяющий центр имеет графический интерфейс, разработанный на Tcl/Tk.

УЦ CAFL63 разрабатывался с учетом требований Федерального закона от 6 апреля 2011г. №63-ФЗ "Об электронной подписи", а также «Требований к форме квалифицированного сертификата ключа проверки электронной подписи», утвержденных приказом ФСБ России от 27.12.2011 № 795.

В его состав УЦ входит Центр Регистрации (ЦР), который ответственен за прием от граждан заявок на сертификаты. Сегодня сертификаты выпускаются для юридических лиц, физических лиц и индивидуальных предпринимателей. Заявки принимаются в электронном виде в формате PKCS#10, CSR (Certificate Signing Request) или SPKAC. Отметим, что формат CSR – это запрос PKCS#10 в PEM-кодировке с заголовком -----BEGIN REQUEST CERTIFICATE-----.

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

В ЦР проверяют документы, запрос (заполненные данные, корректность электронной подписи и т.д), и, если все прошло успешно, принимают запрос, утверждают его и передают в Центр Сертификации (ЦС).

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

Утвержденный запрос на электронном носителе передается в ЦС, где на его основе выпускается сертификат.

Это принципиальная схема работы УЦ. Детали станут понятны ниже. Одно замечание, в целях удобства демонстрации утилита подготовки запроса, ЦР и ЦС объединены в один демонстрационный комплекс. Но никаких проблем с разнесением функционала нет. Самое простое решение - на каждом рабочем месте иметь по экземпляру CAFL63 и задействовать только требуемый функционал.

Когда реализация проекта шла полным ходом, на глаза попался проект SimpleCA. Изучение этого проекта очень помогло при окончательной реализации УЦ CAFL63.

Скачать дистрибутив CAFL63 для платформ Win32/Win64, Linux_x86/Linux_x86_64 можно здесь.

Итак, запускаем утилиту CAFL63 - на экране появляется стартовая страница CAFL63:


Работу мы начинаем с нажатия кнопки «Создать БД». База данных УЦ создается средствами кроссплатформенной СУБД SQLite3. БД УЦ содержит несколько таблиц. Главная таблица - mainDB - содержит всего одну запись, в которой хранится корневой сертификат, закрытый ключ, зашифрованный на пароле, и настройки УЦ. Есть две таблицы, связанные с запросами на сертификаты: текущие запросы reqDB и архив запросов reqDBArc. Для сертификатов создаются три таблицы: таблица новых сертификатов certDBNew, таблица архива сертификатов CertDB и таблица отозванных сертификатовCertDBRev. Все таблицы запросов и сертификатов в качестве ключа (primary key) используют значение хэш (sha1) от открытого ключа. Это оказалось очень удобным, например, при поиске сертификата по запросу или наоборот. В БД есть еще одна таблица crlDB, в которой хранятся списки отозванных сертификатов. И так, мы нажали кнопку «Создать БД»:

Создание УЦ начинается с выбора каталога, в котором будем хранить БД, и задания пароля для доступа к закрытому ключу УЦ. Нажав клавишу «След», мы переходим к странице выбора типа и параметров ключевой пары для УЦ:

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

Отметим, что утилита CAFL63 обладает определенным «интеллектом» и поэтому контролирует не только наличие данных в полях, но и правильность (красная подсветка - неправильно) заполнения таких полей как ИНН, ОГРН, СНИЛС, ОГРНИП, адрес электронной почты и др.

После заполнения полей информацией о владельце УЦ будет предложено определиться  с системными настройками УЦ:

Если вы не собираетесь работать с российской криптографией, то можете использовать обычный OpenSSL. Для работы с российской криптографией, необходимо указать соответствующую версию, модификацию OpenSSL. Более подробно читайте README.txt в скаченном дистрибутиве. Также, в соответствии с ФЗ-63, предлагается задать информацию о сертификации самого УЦ и используемым им СКЗИ.

После правильного заполнения всех полей, еще раз будет предложено проверить их достоверность и нажать кнопку «Finish»:

После нажатия кнопки «Готово» будет создана БД УЦ, в которую будут сохранены: корневой сертификат УЦ, закрытый ключ, системные настройки. А на экране вновь появится стартовая страница утилиты CAFL63. Теперь, когда у нас создана база данных вновь создаваемого УЦ, мы нажимаем кнопку «Открыть БД», выбираем каталог с БД и попадаем в главное рабочее окно УЦ:

Нажав кнопку «Просмотр CA УЦ», мы убеждаемся в том, что именно это именно наш корневой сертификат.

Следующим шагом мы подготавливаем шаблоны/профили заявок для юридический лиц, физических лиц и индивидуальных предпринимателей (Средства->Настройки->Типы Сертификатов->Новый ):

После задания имени нового профиля будет предложено определить его состав:

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

Если заявитель пришел с готовой заявкой, то после проверки его документов, заявка импортируется в БД УЦ. Для этого необходимо на главном рабочем окне выбрать вкладку «Запросы на сертификаты», нажать кнопку «Импорт запроса/CSR» и выбрать файл с запросом. После этого появится окно с информацией о запросе:

Просмотрев запрос и убедившись в его правильном заполнении, можно нажимать кнопку «Import» для занесения его в базу данных. Сразу отметим, что при попытке повторного внесения запроса в БД УЦ будет выдано сообщение:

Запросы в БД УЦ помечаются (колонка «Type») либо как «Locale», созданные на УЦ, либо как «Import», созданные самим заявителем, а также фиксируется время поступления заявки в УЦ. Это может оказаться полезным при разборе конфликтных ситуаций.

Если заявитель пришел без заявки и просит ее создать, то прежде всего необходимо определиться (Настройки->Типы Сертификатов->Физ.лицо->Редактировать) с типом ключевой пары (->Key Pair), для каких целей ( ->Key Usage) необходим сертификат:

Ключевая пара может создаваться как как средствами СКЗИ "ЛИРССЛ-CSP" (кнопка OpenSSL) и сохранятся в файле, так и на токене PKCS#11 (кнопка PKCS#11). В последнем случае необходимо также указать библиотеку для доступа к токену(например, rtpkcs11ecp для токена RuToken ECP или ls11cloud для облачного токена).

Далее для создания запроса необходимо нажать кнопку «Создать запрос/CSR»:

После того, как вы определились с профилем и нажали кнопку «След», дальнейшая процедура мало чем отличается от выпуска корневого сертификата. Одно важное замечание: запомните место хранение закрытого ключа и пароль для доступа к ключу. Если в качестве СКЗИ для генерации ключевой пары используется токен/смаркарта PKCS#11, то необходимо его доключить к компьютеру:


Созданная или импортированная заявка находится в БД УЦ и отображается в главном окне на вкладке «Запросы на сертификаты». Поступившие запросы находятся  в стадии «рассмотрения» (колонка «Status» вкладки «Запросы на сертификат» и «Архив Запросов»).  По каждому вновь поступившему запросу должно быть принято решение (контекстное меню при нажатии правой клавиши мышки на выбранном запросе):

Каждый запрос может быть отклонен или утвержден:


Если запрос отклоняется, то он перемещается из таблицы текущих запросов reqDB в таблицу архива запросов reqDBArc и, соответственно, исчезает на вкладке «Запросы на сертификаты» и появляется на вкладке «Архив Запросов».

Утвержденная заявка остается в таблице reqDB и на вкладке «Запросы на сертификаты» до выпуска сертификата, а потом тоже попадает в архив.

Процедура выпуска сертификата пункт меню «Выпустить сертификат») мало отличается от процедуры создания заявки :

Выпущенный сертификат сразу же появляется на вкладке «Сертификаты». При этом сам сертификат попадает в таблицу certDBNew БД УЦ и остается там до тех пор, пока он не будет опубликован. Сертификат считается опубликованным после его экспорта в SQL-дамп новых сертификатов, который передается на публичный сервис. Опубликование сертификата приводит к перемещению его из таблицы certDBNew в таблицу certDB.

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

Если запрос создавался на УЦ с генерацией ключа и его сохранением в файле, то нужно сформировать контейнер PKCS#12 и передать его заявителю:

Следует обратить внимание на «friendly name» - кавычки в нем должны экранироваться:


После создания защищенного контейнера PKCS#12 файл с закрытым ключом заявителя уничтожается.

Итак, УЦ начал свою жизнь, выпустил первый сертификат. Одна из задач УЦ – это организация свободного доступа к выпускаемым сертификатам. Публикация сертификатов, как правило, идет через веб-сервисы. Есть такой сервис  и у CAFL63:


Для публикации сертификатов и списков отозванных сертификатов на публичном сервисе УЦ либо предварительно выгружает сертификаты в файлы (Сертификаты->Экспорт сертификатов), либо делает SQL–дамп всей таблицы сертификатов, из которой можно создать БД сертификатов и загрузить в нее список сертификатов, а в последующем делать SQL-дамп новых сертификатов, из которого они будут добавляться в БД публичного сервиса:


Основополагающая функция УЦ – это публикация списка отозванных сертификатов по аналогии с тем как это делает МВД относительно утративших силу паспортов. Сертификат может быть отозван по заявлению владельца. Основной причиной отзыва является утрата закрытого ключа или потеря доверия к нему.

Для отзыва сертификата достаточно выбрать его на вкладке «Сертификаты», нажать правую кнопку мыши и выбрать пункт меню «Отзыв сертификата»:

Процедура отзыва не отличается от процедуры создания запроса или выпуска сертификата. Отозванный сертификат попадает в таблицу cerDBRev базы данных УЦ и появляется во вкладке «Отозванные сертификаты».

Осталось рассмотреть последнюю функцию УЦ – выпуск CRL - списка отозванных сертификатов.  Список CRL формируется на вкладке «Отозванные сертификаты» при нажатии кнопки «Создать СОС/CRL». Все что потребуется здесь от администратора - это ввести пароль УЦ и подтвердить свое намерение выпустить CRL:


Выпущенный CRL попадает в таблицу crlDB базы данных и отображается на вкладке «CRL/СОС». Для просмотра CRL или его экспорта с целью публикации на публичном сервисе необходимо, как всегда, выбрать нужную строку, нажать правую кнопку мыши и выбрать пункт меню:

Скачать дистрибутив CAFL63 для платформ Win32/Win64, Linux_x86/Linux_x86_64 можно здесь.

Более того, это все успешно работает и на платформе Android.

Дополнительная информация доступна здесь.

Метки: CAFL63, SQLite3, Tcl/Tk, УЦ, ЭП, ЭЦП, решения, удостоверяющий центр, электронная подпись.
© 2002-2018. ООО "ЛИССИ-Софт". Все права защищены
Телефон: +7(495) 589-99-53
Техническая поддержка: +7(499) 110-90-40
E-mail: support@lissi.ru
Принимаем к оплате