Главная > Блог > ОС Linux > Команды >

OpenSSL. Примеры использования

16.06.2024

Теги: HTTP • HTTPS • SSL • Ключ • Команда

Симметричное шифрование

При симметричном шифровании используется один ключ для передачи данных между участниками обмена. Это означает, любой у кого он есть, может читать и посылать сообщения другим держателям ключа. Такая схема еще часто называется с «общим секретом» (shared secret) или «секретный ключ». Для примера, секретный ключ используется для обмена данными по SSH и по HTTPS.

Клиент и сервер (SSH и HTTPS) проходят некоторую процедуру, чтобы «договориться» о вышеозначенном секрете. Она называется «обмен ключами» и происходит с помощью конкретных приемов, в результате которых, обе стороны получают один и тот же ключ, манипулируя открытыми частями информации. Как это возможно? Алгоритм Диффи-Хеллмана!

Асимметричное шифрование

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

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

Алгоритм Диффи-Хеллмана

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

Математические функции, лежащие в основе этого алгоритма, имею важную отличительную особенность — они относительно просто вычисляются в прямом направлении, но практически не вычисляются в обратном. Это именно та область, где в игру вступают очень большие простые числа.

Аутентификация клиента и сервера

Алгоритм Диффи-Хеллмана позволяет двум сторонам получить закрытый секретный ключ. Но откуда обе стороны могут уверены, что разговаривают действительно друг с другом? Мы еще не говорили об аутентификации — клиент аутентицирует сервер, сервер аутенифицирует клиента.

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

$ ssh evgeniy@server.com # подтвердить отпечаток публичного хост-ключа
The authenticity of host 'server.com (123.123.123.123)' can't be established.
ED25519 key fingerprint is SHA256:kJO8Y9mRmYsL25Adz3IPlxAWeEjogBy6da+h8id3M1Q.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'server.com' (ED25519) to the list of known hosts.

С другой стороны, клиент должен пройти аутентификацию на сервере. Это можно сделать с помощью пароля или с помощью ключей. Клиент создает пару ключей, затем копирует свой публичный ключ на сервер, в специальный файл ~/.ssh/authorized_keys. Сервер использует этот публичный ключ для зашифровывания специального проверочного сообщения. Если клиент сможет его расшифровать — аутентификация успешна.

В HTTPS публичный ключ сервера называется сертификатом. Владелец сайта генерирует пару публичный-приватный ключ и просит третью сторону (Центр Сертификации, CA) подписать его публичный ключ. В результате публичный ключ распространяется с цифровой подписью, которую можно проверить публичным ключом третьей стороны.

Публичный ключ вместе с другой информацией для подписи (например, название домена) упаковывается в файл в специальном формате. Он называется — Certificate Signing Request (CSR), то есть «запроса на подпись сертификата». Данный запрос на подпись (CSR) отправляется в Центр Сертификации (CA), который подписывает эти данные своим приватным ключом и всё это упаковывается в другой специальный файл, называемый сертификат.

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

Утилита OpenSSL

Синтаксис утилиты openssl

$ openssl команда опции

Основные команды утилиты

genpkey (заменяет устаревшие genrsa и gendsa) — создание приватного ключа и параметров
genrsa (устарело) — создание приватного ключа RSA (рекомендуется использовать genpkey)
gendsa (устарело) — создание приватного ключа DSA из параметров (рекомендуется использовать genpkey и pkey)
dsaparam (устарело) — создание и управление параметрами DSA (рекомендуется использовать genpkey и pkeyparam)
pkeyparam — управление параметрами алгоритма открытого ключа
pkey (заменяет устаревшие rsa и dsa) — для работы с публичными и приватными ключами
rsa (устарело) — для работы с публичными и приватными ключами RSA (рекомендуется использовать pkey)
dsa (устарело) — для работы с публичными и приватными ключами DSA (рекомендуется использовать pkey)
req — для создания запросов на подпись сертификата и для создания самоподписанных сертификатов
x509 — для подписи сертификатов и для показа свойств сертификатов
ca — является минимальным CA-приложением. Может использоваться для подписи запросов на сертификаты в различных формах и генерировать списки отзыва сертификатов. Она также поддерживает текстовую базу данных выданных сертификатов и их статус.
enc — различные действий с симметричными шифрами

Примеры использования

1. Приватные и публичные ключи RSA

Создание приватного ключа RSA (асимметричное шифрование)

$ openssl genpkey -algorithm RSA -out private.key

Извлечение публичного ключа RSA из приватного (асимметричное шифрование)

$ openssl pkey -in private.key -pubout -out public.key # новый вариант
$ openssl rsa -in private.key -pubout -out public.key # старый вариант

Создание приватного ключа RSA, зашифрованного помощью aes-256-cbc

$ openssl genpkey -algorithm RSA -out private-passwd.key -aes-256-cbc
..........
Enter PEM pass phrase: пароль
Verifying - Enter PEM pass phrase: пароль

Извлечение публичного ключа RSA из зашифрованного приватного

$ openssl pkey -in private-passwd.key -pubout -out public-passwd.key # новый вариант
Enter pass phrase for private-passwd.key: пароль
$ openssl rsa -in private-passwd.key -pubout -out public-passwd.key # старый вариант
Enter pass phrase for private-passwd.key: пароль

Удалить пароль, которым защищен приватный ключ RSA

$ openssl pkey -in private-passwd.key -out private-no-passwd.key # новый вариант
Enter pass phrase for private-passwd.key: пароль
$ openssl rsa -in private-passwd.key -out private-no-passwd.key # старый вариант
Enter pass phrase for private-passwd.key: пароль

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

$ openssl pkey -in private-no-passwd.key -pubout -out public-no-passwd.key # новый вариант
$ openssl rsa -in private-no-passwd.key -pubout -out public-no-passwd.key # старый вариант

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

$ ls -la /home/evgeniy/rsa
итого 32
drwxrwxr-x  2 evgeniy evgeniy 4096 июн 16 12:20 .
drwxr-x--- 23 evgeniy evgeniy 4096 июн 16 11:36 ..
-rw-------  1 evgeniy evgeniy 1704 июн 16 11:42 private.key
-rw-------  1 evgeniy evgeniy 1704 июн 16 12:19 private-no-passwd.key
-rw-------  1 evgeniy evgeniy 1874 июн 16 12:09 private-passwd.key
-rw-rw-r--  1 evgeniy evgeniy  451 июн 16 11:57 public.key
-rw-rw-r--  1 evgeniy evgeniy  451 июн 16 12:20 public-no-passwd.key
-rw-rw-r--  1 evgeniy evgeniy  451 июн 16 12:11 public-passwd.key

$ cat /home/evgeniy/rsa/public-no-passwd.key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApbDSBbR8vZVUAce6+fYy
zMAnFYJyRTpXfSplaLMzt6lM2rbXikBenusA0qh6VWdwahhBdzHsFZFkOtOmpAv9
xr2cO37RtNOUhXPs2i8jOoGi0z4g/knTYfd/guxqXBrONw860KbLWLkyRwwsi+Sx
hNris1tlX0gcsZATSgVKkB/81yA9/BRyKfT/LfeTnJW0+Vgvh6IDI1r1XM5CZICG
1D2z0yXICTAbu3Biv1lDOpGkcGQbSzh5BjAOb9yhZy6iNHfnVxoQ7XPJgGju4SBB
1MHdg1MLnYHX2OyZvFwoodwAeXF1J7veX+3k5sBd88LR1VQNWkGZR/Qp3SYUaGOX
yQIDAQAB
-----END PUBLIC KEY-----
$ cat /home/evgeniy/rsa/public-passwd.key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApbDSBbR8vZVUAce6+fYy
zMAnFYJyRTpXfSplaLMzt6lM2rbXikBenusA0qh6VWdwahhBdzHsFZFkOtOmpAv9
xr2cO37RtNOUhXPs2i8jOoGi0z4g/knTYfd/guxqXBrONw860KbLWLkyRwwsi+Sx
hNris1tlX0gcsZATSgVKkB/81yA9/BRyKfT/LfeTnJW0+Vgvh6IDI1r1XM5CZICG
1D2z0yXICTAbu3Biv1lDOpGkcGQbSzh5BjAOb9yhZy6iNHfnVxoQ7XPJgGju4SBB
1MHdg1MLnYHX2OyZvFwoodwAeXF1J7veX+3k5sBd88LR1VQNWkGZR/Qp3SYUaGOX
yQIDAQAB
-----END PUBLIC KEY-----

Зашифровать существующий приватный ключ с использованием aes-256-cbc

$ openssl pkey -in private.key -out private-add-passwd.key -aes-256-cbc # новый вариант
Enter pass phrase: пароль
Verifying - Enter pass phrase: пароль
$ openssl rsa -in private.key -out private-add-passwd.key -aes-256-cbc # старый вариант
Enter pass phrase: пароль
Verifying - Enter pass phrase: пароль

Создадим публичный ключ из приватного, на который поставили пароль

$ openssl pkey -in private-add-passwd.key -pubout -out public-add-passwd.key # новый вариант
Enter pass phrase for private-add-passwd.key: пароль
$ openssl rsa -in private-add-passwd.key -pubout -out public-add-passwd.key # старый вариант
Enter pass phrase for private-add-passwd.key: пароль

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

$ ls -la /home/evgeniy/rsa
итого 40
drwxrwxr-x  2 evgeniy evgeniy 4096 июн 16 12:33 .
drwxr-x--- 23 evgeniy evgeniy 4096 июн 16 11:36 ..
-rw-------  1 evgeniy evgeniy 1874 июн 16 12:30 private-add-passwd.key
-rw-------  1 evgeniy evgeniy 1704 июн 16 11:42 private.key
-rw-------  1 evgeniy evgeniy 1704 июн 16 12:19 private-no-passwd.key
-rw-------  1 evgeniy evgeniy 1874 июн 16 12:09 private-passwd.key
-rw-rw-r--  1 evgeniy evgeniy  451 июн 16 12:33 public-add-passwd.key
-rw-rw-r--  1 evgeniy evgeniy  451 июн 16 11:57 public.key
-rw-rw-r--  1 evgeniy evgeniy  451 июн 16 12:20 public-no-passwd.key
-rw-rw-r--  1 evgeniy evgeniy  451 июн 16 12:11 public-passwd.key

$ cat /home/evgeniy/rsa/public-add-passwd.key 
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmuEG870qKJdQBfbP/HCf
ckgb729oagckPKxweo7Tz6ZNPSE0iGfOdUR1a0cL9dxvIhQT/dkeTiGopNRBDvkM
0SuLnTY//itxNNg8EgD6x9IeXL9C/DqaQ+LyM5A7Patsb4M8a7lMOM7Rtx3AXfWJ
oQSh16HDsxZZM7HlTtptTwInOAIZ8Wb7VZwcOuZQYfO6J1eD5OdSvNWWf2GAbhIv
g0ghNb4O2txgCPPwo0ONWzPmDpOYQLkzGKaBkKezySK4U/ZoFC0Pe6Sf4ywBrfrN
8Jp5g4QPJ1V7Lsr/lOThvJffJypFaMYM/kqomgiOVNB6EwUc/t62yIn1XSNc/gCz
YQIDAQAB
-----END PUBLIC KEY-----
$ cat /home/evgeniy/rsa/public.key 
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmuEG870qKJdQBfbP/HCf
ckgb729oagckPKxweo7Tz6ZNPSE0iGfOdUR1a0cL9dxvIhQT/dkeTiGopNRBDvkM
0SuLnTY//itxNNg8EgD6x9IeXL9C/DqaQ+LyM5A7Patsb4M8a7lMOM7Rtx3AXfWJ
oQSh16HDsxZZM7HlTtptTwInOAIZ8Wb7VZwcOuZQYfO6J1eD5OdSvNWWf2GAbhIv
g0ghNb4O2txgCPPwo0ONWzPmDpOYQLkzGKaBkKezySK4U/ZoFC0Pe6Sf4ywBrfrN
8Jp5g4QPJ1V7Lsr/lOThvJffJypFaMYM/kqomgiOVNB6EwUc/t62yIn1XSNc/gCz
YQIDAQAB
-----END PUBLIC KEY-----

Давайте еще посмотрим на приватные ключи с паролем и без пароля

$ cat /home/evgeniy/rsa/private-passwd.key 
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFLTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQIXOczenHvUAACAggA
MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAEqBBCK4QlTnqw19dst2ndQp/5GBIIE
0ABTf/vbIfX1wqOmTWnwVgmAVAJ9MXBCSIwl6UOBqX8fEUN8umDvtVOlIY6ky7hM
..........
lRog7FAR1GjG82j2m5B2u5f6d0x9aWzYNMNTcUw8YE/toiau+ki7hAvGEvkkApyQ
CsAvDVvppum9VkvcXvELI4R2h/G3wOimC7SHN2p9BQb/CpNAuhDsDKo3G1MdBjWZ
AyUd9yR/PFUwE9AEb7oCUeco7Ga7IyIwJ3wwozcbdn+r
-----END ENCRYPTED PRIVATE KEY-----

$ cat /home/evgeniy/rsa/private.key 
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCa4QbzvSool1AF
9s/8cJ9ySBvvb2hqByQ8rHB6jtPPpk09ITSIZ851RHVrRwv13G8iFBP92R5OIaik
1EEO+QzRK4udNj/+K3E02DwSAPrH0h5cv0L8OppD4vIzkDs9q2xvgzxruUw4ztG3
..........
HlY0xaE+AewBRc8Wpg/qGTl7FyVZPSbJZGYtg7ntgm3GjS0FRmwW7VbpEakUUq1o
QFiQJLy18+vt+dI2UftSA3a4nxUDDTxj/Ix+KqCo49H+gISLk5dVis2zwNf8d13o
f/TKn5Eh+oIp8lDOiF7i6Gie
-----END PRIVATE KEY-----

2. Приватные и публичные ключи DSA

Для создания приватного ключа DSA необходимо выполнить два шага

$ openssl genpkey -genparam -algorithm DSA -out dsaparam.pem -pkeyopt dsa_paramgen_bits:2048 # новый вариант
$ openssl genpkey -paramfile dsaparam.pem -out private.key # новый вариант

$ openssl dsaparam -out dsaparam.pem 2048 # старый вариант
$ openssl gendsa -out private.key dsaparam.pem # старый вариант

На первом шаге создается файл параметров DSA dsaparam.pem, который содержит инструкции для OpenSSL по созданию на втором шаге ключа размером 2048 бит. Файл dsaparam.pem не является ключом, поэтому его можно удалить после создания открытого и закрытого ключей. На втором шаге генерируется закрытый ключ private.key.

Извлечение публичного ключа DSA из приватного

$ openssl pkey -in private.key -pubout -out public.key # новый вариант
$ openssl dsa -in private.key -pubout -out public.key # старый вариант

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

SSL (TLS) сертификат для сайта

Допустим, у нас есть тестовый веб-сервер и нужно выпустить сертификат для локального домена example.com — это делается в несколько этапов.

Сначала создаем приватный ключ Центра Сертификации (Certificate Authority, CA). Потом создаем самоподписанный сертификат Центра Сертификации, который надо добавить в доверенные в браузере. По сути, этот сертификат является публичным ключом, в который добавлена информация о Центре Сертификации + электронная подпись приватным ключом.

Далее создаем приватный ключ для домена example.com + создаем запрос на подпись сертифката для домена example.com в Центре Сертфикации. Запрос на подпись содержит публичный ключ для домена + имя домена + информацию об организации. После того, как публичный ключ будет подписан — добавляем сертификат для домена в файл конфигурации веб-сервера.

На самом деле, приватный ключ веб-сервера и приватный ключ Центр Сертификации (CA) по своей природе ничем не отличаются — они генерируются одной и той же командой. Но Центр Сертификации (CA) имеет особый статус постольку:

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

1. Создание локального Центра Сертификации

Создаем отдельную директорию, где будем создавать публичные и приватные ключи, запросы на подпись, подписывать сертифиакты для доменов приватным ключом CA и т.п.

$ mkdir ~/ca
$ chdir ~/ca

Создание приватного ключа RSA Центра Сертификации

$ openssl genpkey -algorithm RSA -out root-ca.key

Создание приватного ключа RSA Центра Сертификации, зашифрованного с помощью aes-256-cbc

$ openssl genpkey -algorithm RSA -pass pass:qwerty -out root-ca.key -aes-256-cbc

2. Самоподписанный сертификат Центра Сертификации

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

$ openssl req -x509 -new -days 3650 -key root-ca.key -out root-ca.crt
..........
Country Name (2 letter code) [AU]: RU
State or Province Name (full name) [Some-State]: CA
Locality Name (eg, city) []: CA
Organization Name (eg, company) [Internet Widgits Pty Ltd]: CA
Organizational Unit Name (eg, section) []: CA
Common Name (e.g. server FQDN or YOUR name) []: CA
Email Address []: CA

Чтобы не вводить все эти значения — можно указать их с помощью опции -subj.

$ openssl req -x509 \
>    -new \
>    -key root-ca.key \
>    -days 3650 \
>    -subj "/C=RU/ST=CA/L=CA/O=CA/OU=CA/CN=CA" \
>    -out root-ca.crt

Опция -new означает создание нового сертификата. Команда req -x509 означает не создание запроса на подпись, а подпись приватным ключом CA. Опция -key указывает на имя файла приватного ключа. Опция -days — это срок действия сертификата Центра Сертификации.

Теперь нужно скопировать корневой сертификат root-ca.crt на свой компьютер и добавить его в доверенные в браузере. Для примера, в браузере Chrome нужно зайти в настройки, перейти в «Безопасность и конфиденциальность», потом «Безопасность», дальше «Настроить сертификаты». И добавить сертификат в «Доверенные корневые центры сертификации».

3. Создание приватного ключа для домена

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

$ openssl genpkey -algorithm RSA -out example-com.key

4. Создание запроса на подпись сертификата

Создание запроса на подпись в Центр Сертификации

$ openssl req -new \
>    -key example-com.key \
>    -subj "/C=RU/ST=Demo/L=Demo/O=Demo/OU=Demo/CN=example.com" \
>    -addext "subjectAltName=DNS:example.com,DNS:www.example.com" \
>    -out example-com.csr

Файл запроса на подпись, кроме публичного ключа содержит дополнительную информацию о домене и организации, которая контролирует этот домен. Эту информацию можно задать с помощью опции -subj или просто ответить на вопросы. Опция -new говорит о необъодимости создания нового запроса на подпись.

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

$ openssl req \
>    -newkey rsa:2048 \
>    -noenc \
>    -subj "/C=RU/ST=Demo/L=Demo/O=Demo/OU=Demo/CN=example.com" \
>    -addext "subjectAltName=DNS:example.com,DNS:www.example.com" \
>    -keyout example-com.key \
>    -out example-com.csr

5. Подписывание сертификата для домена в CA

Подписывание сертификата для домена приватным ключом CA и получение сертификата для домена на год

$ openssl req -x509 \
>    -in example-com.csr \
>    -CA root-ca.crt \
>    -CAkey root-ca.key \
>    -days 365 \
>    -out example-com.crt \
>    --copy_extensions=copyall

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

6. Изменение файла конфигурации веб-сервера

Конфигурация для веб-сервера Nginx

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

    root /var/www/example.com/html/;
    index index.php index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    ssl_certificate /etc/ssl/certs/example-com.crt;
    ssl_certificate_key /etc/ssl/private/example-com.key;

    access_log /var/log/nginx/example.com-access.log;
    error_log /var/log/nginx/example.com-error.log error;
}

Конфигурация для веб-сервера Apache

<VirtualHost *:80 *:443>
    ServerName example.com
    ServerAdmin webmaster@example.com

    <IfModule ssl_module>
        SSLEngine On
        SSLCertificateFile /etc/ssl/certs/example-com.crt
        SSLCertificateKeyFile /etc/ssl/private/example-com.key
    </IfModule>

    <IfModule rewrite_module>
        RewriteEngine On
        RewriteCond %{HTTPS} =off
        RewriteRule .* https://example.com%{REQUEST_URI} [R=301]
    </IfModule>

    DocumentRoot /var/www/example.com/html
    DirectoryIndex index.php index.html
    Options -Indexes

    ErrorLog ${APACHE_LOG_DIR}/example-com-error.log
    CustomLog ${APACHE_LOG_DIR}/example-com-access.log combined
</VirtualHost>

7. Сертификат для домена одной командой

Мы уже говорили выше, что приватный ключ CA и приватный ключ для домена ничем не отличаются. Так что можно создать сертификат для домена example.com, который будет подписан приватным ключом для этого домена. В этом случае мы добавляем этот сертифкат в доверенные в браузере, а не сертификат CA.

$ openssl req \
>    -newkey rsa:2048 \
>    -noenc \
>    -x509 \
>    -days 365 \
>    -subj "/C=RU/ST=Demo/L=Demo/O=Demo/OU=Demo/CN=example.com" \
>    -addext "subjectAltName=DNS:example.com,DNS:www.example.com" \
>    -keyout example-com.key \
>    -out example-com.crt

Эта команда фактически выполняет три операции — создание приватного ключа, создание временного CSR, подпись запроса приватным ключом.

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

Дополнительно

Поиск: HTTP • HTTPS • SSL • Ключ • Команда • OpenSSL • шифрование • сертификат • RSA • DSA