Добавление сертификатов в хранилище доверенных корневых центров сертификации для локального компьютера – Тендерные займы и кредиты

[ ca_default ]

В секции [CA_default] зададим значения по умолчанию. Сначала пропишем пути основных директорий

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге
# (чтоб не редактировать в ста местах)
dir = /root/ca/RootCA
certs = $dir/certs
new_certs_dir = $certs
private = $dir/certs
crl_dir = $dir/crl
serial = $dir/serial 
database = $dir/index.txt
RANDFILE = $dir/private/.rand

• dir – это исключительно наша переменная, для того, чтоб сэкономить нам время. Тут мы укажем пусть до основной директории того ЦС, для которого конфигурация будет предназначена;
• certs – эта переменная для сертификатов, ей мы указываем нашу папку;
• new_certs_dir – аналогично certs (в разных версиях OpenSSL разные переменные для сертификатов), поэтому указываем обе;
• private – в эту переменную передаем место нашей приватной директории, в описании директорий, мы уже говорили, что тут храним приватные ключи;
• crl_dir – как уже говорили, тут будет путь к директории отозванных сертификатов;
• serial – указываем наш файл serial;
• database – текстовая база данных, наш index.txt;
• RANDFILE – случайный файл для случайных данных.

Идем дальше и укажем теперь определенные параметры

# Сертификат и ключ, которым будет подписан другой сертификат,
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key = $private/RootCA.key.pem
certificate = $certs/RootCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber = $dir/crlnumber
crl = $crl_dir/RootCA.crl.pem
crl_extensions = crl_ext
default_crl_days = 30

# используемый алгоритм хеширования
default_md = sha256

name_opt = ca_default
cert_opt = ca_default

default_days = 365
preserve = no
policy = policy_root

policy
policy — в разных конфигурациях мы укажем разные значения. У нас их будет несколько: policy_root, policy_intermediate_person, policy_intermediate_server, policy_intermediate_code.
policy_root — будет в конфигурации для корневого сертификата, и у него будет заданы жесткие правила для подписи промежуточных.
policy_intermediate — а эта секция правил будет в конфигурации промежуточных, и правила подписи будут не такими строгими.

Параметры:

Напишем политики, о которых мы сказали в примечании

[ policy_root ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = supplied
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ policy_intermediate_person ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = optional

[ policy_intermediate_code ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ policy_intermediate_server ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = supplied

Тут мы не будем останавливаться, т.к. уже все расписано ранее. А о полях я расскажу чуть-чуть позже.

Essl — embedded secure socket layer

Дальше я представлю на Ваш суд результаты моих исследований данного вопроса проверенные опытным путем. Термин

eSSL

пришел мне в голову в процессе написания этой статьи, так что любые упоминания прошу употреблять вместе со ссылкой на

Итак, освещу немного

важные аспекты строения сертификатов

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

private key

). Сертификат также содержит в себе открытый ключ для проверки подлинности данных содержащихся в этих строковых полях. Перечень полей определен в формате Х.509 v3 и описан в документе

RFC 5280

(это последняя на данный момент редакция документа, до этого действовал

RFC 3280

). Сертификат содержит поле

commomName

которое описывает имя субъекта сертификации, обычно оно совпадает с доменом веб-сайта для которого выпущен сертификат, но в стандарте нет никаких запретов на то что будет вписано в эту строку, например, строка “Вася Пупкин” будет так же валидна для этого поля с точки зрения стандарта — это

первый аспект

. Но веб-браузеры проверяют именно это поле на соответствие с именем сайта который предъявляет сертификат. К счастью для нас в формате X509 v3 определены дополнительные расширения, одно из которых

subjectAltName

, которое позволяет добавить идентификаторы, связанные с основным именем субъекта сертификации (

commomName

). Такими идентификаторами могут быть:

и это

второй

и, пожалуй, наиболее важный

аспект

строения сертификатов 3й версии стандарта. Дело в том что таких идентификаторов можно добавить несколько, т.е. можно вписать несколько IP адресов для которых будет валиден выпущенный сертификат. А это и есть то что нам нужно в случае если некое устройство имеет два Ethernet интерфейса для работы в разных под-сетях, да еще и возможность выхода в сеть через различные типы модемов, если соединение будет по PPP, то это будет третий интерфейс со своим IP адресом. Опытным путем мною был установлен

один важный момент

в назначении альтернативных IP адресов. Браузеры Internet Explorer и FireFox по разному производят проверку альтернативных имен. FireFox сверяет адрес который указан в идентификаторе

IP

, а IE — сверяет адрес с идентификатором

DNS

. Поэтому, для осуществления проверки сертификата в обоих браузерах, каждый необходимый IP адрес

должен быть указан и как IP и как DNS

. О том как это сделать будет рассказано дальше.

Вариант 1: создать csr

Первое, что нужно сделать, – это создать 2048-битную пару ключей RSA локально. Эта пара будет содержать как ваш закрытый, так и открытый ключ. Вы можете использовать инструмент Java key или другой инструмент, но мы будем работать с OpenSSL.

Чтобы создать открытый и закрытый ключ с запросом на подпись сертификата (CSR), выполните следующую команду OpenSSL:

openssl req –out certificatesigningrequest.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key

Что эта команда означает:

• openssl – активирует программное обеспечение OpenSSL
• req – указывает, что мы хотим CSR
• –out – указывает имя файла, в котором будет сохранен ваш CSR. У нас в примере это certificatesigningrequest.csr
• –new –newkey – создать новый ключ
• rsa:2048 – cгенерировать 2048-битный математический ключ RSA
• –nodes – нет DES, то есть не шифровать закрытый ключ в PKCS#12 файл
• –keyout – указывает домен, для которого вы генерируете ключ

Далее ваша система должна запустить текстовую анкету для заполнения, которую мы описывали в таблице выше:

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

После завершения работы программы вы сможете найти файл CSR в вашем рабочем каталоге. Запрос на подпись сертификата, сгенерированный с помощью OpenSSL, всегда будет иметь формат файла .csr. Чтобы найти в папке все файлы этого формата используйте команду

ls *.csr

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

Также вы можете открыть файл .csr в текстовом редакторе, например nano, чтобы просмотреть сгенерированный буквенно-цифровой код.

sudo nano your_domain.csr

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

openssl req -in server.csr -noout -text

Далее можно декодировать CSR и убедиться, что он содержит правильную информацию о вашей организации, прежде чем он будет отправлен в центр сертификации. В Интернете существует множество CSR-декодеров, которые могут помочь вам сделать то же самое, просто скопировав содержимое файла CSR, например sslshopper.

Как я оформлял доверенность

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

Если возникает спор, оба идут с этими файлами в суд. У суда не возникает вопросов, подлинная ли подпись. Перепечатать первую страницу договора не получится — подпись заверяет не одну страницу, а документ целиком. Даже если изменить одну запятую, подпись сломается — подделку будет видно.

Договоров я ни с кем не заключал, поэтому решил оформить доверенность в простой письменной форме, которую не нужно заверять у нотариуса, и подписать ее ЭП. Главное удобство такой доверенности — ее можно отправить по электронной почте или через любой мессенджер.

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

Ожидания. Я надеялся, что мой представитель без проблем будет получать документы в суде и на почте по доверенности с ЭП. Все-таки электронная подпись равносильна собственноручной по закону — вопросов у сотрудников госорганов быть не должно.

Как это работает. Сначала нужно составить текст доверенности в ворде. Я больше люблю работать с гугл-документами, но в данном случае выбора у меня не было. У гугл-документов свои службы цифровых подписей, и с тем типом ЭП, что у меня, они не работают.

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

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

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

Как я пытался поменять полис омс через госуслуги

На портале госуслуг с помощью ЭП можно сделать многое. Эти сервисы планируют расширять. Недавно появились прототипы пяти суперсервисов:

1. Рождение ребенка.
2. Поступление в вуз онлайн.
3. Переезд в другой регион.
4. Оформление европротокола онлайн.
5. Цифровое исполнительное производство.

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

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

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

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

Когда я заполнил форму, нужно было подписать заявление электронной подписью. Для этого необходимо вставить токен в USB-порт. Система сама обратится к токену — нужно только следовать подсказкам и в конце нажать на кнопку «Отправить».

Реальность. Сообщение о приеме заявления я не увидел. 30 дней прошло — заявление так и не было отправлено в страховую компанию.

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

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

Как я успешно подал жалобу в гибдд

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

Можно было обратиться в суд, но проще всего отправить жалобу руководителю сотрудника ГИБДД, который оформил постановление об административном правонарушении. Обратиться можно через онлайн-сервис ГИБДД.

Ожидания. Я надеялся, что ГИБДД будет удобнее работать с заявлением, подписанным ЭП. Там будут точно знать, что отправитель именно я, и это не мой сосед заполнил жалобу, подписал ее моей фамилией и указал мой адрес.

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

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

Я создал одно обращение сразу в два подразделения ГИБДД в ворде: в шапке заявления указал обоих адресатов. К форме для подачи жалобы в качестве вложения прикрепил вордовский файл, подписанный ЭП.

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

Реальность. На следующий день после отправки жалобы информация о штрафах исчезла из моего личного кабинета на госуслугах. Вскоре пришло два ответа из ГИБДД, что скорость превысили другие водители, а не я.

Если бы я отправил вордовский документ, не подписанный ЭП, мое обращение все равно бы рассмотрели. И я получил бы аналогичный ответ.

Получение электронной подписи: к кому обратиться

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

К кому обратиться за IT-продуктом и какие опции комплексного обслуживания включать в договор?

При выборе центра сертификации учитывайте следующие моменты:

• дату основания учреждения – долгое присутствие организации на рынке высоких технологий и информационной безопасности говорит о чистоте и надежности ее реноме;
• частоту клиентских обращений и пользовательские отзывы;
• опции комплексного сопровождения – например, перевыпуск ЦП, установку и настройку программных приложений, отладку веб-обозревателя, инсталляцию сертификатов, в том числе корневого (принадлежащего УЦ), в хранилище ОС, установленной на рабочем ПК, наличие технической поддержки, защиту от руткитов (компьютерных вирусов);
• количество точек выдачи средств ЦП – чем их больше, тем выше вероятность, что вы найдете пункт, расположенный недалеко от вашего дома или офиса;
• опцию экспресс-выпуска (время выдачи ЭЦП составляет от 15 – 20 мин.) в качестве дополнительной услуги ;
• репутацию учреждения: честность центра сертификации не подвергается сомнению – достаточно одного судебного процесса или скандала в СМИ, связанного с утечкой персональных данных, чтобы УЦ раз и навсегда был дискредитирован в глазах заявителей.

Списки аккредитованных УЦ опубликованы здесь или здесь.

Бланк заявки на изготовление и выдачу цифровой подписи получают в офисе УЦ или скачивают с веб-портала учреждения. Если при заполнении документа у вас возникли вопросы, обратитесь за разъяснениями к оператору центра сертификации или в чат саппорта. Не забудьте отметить галкой пункт о согласии с обработкой персональных данных в соответствии с требованиями 152-ФЗ.

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

Таблица №1 – бумаги, которые могут потребоваться для получения ЦП

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

Работаем с сертификатами

Создаем корневой приватный ключ

openssl genrsa -aes256 -out /root/ca/RootCA/private/RootCA.key.pem 4096 chmod 400 /root/ca/RootCA/private/RootCA.key.pem

Создаем корневой сертификат

openssl req -config /root/ca/config/RootCA.cnf 
-key /root/ca/RootCA/private/RootCA.key.pem 
-new -x509 -days 7300 -sha256 -extensions root_ca 
-out /root/ca/RootCA/certs/RootCA.cert.pem
chmod 444 /root/ca/RootCA/certs/RootCA.cert.pem

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

openssl x509 -noout -text -in /root/ca/RootCA/certs/RootCA.cert.pem

Создаем промежуточные и подписываем их корневым

#Создаем приватный ключ 
openssl genrsa -aes256 
-out /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem 4096
chmod 400 /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem
#Создаем запрос
openssl req -config /root/ca/config/PersonIntermediateCA.cnf -new -sha256 
-key /root/ca/PersonIntermediateCA/private/PersonIntermediateCA.key.pem 
-out /root/ca/PersonIntermediateCA/csr/PersonIntermediateCA.csr.pem #Создаем подписанный сертификат
openssl ca -config /root/ca/config/RootCA.cnf -extensions intermediate_ca 
-days 3650 -notext -md sha256 
-in /root/ca/PersonIntermediateCA/csr/PersonIntermediateCA.csr.pem 
-out /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem

Using configuration from /root/ca/config/RootCA.cnf
Enter pass phrase for /root/ca/RootCA/private/RootCA.key.pem: secret

Check that the request matches the signature
Signature ok
Certificate Details:
...
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

chmod 444 /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem

Проверяем валидацию

openssl verify -CAfile /root/ca/RootCA/certs/RootCA.cert.pem  /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem
#result: /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem: OK

Идем дальше и создаем certificate chain

certificate chain — эта цепочка нам нужна, когда у клиента нет корневого, или промежуточного сертификата.

Если в AD мы ничего не добавили, то клиенту нужна связка конечный промежуточный корневой.
Если мы добавим в AD только корневой сертификат, то certificate chain нам нужен в связке конечный промежуточный.
Если в AD добавлены и промежуточный сертификаты, то certificate chain нам не нужен

cat /root/ca/PersonIntermediateCA/certs/PersonIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/PersonIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/PersonIntermediateCA/certs/ca-chain.cert.pem

cat /root/ca/CodeIntermediateCA/certs/CodeIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/CodeIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/CodeIntermediateCA/certs/ca-chain.cert.pem cat

/root/ca/ServerIntermediateCA/certs/ServerIntermediateCA.cert.pem 
/root/ca/RootCA/certs/RootCA.cert.pem > /root/ca/ServerIntermediateCA/certs/ca-chain.cert.pem
chmod 444 /root/ca/ServerIntermediateCA/certs/ca-chain.cert.pem

Усиленная электронная подпись

В КЭП и НЭП заложены криптографические алгоритмы. Чем эти виды подписи отличаются друг от друга?

1. Средствами и алгоритмами, при помощи которых создается ЭП. В случае с НЭП на них не накладываются никакие дополнительные ограничения. Это может быть американский, российский, белорусский и другой криптографический алгоритм.
2. ПО для работы с ЭП. В случае с НЭП на средства ЭП не накладываются ограничения. В случае с КЭП, наоборот, к средствам предъявляются дополнительные требования — они должны быть сертифицированы в ФСБ и соответствовать определенным стандартам. Это сразу же влечет за собой ограничение на криптографический алгоритм, а именно должны применяться только российские алгоритмы в соответствии с ГОСТ. Накладываются требования и на сам сертификат ЭП по его структуре, то есть существуют жесткие требования, определяющие структуру этого сертификата.
3. Аккредитованный удостоверяющий центр (УЦ). Квалифицированные сертификаты ЭП должны выпускаться УЦ, которые прошли процедуру аккредитации в Минкомсвязи. Такие  УЦ удовлетворяют ряду довольно серьезных требований, гарантирующих их надежность.
4. Структура сертификата ЭП. Квалифицированный сертификат ЭП должен удовлетворять требованиям по структуре, например, содержать СНИЛС владельца. К неквалифицированным таких требований не предъявляется.

Таким образом, суть отличия между НЭП и КЭП прозрачна: так как на КЭП накладывается несколько жестких ограничений, ее юридический статус выше. КЭП — это единственная подпись, которая признается равной собственноручной подписи без дополнительных мероприятий.

Что касается НЭП, то для признания ее равной собственноручной подписи требуются дополнительные соглашения между участниками электронного документооборота (ЭДО) либо отдельный нормативно-правовой акт, регламентирующий факт равнозначности. Например, если между двумя компаниями осуществляется ЭДО, то документы они подписывают ЭП.

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

При этом в суде им нужно будет доказывать юридическую значимость на основе данного соглашения. В случае допущения в соглашении о документообороте каких-то ошибок, значимость электронного документа может быть не признана. Если те же самые компании ведут ЭДО, используя КЭП, то им не понадобятся дополнительные соглашения друг с другом, а юридическая значимость документов будет в силу ФЗ признаваться автоматически.

Установка личного сертификата криптопро

Уходим в консоль

Базовую конфигурацию мы подготовили, теперь можно и в консоль идти 🙂

Создаем рабочие директории

mkdir -p /root/ca/config
mkdir -p /root/ca/{RootCA,PersonIntermediateCA,ServerIntermediateCA,CodeIntermediateCA}/{certs,crl,newcerts,private}
mkdir -p /root/ca/{PersonIntermediateCA,ServerIntermediateCA,CodeIntermediateCA}/csr

Выставим всем private права 400

chmod 400 /root/ca/RootCA/private
chmod 400 /root/ca/PersonIntermediateCA/private
chmod 400 /root/ca/ServerIntermediateCA/private
chmod 400 /root/ca/CodeIntermediateCA/private

Создаем файлы конфигурации

touch /root/ca/config/RootCA.cnf
touch /root/ca/config/PersonIntermediateCA.cnf cp
touch /root/ca/config/ServerIntermediateCA.cnf cp 
touch /root/ca/config/CodeIntermediateCA.cnf

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/RootCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/RootCA.key.pem
certificate       = $certs/RootCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/RootCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_root

[ policy_root ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = supplied
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = support@CertService.info

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/PersonIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/PersonIntermediateCA.key.pem
certificate       = $certs/PersonIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/PersonIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_person

[ policy_intermediate_person ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = support@CertService.info

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ user_cert ]
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "Client certificates"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment 
extendedKeyUsage = clientAuth, emailProtection

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/ServerIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/ServerIntermediateCA.key.pem
certificate       = $certs/ServerIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/ServerIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_server

[ policy_intermediate_server ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = supplied

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = support@CertService.info

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
# Серверный
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

[ ca ]
default_ca = CA_default

[ CA_default ]
# Переменные указывающие директории, нам это пригодиться в конфиге 
# (чтоб не редактировать в ста местах)
dir               = /root/ca/CodeIntermediateCA
certs             = $dir/certs
private           = $dir/private
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# Сертификат и ключ, которым будет подписан другой сертификат, 
# проходящий через этот конфиг (в данном случае - это корневой сертификат)
private_key       = $private/CodeIntermediateCA.key.pem
certificate       = $certs/CodeIntermediateCA.cert.pem

# Параметры для отозванных сертификатов
crlnumber         = $dir/crlnumber
crl               = $crl_dir/CodeIntermediateCA.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# используемый алгоритм хеширования
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 365
preserve          = no
policy            = policy_intermediate_code

[ policy_intermediate_code ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
subjectAltName = optional

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

default_md          = sha256

# Расширение при использовании опции -x509.
x509_extensions     = root_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code) (C)
countryName_min		= 2
countryName_max		= 2
countryName_default          = RU

stateOrProvinceName             = State or Province Name (S)
stateOrProvinceName_default     = Krasnoyarskiy kray

localityName                    = Locality Name (L)
localityName_default            = Norilsk

0.organizationName              = Organization Name (O)
0.organizationName_default      = CertService

organizationalUnitName          = Organizational Unit Name (OU)
organizationalUnitName_default = CertService. IT-Department.

commonName                      = Common Name (CN)
#commonName_default          = CertService.info

emailAddress                    = Email Address
emailAddress_max		= 60
#emailAddress_default          = support@CertService.info

subjectAltName = Alternative DNS names (comma seperated list)
#subjectAltName_default = DNS:www.CertService.info

[ root_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ code_cert ]
# Для подписи кода
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "Code Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = digitalSignature
extendedKeyUsage = codeSigning, msCodeInd, msCodeCom

[ crl_ext ]
# Для отзыва сертификатов
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Для OCSP (Online Certificate Status Protocol)
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

Создадим наши недо-базы данных