- Вступление
- Начальные настройки
- Mac os x
- Online certificate status protocol
- Openssl certificate authority. центр сертификации openssl.
- Pem (.pem, .crt, .cer) в pfx
- Pkcs # 7 / p7b (.p7b, .p7c) в pfx
- Windows
- В ubuntu
- Ипользование crl на сервере
- Использование crl клиентами
- Компиляция openssl библиотеки
- Компиляция privkey.c
- Настройка apache 2 для использования сертификатов
- Настройка аутентификации клиентов
- Общие преобразования pem
- Подготовка каталогов
- Подготовка конфигурационного файлы
- Подготовка конфигурационных файлов
- Подготовка файла конфигурации
- Подписывание серверного и клиентского сертификатов
- Пользуемся закрытым ключом private.key для подписывания файла file.txt
- Проверка корневого сертификата
- Проверка промежуточного сертификата
- Проверяем подпись
- Просмотр содержимого файла сертификата pem
- Просмотр содержимого файла сертификата в кодировке der
- Разворачиваем собственный цс
- Расширения имени файла der
- Сборка утилиты конвертирования ключа
- Создаем сертификат подписаный нашим са
- Создание crl
- Создание ключа
- Создание корневой пары ключей
- Создание пары ocsp
- Создание промежуточного ключа
- Создание промежуточного сертификата
- Создание промежуточной пары ключей
- Установка сертификата
- Файл header.key
- Файл masks.key
- Файл primary.key
- Формирование файла закрытого ключа private.key
- Центры сертификации: как они используются
- Читаем закрытый ключ и конвертируем
- Списки отзывов сертификатов
- Отзыв сертификата
Вступление
OpenSSL — это криптографическая библиотека со свободным и открытым исходным кодом, которая предоставляет несколько инструментов командной строки для работы с цифровыми сертификатами. Некоторые из этих инструментов могут быть использованы в качестве центра сертификации.
Центр сертификации (CA) является объектом, который подписывает цифровые сертификаты. Многие веб-сайты нуждаются в том, чтобы их клиенты знали, что соединение является безопасным, поэтому они платят международным доверенным центрам сертификации (например, VeriSign, DigiCert) за подпись сертификата для своего домена.
В некоторых случаях имеет больше смысла выступать в качестве вашего собственного центра сертифкации, чем платить центрам сертификации, таким как DigiCert. Например, обеспечение безопасности вебсайта в интранете или для выдачи собственных сертификатов клиентам, чтобы позволить им проверять подлинность сервера (Apache, OpenVPN).
Начальные настройки
Сперва заполним файл /root/.rnd, который используется как источник начальных случайных значений в генераторе псевдослучайных чисел OpenSSL. Суть использования этого файла описана на сайте OpenSSL. Нам надо заполнить свой файл случайными данными, как вариант — скопировав из /dev/urandom 32768 байт в файл .rnd таким образом:
Далее создадим сертификат для CA:
root@shpc:/opt/simple_CA# openssl req -newkey rsa:4096-keyform PEM -keyout ca.key -x509-days3650-outform PEM -out ca.cer
Опции для сертификата берутся из файла /etc/ssl/openssl.cnf. Сам файл довольно большой, мы не будем приводить здесь его содержимое. В реальности стоит создать свой конфигурационный файл с необходимыми опциями и блоками — и использовать его для генерации сертификатов.
На выходе получим два файла: ключ и сертификат.
Оба файла надо беречь. Если они попадут к злоумышленнику, он сможет использовать их для генерации сертификатов. Посмотреть сертификат можно при помощи этой команды (вывод обрезан для краткости):
root@shpc:/opt/simple_CA# openssl x509 -text-noout-in ca.cer
Далее на основе полученного сертификата (напомним, что это сертификат корневого CA) можно сгенерировать сертификат для сервера. Вначале генерируем закрытый ключ для сервера:
root@shpc:/opt/simple_CA# openssl genrsa -out server.key 4096
Теперь используем этот ключ для генерации запроса на выдачу сертификата (CSR):
root@shpc:/opt/simple_CA# openssl req -new-key server.key -out server.req -sha256
Отметим, что данные, которые вы вводите в поля, должны совпадать со значениями в тех полях, что указывались при создании сертификата корневого сервера. Теперь возьмём корневой сертификат CA и запрос — и сгенерируем на их основе сертификат для сервера:
root@shpc:/opt/simple_CA# openssl x509 -req-in server.req -CA ca.cer -CAkey ca.key -set_serial 100-extensions server -days1460-outform PEM -out server.cer -sha256
Должно получиться 5 файлов.
Файл server.req можно удалить — а при необходимости создать заново. Теперь надо перенастроить веб-сервер для работы с сертификатами.
Mac os x
Safari, FireFox, Chrome — используют системный репозиторий.
Запускаем KeyChain Access.Идём в меню File — Import Items (login или System) — выбираем файл rootCA.crt.Когда нас спросят, отвечаем — Always Trust.
Для вашего личного Safari достаточно выбрать login.
Online certificate status protocol
Online Certificate Status Protocol (OCSP) был создан в качестве альтернативы CRL. Как и CRL, OCSP позволяет запрашивающей стороне (к примеру, веб-браузеру) определять статус отзыва сертификата.
Openssl certificate authority. центр сертификации openssl.
Вольный перевод с источника
Эта инструкция демонстрирует, как работает собственный центр сертификации (CA – Certificate Authority), используя набор инструментов командной строки OpenSSL. Это полезно в ряде случаев, таких как выдача сертификата сервера для защиты вебсайта в интранете, или для выдачи сертификатов для клиентов, чтобы позволить им проверить подлинность сервера.
Pem (.pem, .crt, .cer) в pfx
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile more.crt
Разбивая команду:
openssl– команда для запуска OpenSSLpkcs12– файловая утилита для файлов PKCS # 12 в OpenSSL-export -out certificate.pfx– экспортировать и сохранить файл PFX как certificate.pfx-inkey privateKey.key– используйте файл закрытого ключа privateKey.key в качестве закрытого ключа для объединения с сертификатом.-in certificate.crt– используйте certificate.crt в качестве сертификата, с которым будет объединен закрытый ключ.-certfile more.crt– Это необязательно, это если у вас есть какие-либо дополнительные сертификаты, которые вы хотите включить в файл PFX.
После ввода команды вам будет предложено ввести и подтвердить пароль экспорта для защиты файла PFX. Запомни этот пароль! Он понадобится вам, когда вы захотите экспортировать сертификаты и ключ.
Pkcs # 7 / p7b (.p7b, .p7c) в pfx
Файлы P7B нельзя использовать для непосредственного создания файла PFX. Файлы P7B должны быть преобразованы в PEM. После преобразования в PEM выполните описанные выше шаги, чтобы создать файл PFX из файла PEM.
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.crt
Разбивая команду:
openssl– команда для запуска OpenSSLpkcs7– файловая утилита для файлов PKCS # 7 в OpenSSL-print_certs -in certificate.p7b– распечатывает все сертификаты или CRL, содержащиеся в файле.-out certificate.crt– вывести файл как certificate.crt
Windows
IE, Chrome — используют репозиторий сертификатов Windows.
Мой путь к нему таков:
Chrome — Settings — Manage Certificates…Выбрать таб Trusted Root Certificate Authorities — Import — rootCA.crtперезапустить Chrome
FireFox на виндоус имеет свой репозиторий.
Java имеет свой репозиторий.
В ubuntu
sudo mkdir /usr/share/ca-certificates/extra
sudo cp rootCA.crt /usr/share/ca-certificates/extra/rootCA.crt
sudo dpkg-reconfigure ca-certificates
sudo update-ca-certificates
Ипользование crl на сервере
Обычно серверное приложение (к примеру, Apache) делает проверку для клиентских сертификатов.Это приложение должно иметь локальный доступ до CRL.
В случае Алисы, она может добавить директиву SSLCARevocationPath в ее конфигурацию Apache и скопировать CRL на свой сервер. В следующий раз, когда Боб подключится к веб-серверу, Apache проверит его клиентский сертификат в CRL и запретит доступ. По аналогии, OpenVPN имеет директиву crl-verify, и можно блокировать клиентов, чьи сертификаты были отозваны.
Использование crl клиентами
Для серверных сертификатов, обычно клиентское приложение (к примеру, веб-браузер) выполняет проверку. Это приложение должно иметь удаленный доступ к CRL.
Если сертификат был подписан с расширением, которое включает crlDistributionPoints, клиентское приложение может прочитать эту информацию и получить CRL из указанного места.
Точки распространения CRL видны в спецификациях X509v3 сертификата.
Компиляция openssl библиотеки
После
и распаковки исходных текстов openssl в целевой директории выполняем команды:
./config
make
Получаем готовую библиотеку libcrypto.a в текущей директории.
Также потребуются заголовочные файлы из директорий engines/ccgost и include.
Компиляция privkey.c
gcc -o privkey -Iengines/ccgost -Iinclude privkey.c libcrypto.a -pthread -ldl
Настройка apache 2 для использования сертификатов
Переходим в каталог /etc/apache2:
root@shpc:/mnt# cd/etc/apache2/
Создаём каталог для хранения сертификатов:
root@shpc:/etc/apache2# mkdir ssl
Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:
a2enmod headers
Перезапускаем веб-сервер:
root@shpc:/etc/apache2# systemctl restart apache2Аналогично нужно включить поддержку заголовков:
Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:
root@shpc:/mnt# cd /etc/apache2/conf-available root@shpc:/etc/apache2/conf-available# nano ssl-params.conf
Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):
Далее созданный конфиг надо активировать:
root@shpc:/etc/apache2/conf-available# a2enconf ssl-paramsТеперь переходим в каталог /etc/apache2/sites-available:
root@shpc:/etc/apache2/conf-available# cd/etc/apache2/sites-available
И делаем на всякий случай резервные копии всех хранящихся там файлов:
root@shpc:/etc/apache2/sites-available# cp 000-default.conf 000-default.conf.bak root@shpc:/etc/apache2/sites-available# cp default-ssl.conf default-ssl.conf.bak
Теперь ещё раз проверяем подключённые модули headers и SSL:
Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:
root@shpc:/opt/simple_CA# cp ca.cer /etc/ssl/certs/ root@shpc:/opt/simple_CA# cp server.cer /etc/ssl/certs/server.crt root@shpc:/opt/simple_CA# cp server.key /etc/ssl/private/server.key
Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:
SSLCertificateFile /etc/ssl/certs/server.crt SSLCertificateKeyFile /etc/ssl/private/server.key SSLCACertificateFile /etc/ssl/certs/ca.cer
Теперь перезагружаем веб-сервер:
root@shpc:/etc/apache2# a2ensite default-ssl root@shpc:/etc/apache2/sites-available# service apache2 restart
Проверяем доступность сайта:
Видим, что Firefox не может проверить сертификат сайта. Чтобы смог, надо импортировать цепочку сертификатов, подтверждающих сертификат сервера, в список доверенных. Создадим цепочку:
root@shpc:/opt/simple_CA# openssl crl2pkcs7 -nocrl-certfile ca.cer -certfile server.cer -out serve-and-ca-chain.p7c -outform der
У полученного файла не забываем сменить атрибуты на 555:
root@shpc:/opt/simple_CA# chmod555 serve-and-ca-chain.p7c
Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):
Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:
Когда сертификаты добавлены в список доверенных, можно снова зайти на сайт и увидеть, что соединение помечается как доверенное:
Сейчас время настроить аутентификацию для клиентов.
Настройка аутентификации клиентов
Веб-сервер Apache поддерживает аутентификацию клиента. Это значит, что мы можем выписать клиенту сертификат SSL, а сервер сможет его проверить. Если у пользователя не будет сертификата — аутентификация не пройдёт. Для активации такой возможности надо добавить в конфиг default-ssl.conf такие опции:
SSLCACertificateFile /opt/simple_CA/ca.cer SSLVerifyClient require SSLVerifyDepth 2
После этого к сайту сможет подключиться только тот пользователь, сертификат которого:
- установлен в браузере, если клиентом является браузер, — тогда сертификат будет предъявлен при подключении к серверу;
- подписан сертификатом доверенного УЦ.
Сначала сгенерируем сертификат для клиента. Первым делом создаём ключ:
root@shpc:/opt/simple_CA# openssl genrsa -out client.key 4096
Затем на основе ключа сгенерируем CSR:
root@shpc:/opt/simple_CA# openssl req -new-key client.key -out client.req
Теперь на базе запроса сгенерируем сам сертификат:
root@shpc:/opt/simple_CA# openssl req -new-key client.key -out client.req
И импортируем сертификат в формате p12:
root@shpc:/opt/simple_CA# openssl pkcs12 -export-inkey client.key -in client.cer -out client.p12
В итоге у нас должен получиться файл client.p12. Нужно поменять права на файл, иначе сертификат не импортируется:
root@shpc:/opt/simple_CA# chmod555 client.p12
Теперь можно импортировать его в браузер по аналогии с корневыми сертификатами:
После импорта должно получиться примерно так:
После этого перезапускаем веб-сервер и возвращаемся на сайт. Видим окно выбора сертификата того пользователя, которого мы импортировали в браузер:
Общие преобразования pem
В приведенных ниже командах OpenSSL замените имена файлов ВСЕМИ ЗАГЛАВНЫМИ буквами фактическими путями и именами файлов, с которыми вы работаете.
Подготовка каталогов
Файлы корневого центра сертификации хранятся в /root/ca. Выберем каталог (/root/ca/intermediate) для хранения файлов промежуточного центра сертификации.
# mkdir /root/ca/intermediate
Создадим точно такую же структуру каталогов, которая используется для корневого центра сертификации. Также удобно создать каталог csr для хранения запросов на подпись сертификатов.
Подготовка конфигурационного файлы
Для использования OCSP центр сертификации должен закодировать расположение сервера OCSP в сертификат, который он подписывает. Используем опцию authorityInfoAccess в соответствующей секции, в нашем случае в секции server_cert.
Подготовка конфигурационных файлов
Необходимо создать конфигурационный файл для OpenSSL. Создадим файл /root/ca/openssl.cnf, скопируем в него следующее содержимое root-config.txt.Раздел [ca] является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела [CA_default]:
[ ca ]
#man ca
default_ca = CA_default
Раздел [CA_default] содержит ряд значений по умолчанию:
[ CA_default ]
# Directory and file locations.
dir = /root/ca
certs = $dir/certs
crl_dir = $dir/crl
new_certs_dir = $dir/newcerts
database = $dir/index.txt
serial = $dir/serial
RANDFILE = $dir/private/.rand
# The root key and root certificate.
private_key = $dir/private/ca.key.pem
certificate = $dir/certs/ca.cert.pem
# For certificate revocation lists.
crlnumber = $dir/crlnumber
crl = $dir/crl/ca.crl.pem
crl_extensions = crl_ext
default_crl_days = 30
# SHA-1 is deprecated, so use SHA-2 instead.
default_md = sha256
name_opt = ca_default
cert_opt = ca_default
default_days = 375
preserve = no
policy = policy_strict
Policy_strict будет применяться для всех подписей корневого центра сертификации, и корневой центр сертификации будет использоваться только для создания промежуточных центров сертификации.
[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of man ca.
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Применим policy_loose для всех подписей промежуточных центров серфтификации, так как промежуточные центры сертификации это подписывающие серверы, и клиентские сертификаты могут приходить от различных третьих лиц.
[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Параметры из секции [ req ] применяются когда создаются сертификаты или запросы на подписывание сертификатов.
[ req ]
# Options for the `req` tool (`man req`).
default_bits = 2048
distinguished_name = req_distinguished_name
string_mask = utf8only
# SHA-1 is deprecated, so use SHA-2 instead.
default_md = sha256
# Extension to add when the -x509 option is used.
x509_extensions = v3_ca
Секция [ req_distinguished_name ] определяет информацию, которая обычно требуется при запросе на подписывание сертификата. Можно указать некоторые значения по умолчанию.
Подготовка файла конфигурации
Когда центр сертификации подписывает сертификат, он обычно зашифровывает расположение CRL в сертификат. Добавляется crlDistributionPoints в подходящие секции. В нашем случае, добавляет к секции server_cert.
Подписывание серверного и клиентского сертификатов
Подпишем сертификаты используя наш промежуточный центр сертификации. Эти подписанные сертификаты можно использовать в различных ситуациях, таких как защищать соединения к веб серверу или аутентифицировать клиентов, присоединяющихся к сервису.
Указанные ниже шаги с вашей точки сзрения, где вы выступаете в качестве центра сертификации. Стороннее лицо, однако, вместо этого может создать свой собственный частный ключ и запрос на подпись сертификата (CSR) без раскрытия вам своего частного ключа. Они дают вам собственный CSR, а вы отдаете им подписанный сертификат. В этом случае, пропустите команды genrsa и req.
Пользуемся закрытым ключом private.key для подписывания файла file.txt
openssl cms -sign -inkey private.key -in file.txt -CAfile CA.cer -signer signer.cer -engine gost -out test.sign -outform DER -noattr -binary
Проверка корневого сертификата
# openssl x509 -noout -text -in certs/ca.cert.pem
Вывод показывает:
- Используемый алгоритм Signature Algorithm
- Даты периода действия сертификата Validity
- Длину публичного ключа Public-Key
- Эмитент сертификата Issuer, который является объектом, который подписал сертификат
- Предмет Subject, который относится к самому сертификату.
Эмитент (Issuer) и предмет (Subject) идентичны для самоподписанных сертификатов. Все корневые сертификаты являются самоподписанными.
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Validity
Not Before: Apr 11 12:22:58 2021 GMT
Not After : Apr 6 12:22:58 2035 GMT
Subject: C=GB, ST=England,
O=Alice Ltd, OU=Alice Ltd Certificate Authority,
CN=Alice Ltd Root CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Вывод также показывает расширения X509v3, т.к. было применено расширение v3_ca, и опции из секции [ v3_ca ] отражены в выводе.
X509v3 extensions:
X509v3 Subject Key Identifier:
38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Authority Key Identifier:
keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Проверка промежуточного сертификата
Как мы делали с корневым сертификатом, убедимся, что детали промежуточного сертификата корректны.
# openssl x509 -noout -text
-in intermediate/certs/intermediate.cert.pem
Сверим промежуточный сертификат с корневым сертификатом. ОК показывает, что цепочка доверия не повреждена.
# openssl verify -CAfile certs/ca.cert.pem
intermediate/certs/intermediate.cert.pem
intermediate.cert.pem: OK
Проверяем подпись
openssl cms -verify -content file.txt -in test.sign -CAfile CA.cer -signer signer.cer -engine gost -inform DER -noattr -binary
Все работает просто замечательно!
Спасибо за внимание. Это была моя первая статья на хабре.
Просмотр содержимого файла сертификата pem
openssl x509 -в CERTIFICATE.pem -text -noout
Просмотр содержимого файла сертификата в кодировке der
openssl x509 -inform der -in CERTIFICATE.der -text -noout
Разворачиваем собственный цс
Чтобы лучше понять все процессы, лежащие в основе PKI, рассмотрим на практике развёртывание небольшого ЦС на виртуальной машине под управлением Ubuntu 18 (без выхода в глобальную сеть). Мы не будем жёстко придерживаться правил и стандартов выдачи сертификатов — просто разберём работу с ними.
С учетом того, что. все эксперименты мы проводим в виртуальной среде (без выхода в глобальную сеть), мы можем использовать любое доменное имя — например www.simple.org. Однако надо помнить, что в глобальной сети такое имя вполне может быть зарегистрировано за каким-нибудь сайтом.
Расширения имени файла der
DER-кодированные файлы обычно находятся с расширениями .der и .cer.
Сборка утилиты конвертирования ключа
Далее сборка исходников описана для Linux версии.
Создаем сертификат подписаный нашим са
Генерируем ключ.
openssl genrsa -out server101.mycloud.key 2048
Создаем запрос на сертификат.
openssl req -new -key server101.mycloud.key -out server101.mycloud.csr
Тут важно указать имя сервера: домен или IP (например домен
server101.mycloud
Common Name (eg, YOUR name) []: server101.mycloud
и подписать запрос на сертификат нашим корневым сертификатом.
openssl x509 -req -in server101.mycloud.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server101.mycloud.crt -days 5000
Теперь на клиенты нужно установить корневой сертификат rootCA.crt
rootCA.crt — можно давать друзьям, устанавливать, копировать не сервера, выкладывать в публичный доступrootCA.key — следует держать в тайне
Создание crl
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf
-gencrl -out intermediate/crl/intermediate.crl.pem
Секция CRL OPTIONS в man ca содержит больше информации о том, как создавать CRL.
Можно проверить содержимое CRL с помощтю утилиты crl.
# openssl crl -in intermediate/crl/intermediate.crl.pem -noout –text
Пока еще не было отозванных сертификатов, поэтому в выводе указано:
No Revoked Certificates.
Необходимо пересоздавать CRL на регулярной основе. По умолчанию, CRL истекает через 30 дней. Это настраивается опцией default_crl_days в секции CA_default.
Создание ключа
Наши корневая и промежуточная пары 4096 бит. Серверный и клиентский сертификат обычно истекают после одного года, поэтому мы можем безопасно использовать 2048 бит.
Хотя 4096 бит немного больше безопаснее, чем 2048 бит, он замедляет TLS хэндшейки и значительно увеличивает нагрузку на процессор во время хэндшейков. По этой причине, большинство веб-сайтов используют 2048-битные пары ключей.
Если вы создаете криптографическую пару для использования веб-сервером (к примеру, Apache), вам потребуется вводить пароль каждый раз, когда вы перезапускаете веб-сервер. Вы можете указать опцию –aes256 для создания ключа без пароля.
Создание корневой пары ключей
Выступая в качестве центра сертификации (CA) означает иметь дело с криптографическими парами приватных (частных) ключей и публичными сертификатами. Самой первой криптографической парой создадим корневую пару. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует идентичность нашего центра сертификации.
Как правило, корневой центр сертификации не подписывает напрямую серверные или клиентские сертификаты. Корневой центр сертификации используется только для создания одного или нескольких промежуточных центров сертификации, которые являются доверенными корневому центру сертификации чтоб подписывать сертификаты от их имени.
Это является лучшей практикой. Таким образом, корневой ключ может хранится «оффлайн» и по-максимому не использоваться, так как любая компрометация губительна для ключа. В качестве примера лучшей практики является создание корневой пары в максимально защищенной среде.
Создание пары ocsp
Ответчик OCSP нуждается в криптографической паре для подписывания ответа, который посылается запрашивающей стороне. Криптографическая пара OCSP должна быть подписана на том же центре сертификации, на котором проверяется подписанный сертификат.
Создадим частный ключ и зашифруем его алгоритмом AES-256.
Создание промежуточного ключа
Создадим промежуточный ключ (intermediate.key.pem). Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем.
# cd /root/ca
# openssl genrsa -aes256
-out intermediate/private/intermediate.key.pem 4096
Enter pass phrase for intermediate.key.pem: secretpassword
Verifying - Enter pass phrase for intermediate.key.pem: secretpassword
# chmod 400 intermediate/private/intermediate.key.pem
Создание промежуточного сертификата
Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци (intermediate/openssl.cnf).
# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256
-key intermediate/private/intermediate.key.pem
-out intermediate/csr/intermediate.csr.pem
Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Intermediate CA
Email Address []:
Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением v3_intermediate_ca для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации (/root/ca/openssl.cnf).
# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca
-days 3650 -notext -md sha256
-in intermediate/csr/intermediate.csr.pem
-out intermediate/certs/intermediate.cert.pem
Enter pass phrase for ca.key.pem: secretpassword
Sign the certificate? [y/n]: y
# chmod 444 intermediate/certs/intermediate.cert.pem
Для хранения базы данных сертификатов, выданных утилитой ca OpenSSL, используется файл index.txt. Не следует удалять или править вручную этот файл. Сейчас он должен содержать одну строку, которая относится к промежуточному сертификату.
V 250408122707Z 1000 unknown … /CN=Alice Ltd Intermediate CA
Создание промежуточной пары ключей
Промежуточным центомр сертификации является объект, который может подписывать сертификаты от имени корневого центра сертификации. Корневой центр сертификации подписывает промежуточный сертификат, образуя цепочку доверия.
Цель использования промежуточного центра сертификации, прежде всего, для обеспечения безопасности. Корневой ключ должен храниться «оффлайн» и использоваться как можно реже. Если промежуточный ключ будет скомпрометирован, корневой центр сертификации может отозвать промежуточный сертификат и создать новую промежуточную криптографическую пару.
Установка сертификата
Теперь можно установить новый сертификат на сервере, или распространить сертификат на клиентов. При установке на серверное приложение (к примеру, Apache), понадобятся следующие файлы:
Файл header.key
Из этого файла нам потребуется параметры электронной подписи CryptoProParamSet (подчеркнуто красным).
А также первые 8 байт открытого ключа (подчеркнуто) для контроля правильности чтения закрытого.
Файл masks.key
Содержит 32 байта маски ключа в формате Asn1, зашифрованного на ключе хранения pwd_key. Далее 12 байт «затравочной» информации для генерации ключа хранения pwd_key, если криптоконтейнер защищен паролем, то пароль также участвует в генерации ключа хранения.
Далее контрольная сумма (имитозащита) 4 байта. Контрольной информацией для простоты мы пользоваться не будем, общий контроль будет осуществляться путем генерации открытого ключа и сравнения первых 8 байт полученного ключа с соответствующим полем из файла header.key:
Файл primary.key
Содержит 32 байта ключа в формате Asn1. Это только половина ключа, полный ключ получается при делении этого числа по модулю Q на маску. Поле, хранящее модуль Q в библиотеке OpenSSL имеет название order. Маска лежит в файле masks.key:
Формирование файла закрытого ключа private.key
./privkey /mnt/usbflash/lp-9a0fe.000
Тестовый закрытый ключ в криптоконтейнере lp-9a0fe.000, сертификат открытого ключа signer.cer и другие файлы для тестирования можно
Получаем результат работы:
-----BEGIN PRIVATE KEY-----
MEYCAQAwHAYGKoUDAgITMBIGByqFAwICJAAGByqFAwICHgEEIwIhAKzsrv/l1Uwk
uzph/LQN9mux0Jz0yaW21kOYEFv0Xyut
-----END PRIVATE KEY-----
Cохраняем в private.key
Центры сертификации: как они используются
Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи. Логику работы ЦС, как правило, можно описать тезисом «никто не доверяет друг другу, но все доверяют ЦС».
Допустим, условная сущность Аlice имеет сертификат, подписанный ЦС Comp, а сущность Bob пытается проверить подлинность этого сертификата. Проверка будет успешной, если Bob и Alice доверяют одному и тому же ЦС. Для решения такой проблемы в ОС Alice и ОС Bob установлено множество сертификатов различных ЦС.
Читаем закрытый ключ и конвертируем
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <openssl/pem.h>
#include <openssl/cms.h>
#include <openssl/err.h>
#include "gost_lcl.h"
/* Convert little-endian byte array into bignum */
BIGNUM *reverse32bn(char *b, BN_CTX *ctx)
{
BIGNUM *res;
char buf[32];
BUF_reverse(buf, b, 32);
res = BN_bin2bn(buf, 32, BN_CTX_get(ctx));
OPENSSL_cleanse(buf, sizeof(buf));
return res;
}
void xor_material(char *buf36, char *buf5C, char *src)
{
int i;
for(i = 0; i < 32; i )
{
buf36[i] = src[i] ^ 0x36;
buf5C[i] = src[i] ^ 0x5C;
}
}
int make_pwd_key(char *result_key, char *start12, int start12_len, char *passw)
{
int result;
int i;
char pincode4[1024];
int pin_len;
char current[32];
char material36[32];
char material5C[32];
char hash_result[32];
gost_hash_ctx ctx;
init_gost_hash_ctx(&ctx, &GostR3411_94_CryptoProParamSet);
memset(pincode4, 0, sizeof(pincode4));
pin_len = strlen(passw);
if (pin_len*4 > sizeof(pincode4)) { result = 1; goto err; }
for(i = 0; i < pin_len; i )
pincode4[i*4] = passw[i];
start_hash(&ctx);
hash_block(&ctx, start12, start12_len);
if (pin_len)
hash_block(&ctx, pincode4, pin_len * 4);
finish_hash(&ctx, hash_result);
memcpy(current, (char*)"DENEFH028.760246785.IUEFHWUIO.EF", 32);
for(i = 0; i < (pin_len?2000:2); i )
{
xor_material(material36, material5C, current);
start_hash(&ctx);
hash_block(&ctx, material36, 32);
hash_block(&ctx, hash_result, 32);
hash_block(&ctx, material5C, 32);
hash_block(&ctx, hash_result, 32);
finish_hash(&ctx, current);
}
xor_material(material36, material5C, current);
start_hash(&ctx);
hash_block(&ctx, material36, 32);
hash_block(&ctx, start12, start12_len);
hash_block(&ctx, material5C, 32);
if (pin_len)
hash_block(&ctx, pincode4, pin_len * 4);
finish_hash(&ctx, current);
start_hash(&ctx);
hash_block(&ctx, current, 32);
finish_hash(&ctx, result_key);
result = 0; //ok
err:
return result;
}
BIGNUM *decode_primary_key(char *pwd_key, char *primary_key, BN_CTX *bn_ctx)
{
BIGNUM *res;
char buf[32];
gost_ctx ctx;
gost_init(&ctx, gost_cipher_list->sblock);
gost_key(&ctx, pwd_key);
gost_dec(&ctx, primary_key, buf, 4);
res = reverse32bn(buf, bn_ctx);
OPENSSL_cleanse(buf, sizeof(buf));
return res;
}
BIGNUM *remove_mask_and_check_public(char *oid_param_set8, BIGNUM *key_with_mask, BIGNUM *mask, char *public8, BN_CTX *ctx)
{
int result;
EC_KEY *eckey = NULL;
const EC_POINT *pubkey;
const EC_GROUP *group;
BIGNUM *X, *Y, *order, *raw_secret, *mask_inv;
char outbuf[32], public_X[32];
ASN1_OBJECT *obj;
int nid;
order = BN_CTX_get(ctx);
mask_inv = BN_CTX_get(ctx);
raw_secret = BN_CTX_get(ctx);
X = BN_CTX_get(ctx);
Y = BN_CTX_get(ctx);
if (!order || !mask_inv || !raw_secret || !X || !Y) { result = 1; goto err; }
obj = ASN1_OBJECT_create(0, oid_param_set8 1, *oid_param_set8, NULL, NULL);
nid = OBJ_obj2nid(obj);
ASN1_OBJECT_free(obj);
if (!(eckey = EC_KEY_new())) { result = 1; goto err; }
if (!fill_GOST2001_params(eckey, nid)) { result = 1; goto err; }
if (!(group = EC_KEY_get0_group(eckey))) { result = 1; goto err; }
if (!EC_GROUP_get_order(group, order, ctx)) { result = 1; goto err; }
if (!BN_mod_inverse(mask_inv, mask, order, ctx)) { result = 1; goto err; }
if (!BN_mod_mul(raw_secret, key_with_mask, mask_inv, order, ctx)) { result = 1; goto err; }
if (!EC_KEY_set_private_key(eckey, raw_secret)) { result = 1; goto err; }
if (!gost2001_compute_public(eckey)) { result = 1; goto err; }
if (!(pubkey = EC_KEY_get0_public_key(eckey))) { result = 1; goto err; }
if (!EC_POINT_get_affine_coordinates_GFp(group, pubkey, X, Y, ctx)) { result = 1; goto err; }
store_bignum(X, outbuf, sizeof(outbuf));
BUF_reverse(public_X, outbuf, sizeof(outbuf));
if (memcmp(public_X, public8, 8) != 0) { result = 1; goto err; }
result = 0; //ok
err:
if (eckey) EC_KEY_free(eckey);
if (result == 0) return raw_secret;
return NULL;
}
int file_length(char *fname)
{
int len;
FILE *f = fopen(fname, "rb");
if (f == NULL) return -1;
fseek(f, 0, SEEK_END);
len = ftell(f);
fclose(f);
return len;
}
int read_file(char *fname, int start_pos, char *buf, int len)
{
int read_len;
FILE *f = fopen(fname, "rb");
if (f == NULL) return 1;
if (start_pos) fseek(f, start_pos, SEEK_SET);
read_len = fread(buf, 1, len, f);
fclose(f);
if (read_len != len) return 1;
return 0; //ok
}
int get_asn1_len(unsigned char *buf, int *size_hdr)
{
int n, i, res;
int pos = 0;
if ((buf[pos]&0x80) == 0) {
*size_hdr = 1;
return buf[pos];
}
n = buf[pos ]&0x7f;
res = 0;
for(i = 0; i < n; i ) {
res = res*256 buf[pos ];
}
*size_hdr = n 1;
return res;
}
#define MAX_HEADER 20000
int read_container(char *fpath, int flag2, char *salt12, char *primary_key, char *masks_key, char *public8, char *oid_param_set8)
{
int result;
char primary_path[1024 30];
char masks_path[1024 30];
char header_path[1024 30];
char header_buf[MAX_HEADER];
int header_len;
int i, len, pos, size_hdr;
if (strlen(fpath)>1024) { result = 1; goto err; }
sprintf(header_path, "%s/header.key", fpath);
if (flag2 == 0)
{
sprintf(primary_path, "%s/primary.key", fpath);
sprintf(masks_path, "%s/masks.key", fpath);
}
else
{
sprintf(primary_path, "%s/primary2.key", fpath);
sprintf(masks_path, "%s/masks2.key", fpath);
}
if (read_file(primary_path, 4, primary_key, 32)) { result = 1; goto err; }
if (read_file(masks_path, 4, masks_key, 32)) { result = 1; goto err; }
if (read_file(masks_path, 0x26, salt12, 12)) { result = 1; goto err; }
header_len = file_length(header_path);
if (header_len < 0x42 || header_len > MAX_HEADER) { result = 1; goto err; }
if (read_file(header_path, 0, header_buf, header_len)) { result = 1; goto err; }
//------------- skip certificate ---------------------------
pos = 0;
for(i = 0; i < 2; i )
{
get_asn1_len(header_buf pos 1, &size_hdr);
pos = size_hdr 1;
if (pos > header_len-8) { result = 2; goto err; }
}
//------------------ get oid_param_set8 -----------------------
#define PARAM_SET_POS 34
if (memcmp(header_buf pos PARAM_SET_POS, "x6x7", 2) != 0) { result = 2; goto err; }
memcpy(oid_param_set8, header_buf pos PARAM_SET_POS 1, 8);
//------------------ get public8 -----------------------
result = 2; //not found
pos = 52;
for(i = 0; i < 3; i )
{
len = get_asn1_len(header_buf pos 1, &size_hdr);
if (len == 8 && memcmp(header_buf pos, "x8ax8", 2) == 0)
{
memcpy(public8,header_buf pos 2,8);
result = 0; //ok
break;
}
pos = len size_hdr 1;
if (pos > header_len-8) { result = 2; goto err; }
}
err:
OPENSSL_cleanse(header_buf, sizeof(header_buf));
return result;
}
#define START_OID 0x12
#define START_KEY 0x28
unsigned char asn1_private_key[72] = {
0x30,0x46,2,1,0,0x30,0x1c,6,6,0x2a,0x85,3,2,2,0x13,0x30,0x12,6,7,0x11,
0x11,0x11,0x11,0x11,0x11,0x11,6,7,0x2a,0x85,3,2,2,0x1e,1,4,0x23,2,0x21,0
};
int main(int argc, char **argv)
{
int result;
char *container_path;
char *passw;
char salt12[12];
char primary_key[32];
char masks_key[32];
char public8[8];
char oid_param_set8[8];
BN_CTX *ctx;
BIGNUM *key_with_mask;
BIGNUM *mask;
BIGNUM *raw_key;
char pwd_key[32];
char outbuf[32];
ctx = BN_CTX_new();
if (argc == 2)
{
container_path = argv[1];
passw = "";
}
else
if (argc == 3)
{
container_path = argv[1];
passw = argv[2];
}
else
{
printf("get_private container_path [passw]n");
result = 1;
goto err;
}
if (read_container(container_path, 0, salt12, primary_key, masks_key, public8, oid_param_set8) != 0 &&
read_container(container_path, 1, salt12, primary_key, masks_key, public8, oid_param_set8) != 0)
{
printf("can not read container from %sn", container_path);
result = 2;
goto err;
}
make_pwd_key(pwd_key, salt12, 12, passw);
key_with_mask = decode_primary_key(pwd_key, primary_key, ctx);
OPENSSL_cleanse(pwd_key, sizeof(pwd_key));
mask = reverse32bn(masks_key, ctx);
raw_key = remove_mask_and_check_public(oid_param_set8, key_with_mask, mask, public8, ctx);
if (raw_key)
{
BIO *bio;
store_bignum(raw_key, outbuf, sizeof(outbuf));
memcpy(asn1_private_key START_OID, oid_param_set8, 8);
memcpy(asn1_private_key START_KEY, outbuf, 32);
//bio = BIO_new_file("private.key", "w");
bio = BIO_new_fp(stdout, BIO_NOCLOSE | BIO_FP_TEXT);
PEM_write_bio(bio, "PRIVATE KEY", "", asn1_private_key, sizeof(asn1_private_key));
BIO_free(bio);
OPENSSL_cleanse(outbuf, sizeof(outbuf));
OPENSSL_cleanse(asn1_private_key, sizeof(asn1_private_key));
result = 0; //ok
}
else
{
printf("Error check public keyn");
result = 3;
}
err:
BN_CTX_free(ctx);
OPENSSL_cleanse(salt12, sizeof(salt12));
OPENSSL_cleanse(primary_key, sizeof(primary_key));
OPENSSL_cleanse(masks_key, sizeof(masks_key));
return result;
}
Списки отзывов сертификатов
Списки отзывов сертификатов (CRL) предоставляют список сертификатов, которые были отозваны. Клиентское приложение, к примеру, веб-браузер, может использовать CRL для проверки подлинности сервера. Серверные приложения, такие как Apache или OpenVPN, могут использовать CRL для запрета доступа клиентам, которые больше не являются доверенными.
Отзыв сертификата
Утилита OpenSSL ocsp может выступать в качестве ответчика OCSP, но она предназначена только для тестирования. Для производственной среды OCSP ответчики тоже существуют, но они выходят за рамки данной статьи.
Создадим серверный сертификат для тестирования.
