Метод 1: Быстрое создание корневого сертификата и сертификата сервера
Метод 2: Быстрое создание единого сертификата (корневого и сервера)
Метод 4: Создание подчинённых УЦ, промежуточных сертификатов и кросс-сертификатов
В этом разделе показано использование команд OpenSSL для выполнения задач, связанных с сертификатами X.509. Для иллюстрации всех функций работы с сертификатами он охватывает генерацию запросов на подписание сертификата (CSR), а также того, что в просторечии называется самоподписанными сертификатами. Термин "самоподписанные" требует небольшого разъяснения, поскольку у него два потенциальных значения.
Если подходить строго, то этот термин означает сертификат, в котором значения атрибутов issuer и subject совпадают. В этом смысле все корневые сертификаты являются самоподписанными. Второе значение — то, когда пользователь становится сам себе удостоверяющим центром (УЦ), что является альтернативой покупке сертификата X.509 у официально признанных УЦ, таких как GoDaddy или Thawte (и других), которые уже являются доверенными (их корневые сертификаты (сертификаты УЦ) предустанавливаются на компьютер пользователя основными инструментами работы с сертификатами, например, браузерами). Полученный браузером с веб-сайта во время фазы протокола рукопожатия TLS/SSL сертификат пользователя (конечного субъекта), изданный одним из официально признанных УЦ, может быть отслежен (и, следовательно, аутентифицирован) браузером вплоть до удостоверяющего центра (УЦ) с использованием атрибута issuer полученного сертификата. Чтобы браузер не выводил сообщений об ошибках, должен быть предустановлен корневой сертификат УЦ (а также любые промежуточные сертификаты). Для определения установленных сертификатов используется термин якорь доверия. Обычно такие сертификаты устанавливаются в структуре keystore (хранилище ключей), которая может быть защищена (или не защищена) паролем. Корневые сертификаты большинства коммерческих УЦ и многих национальных УЦ распространяются и инсталлируются с программным обеспечением браузеров, таких как MSIE, Firefox, Opera и т.д., а также в составе операционных систем или библиотек языков программирования, таких как Java.
Далее в этом разделе рассматриваются самоподписанные сертификаты по второму значению этого термина — пользователь становится сам себе удостоверяющим центром. Такая форма самоподписанных сертификатов может быть использована либо во время тестирования, либо в рабочей среде, например, когда пользователь хочет организовать контроль доступа в какой-либо частной сети, закрытой группе пользователей или каком-либо другом сообществе. В этом случае отношения доверия, обычно ассоциированные с внешним УЦ, могут рассматриваться как неявные из-за характера организации подписания таких сертификатов.
Когда программное обеспечение с поддержкой TLS/SSL (браузер) впервые встречает такой самоподписанный сертификат и подразумевается, что у браузера нет копии соответствующего корневого сертификата, будет сгенерировано сообщение, спрашивающее пользователя, желает ли он принять сертификат. С другой стороны, самоподписанный корневой сертификат может быть предустановлен или импортирован на компьютер пользователя, в этом случае браузер не будет генерировать сообщения об ошибке.
Примечание по срокам действия сертификатов и размерам ключей: Большинство сертификатов, описанных в последующих подразделах, имеют срок действия от 1 до 3 лет. Однако, большинство коммерческих корневых сертификатов, поставляемых с браузерами, имеют сроки действия 10 лет и больше! Нет ничего страшного в использовании достаточно длительных сроков действия сертификатов, чтобы не беспокоиться об их постоянном перевыпуске. Текущая (2011 год) рекомендация по длине ключа RSA, — 2048 бит, — действительна до 2030 года (вследствие чего срок действия многих ныне действующих корневых сертификатов истекает около 2028 года, давая им запас времени в пару лет для увеличения размера ключа, прежде чем ключи размером 2048 бит не перестанут быть легитимными в 2030 году). Рекомендации RSA по силе и требуемым срокам действия ключей. Аналогичные рекомендации по размеру (2048 бит) и срокам действия (до 2030 года) ключей также содержатся в специальной публикации 800-57, часть 1, ревизия 2, таблица 4 Национального института стандартов и технологий США (National Institute of Standards and Technology, US NIST).
В приведённых далее последовательностях действий используются команды OpenSSL (тестировались на OpenSSL 1.1.1d) для генерации самоподписанных сертификатов X.509, которые могут быть установлены и использованы серверными системами TLS/SSL, такими как веб, FTP, LDAP или почтовыми системами (агентами SMTP). Команды OpenSSL используют множество параметров, в том числе ответы по умолчанию, сроки действия и атрибуты сертификатов, из файла openssl.cnf (в FreeBSD — /etc/ssl/openssl.cnf), и если Вы собираетесь работать с сертификатами всерьёз, стоит просмотреть и, по мере необходимости, отредактировать этот файл, чтобы потом печатать поменьше параметров в командной строке.
Примечание: Есть серьёзные опасения, что ошибки, допущенные при редактировании openssl.cnf или при экспериментах с CA.pl (полезный скриптовый файл), могут привести к падению небес на землю. Создайте резервную копию всех подобных файлов, прежде чем начинать что-либо делать, тогда Вы в любой момент сможете вернуть Вашу систему в первоначальное состояние, если что-то пойдёт не так. Помните: всё что Вы делаете, Вы делаете на свой страх и риск.
Создаваемые при работе с сертификатами файлы будут содержать либо открытые ключи, которые обычно не требуют особенной защиты, либо закрытые ключи, которые необходимо хорошо защищать. Будут ли оба типа файлов храниться в одной структуре каталогов или нет — зависит от локальной политики безопасности.
Как и с любым сложным программным обеспечением, существует огромное множество способов что-либо сделать, но из них лишь два-три могут оказаться действительно полезными методами (Really Useful Methods, RUM™). Окончательный выбор зависит от требований локального окружения.
Рабочие заметки: Некоторые из представленных методов используют PERL-скрипт CA.pl, обычно поставляемый с OpenSSL. На свежеустановленной FreeBSD 8.1 в установке openssl по умолчанию (0.9.8n) отсутствует скрипт CA.pl. Если в процессе установки Вы запрашивали инсталляцию исходных кодов, то его можно найти в /usr/src/crypto/openssl/apps/CA.pl. Другой вариант — использовать систему портов (/usr/ports/security/openssl), а затем выполнить make patch (просто скачать и распаковать openssl, но не устанавливать его), после чего найти скрипт с помощью find ./ -name "CA.pl". Поскольку PERL в FreeBSD больше не устанавливается по умолчанию, его нужно установить самостоятельно. Если Вы используете cygwin на Windows, то Вам не повезло. Но (поскольку Вы также можете установаить PERL) можно получить копию файла из репозитория проекта https://github.com/openssl/openssl/blob/master/apps/CA.pl.in. В любом случае, CA.pl не является необходимым для работы, он просто упрощает процесс настройки соответствующей структуры каталогов файловой системы. (Кроме всего прочего, cygwin прячет файл openssl.conf в cygwin\etc\pki\tls).
Метод 1: Быстрое создание корневого сертификата и сертификата сервера.
Метод 4: Создание подчинённых УЦ, промежуточных сертификатов и кросс-сертификатов.
Создаётся сертификат УЦ, то есть корневой сертификат, который можно импортировать в браузер в целях тестирования, а также один сертификат сервера, который может быть использован сервером, например, Apache. Для упрощения процесса используется стандартный скрипт OpenSSL CA.pl (для упрощения примеров мы переместили его в /etc/ssl, Вы же указывайте своё расположение).
Примечание: Для генерации сертификатов, которые можно было бы использовать с несколькими именами сервера, например, example.com, www.example.com или www.example.net требуется процесс, описанный ниже.
# По умолчанию используется алгоритм RSA с ключами 1024 бит (2011 год). # О том как изменить значения по умолчанию смотрите в пункте 1 метода 3. # Создаём директории и самоподписанный корневой сертификат УЦ: cd /etc/ssl ./CA.pl -newca # Запрашиваемая здесь последовательность атрибутов относится к DN УЦ. # По умолчанию корневой сертификат создаётся в # demoCA/cacert.pem # а закрытый ключ УЦ в # demoCA/private/cakey.pem # Срок действия cacert.pem - 3 года ./CA.pl -newreq # Создаём запрос на подписание сертификата (CSR) # Запрашиваемая последовательность атрибутов относится к DN сервера # Важно лишь значение атрибута CN (CommonName), # где следует указать имя веб-сервера или другого сервера, # например, www.example.com, ldap.example.com или mail.example.com ./CA.pl -sign # Подписываем CSR и оставляем сертификат в # /usr/local/openssl/newcert.pem # Срок действия newcert.pem - 1 год. # Закрытый ключ в # /usr/local/openssl/newkey.pem # Удаляем парольную фразу из newkey.pem # чтобы сервер не запрашивал пароль при загрузке openssl rsa -in newkey.pem -out keyout.pem # ВНИМАНИЕ: этот файл содержит закрытый ключ, и права только на чтение # должны быть только у владельца этого файла # Переместите и переименуйте файлы согласно требованиям сервера. # Необходимы оба файла newcert.pem и keyout.pem. # Пример для apache: SSLCertificateFile /path/to/newcert.pem SSLCertificateKeyFile /path/to/keyout.pem # Пример для OpenLDAP: TLSCACertificateFile /path/to/cacert.pem TLSCertificateFile /path/to/newcert.pem TLSCertificateKeyFile /path/to/keyout.pem
Дополнительные пояснения и примечания смотрите далее. Файл demoCA/cacert.pem, являющийся корневым сертификатом, может быть скопирован и импортирован в браузер.
Это самый простой (в одну команду) путь создания сертификата X.509, который можно будет использовать и как сертификат сервера, и как корневой сертификат (сертификат УЦ). Поскольку этот сертификат самоподписанный (и присутствует атрибут CA:True), он может быть импортирован в браузер или другое клиентское ПО как корневой сертификат (сертификат УЦ). Кроме того, один и тот же сертификат может быть использован в качестве сертификата сервера как в настройках Apache, так и в настройках, например, LDAP-сервера. Запрашиваемая последовательность атрибутов относится к DN того сервера, для которого генерируется сертификат. В частности, атрибут CN должен определять имя хоста сервиса, такое как www.example.com, а не имя хоста компьютера. То есть, если веб-сервис имеет адрес https://www.example.com, а выполняется на хосте webserver.example.com, следует использовать CN=www.example.com. Далее показан стандартный диалог OpenSSL, значения #обрамлённые_знаками_решётки# должны быть заменены на требуемые, например, #имя_сервера# следует заменить на действительное имя сервера, который подлежит аутентификации, скажем, www.exmple.com или ldap.example.com.
Примечание: Для генерации сертификатов, которые можно было бы использовать с несколькими именами сервера, например, example.com, www.example.com или www.example.net требуется процесс, описанный ниже.
cd /etc/ssl openssl req -x509 -nodes -days 1059 -newkey rsa:2048 \ -keyout testkey.pem -out testcert.pem Generating a 2048 bit RSA private key .....++++++ ..................++++++ writing new private key to 'testkey.pem' 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) [AU]:#код_вашей_страны# State or Province Name (full name) [Some-State]:#название_вашего_субъекта_страны# Locality Name (eg, city) []:#название_вашего_города# Organization Name (eg, company) [Internet Widgets Pty Ltd]:#название_вашей_организации# Organizational Unit Name (eg, section) []:#необязательное_поле# Common Name (eg, YOUR name) []:#имя_сервера# Email Address []:. # Создаётся сертификат testcert.pem # и незашифрованный закрытый ключ testkey.pem # которому необходимо немедленно дать права # только на чтение только владельцу: # chown user:group testkey.pem # chmod 0400 testkey.pem # Переместите и переименуйте файлы согласно требованиям сервера. # Необходимы оба файла testcert.pem и testkey.pem. # Пример для apache: SSLCertificateFile /path/to/testcert.pem SSLCertificateKeyFile /path/to/testkey.pem # Пример для TLS-сервера OpenLDAP (slapd.conf) TLSCertificateFile /path/to/testcert.pem TLSCertificateKeyFile /path/to/testkey.pem # Пример для TLS-клиента OpenLDAP (ldap.conf) TLS_CACERT /path/to/testcert.pem
Примечание: Параметр -x509 используется для создания самоподписанного сертификата УЦ. -nodes подавляет диалог запроса парольной фразы. -days 1059 устанавливает срок действия сертификата: 2 года 329 дней.
<ляп> Читатели могут задаться вопросом, зачем здравомыслящему человеку может потребоваться создавать сертификат сроком действия 2 года 329 дней? Тому есть две причины. Во-первых, если можно так сделать, то почему бы и нет? Во-вторых, внимательные читатели могли заметить, что 3 года составляет 1095 дней а не 1059, которые были использованы в тестах. Если честно, при первоначальном запуске тестов мы перепутали 5 и 9 (по молодости лет, плохому зрению или глупости — решайте сами) и вместо того, чтобы перезапустить тесты с 1095 днями, мы оставили 1059 и придумали эту глупую отмазку. Наконец, поскольку предполагается, что текущие рекомендации по размеру ключей в 2048 бита будут действительны до 2030 года, можно вполне разумно задать это значение в -days 6205 (по состоянию на 2013 год): 17 лет с учётом високосных лет.</ляп>
Если Вы собираетесь генерировать несколько сертификатов, скажем, для использования во внутренней системе, этому стоит посвятить некоторое время и усилия. Мы пробовали несколько методов и этот, на наш взгляд, самый простой. В нём используется стандартный скрипт CA.pl для создания удостоверяющего центра, при этом инициализируются множество директорий и файлов, которые очень проблематично настроить другим способом, а затем используются команды openssl для генерации CSR и подписания сертификатов, поскольку таким способом достигается больший контроль над переменными и (относительно) меньший уровень проблем.
Размещение и предварительная подготовка. Необязательный этап, позволяющий поменьше печатать в командной строке. Решите, где Вы собираетесь построить свой репозиторий сертификатов. Для наглядности мы создадим его в /etc/ssl, и это размещение будет использоваться далее по тексту. Измените его в соответствии с Вашими потребностями. Переместите скрипт CA.pl (если Вы не можете его найти, используйте locate CA.pl) в /etc/ssl/CA.pl либо туда, где Вы собираетесь создавать репозиторий сертификатов. Мы также переименовали этот скрипт в ca.pl из-за патологического отвращения к клавише shift, но если Вы не разделяете наших взглядов, просто используйте CA.pl в примерах.
Файлы ca.pl (или CA.pl) и /etc/ssl/openssl.cnf оказывают существенное влияние на работу как самого скрипта, так и команды openssl. Произведённые нами изменения показаны ниже, для удобства в файле CA.pl (ca.pl) приведены только изменённые строки:
# ПРЕДУПРЕЖДЕНИЕ: Следует сделать и хранить копии первоначальных файлов # CA.pl и openssl.cnf прежде чем вносить какие-либо изменения # Срок действия корневого сертификата - 10 лет, можете установить другой, # но большинство общедоступных УЦ предоставляют корневые сертификаты, # действительные до 2028 $CADAYS="-days 3650"; # 10 лет # по умолчанию $CADAYS="-days 1059"; # 3 года # Изменяем директорию УЦ $CATOP="./ca"; # по умолчанию $CATOP="./demoCA"; # при изменении этой переменной требуются соответствующие изменения в openssl.cnf
Чтобы упростить себе жизнь, мы сделали следующие изменения в /etc/ssl/openssl.cnf (опять же, приведены только изменённые строки):
# ПРЕДУПРЕЖДЕНИЕ: Следует сделать и хранить копии первоначальных файлов # CA.pl и openssl.cnf прежде чем вносить какие-либо изменения [ CA_default ] # изменение директории как в ca.pl dir = ./ca # Тут будет всё # dir = ./demoCA # по умолчанию # Параметр копирования расширений: используйте с осторожностью copy_extensions = copy # раскомментируйте эту директиву если требуется сертификат для нескольких имён DNS, # иначе оставьте закомментированной (по умолчанию) # Срок действия сертификата изменён на 3 года. # Можно опустить опцию -days default_days = 1059 # 3 года # по умолчанию default_days = 365 # 1 год [ policy_match ] # Добавление этой строки в предыдущий раздел # приведёт к добавлению атрибута L= в DN issuer и subject, # в противном случае этот атрибут будет опущен - на Ваш выбор localityName = optional [req] default_bits = 2048 # текущая рекомендация на 2011-2030 годы # default_bits = 1024 # значение в оригинальном файле [ req_distinguished_name ] # Чтобы меньше печатать установите корректные значения _default. # Отредактируйте или добавьте в нужное место countryName_default = MY stateOrProvinceName_default = STATE localityName_default = CITY 0.organizationName_default = ONE INC organizationalUnitName_default = IT
Стоит проверить все остальные значения этого файла — вдруг Вы захотите что-то изменить.
Создание удостоверяющего центра. Первая команда создаёт корневой сертификат удостоверяющего центра (УЦ) и некоторые другие служебные файлы. Создаётся пара ключей — открытый и закрытый. Открытый ключ записывается в корневой сертификат /etc/ssl/ca/cacert.pem, закрытый ключ — в /etc/ssl/ca/private/cakey.pem. Формат файла по умолчанию — PEM. Запрашиваемые детали DN будут использованы для формирования атрибутов issuer и subject этого корневого сертификата, а также для атрибута issuer всех последующих подписанных сертификатов, укажите их в соответствии со своими требованиями. Парольная фраза обязательна, она устанавливается для защиты закрытого ключа и будет запрашиваться при всех последующих подписаниях сертификатов, так что её стоит запомнить:
cd /etc/ssl
./ca.pl -newca
CA certificate filename (or enter to create) #ENTER
Making CA certificate ...
Generating a 2048 bit RSA private key
.....++++++
..................++++++
writing new private key to './ca/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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) [MY]:
State or Province Name (full name) [STATE]:
Locality Name (eg, city) [CITY]:
Organization Name (eg, company) [ONE INC]:CA COMPANY NAME
Organizational Unit Name (eg, section) [IT]:X.509
Common Name (eg, YOUR name) []:CA ROOT
Email Address []:.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for ./ca/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
bb:7c:54:9b:75:7b:28:9c
Validity
Not Before: Apr 15 21:07:36 2008 GMT
Not After : Apr 13 21:07:36 2018 GMT
Subject:
countryName = MY
stateOrProvinceName = STATE
organizationName = CA COMPANY NAME
localityName = CITY
organizationalUnitName = X.509
commonName = CA ROOT
X509v3 extensions:
X509v3 Subject Key Identifier:
54:0D:DE:E3:37:23:FF...
X509v3 Authority Key Identifier:
keyid:54:0D:DE:E3:37...
DirName:/C=MY/ST=STATE/O=CA COMPANY NAME/L=CITY/OU=X.509/CN=CA ROOT
serial:BB:7C:54:9B:75:7B:28:9C
X509v3 Basic Constraints:
CA:TRUE
Certificate is to be certified until Apr 13 21:07:36 2018 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).
Создаётся стандартная структура директорий:
ca # cacert.pem (корневой сертификат)
# serial (отслеживание серийных номеров)
# crlnumber (серийные номера CRL)
# index.txt
ca/private/cakey.pem # закрытый ключ УЦ
ca/newcerts # копии всех созданных сертификатов
ca/crl # опциональное место размещения созданных CRL
ca/certs # опциональное место размещения созданных сертификатов
Срок действия созданного корневого сертификата (ca/cacert.pem) — 10 лет (3650 дней) согласно отредактированному значению в файле ca.pl. Соответствующий закрытый ключ (ca/private/cakey.pem) защищён парольной фразой PEM, но всё равно его следует защищать установкой минимально возможных прав доступа (назначаемые по умолчанию права 0644 неоправданно высоки). Запрашиваемый Challenge Password — простой пароль, который может быть использован для защиты доступа к сертификатам, CSR и последующим сертификатам X.509. Большинство (если не все) коммерческие удостоверяющие центры не приветствуют установку этого пароля и сопутствующего опционального названия компании (Optional Company Name), и во всех примерах это поле оставляется незаполненным. Если Вы хотите отключить запрос этих значений, отредактируйте /etc/ssl/openssl.cnf:
[ req_attributes ] # Закомментируйте указанные строки #challengePassword = A challenge password #challengePassword_min = 4 #challengePassword_max = 20 #unstructuredName = An optional company name
Создание запроса на подписание сертификата (CSR). Запрашиваемые в этом случае атрибуты DN будут относиться к полю subject итогового сертификата.
Эта команда может использоваться и для создания запроса CSR (Certificate Signing Request) в коммерческий УЦ, а поскольку большинство УЦ не приветствуют паролей, просто нажмите ENTER при запросе A challenge password (о том, как совсем отключить эти запросы смотрите выше). Опциональное значение emailAddress также остаётся пустым, главным образом потому, что для сертификата сервера оно не имеет никакого значения, а также потому, что в большинстве запросов в коммерческие УЦ оно не заполняется.
openssl req -nodes -new -newkey rsa:2048 \ -keyout ca/private/cert1key.pem -out ca/certs/cert1csr.pem Generating a 2048 bit RSA private key ...................++++++ ............++++++ writing new private key to 'ca/private/cert1key.pem' ----- 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) [MY]: State or Province Name (full name) [STATE]: Locality Name (eg, city) [CITY]: Organization Name (eg, company) [ONE INC]: Organizational Unit Name (eg, section) [IT]: Common Name (eg, YOUR name) []:www.example.com Email Address []:. Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Эта команда создаёт новый запрос на подписание сертификата (в /etc/ssl/ca/certs/cert1csr.pem), который затем должен быть подписан с помощью закрытого ключа УЦ, и закрытый ключ (который, за счёт использования параметра -nodes, не будет защищён парольной фразой — ведь мы будем использовать его в серверном приложении) в /etc/ssl/ca/private/cert1key.pem. Значение CN (в примере — www.example.com) — это используемое приложением имя сервиса. Оно могло бы быть ldap.example.com, либо любым другим подходящим именем. Имейте также ввиду, что такой сертификат сработает при доступе на https://www.example.com, но если для доступа к тому же сервису используется https://example.com, то Вам перед созданием CSR нужно обязательно добавить атрибут сертификата subjectAltName с помощью описанной ниже процедуры (и использовать в секции VirtualHost настроек Apache директиву ServerAlias). Имя сервиса не следует путать именем хоста сервера. Так, если к веб-сервису обращаются как к https://www.example.com, а он выполняется на хосте webserver.example.com, в CN нужно использовать www.example.com.
Для просмотра запроса сертификата выполните:
openssl req -in ca/certs/cert1csr.pem - noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:ae:19:86:44:3c:dd...
...
99:20:b8:f7:c0:9c:e8...
38:c8:52:97:cc:76:c9...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha1WithRSAEncryption
79:f5:20:45:6c:ec:8e:ae...
...
bd:61:cd:c5:89:7c:e0:0d...
40:7d
Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).
Создание и подписание сертификата конечного пользователя. Эта команда принимает на входе CSR (ca/certs/cert1csr.pem) и создаёт сертификат конечного пользователя (конечного субъекта) (ca/certs/cert1.pem):
openssl ca -policy policy_anything \
-in ca/certs/cert1csr.pem -out ca/certs/cert1.pem
Using configuration from /usr/local/openssl/openssl.cnf
Enter pass phrase for ./ca/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
bb:7c:54:9b:75:7b:28:9d
Validity
Not Before: Apr 15 22:21:10 2008 GMT
Not After : Mar 10 22:21:10 2011 GMT
Subject:
countryName = MY
stateOrProvinceName = STATE
localityName = CITY
organizationName = ONE INC
organizationalUnitName = IT
commonName = www.example.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
EE:D9:4A:74:03:AC:FB:2C...
X509v3 Authority Key Identifier:
keyid:54:0D:DE:E3:37:23...
Certificate is to be certified until Mar 10 22:21:10 2011 GMT (1059 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
Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).
Атрибут issuer полученного в результате сертификата формируется из атрибута subject корневого сертификата (ca/cacert.pem), а атрибут subject нового сертификата — из CSR. Многие значения по умолчанию команда берёт из openssl.cnf: срок действия (default_days =), ключ подписания (private_key =) и DN издателя из корневого сертификата (certificate =). В зависимости от требований Вашей системы параметр -policy policy_anything может быть обязательным. Он указывает на определённую в файле openssl.cnf секцию policy_anything, которая позволяет задавать в DN атрибута subject сертификата значения атрибутов, отличные от соответствующих атрибутов в DN атрибута issuer. При отсутствии этого параметра по умолчанию используется -policy policy_match, накладывающее ограничения на значения RDN C=, ST= и O=.
Для просмотра полученного в результате сертификата выполните:
openssl x509 -in ca/certs/cert1.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
bb:7c:54:9b:75:7b:28:9d
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=MY, ST=STATE, O=CA COMPANY NAME, L=CITY, OU=X.509, CN=CA ROOT
Validity
Not Before: Apr 15 22:21:10 2008 GMT
Not After : Mar 10 22:21:10 2011 GMT
Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:ae:19:86:44:3c:dd...
...
99:20:b8:f7:c0:9c:e8...
38:c8:52:97:cc:76:c9...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
EE:D9:4A:74:03:AC:FB:2C...
X509v3 Authority Key Identifier:
keyid:54:0D:DE:E3:37:23...
Signature Algorithm: sha1WithRSAEncryption
52:3d:bc:bd:3f:50:92...
...
51:35:49:8d:c3:9a:bb...
b8:74
Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями, которые в реальной ситуации в этих местах быть не могут).
Проверка и просмотр сертификатов. Может случиться неприятность и произойти повреждение файлов. Чтобы убедиться в целостности сертификатов, используйте такие команды:
openssl x509 -in certificate-name.pem -noout -text # отображает сертификат целиком openssl x509 -in certificate-name.pem -noout -dates # выводит только даты начала и окончания срока действия openssl x509 -in certificate-name.pem -noout -purpose # выводит список всех возможных целей применения сертификата openssl x509 -in certificate-name.pem -noout -purpose - dates # выводит срок действия и цели применения сертификата
Импорт самоподписанного корневого сертификата. Созданный на этапе 2 файл в формате PEM (ca/cacert.pem) может быть импортирован непосредственно в MSIE и Firefox, чтобы они не выдавали запросы о недоверенных сертификатах. Описание процедуры импорта.
В методе 3 создаётся простая цепочка из двух сертификатов: сертификата конечного субъекта (сервера) и корневого сертификата УЦ. В методе 4 производится исследование того, что можно добавить к этой структуре (по тем или иным причинам). Мы создадим подчинённый УЦ, возможно, второй корневой УЦ, а также, основываясь на этой структуре, создадим всевозможные кросс-сертификаты и промежуточные сертификаты.
Основные настройки: Выполните этапы 1 и 2 метода 3. Создаётся просто структура директорий и наш первый корневой УЦ. Если Вы уже прошли все этапы метода 3, то ни одно из имён файлов, создаваемых далее не будет конфликтовать с уже созданными, так что Вы ничего не потеряете и Ваша система не нарушится. По завершении этого процесса будут созданы следующие директории и файлы:
ca # cacert.pem (корневой сертификат)
# serial (отслеживание серийных номеров)
# crlnumber (серийные номера CRL)
# index.txt
ca/private/cakey.pem # закрытый ключ УЦ
ca/newcerts # копии всех созданных сертификатов
ca/crl # опциональное место размещения созданных CRL
ca/certs # опциональное место размещения созданных сертификатов
Замечание по стратегии: Команда openssl берёт многие из своих расширенных параметров из конфигурационного файла (openssl.cnf). До этого момента мы предполагали, что изменения нужно производить именно в этом стандартном файле, поскольку он обычно используется при выполнении всех таких команд. Но для текущей задачи такой подход не подойдёт. Вместо этого мы рекомендуем скопировать стандартный конфигурационный файл (openssl.cnf), дать этому новому файлу подходящее имя (которое легко запомнить) и использовать аргумент -config filename для выбора, в зависимости от задачи, соответствующего конфигурационного файла. Это позволяет работать быстрее (со временем), не путаться (со временем) и использовать конфигурацию повторно (изначально).
Создаём подчинённый УЦ:
Создаём новые директории, скажем, subca и subca/private (с теми же правами, что и ca/private). Этот шаг просто позволит поддерживать порядок (в своём роде):
cd /etc/ssl mkdir ca/subca mkdir ca/subca/private # создаём необходимый пустой файл базы данных для издателя subca touch ca/subca/index.txt
Редактируем openssl.cnf, создаём секцию [ sub_ca ], она может находиться в любом месте файла, но для определённости создадим её перед секцией [ user_certs ]. Различные параметры в этой секции будут использоваться для переопределения обычных параметров, используемых при подписании сертификата.
# новая секция [ sub_ca ] basicConstraints=CA:TRUE # другой вариант: # basicConstraints= CA:TRUE,pathlen:0 # pathlen:0 ограничивает subCA, чтобы он мог # подписывать только сертификаты конечных субъектов # необязательная строка тестового комментария # nsComment="Most Trusted Certificate in the World" nsComment="OpenSSL Generated Certificate" # следующие два параметра - обычные для всех некорневых сертификатов subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # следующая строка лишь демонстрирует позицию секции sub_ca в файле [ user_cert ]
Создаём сертификат подчинённого УЦ:
Создаём CSR для подчинённого УЦ и подписываем его с использованием корневого сертификата УЦ:
# ПРИМЕЧАНИЕ: На этих этапах используется корневой УЦ, созданный на этапах 1 и 2 метода 3.
# Создаём CSR для подчинённого УЦ
openssl req -new -keyout ca/subca/private/subca1key.pem \
-out ca/subca/subca1csr.pem
Generating a 2048 bit RSA private key
...................++++++
............++++++
writing new private key to 'ca/subca/private/subca1key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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) [MY]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) [Some City]:
Organization Name (eg, company) [My Company Name]:
Organizational Unit Name (eg, section) []:Certs
Common Name (eg, YOUR name) []:subCA1
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
# Примечания:
# 1. Значение Organizational Unit не так важно, несёт больше описательную нагрузку.
# 2. Значение Common Name - имя (название), данное подчинённому УЦ.
## Теперь подпишем этот запрос с использованием ключа корневого УЦ.
## Для установки определённых нами расширений используем -extensions sub_ca.
openssl ca -policy policy_anything -in ca/subca/subca1csr.pem \
-out ca/subca/subca1cert.pem -extensions sub_ca
# Выводим полученный сертификат:
openssl x509 -in ca/subca/subca1cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
c6:bd:b2:ce:22:bc:4d:57
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=MY, ST=Some-State, O=My company name, OU=Certs, CN=Root CA1
Validity
Not Before: Dec 9 20:40:18 2011 GMT
Not After : Dec 6 20:40:18 2021 GMT
Subject: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Certs, CN=subCA1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a9:f3:02:01:c9...
01:b6:27:c8:a0:9c...
...
f0:37:71:5d:e3:c7:3d:59:ff...
55:87
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
58:47:30:77:3F:EF...
X509v3 Authority Key Identifier:
keyid:FB:7B:FB:7B...
Signature Algorithm: sha1WithRSAEncryption
43:b5:e2:8d:4d:07:56...
...
12:2c:a2:7c:eb:dc:45...
e0:f3:2b:72
Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).
Четыре расширения X509v3 extensions, — следствие использования аргумента -extensions sub_ca, — переопределяют обычные характеристики сертификата. Если от корневого УЦ требуется подписать обычный сертификат конечного субъекта, просто опустите этот аргумент. Технически, получившийся в результате сертификат (ca/subca/subca1cert.pem) — это кросс-сертификат, поскольку и полученный сертификат, и сертификат издателя имеют атрибут basicConstraints, в котором cA установлено в True.
Подписание сертификата конечного субъекта подчинённым УЦ:
Чтобы подписать сертификат конечного субъекта с использованием ключа подчинённого УЦ, нам сначала нужно скопировать файл openssl.cnf и переименовать его, скажем, в subca1.cnf. Теперь внесём изменения в subca1.cnf (эти изменения просто сообщат openssl где брать различные файлы, относящиеся к subCA, тогда как стандартный файл openssl.cnf продолжит ссылаться на информацию о корневом УЦ):
[ CA_default ] # Показаны только те значения, которые были изменены. database = $dir/subca/index.txt # индексный файл базы данных. certificate = $dir/subca/subca1cert.pem # сертификат subCA # Следующий параметр говорит о том, что сертификаты от обоих центров # (корневого и подчинённого) будут иметь сквозную (единую) нумерацию. # Чтобы изменить это, скопируйте ca/serial в ca/subca/serial # и модифицируйте параметр. serial = $dir/serial # текущий серийный номер # Эти параметры задаются, если будут выпускаться отдельные CRL, # в противном случае оставьте их без изменений crl_dir = $dir/subca/crl # месторасположение подписанных crl crlnumber = $dir/subca/crlnumber # текущий номер crl # Закомментируйте, если собираетесь использовать CRL V1 crl = $dir/subca/crl.pem # текущий CRL private_key=$dir/subca/private/subca1key.pem # закрытый ключ subCA RANDFILE = $dir/subca/private/.rand # закрытый файл со случайным числом
Теперь создадим CSR на сертификат конечного субъекта и подпишем его ключом subCA:
# Создаём CSR:
openssl req -new -nodes -keyout ca/private/user1key.pem \
-out ca/certs/user1csr.pem
# Подписываем его ключом subCA с использованием -config subca1.cnf:
openssl ca -policy policy_anything -in ca/certs/user1csr.pem \
-out ca/certs/user1cert.pem -config subca1.cnf
# Выводим получившийся сертификат:
openssl x509 -in ca/certs/user1cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
c6:bd:b2:ce:22:bc:4d:58
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Certs, CN=subCA1
Validity
Not Before: Dec 9 21:06:43 2011 GMT
Not After : Dec 6 21:06:43 2021 GMT
Subject: C=MY, ST=Some-State, L=Some City, O=My company name, OU=Server, CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:c3:f4:dc:07:08:30:3a...
...
a8:45:fd:c5:d7:a4:04:82...
af:dd
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
B1:5A:23:4E:C8:2B:FD:98...
X509v3 Authority Key Identifier:
keyid:58:47:30:77:3F:EF...
Signature Algorithm: sha1WithRSAEncryption
50:4b:8e:50:8f:fa:f4:98...
...
3d:97:52:28:1f:a6:9d:2e...
ac:58:be:eb
Примечание: В приведённом примере строки, мало что дающие для понимания материала, были обрезаны или даже пропущены (места пропусков обозначены многоточиями).
В данном случае издатель сертификата — subCA1, а не root CA1, как было при подписании запроса на создание сертификата подчинённого УЦ. Чтобы разрешить проверку подлинности сертификата конечного субъекта по всей цепочке, в браузер должны быть импортированы ОБА сертификата: корневого УЦ (ca/cacert.pem) и подчинённого УЦ (ca/subca/subca1cert.pem).
Другие возможности:
Используя подобную технику, можно создать второй корневой УЦ (root CA2), при этом, понятное дело, потребуется ещё одна копия openssl.cnf, либо второй подчинённый УЦ (subCA2), опять же, с уникальным конфигурационным файлом. Короче, любой каприз...
Если сертификат предназначен для использования на хосте, у которого больше одного имени DNS, скажем, https://www.example.com, https://example.com или даже www.example.net, то вам нужно указать использование атрибута сертификата subjectAltName в запросе на подписание сертификата (CSR). Чтобы это сделать, отредактируйте файл openssl.cnf как показано ниже (приведены только изменённые строки):
# Сначала найдите секцию [CA_Default] [CA_Default] .... # Раскомментируйте или добавьте copy_extensions = copy # Это заставит функцию ca скопировать атрибуты расширений из CSR. # Эти манипуляции следует произвести на хосте, создающем # сертификаты на основе CSR. # Теперь найдите секцию [v3_req] [v3_req] ... # Добавьте следующую строку с нужными именами хостов: subjectAltName = "DNS:www.example.com, DNS:example.com,DNS:example.net" # Это следует сделать на хосте, который генерирует CSR.
При запуске команды на создание CSR добавьте к её аргументам -reqexts "v3_req" только в том случае, когда Вам нужно включить дополнительные атрибуты subjectAltName. Хотя в приведённом примере показано добавление трёх имён, на практике можно добавить любое количество. Каждое включение имеет формат DNS:hostname.domain.name, несколько включений должны быть разделены запятыми, а все вместе они должны быть заключены в кавычки. Вот запрос на создание CSR из этапа 3 метода 3 с дополнительным аргументом:
openssl req -nodes -new -newkey rsa:2048 \ -keyout ca/private/cert1key.pem -out ca/certs/cert1csr.pem -reqexts "v3_req"
Если при создании CSR не указывался аргумент -reqexts, по этому CSR будет создан обычный сертификат с единственным именем сервера. Приведённый пример работает как дополнение рассмотренного выше метода 3 и представляет собой наиболее гибкий подход.
Примечание: Если Вы хотите выпустить несколько сертификатов с разным набором имён серверов в каждом, то лучшей стратегией будет простое копирование и переименование стандартного конфигурационного файла (openssl.cnf) во что-то более осмысленное, а затем использование аргумента -config filename для выбора каждого из файлов по мере необходимости. Количество подобных конфигурационных файлов может быть любым, просто помните их имена и предназначение.
Если Вы хотите создать сертификаты с несколькими именами сервера в методах 1 или 2, то в дополнение к приведённым выше правкам openssl.cnf добавьте это:
# Найдите секцию [req] [req] .... # Добавьте или раскомментируйте: req_extensions = v3_req
При такой модификации атрибуты сертификата subjectAltName будут безусловно добавляться в каждый CSR.
Большинство веб-сайтов коммерческих УЦ дают на выбор два варианта подписания сертификатов: либо путём предоставления запроса на подписание сертификата (Certificate Signing Request, CSR) (в этом случае УЦ сгенерирует сертификат и выдаст файл с цепочкой сертификатов корневого и промежуточных УЦ), либо с использованием мастера/формы (в этом случае УЦ выдаст сертификат, закрытый ключ и файл с цепочкой сертификатов корневого и промежуточных УЦ). По соображениям эксплуатационной гибкости, принятой в организации политики или старой доброй паранойи многие предпочитают самостоятельно генерировать CSR и соответствующий ему закрытый ключ. В этом разделе приводятся простые команды OpenSSL, охватывающие самые распространенные требования.
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2020 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 5 декабря 2019 г.
Переведено участниками проекта Pro-LDAP.ru в 2013-2020 г.