Если прогуляться по просторам Хабрахабра, то можно найти различные публикации на тему создания цифровых сертификатов, организации Центров сертификации (ЦС) или даже Удостоверяющих Центров (УЦ) на базе OpenSSL. В основном эти статьи в той или иной мере полноты описывают использование либо утилиты openssl либо библиотечных функций OpenSSL для работы с сертификатами. При этом база данных удостоверяющих центров как строилась на каталогах и файлах, так и продолжает строиться на них, как использовалась командная строка в качестве интерфейса администратора (даже на Android ), так и продолжает им оставаться. Приятным исключением здесь является проект XCA.
В голове давно зрела мысль отойти от использования при работе с утилитой OpenSSL файлов и использовать полноценную базу данных, а если говорить о развертывании на базе OpenSSL полнофункционального УЦ, то предоставить его администраторам удобный графический интерфейс. А поскольку мы живем в Российской Федерации, то неплохо было бы, чтобы этот УЦ соответствовал требованиям Федерального закона от 6 апреля 2011г. №63-ФЗ «Об электронной подписи», а также «Требованиям к форме квалифицированного сертификата ключа проверки электронной подписи», утвержденных приказом ФСБ России от 27.12.2011 № 795.
Но даже не это заставило меня взяться за реализацию этого проекта. Сегодня, как и почти 20 лет назад (вспомним, Электронная Россия, Электронная Москва, Электронное Правительство и т.д.), много говориться об электронном документообороте, о цифровой экономике и т.д. Естественно, неотъемлемой частью всего этого является электронная подпись (ЭП), и не просто ЭП, а квалифицированная ЭП, усовершенствованная ЭП. Теперь соединим оба этих понятия и получим усовершенствованную квалифицированную ЭП, а если добавить еще и усиленную … Использование ЭП невозможно без сертификатов, а для выпуска сертификатов и управления ими, естественно требуются УЦ . И сколько проводится тендеров, сколько разворачивается УЦ, сколько тратится денег … У простых граждан создается впечатление, что УЦ это что-то громадное (как же Центр, почти как Центр Управления Полетами).
С точки зрения ответственности УЦ – это именно так. Ведь сертификаты, выпускаемые УЦ, фактически сегодня приравнены в паспорту.
С программистской точки зрения, все не так страшно. Так родился проект удостоверяющего центра CAFL63.
И так, что же такое Удостоверяющий Центр сегодня? В его состав входит Центр Регистрации (ЦР), который ответственен на прием от граждан заявок на сертификаты. Сегодня сертификаты выпускаются для юридический лиц, физических лиц, индивидуальных предпринимателей. Заявки принимаются в электронном виде в формате PKCS#10, CSR (Certificate Signing Request) или SPKAC. Отметим, что формат CSR это запрос PKCS#10 (DER-кодировка) в PEM-кодировке с заголовком -----BEGIN REQUEST CERTIFICATE-----.
Пользователи, которые хотят получить сертификат, должны иметь некую программу/утилиту, которая поможет им создать запрос:

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

Запрос – это заполненная анкета, цели, для которых нужен сертификат, открытый ключ пользователя, и все это завизировано (подписано) закрытым ключом пользователя. О такой утилите, которая может генерировать закрытый ключ не только в файле, но и на токене PKCS#11, а также с использованием CSP аля Микрософт, мы расскажем в следующей публикации. Далее, с пакетом документов, удостоверяющих, в частности, личность заявителя, и с электронном носителем, на котором хранится запрос (подчеркиваю, запрос, закрытый ключ лучше хранить в другом месте) гражданин приходит в ЦР УЦ.
В ЦР проверяют документы, запрос (заполненные данные, корректность электронной подписи и т.д), и, если все прошло успешно принимают запрос, утверждают его и передают в Центр Сертификации (ЦС). Но это в идеале. На практике, все выглядит по другому.
Гражданам, организациям нужен сертификат (для доступа на портал Госуслуг, для сдачи налогой отчетности, для участия в торгах), но они не знают что это такое и что с ним делать. Они искренне убеждены, что в УЦ получают электронную подпись типа факсимиле. Но это проблемы просвещения. Поэтому заявители приходят в ЦР УЦ, предъявляют документы. Вместе с сотрудником ЦР идут на отдельное рабочее место и готовят запрос на сертификат. Подготовленный запрос на электронном носителе, о чем уже говорилось, поступает в ЦР. Что здесь нужно помнить заявителю. Первое и главное забрать носитель с созданным закрытым ключом!
Утвержденный запрос на электронном носителе передается в ЦС, где на его основе и будет выпущен сертификат.
Это принципиальная схема работы УЦ. Детали станут понятны ниже. Одно замечание, в целях удобства демонстрации утилита подготовки запроса, ЦР и ЦС объединены в один демонстрационный комплекс. Но никаких проблем с разнесением функционала нет. Самый простой из них, это на каждом рабочем месте иметь по экземпляру CAFL63 и задействовать только требуемый функционал.
Когда реализация проекта шла полным ходом, на глаза попался проект SimpleCA. Изучение этого проекта очень помогла при окончательной реализации УЦ CAFL63.
Дистрибутив и исходный код CAFL63 для платформ Win32/Win64, Linux_x86/Linux_x86_64 можно скачать здесь. После скачивания дистрибутива внимательно прочитайте файл README.txt.
И так, запускаем утилиту CAFL63 и на экране появляется стартовая страница:
$CAFL63

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

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

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

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

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

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

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

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

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

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

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

Запросы в БД УЦ помечаются (колонка «Type») либо как «Locale», созданные на УЦ, либо как «Import», созданные самим заявителем, а также фиксируется время поступления заявки в УЦ. Это может оказаться полезным при разборе конфликтных ситуаций.
Если заявитель пришел без заявки и просит ее создать, то прежде всего необходимо определиться (Настройки->Типы Сертификатов->Физ.лицо->Редактировать) с типом ключевой пары (->Key Pair), для каких целей ( ->Key Usage) необходим сертификат:

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

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

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

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

Если запрос отклоняется, то он перемещается из таблицы текущих запросов reqDB в таблицу архива запросов reqDBArc и, соответсвенно, исчезает на вкладке «Запросы на сертификаты» и появляется на вкладке «Архив Запросов».
Утвержденная заявка остается в таблице reqDB и на вкладке «Запросы на сертификаты» до выпуска сертификата, а потом тоже попадает в архив.
Процедура выпуска сертификата мало отличается от процедуры создания завки (пункт меню «Выпустить сертификат»):

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

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

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

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

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

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

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

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

Вот и все.
Скачать дистрибутив CAFL63 для платформ Win32/Win64, Linux_x86/Linux_x86_64 можно здесь. Более того, это все успешно работает и на платформе Android. Представляете какой защищенный УЦ: на одном планшете ЦС, на другом ЦР и все это в выделенном помещении. Ни какой враг не страшен.

Если возникнут вопросы, пожелания или желание оказать помощь, я к вашим услугам. Мне кажется, что если бы провести тематические исследования вместе с форком openssl, то все вопросы с УЦ, кроме организационных, можно было бы закрыть раз и навсегда.