Создание центра сертификации электронных ключей на базе Ubuntu
1. Что такое электронные ключи, сертификаты, и зачем нужен центр сертификации электронных ключей
Электронный ключ - это просто очень большое, предположительно, уникальное число. (Порядок великости - нууу, примерно как отсюда до центра вселенной и обратно. Повторить несколько тысяч миллионов раз - это будет примерно одна триллионная возможных значений. В общем - дофига.) Или вы можете просто считать его набором битов, длиной от 512 до 4096 бит. Чем он, по сути, и является.
Электронные ключи применяются для защиты каналов связи, шифрования переписки и других данных, подписывания документов и исполнимого кода программ... И это только небольшая часть применения электронных ключей, хотя во многих случаях всё разнообразие способов использования можно свести к трём основным: шифрование данных, подписывание данных, аутентификация участника.
Сертификат ключа электронной подписи - это электронный (же) документ, утверждающий право владельца соответствующего электронного ключа на совершение этим ключом определённых действий. Например, на подписывание документов.
Центр сертификации (Certificate Authority) - это система, позволяющая создавать, распределять и управлять сертификатами электронных ключей.
Как вы можете заключить из вышеизложенного, Центр сертификации - штука важная и ответственная. Поэтому не удивляйтесь, что некоторые рекомендации и требования в этой статье выглядят завышенными. Это не требования завышены - это у вас оценка серьёзности предприятия занижена.
$Id: SSL-CA-HOW-TO-1-Why-CA.txt 315 2015-09-18 09:45:01Z anrdaemon $
2. Подготовительные работы
По-хорошему (или, "в идеальном случае..."), под Центр Сертификации желательно отдать отдельную машину, доступ к которой будет физически ограничен строго определённым кругом лиц. В серьёзных центрах сертификации так и поступают.
Зачастую, такая машина даже к локальной сети здания не подключена, не то что к Интернету... У нас, к счастью (или к сожалению), требования не столь жёсткие, так что постараемся обойтись наличными средствами.
2.1. Наличное средство №1: Строго изолированное рабочее пространство.
Пусть у нас нет отдельного физического сервера, это не означает, что мы можем радостно свалить всю структуру CA в /etc/ на первом подходящем компе и спать спокойно.
Варианты выхода из положения могут быть следующими:
а) Виртуальный выделенный сервер. Внимательно выбирайте, что и куда вы ставите. Решения, пригодные для VPS (такие, как OpenVZ) тут НЕ ГОДЯТСЯ - к диску контейнера OpenVZ можно тривиально получить доступ с консоли несущего сервера в обход любых возможных ограничений самого контейнера.
б) Зашифрованный домашний каталог отдельного пользователя. Вероятно, оптимальное решение, но я мало знаком с этой технологией.
в) Расположение CA на внешнем хранилище (например, на Flash-диске). Помимо находящейся под большим вопросом надёжности, этот способ вполне заслуживает внимания.
г) Гибрид указанных способов. Например, хранение на внешнем носителе только главного ключа системы, либо только пароля к нему.
Вы как хотите, а я буду использовать виртуальную машину (в частности, VirtualBox) для создания фиктивного "отдельно стоящего железа". (Во-первых, я с ним хорошо знаком, во-вторых - он у меня уже есть.)
Выгодой такого подхода является почти моментальный перенос "сервера" с места на место, при необходимости я даже могу запускать систему с общего ресурса, находящегося в сети. Скорость будет так себе, но мы же никуда не опаздываем, верно?
Надеюсь, с установкой Ubuntu server под VirtualBox вы справитесь без меня?
Не забудьте поставить (убедиться, что они поставлены) пакеты pwgen, openssl и openssh-server.
2.2. Наличное средство номер #2: Технологический пользователь для пользования полезняшками.
Это всегда хорошая идея - создать отдельного пользователя в системе для выполнения высоко ответственного, строго ограниченного круга задач.
Банальное обслуживание системы может производиться десятком операторов, это нормально. Управление главным центром сертификации должно быть возможно более обособлено. Отсюда же следует, что давать этому пользователю права sudo НЕ НАДО. Он без них нормально проживёт, и вам меньше геморроя.
Один sudo пользователь в системе уже есть - вы. Этого достаточно. Если этого НЕ достаточно, побейтесь об стену головой. Чем больше людей имеет доступ к системе CA, тем больше вероятность её компрометации, либо банального сбоя.
Создаём нового пользователя:
$ sudo -E -s
[sudo] password for anrdaemon: <*****>
# useradd -c "OpenSSL CA administrator" --home /home/.CA --shell /bin/bash --no-user-group --groups ssl-cert,www-data --create-home -p $(pwgen -scn 20) minica
#Обратите внимание, что пароль мы задаём в формате, отличном от ожидаемого командой useradd. Таким образом, по паролю мы этим пользователем войти в систему не сможем.
Но - оно нам надо? Сразу скажу - нет, не надо.
Сделаем одну значительную поправку - исправим права на домашний каталог и маску прав по умолчанию для вновь создаваемых пользователем файлов.
# chmod -R g=X,o= /home/.CA
(Обратите внимание, следующая строчка без -R !!)
# chmod o=X /home/.CA
# nano /home/.CA/.profileВозле самого начала файла находится закомментированная строка "umask 022"
Под ней, на новой строчке напишите
umask 0066
И сохраните файл (Ctrl+O, Ctrl+X)
Это предотвратит создание новых файлов с черезчур обширными правами доступа.
Теперь нам надо поработать под новым пользователем.
# sudo -u minica -i
$ pwd
/home/.CA
$Сейчас мы под именем
minica находимся в домашнем каталоге пользователя minica.
Конечно, мы не будем постоянно так делать. Мы поступим проще и скромнее.
Создадим ключ для SSH (ОБЯЗАТЕЛЬНО задайте пароль!):
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/.CA/.ssh/id_rsa):
Created directory '/home/.CA/.ssh'.
Enter passphrase (empty for no passphrase): <myveryownca>
Enter same passphrase again: <myveryownca>
Your identification has been saved in /home/.CA/.ssh/id_rsa.
Your public key has been saved in /home/.CA/.ssh/id_rsa.pub.
The key fingerprint is:
d4:fe:f3:97:f4:10:2d:44:38:29:86:c9:40:a5:a3:b1 sslca@daemon-v5
$Как вежливо со стороны генератора ключей поставить нас в известность о точном местоположении созданных файлов. Воспользуемся этим:
$ cp /home/.CA/.ssh/id_rsa.pub /home/.CA/.ssh/authorized_keys
$ exit
# cp /home/.CA/.ssh/id_rsa ~/.ssh/minica-rsa.key
# chown $SUDO_USER ~/.ssh/minica-rsa.key
#Можно попробовать сразу и подключиться.
# ssh -i /home/anrdaemon/.ssh/minica-rsa.key minica@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is bf:d0:fe:cd:b1:cf:7d:93:61:00:c1:d9:9e:2f:6f:2f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
Enter passphrase for key '/home/anrdaemon/.ssh/minica.rsa': <myveryownca>
Linux daemon-v5 2.6.24-31-server #1 SMP Fri Apr 27 21:31:40 UTC 2012 i686
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
$ exit
#Работает?! Работает. Выходим из терминала. Совсем выходим.
# exit
$ exitТеперь можно скачать ключ себе на машину и подключиться уже по-нормальному под нужным пользователем. Для Linux это будет что-то вроде:
$ scp username@daemon-v5:/home/profile/.ssh/minica-rsa.key ~/.ssh/minica-rsa.key
$ ssh -i ~/.ssh/minica-rsa.key minica@daemon-v5Для Windows - сами сообразите, десять лет окошками пользуетесь, небось, научились.
$Id: SSL-CA-HOW-TO-2-Preparations.txt 315 2015-09-18 09:45:01Z anrdaemon $
3. Настройка рабочего места
Предыдущую главу мы закончили на том, что подключились к серверу под именем нашего CA-администратора.
$ ssh -i ~/.ssh/minica-rsa.key minica@daemon-v5Сейчас нам необходимо создать несколько каталогов и создать/отредактировать несколько файлов.
Начнём с простого - установка одной переменной и создание каталогов и файлов.
$ export OPENSSL_CONF=${HOME}/ca.conf
$ mkdir -p ~/bin ~/archive ~/store/keys ~/tmpВ
~/bin мы будем держать наши скрипты.
В
~/archive будут находиться все когда-либо выданные нашим центром сертификаты.
В
~/tmp мы будем складывать временные данные.
В
~/store будем хранить запросы и сертификаты.
В
~/store/keys будем хранить ключи.
$ touch -f ~/.rnd ~/oid_list.txt ~/certdb.txt
$ echo "01" > ~/.certserial
$ echo "01" > ~/.crlserialФайл
~/.rnd используется при работе генератора ключей.
В
~/oid_list.txt хранятся описания идентификаторов объектов (назначений) сертификатов.
В
~/certdb.txt ведётся база сертификатов (время выдачи, статус, время отзыва - и так далее).
Файл
~/.certserial содержит порядковый номер следующего сертификата.
Файл
~/.crlserial содержит порядковый номер следующего списка отзыва.
Продолжим наши мытарства. Добавим несколько переменных, чтобы программы знали, где искать настройки.
$ nano ~/.profileЭтот файл мы уже видели. Сразу после добавленной ранее строчки напишите
export OPENSSL_CONF=${HOME}/ca.conf
export TMPDIR=${HOME}/tmp
и сохраните файл (Ctrl+O, Ctrl+X)
Переменная
OPENSSL_CONF указывает на файл с настройками openssl, мы её выставили раньше вручную, так что перезаходить на сервер сейчас нет нужды.
Переменная
TMPDIR используется для поиска места, в котором должны создаваться временные файлы (например, командой mktemp).
$Id: SSL-CA-HOW-TO-3-Configuration.txt 315 2015-09-18 09:45:01Z anrdaemon $
4. Создание конфигурации центра сертификации.
Откройте файл настроек на редактирование.
$ nano $OPENSSL_CONFи скопируйте в него этот текст:
--- BEGIN ca.conf ---
# Переменные для предотвращения ошибок выполнения команд
# Если соответствующие переменные почему-то не определены при старте openssl,
# их значения будут взяты отсюда.
HOME = /home/.CA
TMPDIR = ${ENV::HOME}/tmp
# Адрес сайта, распространяющего сертификаты и списки отзыва.
# Всегда HTTPS.
MCA_WEBSITE = ca.example.org
# Настройки, которые вам вряд ли понадобится менять.
MCA_KEYLEN = 2048
MCA_KEYAGE = 366
# Невозможно из командной строки указать subjectAltName
# Приходится извращаться. Смотри комментарии в x509_base.
SSLSAN = email:copy
[ ca ]
default_ca = org1
# Наш центр сертификации по умолчанию
[ org1 ]
RANDFILE = ${ENV::HOME}/.rnd
# Ссылки на сертификат центра и закрытый ключ центра.
certificate = ${ENV::HOME}/ca.crt
private_key = ${ENV::HOME}/ca.key
# Расположение архива выдаваемых сертификатов
new_certs_dir = ${ENV::HOME}/archive
# Расположение служебных файлов
oid_file = ${ENV::HOME}/oid_list.txt
database = ${ENV::HOME}/certdb.txt
serial = ${ENV::HOME}/.certserial
crlnumber = ${ENV::HOME}/.crlserial
# Параметры по умолчанию для выдаваемых сертификатов
default_days = ${ENV::MCA_KEYAGE}
default_crl_days = 31
default_md = sha512
unique_subject = no
preserve = no
email_in_dn = no
#name_opt
#cert_opt
copy_extensions = copy
# Расширения, добавляемые по умолчанию при создании нового сертификата
x509_extensions = x509_client
# Расширения, добавляемые по умолчанию при создании нового списка отзыва
crl_extensions = org1_CRLext
# Политики создания запросов.
policy = org1_policy
# Параметры по умолчанию для запроса сертификатов
[ req ]
# Ссылки на служебные файлы из нашего CA - они все те же самые
oid_file = ${org1::oid_file}
default_bits = ${ENV::MCA_KEYLEN}
RANDFILE = ${org1::RANDFILE}
default_md = ${org1::default_md}
# Установление ограничений на содержимое строковых переменных.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# В нашем случае, ввод ограничен только печатными ASCII символами.
# Для включения полной поддержки UTF-8 придётся немного допилить всю систему,
# это можно сделать и позже.
string_mask = nombstr
#prompt = no
#utf8 = yes
# Расширения, добавляемые к сертификатам при создании запроса/нового сертификата
x509_extensions = x509_client
req_extensions = x509_client_req
# Уникальное имя для генерации сертификата
distinguished_name = org1_dn
attributes = org1_attr
# Общие параметры X.509 сертификата.
# Мы будем использовать их как шаблон для создания реальных сертификатов.
[ x509_base ]
# Базовые свойства сертификата.
# Критическое расширение, имееющее два параметра:
# CA - true/false - может ли этот сертификат выступать в роли подписывающего
# для других сертификатов
# pathlen - число - количество "старших" сертификатов, при превышении которого
# сертификат считается ошибочным.
#basicConstraints = critical, CA:FALSE, pathlen:0
# keyUsage - Основное направление использования сертификата.
# Определяет предназначение (например, шифрование данных, подписывание
# сообщений, подписывание сертификатов) ключа, содержащегося в сертификате.
# Ограничения использования могут быть применены, если ключ, содержащийся в
# сертификате, может быть использован для разных операций.
# Подробности:
# http://tools.ietf.org/html/rfc5280#section-4.2.1.3
# The Key Usage extension in X.509 Public Key Infrastructure Certificate
#
# http://tools.ietf.org/html/rfc3279#section-2.3.1
# http://tools.ietf.org/html/rfc4055#section-1.2
# RSA and RSA-based keys usage
#
# http://tools.ietf.org/html/rfc3279#section-2.3.2
# http://tools.ietf.org/html/rfc5758
# DSA and ECDSA keys
#
# http://tools.ietf.org/html/rfc4491#section-2.3
# GOST keys usage
#
# Возможные значения - список из
# digitalSignature, nonRepudiation, keyEncipherment,
# dataEncipherment, keyAgreement, keyCertSign, cRLSign,
# encipherOnly and decipherOnly
#
# Например, такой сертификат будет пригоден для клиент-серверной идентификации
#keyUsage = critical, digitalSignature, dataEncipherment
# extendedKeyUsage - Более точное описание ограничений применения ключа.
# Может содержать OID'ы по именам, либо по номерам.
# Список часто используемых OID:
#
# serverAuth SSL/TLS Web Server Authentication.
# clientAuth SSL/TLS Web Client Authentication.
# codeSigning Executable code signing.
# emailProtection E-mail Protection (S/MIME).
# timeStamping Trusted Timestamping
# msCodeInd Microsoft Individual Code Signing (authenticode)
# msCodeCom Microsoft Commercial Code Signing (authenticode)
# msCTLSign Microsoft Trust List Signing
# msSGC Microsoft Server Gated Crypto
# msEFS Microsoft Encrypted File System
# nsSGC Netscape Server Gated Crypto
#
# Например, этот сертификат может быть использован при идентификации
# веб-сервера и защите электронной переписки.
#extendedKeyUsage = serverAuth, emailProtection
# Некоторые технические параметры создаваемого сертификата
subjectKeyIdentifier = hash
# Как уже было сказано, нельзя в командной строке передать значение
# subjectAltName при создании запроса на сертификацию ключа.
# Но можно использовать значение переменной для заполнения параметра
# конфигурации! И можно задать значение по умолчанию для такой переменной.
# Что мы тут благополучно и проделали.
subjectAltName = ${ENV::SSLSAN}
# Параметры представления подписывающего сертификата в выдаваемом клиентском
# сертификате
authorityKeyIdentifier = keyid:always,issuer:always
issuerAltName = issuer:copy
# Контактная информация источника сертификатов и адрес списков отзыва.
# Отсутствие ENV:: - не ошибка.
# Важно: Оба файла должны быть в DER-кодировке. Не PEM!
authorityInfoAccess = caIssuers;URI:https://${MCA_WEBSITE}/ca.cer
crlDistributionPoints = URI:https://${MCA_WEBSITE}/ca.crl
# Расширения для создания главного сертификата CA
[ x509_ca ]
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, keyCertSign, cRLSign
#extendedKeyUsage =
subjectKeyIdentifier = ${x509_base::subjectKeyIdentifier}
subjectAltName = ${x509_base::subjectAltName}
authorityKeyIdentifier = ${x509_base::authorityKeyIdentifier}
issuerAltName = ${x509_base::issuerAltName}
authorityInfoAccess = ${x509_base::authorityInfoAccess}
crlDistributionPoints = ${x509_base::crlDistributionPoints}
## Расширения для создания сертификата сервера
#
# Важно понимать разницу между расширениями для создания сертификата и
# расширениями для создания запроса.
#
# Расширения для создания запроса задают значения по умолчанию, которые могут
# быть переопределены пользователем, создающим запрос.
#
# Расширения для создания сертификата задают КОНКРЕТНЫЕ ЗНАЧЕНИЯ полей,
# включаемых в сертификат.
#
# Не надо включать в расширения создания сертификата поля, задаваемые
# пользователем при формировании запроса.
#
[ x509_server ]
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth, emailProtection
subjectKeyIdentifier = ${x509_base::subjectKeyIdentifier}
authorityKeyIdentifier = ${x509_base::authorityKeyIdentifier}
issuerAltName = ${x509_base::issuerAltName}
authorityInfoAccess = ${x509_base::authorityInfoAccess}
crlDistributionPoints = ${x509_base::crlDistributionPoints}
# Расширения для запроса сертификата сервера
[ x509_server_req ]
basicConstraints = ${x509_server::basicConstraints}
keyUsage = ${x509_server::keyUsage}
extendedKeyUsage = ${x509_server::extendedKeyUsage}
subjectKeyIdentifier = ${x509_server::subjectKeyIdentifier}
subjectAltName = ${x509_base::subjectAltName}
# Расширения для создания сертификата клиента
[ x509_client ]
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature, nonRepudiation, dataEncipherment
extendedKeyUsage = clientAuth, emailProtection, codeSigning
subjectKeyIdentifier = ${x509_base::subjectKeyIdentifier}
authorityKeyIdentifier = ${x509_base::authorityKeyIdentifier}
issuerAltName = ${x509_base::issuerAltName}
authorityInfoAccess = ${x509_base::authorityInfoAccess}
crlDistributionPoints = ${x509_base::crlDistributionPoints}
# Расширения для запроса сертификата клиента
[ x509_client_req ]
basicConstraints = ${x509_client::basicConstraints}
keyUsage = ${x509_client::keyUsage}
extendedKeyUsage = ${x509_client::extendedKeyUsage}
subjectKeyIdentifier = ${x509_client::subjectKeyIdentifier}
subjectAltName = ${x509_base::subjectAltName}
[ org1_CRLext ]
authorityKeyIdentifier=${x509_base::authorityKeyIdentifier}
authorityInfoAccess = ${x509_base::authorityInfoAccess}
crlDistributionPoints = ${x509_base::crlDistributionPoints}
# Политики заполнения сертификата
# "supplied" - значение должно быть заполнено запрашивающим
# "match" - значение должно быть заполнено И совпадать с сертификатом CA
# "optional" - значение необязательно к заполнению
# Любые значения, не указанные в политиках явно, будут удалены из сертификата,
# если только не используется опция -preserveDN, но это больше особенность
# программы, чем действительно подразумеваемая функциональность.
[ org1_policy ]
countryName = supplied
stateOrProvinceName = optional
localityName = supplied
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = supplied
subjectAltName = optional
# Настройка вопросов для построения уникального имени
[ org1_dn ]
countryName = Country Name (2 letter code, mandatory)
countryName_default = RU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or province name (optional)
localityName = Locality Name (eg, city, mandatory)
localityName_default = Moscow
organizationName = Organization name (optional)
organizationName_default = Example org.
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = MiniCA
commonName = Common Name (eg, YOUR name, or a server address)
commonName_max = 64
emailAddress = Email Address (mandatory)
emailAddress_max = 40
[ org1_attr ]
#challengePassword = A challenge password
#challengePassword_min = 4
#challengePassword_max = 20
--- END ca.conf ---
Хотя и кажется, что тут уж больно много всего наворочено, на самом деле реальных настроек очень немного.
А после x509_base 5 секций просто ссылаются друг на друга в большинстве настроек, копируя параметры.
Основные секции, которые вы будете настраивать - это org1 и org1_dn. И то, там мало что можно настроить - основные параметры будут вводиться пользователем либо браться из сертификата/запросов.
Теперь надо создать главный ключ удостоверяющего центра. И сертификат, конечно же... Обязательно ставьте на ключ пароль! Обязательно!
$ openssl req -newkey rsa:4096 -x509 -extensions x509_ca -keyout ~/ca.key -out ~/store/ca-$(date +%Y%m%d-%H%M).crt -days 3654
Generating a 4096 bit RSA private key
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
............................++
................................................................................
................................................................................
...............................++
writing new private key to '/home/.CA/ca.key'
Enter PEM pass phrase: <myveryownca>
Verifying - Enter PEM pass phrase: <myveryownca>
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code, mandatory) [RU]:
State or province name (optional) []:Russian Federation
Locality Name (eg, city, mandatory) [Moscow]:
Organization name (optional) []:Example org.
Organizational Unit Name (eg, section) []:MiniCA
Common Name (eg, YOUR name, or a server address) []:Example org. MiniCA root authority
Email Address []:ca@example.orgЭто было много-много точечек, да...
Поясню, что именно мы сделали - это поможет ориентироваться в дальнейших
командах.
openssl req - вызывается функция создания запроса сертификата
-newkey rsa:4096 - запрашивается генерация нового ключа RSA с длиной 4096 бит.
-x509 - а вот тут мы переключаемся в режим самоподписания сертификатов.
Вместо закрытого ключа и запроса сертификата будет создан ключ и сертификат, подписанный этим ключом.
(Сертификат ключа, подписанный этим же самым ключом, называется "самоподписанным" ("self-signed" certificate).)
-extensions x509_ca - из файла настроек загружаются расширения X.509 для CA
-keyout ~/ca.key - файл, куда сохранять ключ.
-out ~/store/ca-$(date +%Y%m%d-%H%M).crt - файл, куда сохранять подписанный сертификат. Файл создается с именем, включающим текущие дату и время - для большей наглядности.
-days 3654 - сертификат будет действителен примерно 10 лет, начиная от момента подписания.
(В 10 годах не 3650 дней. Возьмите календарь, сами посчитайте.)
Но, как вы догадываетесь, оперировать столь длинным именем файла сертификата неудобно.
А мы и не будем мучиться - мы сделаем символическую ссылку...
$ ln -fs /home/.CA/store/ca-20120611-2310.crt ~/ca.crt(Подсказка - введите "ln -s ~/store/ca-" и нажмите Tab - сохраните себе немного нервов...)
Ну... Мы почти закончили. Наша система полностью готова к выдаче первого клиентского сертификата. Нам нехватает только желающих такой сертификат получить... хм. Кто тут, к примеру, в цари крайний? Никого? Тогда я первый!
$ openssl req -new -reqexts x509_client_req -keyout ~/store/keys/client.key -out ~/store/client.csr
Generating a 1024 bit RSA private key
.....................................++++++
...................++++++
writing new private key to '/home/.CA/store/keys/client.key'
Enter PEM pass phrase: <1234>
Verifying - Enter PEM pass phrase: <1234>
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code, mandatory) [RU]:
State or province name (optional) []:Russian Federation
Locality Name (eg, city, mandatory) [Moscow]:Moscow
Organization name (optional) []:Example org.
Organizational Unit Name (eg, section) []:MiniCA
Common Name (eg, YOUR name, or a server address) []:Andrey Repin
Email Address []:anrdaemon@example.org
$Что тут делается?
openssl req - вызывается функция создания запроса сертификата
-new - запрашивается генерация нового ключа с параметрами по умолчанию
-reqexts x509_client_req - выбираются X.509 расширения запроса, подходящие для клиентского сертификата
-keyout ~/store/keys/client.key -out ~/store/client.csr - сохраняются результаты работы программы - ключ и файл-запрос.
Теперь подпишем наш запрос, создавая сертификат.
$ openssl ca -extensions x509_client -in ~/store/client.csr -out ~/store/client.crt
Using configuration from /home/.CA/ca.conf
Enter pass phrase for /home/.CA/ca.key: <myveryownca>
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'RU'
localityName :PRINTABLE:'Moscow'
commonName :PRINTABLE:'Andrey Repin'
Certificate is to be certified until Jun 12 21:05:58 2013 GMT (366 days)
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
$openssl ca - вызываем функции центра сертификации (CA - Certificate Authority)
-extensions x509_client - загружаем расширения X.509 для клиентских сертификатов
-in ~/store/client.csr -out ~/store/client.crt - читаем запрос и сохраняем сертификат.
Теперь бы как-то этот сертификат передать клиенту, запросившему его... Да желательно не один сертификат, а и ключ от него, да и сертификат центра тоже бы не помешал... Это как минимум три файла, что нам теперь, как с букетом с ними бегать?
К счастью, в OpenSSL предусмотрена возможность экспорта всех необходимых данных в контейнер формата PKCS#12 (формат обмена персональными данными). За это отвечает команда pkcs12 утилиты openssl.
$ openssl pkcs12 -export -chain -CAfile ~/ca.crt -in ~/store/client.crt -inkey ~/store/keys/client.key -name "Client Certificate" -out ~/store/client.pfx
Enter pass phrase for /home/.CA/store/keys/client.key: <1234>
Enter Export Password: <1234>
Verifying - Enter Export Password: <1234>
$openssl pkcs12 - вызываются функции PKCS#12
-export - запрашивается экспорт сертификатов (иначе - импорт из контейнера PKCS#12)
-chain - включать в вывод полную цепочку сертификатов
-CAfile ca.crt - указывается файл, содержащий цепочку сертификатов, от младшего к старшему.
-in ~/store/client.crt -inkey ~/store/keys/client.key - добавляются сертификат и ключ
-name "Client Certificate" - устанавливается так называемое "дружественное имя" сертификата в контейнере. Желательно всё таки делать его более дружественным, чем я тут указал, либо вообще не задавать этот ключ.
-out ~/store/client.pfx - указывается путь к контейнеру для экспорта.
Вот теперь можно передать файл
client.pfx вашему клиенту. Т.е., например, скачать его себе на компьютер и попробовать запустить.
После завершения работы мастера импорта, оба сертификата и закрытый ключ будут установлены в локальное хранилище сертификатов системы.
Теперь этот сертификат можно использовать, например, для подписывания электронной почты. Либо, при наличии соответствующих сертификатов у сервера, идентифицировать себя серверу.
$Id: SSL-CA-HOW-TO-4-Creation.txt 315 2015-09-18 09:45:01Z anrdaemon $
--- продолжение ниже ---
На создание статьи подвигла тема
https://forum.ubuntu.ru/index.php?topic=78433.0 и форс-мажор на собственном сервере.
Статья неокончена. Ожидают добавления:
сертификаты серверов,
настройка SSL веб-сервера,
ограничение доступа к серверу с использованием сертификатов, вебмордочка для выдачи сертификатов.
Тема: HOW-TO: Создание собственного центра сертификации (CA - Certificate Authority) (Прочитано 129133 раз)
