OpenSSL
http://www.opennet.ru/base/sec/openssl.txt.html
RFC про PKI: https://tools.ietf.org/html/rfc5280
Рекомендуется использовать бинари одной версии
Иначе все может сломаться и раздебажить будет крайне сложно
Перед началом работы нужно понимать какая версия openssl у тебя установлена
root@postgres-client:~# openssl version
OpenSSL 1.1.1d 10 Sep 2019
Ключ -a покажет много дополнительной информации
Например OPENSSLDIR в которую будет ходить openssl за конфигурацией и сертами
-d - покажет только ssldir
root@postgres-client:~# openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
root@postgres-client:~# ls -lh /usr/lib/ssl
total 4.0K
lrwxrwxrwx 1 root root 14 Feb 17 01:08 certs -> /etc/ssl/certs
drwxr-xr-x 2 root root 4.0K Mar 4 12:48 misc
lrwxrwxrwx 1 root root 20 Feb 17 01:08 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx 1 root root 16 Feb 17 01:08 private -> /etc/ssl/private
Обычно в ней каходятся ссылки на /etc/ssl/
Так как это дефолтная папка для сертов в линуксе
Папка misc содержит несколько скриптов, некоторые из них нужны для создания CA
Скачать исходники можно тут
https://www.openssl.org/source/
Простейшая сборка
./config
make
make install
config - имеет разные параметры, можно собрать под себя
После сборки и установки у меня стало доступно два openssl
root@postgres-client:~# /usr/bin/openssl version
OpenSSL 1.1.1d 10 Sep 2019
root@postgres-client:~# /usr/local/bin/openssl version
OpenSSL 1.1.1j 16 Feb 2021 (Library: OpenSSL 1.1.1d 10 Sep 2019)
Папки private/ и certs/ изначально пустые, это потому что изначально у вас еще нет приватных ключей и доверенных сертификатов
Но так как это лишь ссылки на такие же папки в /etc/, то в certs уже могут быть доверенные сертификаты которые туда положила ОС
openssl это криптографический тулкит, который состоит из множества различных утилит (ниже видно насколько их много)
root@postgres-client:~# /usr/local/bin/openssl help
Standard commands
asn1parse ca ciphers cms
crl crl2pkcs7 dgst dhparam
dsa dsaparam ec ecparam
enc engine errstr gendsa
genpkey genrsa help list
nseq ocsp passwd pkcs12
pkcs7 pkcs8 pkey pkeyparam
pkeyutl prime rand rehash
req rsa rsautl s_client
s_server s_time sess_id smime
speed spkac srp storeutl
ts verify version x509
Message Digest commands (see the `dgst' command for more details)
blake2b512 blake2s256 gost md4
md5 mdc2 rmd160 sha1
sha224 sha256 sha3-224 sha3-256
sha3-384 sha3-512 sha384 sha512
sha512-224 sha512-256 shake128 shake256
sm3
Cipher commands (see the `enc' command for more details)
aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb
aes-256-cbc aes-256-ecb aria-128-cbc aria-128-cfb
aria-128-cfb1 aria-128-cfb8 aria-128-ctr aria-128-ecb
aria-128-ofb aria-192-cbc aria-192-cfb aria-192-cfb1
aria-192-cfb8 aria-192-ctr aria-192-ecb aria-192-ofb
aria-256-cbc aria-256-cfb aria-256-cfb1 aria-256-cfb8
aria-256-ctr aria-256-ecb aria-256-ofb base64
bf bf-cbc bf-cfb bf-ecb
bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc
camellia-192-ecb camellia-256-cbc camellia-256-ecb cast
cast-cbc cast5-cbc cast5-cfb cast5-ecb
cast5-ofb des des-cbc des-cfb
des-ecb des-ede des-ede-cbc des-ede-cfb
des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb
des-ede3-ofb des-ofb des3 desx
idea idea-cbc idea-cfb idea-ecb
idea-ofb rc2 rc2-40-cbc rc2-64-cbc
rc2-cbc rc2-cfb rc2-ecb rc2-ofb
rc4 rc4-40 seed seed-cbc
seed-cfb seed-ecb seed-ofb sm4-cbc
sm4-cfb sm4-ctr sm4-ecb sm4-ofb
Вырезка выше состоит из нескольких частей:
- Commands
- Message Digest
- Ciphers
openssl не поставляет с собой каких либо корневых сертов
Но, как описано выше, можно использовать ОСные серты, это считается нормой
Но они могут быть устаревшими, например когда мы установили ультрадревний дистрибутив
Есть вот такой регулярно обновляемый сертстор от мозиллы:
https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
Но он в их личном формате, что может быть не очень удобно
Есть еще от курла:
http://curl.haxx.se/docs/caextract.html
Он в формате PEM (Privacy-Enhanced Mail)
Но если сильно хочется мозилловский, то есть масса конвертеров на разных языках
Perl: https://raw.githubusercontent.com/bagder/curl/master/lib/mk-ca-bundle.pl
root@postgres-client:~# perl mk-ca-bundle.pl
SHA256 of old file: 0
Downloading certdata.txt ...
Get certdata with curl!
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1141k 100 1141k 0 0 125k 0 0:00:09 0:00:09 --:--:-- 203k
Downloaded certdata.txt
SHA256 of new file: 3bdc63d1de27058fec943a999a2a8a01fcc6806a611b19221a7727d3d9bbbdfd
Processing 'certdata.txt' ...
Done (129 CA certs processed, 20 skipped).
Он сам скачает и создаст ca-bundle.crt в котором куча сертов
Можно в крон засунуть и он будет апдейтить
Создание сертификата состоит из нескольких этапов:
- Генерация приватного ключа
- Создание Certificate Signing Request (CSR)
- Отправка CSR в CA
- Получение сертификата от CA
Прежде чем генерировать приватный ключ нужно принять несколько решений:
- Алгоритм - openssl умеет rsa, dsa, ecdsa, каждый алгоритм имеет преимущества в разных сценариях использования
- Размер ключа - дефолтные значения величины ключа могут быть не очень безопасными, короткие ключи легче перебрать брут форсом, ну а сверхдлинные требуют больше ресурсов для работы
- Пароль ключа - использование пароля для ключа - опционально, но рекомендуемо, так как защищенные ключи могут безопасно храниться, переноситься и бэкапиться. Иногда запароленные ключи будут доставлять неудобства, например нужно будет постоянно вводить пароль при рестарте сервера. В продакшне пароли не приносят большей безопасности
Для генерации rsa ключа:
root@mars:/var/tmp/test# /usr/local/bin/openssl genrsa -aes128 -out fd.key 16384
Generating RSA private key, 16384 bit long modulus (2 primes)
........................+++
..........................................................................................................................................................................................+++
e is 65537 (0x010001)
Enter pass phrase for fd.key:
Verifying - Enter pass phrase for fd.key:
root@mars:/var/tmp/test# ls -lh
total 16K
-rw------- 1 root root 13K Mar 15 14:00 fd.key
Выше я сгенерил максимально длинный (можно и длинее, но не рекомендуется)
Может показаться что ключ это просто кусок рандомных данных, на самом деле у него есть структура которую можно посмотреть так:
(на примере более короткого ключа, у длинного который выше слишком длинный вывод)
root@mars:/var/tmp/test# openssl rsa -in small.key -noout -text
Enter pass phrase for small.key:
RSA Private-Key: (512 bit, 2 primes)
modulus:
00:92:8f:7d:3f:54:d1:ea:4a:e9:5f:25:f4:24:5e:
3d:35:60:75:63:1b:20:4c:29:9a:c5:69:a7:4d:2b:
f2:e6:8e:04:c7:74:86:d8:ec:55:5b:1a:18:fa:1d:
4d:2e:68:b0:3c:b3:e1:a3:d3:af:00:81:89:0b:3b:
40:bb:4c:0e:21
publicExponent: 65537 (0x10001)
privateExponent:
57:44:f9:df:6c:32:52:c0:a8:95:ef:93:a0:d4:3c:
be:3b:e1:aa:51:cc:b9:8d:4c:8b:a0:8d:ee:75:ec:
fd:3b:4d:0e:f7:b1:af:ba:c3:ee:67:30:b8:ea:2a:
51:04:9e:e1:e1:a8:76:19:88:44:8c:55:60:78:cd:
3c:8e:0d:c1
prime1:
00:c2:16:d7:a0:25:17:1e:a1:37:56:3c:b4:ac:53:
42:66:d8:89:b6:6e:5c:bc:4d:d5:68:f9:f9:79:b6:
59:40:4f
prime2:
00:c1:4f:7e:24:af:8d:80:59:3f:a8:2f:1d:74:7d:
37:65:5f:8a:fa:e0:39:22:fe:1b:f2:d9:a3:b8:9a:
c2:3e:8f
exponent1:
57:3d:91:3a:88:b1:75:b1:1d:80:83:d4:ea:48:9a:
66:44:1a:d2:87:94:e3:87:50:cf:d8:dc:cc:5a:ac:
8f:7d
exponent2:
2d:ee:89:76:86:10:05:33:2f:a0:f2:b0:f9:00:d7:
ac:ca:aa:e7:39:67:da:1c:ae:df:61:3f:39:99:ec:
15:99
coefficient:
48:dd:15:cd:36:d6:72:cd:a8:47:9d:36:8b:b9:b8:
9b:3f:63:ee:02:0a:22:e9:a6:95:6c:aa:ba:4c:52:
ab:62
Вытащить из него публичный можно так:
root@mars:/var/tmp/test# openssl rsa -in small.key -pubout -out small.pub
Enter pass phrase for small.key:
writing RSA key
root@mars:/var/tmp/test# ls -lh
total 24K
-rw------- 1 root root 576 Mar 15 14:09 small.key
-rw-r--r-- 1 root root 182 Mar 15 14:24 small.pub
"Вытащить" это условно, приватный ключ содержит в себе компоненты (некоторые из которых нужны для ускорения шифрования/расшифрования)
Из этих компонентов можно получить публичный ключ (в случае rsa, у dsa другой механизм, что там да как я не знаю)
openssl rsa -in private.pem -text -noout | less
modulus - n
privateExponent - d
publicExponent - e
prime1 - p
prime2 - q
exponent1 - d mod (p-1)
exponent2 - d mod (q-1)
coefficient - (q^-1) mod p
Поэтому DSA используется для электронной подписи и процесс генерации у него иной:
openssl dsaparam -genkey 2048 | openssl dsa -out dsa.key -aes128
Generating DSA parameters, 2048 bit long prime
This could take some time
[...]
read DSA key
writing DSA key
Enter PEM pass phrase: ****************
Verifying - Enter PEM pass phrase: ****************
Как видно для разных алгоритмов используются разные команды (генерация rsa не похожа на генерацию dsa, легко запутаться)
Чтобы экономить время можно использовать универсальную команду openssl genpkey для генерации приватных ключей
Имея приватный ключ можно сгенерировать CSR
Ты формируешь что-то типо сертификата и отправляешь его на подпись в CA, чтобы он стал доверенным
root@mars:/var/tmp/test# openssl genrsa -out test.key 2048 ^C
root@mars:/var/tmp/test# openssl rsa -in test.key -pubout -out test.pub ^C
root@mars:/var/tmp/test# openssl req -new -key test.key -out test.csr ^C
root@mars:/var/tmp/test# openssl req -in test.csr -noout -text
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = RU, L = Saint-Petersburg, O = Vandud Ltd., CN = vandud.ru, emailAddress = test@vandud.ru
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ae:ce:40:5c:7a:ca:47:07:e7:8d:dc:e0:1e:91:
ba:e8:f5:61:66:ac:3c:c2:91:02:e0:68:92:29:ba:
01:a7:53:a1:2c:5a:eb:42:fc:37:cb:22:5b:41:92:
4d:b4:00:40:bd:18:52:7c:30:46:f9:03:97:06:d0:
2c:72:c6:26:49:be:ac:21:a1:48:fc:0d:33:44:2f:
8f:fe:ff:86:80:7f:d4:55:3e:9f:1d:cb:98:03:df:
3e:22:d4:47:a5:cf:2f:ea:9f:01:4b:e4:ac:9c:38:
48:33:e6:8e:16:6f:63:94:7d:33:04:ce:df:55:7c:
e8:42:d8:3c:cd:54:ad:44:44:ba:46:9b:91:72:9f:
55:8e:bc:a5:17:6c:e1:fb:1e:63:db:43:fc:0f:b1:
bf:7c:30:40:6e:92:2d:e5:f7:0a:3d:fe:4d:51:d2:
a6:4c:fb:34:43:3d:b8:d0:1d:80:31:d5:82:b1:8d:
61:4e:6e:c6:ad:79:28:d4:5f:b9:c9:c1:bc:23:34:
6d:8c:31:19:d8:42:ca:21:81:ff:c4:e5:2e:9a:b0:
21:80:52:36:89:6c:17:d6:f2:b5:ec:0a:6b:1c:eb:
19:41:20:59:ce:58:45:22:0a:05:de:a6:1f:82:d5:
31:fb:3d:7e:65:d6:fb:38:9d:f8:39:da:87:7c:72:
56:01
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
98:ea:53:c2:dd:00:0a:e1:0d:10:0e:f5:85:b4:84:2b:99:ed:
69:f9:3e:af:2b:d3:22:83:84:c1:64:47:b1:8e:40:3d:78:ce:
8c:a0:3a:b1:35:1c:3c:97:a2:e7:63:cf:cd:58:1b:29:c6:97:
ca:2c:09:67:08:6d:f1:8a:a3:80:c3:de:27:0a:cf:5e:77:a0:
38:94:8f:0d:0d:32:f0:40:da:5c:c6:de:a7:a8:a8:f2:45:60:
ce:a6:be:50:29:1b:08:21:e6:06:4a:b7:84:1f:87:2b:a3:b6:
18:ca:ef:7f:a8:33:60:9a:fe:32:18:a4:87:4b:e0:31:e6:de:
87:10:33:b5:9e:f7:4e:ab:fc:a4:53:88:34:74:cd:1b:e7:71:
11:60:6b:e8:e5:66:9e:43:55:4f:e5:fa:56:35:6b:25:e0:7c:
cf:a0:94:d0:ed:66:31:29:bd:46:2b:46:8e:13:f3:d0:99:8f:
5d:e6:bf:84:84:9a:fb:89:b7:e7:be:d9:65:02:66:4c:a5:12:
f4:f8:fe:b7:ec:cc:59:2d:af:1c:0f:75:b0:57:b5:f8:66:36:
12:16:49:ab:1e:9e:c5:bd:1d:15:7c:f9:34:f0:21:fa:0f:3f:
31:2f:d8:73:33:7f:89:01:6c:af:fd:3a:b0:61:d7:7a:68:83:
27:ce:f7:34
Генерация CSR это интерактивный процесс (то есть ты отвечаешь на вопросы)
В какой-то момент предлагается ввести пароль для CSR, его рекомендуется опустить, так как безопасности это не прибавляет, а проблем может доставить
CSR с дефолтными значениями (если ничего не вписывать, а просто щелкать enter, то openssl проставит свои дефолты, если все таки хочется оставить поле пустым то нужно вписать точку):
root@mars:/var/tmp/test# openssl req -new -key test.key -out test1.csr
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 Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
root@mars:/var/tmp/test# openssl req -in test1.csr -noout -text
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c4:48:03:11:5c:96:7a:5a:76:12:d2:65:16:e9:
a9:43:46:31:fb:67:83:62:e2:6b:62:b5:a9:7e:d1:
09:de:f5:22:2b:ce:20:38:3e:b9:50:87:0d:7e:b8:
90:11:07:ed:eb:85:2a:0a:eb:15:fb:17:83:39:28:
58:a1:0e:cc:5f:70:04:dc:f4:78:f2:cb:27:88:62:
cd:67:16:ca:42:c2:a5:a0:11:8b:35:10:c8:86:80:
12:b0:72:00:bb:8d:d5:b5:47:72:50:4f:81:ca:29:
72:c3:4f:1a:22:be:86:dc:2d:b9:b7:3b:59:32:45:
66:c5:7c:a3:26:37:fc:97:c3:ea:cc:1d:e5:ca:58:
7d:fa:53:0e:53:f3:94:8c:80:b7:8d:17:0a:6f:d1:
f0:cf:e9:47:bf:7a:69:62:82:90:4d:72:93:94:1d:
00:d8:9b:a6:57:e6:a8:e1:ad:26:5b:54:49:10:f9:
05:ed:8a:cd:93:20:de:76:a1:c3:e0:79:8e:01:7a:
96:5c:bf:e7:13:1a:68:f7:b8:30:07:c6:ce:7a:28:
1e:6e:82:ab:5a:98:f4:9b:a3:17:35:56:52:49:12:
73:41:2d:a8:d7:00:b1:02:52:5d:56:eb:f2:ca:d2:
4a:44:18:ab:c9:55:b3:38:37:09:64:87:e9:7b:fb:
ca:a7
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
4f:f8:28:32:3b:e4:09:1c:58:1d:7c:00:bf:92:3d:d2:18:e9:
50:12:a4:29:83:fe:be:a4:02:79:12:d1:04:4c:7f:ae:3d:ba:
45:c7:53:14:11:d3:b5:91:5f:a5:83:fb:84:d6:2e:3b:a7:7d:
5c:e5:18:48:e0:d6:17:7a:55:f1:31:71:96:6b:51:a0:1d:a1:
99:f8:e1:94:1e:02:c0:86:56:f1:7f:1e:73:42:16:dd:55:fb:
19:af:37:81:35:27:96:97:b1:35:ef:a3:0d:94:87:ea:d8:3c:
c4:13:c0:86:38:00:94:45:99:e8:6d:be:26:47:13:ee:cc:28:
bb:b8:5b:0a:71:44:76:92:39:bd:8b:55:0e:35:c1:30:8b:5e:
7d:7b:ba:7b:57:cb:8e:1f:30:73:06:cf:d1:6d:69:9e:14:84:
b3:82:19:56:73:88:8f:24:1b:21:ff:58:b6:49:dd:cf:7c:0b:
a2:84:fb:d6:67:db:7e:5e:1a:f3:8f:00:40:04:ad:7f:2c:2f:
c8:a9:5a:b8:78:73:4e:ce:79:12:64:ae:44:cf:27:d1:54:f9:
5e:1d:d9:b9:ed:0e:44:08:e8:9b:b9:2e:cc:6a:13:1e:47:ab:
7d:11:d4:e7:8a:16:9d:14:ac:12:f3:e7:37:13:4e:8c:78:b3:
bd:9d:74:f8
Дальше этот CSR отправляем на подпись в CA и получаем в ответ сертификат
csr to crt
root@mars:/var/tmp/test# openssl x509 -req -in test.csr -signkey test.key -out test.crt
Signature ok
subject=C = RU, L = Saint-Petersburg, O = Vandud Ltd., CN = vandud.ru, emailAddress = test@vandud.ru
Getting Private key
Для перевыпуска можно не писать кучу команд, а сформировать CSR на основе старого сертификата (в котором можно заменить ключ)
openssl x509 -x509toreq -in fd.crt -out fd.csr -signkey fd.key
Можно автоматизировать генерацию CSR с помощью конфигa:
root@mars:/var/tmp/test# cat test.conf
[req]
prompt = no
distinguished_name = dn
req_extensions = ext
[dn]
CN = www.vandudwithconf.com
emailAddress = webmaster@feistyduck.com
O = Feisty Duck Ltd
L = London
C = GB
[ext]
subjectAltName = DNS:www.feistyduck.com,DNS:feistyduck.com
root@mars:/var/tmp/test# openssl req -new -config test.conf -key test.key -out test3.csr
root@mars:/var/tmp/test# openssl req -in test3.csr -noout -text
Certificate Request:
Data:
Version: 1 (0x0)
Subject: CN = www.vandudwithconf.com, emailAddress = webmaster@feistyduck.com, O = Feisty Duck Ltd, L = London, C = GB
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c4:48:03:11:5c:96:7a:5a:76:12:d2:65:16:e9:
a9:43:46:31:fb:67:83:62:e2:6b:62:b5:a9:7e:d1:
09:de:f5:22:2b:ce:20:38:3e:b9:50:87:0d:7e:b8:
90:11:07:ed:eb:85:2a:0a:eb:15:fb:17:83:39:28:
58:a1:0e:cc:5f:70:04:dc:f4:78:f2:cb:27:88:62:
cd:67:16:ca:42:c2:a5:a0:11:8b:35:10:c8:86:80:
12:b0:72:00:bb:8d:d5:b5:47:72:50:4f:81:ca:29:
72:c3:4f:1a:22:be:86:dc:2d:b9:b7:3b:59:32:45:
66:c5:7c:a3:26:37:fc:97:c3:ea:cc:1d:e5:ca:58:
7d:fa:53:0e:53:f3:94:8c:80:b7:8d:17:0a:6f:d1:
f0:cf:e9:47:bf:7a:69:62:82:90:4d:72:93:94:1d:
00:d8:9b:a6:57:e6:a8:e1:ad:26:5b:54:49:10:f9:
05:ed:8a:cd:93:20:de:76:a1:c3:e0:79:8e:01:7a:
96:5c:bf:e7:13:1a:68:f7:b8:30:07:c6:ce:7a:28:
1e:6e:82:ab:5a:98:f4:9b:a3:17:35:56:52:49:12:
73:41:2d:a8:d7:00:b1:02:52:5d:56:eb:f2:ca:d2:
4a:44:18:ab:c9:55:b3:38:37:09:64:87:e9:7b:fb:
ca:a7
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:www.feistyduck.com, DNS:feistyduck.com
Signature Algorithm: sha256WithRSAEncryption
b8:f9:45:9e:2c:af:80:7b:06:3a:eb:77:3b:86:b6:16:2d:bb:
71:56:c4:fd:e4:25:db:39:be:3f:3e:45:32:f9:df:61:dd:0d:
ab:51:42:f0:ad:ba:25:42:5b:49:14:e0:ad:2d:9c:14:35:93:
ea:ea:4c:96:ad:da:20:95:fd:ea:4e:4f:05:a5:64:d0:37:18:
98:60:91:3a:15:aa:15:3a:80:df:44:d6:57:6c:a8:16:6d:ba:
ff:ba:b3:42:84:5c:86:8c:75:70:08:d9:b1:88:d8:97:10:fd:
5c:d2:28:9a:64:c7:1a:6a:ee:f3:2b:4a:f7:40:74:e3:ef:7c:
f1:fc:f2:c9:97:c2:97:4b:50:7a:1a:4f:e7:a2:96:12:65:db:
75:24:0b:0c:f4:0c:a8:6f:66:9c:3f:16:27:9e:d4:20:15:ca:
6a:36:58:0a:40:82:c8:22:e5:ac:6e:08:17:83:1f:8a:2b:64:
ba:4c:c1:74:40:91:4c:00:8f:f4:1c:92:75:ba:4a:26:55:48:
3c:76:72:52:3f:33:2e:e5:22:bd:01:33:ac:78:9f:70:68:54:
24:d1:3b:d2:2e:92:a4:db:34:6f:be:ec:ff:cd:6d:08:6a:62:
88:07:81:12:b3:52:2f:33:cb:d6:71:0a:6a:b6:f5:85:7a:1c:
26:51:dd:a5
Сгенерить самосерт так:
root@mars:~/nginx# openssl genrsa -out vandud.key 4096
root@mars:~/nginx# openssl req -new -x509 -days 10 -key vandud.key -out vandud.crt
Дефолтный серт поддерживает один хостнейм
Но в наши дни такой подход не годится, требуется мультидоменность
Расширения X509 позволяет это сделать
X509 дает еще массу полезных возможностей
Например CRL и механизм проверки пути сертификации
Когда серт имеет alternative names, common names игнорятся. Поэтому нужно перечислять все домены в altnames
Можно перечислить все расширения которые тебе нужны в текстовом файле
Пример:
root@mars:/var/tmp/test# cat test.ext
subjectAltName = DNS:ext.vandud.ru, DNS:*.vandud.ru
# Подписываю CSR
root@mars:/var/tmp/test# openssl x509 -req -in test.csr -signkey ca.key -out test.crt -extfile test.ext
Signature ok
subject=C = RU, ST = SAINT-P., L = SAINT-P., O = Sub Unit, OU = au, CN = auo.aeu.au
Getting Private key
# Получили Subject Alternative Name в серте
root@mars:/var/tmp/test# openssl x509 -in test.crt -noout -text | grep X509 -A1
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:ext.vandud.ru, DNS:*.vandud.ru
У сертификатов есть basic constraints, оно указывет пренадлежит ли серт CA и годен ли он для подписи других сертов
У не CA сертов это расширение опущено или установлено в FALSE
X509v3 Basic Constraints: critical
CA:FALSE
Key Usage (KU) и Extended Key Usage (EKU) ограничивают места применения серта
Серты могут использоваться для подписи других сертов, для подписи файлов, для подписи ...
Расширение CRL Distribution Points указывет где можно найти CRL этого CA
root@mars:/var/tmp/test# wget crl.starfieldtech.com/sfs3-20.crl -q
root@mars:/var/tmp/test# openssl crl -in sfs3-20.crl -inform der -noout -text
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU = http://certificates.starfieldtech.com/repository, CN = Starfield Secure Certification Authority, serialNumber = 10688435
Last Update: Mar 16 12:05:46 2021 GMT
Next Update: Mar 23 12:05:46 2021 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:49:4B:52:27:D1:1B:BC:F2:A1:21:6A:62:7B:51:42:7A:8A:D7:D5:56
DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
serial:02:01
X509v3 CRL Number:
3588
X509v3 Issuing Distribution Point: critical
Full Name:
URI:http://crl.starfieldtech.com/sfs3-20.crl
No Revoked Certificates.
Signature Algorithm: sha256WithRSAEncryption
75:2f:f7:ba:da:67:88:7d:f8:a5:02:9c:9d:0d:8c:4b:e9:6c:
56:2c:b7:77
...
:78:76:9e:d1:5e:f9:6b:ab:a3:47:d0:fd:45:4a:
fe:1e:de:6c
CRL распрастраняются по незащищенному соединению неспроста
За безопасность беспокоиться не стоит, потому что файл CRL подписан CA которому пренадлежит этот CRL
А распрастранять его по https нельзя, потому что может возникнуть проблема курицы и яйца (чтобы установить https подключение для получения crl нужно иметь этот crl)
CRL обновляется регулярно, обычно еженедельно
[22:36:30] vandud@macbook: tmp [0]$ openssl crl -in gds1-31.crl -inform DER -text -noout
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
Last Update: Mar 28 15:41:03 2021 GMT
Next Update: Apr 4 15:41:03 2021 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:FD:AC:61:32:93:6C:45:D6:E2:EE:85:5F:9A:BA:E7:76:99:68:CC:E7
DirName:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
serial:03:01
X509v3 CRL Number:
3748
X509v3 Issuing Distribution Point: critical
Full Name:
URI:http://crl.godaddy.com/gds1-31.crl
No Revoked Certificates.
Signature Algorithm: sha256WithRSAEncryption
bd:9e:86:f8:bf:5d:3a:0f:12:b2:b3:48:a1:0f:88:96:43:f4:
d7:ea:dc:73:a5:44:0b:c7:e6:d6:fc:95:52:66:bc:8b:a9:02:
d3:73:68:dc:f5:fd:e3:f1:0a:c7:c7:da:5f:7e:47:8f:8e:44:
ad:53:79:b9:75:b1:98:f6:74:b9:65:bd:40:51:fe:1f:20:b6:
50:a7:63:2f:1e:83:00:f2:94:4a:48:3c:df:4e:0b:8f:6c:75:
c2:d8:cc:2b:75:c7:61:ad:a3:2b:7d:78:d7:69:cf:8a:8b:11:
3b:57:23:2a:53:c3:f3:9e:6e:a2:53:c1:d6:2c:5d:da:e3:0c:
38:85:f7:24:16:0e:47:d9:f7:76:87:ad:ae:63:2d:46:2a:34:
0e:ba:16:4a:07:76:60:34:e4:07:d0:84:a4:0e:46:6e:95:1a:
26:0b:cf:f0:e9:d0:53:8b:4f:ce:ec:86:04:13:9d:e1:1f:58:
d3:a1:d0:6a:ad:23:a6:1a:a5:77:6e:b0:eb:a3:a8:ce:e9:c4:
a6:ca:a8:31:d6:2e:3a:46:9b:e9:1f:d7:9f:20:76:75:13:eb:
f2:fd:af:15:b4:db:a4:d0:be:a7:39:73:51:5a:82:c0:b2:2f:
e2:bc:dd:03:cc:aa:02:9e:c3:db:0a:3a:d6:27:eb:9e:1c:9d:
f4:44:a5:79
Certificate Policies и CPS (certificate policy statment)
X509v3 Certificate Policies:
Policy: 2.16.840.1.114413.1.7.23.1
CPS: https://certs.godaddy.com/repository/
Это расширение используется для указания политики под которой был выдан серт
Например это то место по которому бразуер понимер DV, OV или EV серт перед ним
Браузер понимает что перед ним EV сертификат благодаря то что в коде браузера зашиты OID'ы
https://hg.mozilla.org/mozilla-central/file/eab4a81e4457/security/certverifier/ExtendedValidation.cpp
- Список адресов OCSP респондеров центра сертификации (Online Certificate Status Protocol) которые могут быть использованы для проверки того отозван ли серт в реальном времени
- Также это расширение может содержать ссылку на сертификат эмитента (следующий в цепочке серт)
Authority Information Access:
CA Issuers - URI:http://crt.usertrust.com/GandiStandardSSLCA2.crt
OCSP - URI:http://ocsp.usertrust.com
Пользователи часто ошибаются (или забыват) и кладут невалидные серты в цепочку, браузер благодаря этому расширению может самостоятельно собрать валидную цепочку
Subject Key Identifier и Authority Key Identifier это уникальные идентификаторы которые помогают выбрать нужный серт для построения цепочки
Дело в том что ЦА часто используют один приватный ключ в множестве сертификатов
В реальном мире много цепочек поставляемых серверами - невалидные, но это не мешает браузерам строить правильные цепочки самостоятельно по альтернативным путям
root@mars:/var/tmp/a# echo | openssl s_client -connect online.sberbank.ru:443 -servername online.sberbank.ru > online.sberbank.ru.crt 2>/dev/null
root@mars:/var/tmp/a# openssl x509 -in online.sberbank.ru.crt -noout -ext authorityInfoAccess
Authority Information Access:
OCSP - URI:http://status.thawte.com
CA Issuers - URI:http://cacerts.thawte.com/ThawteEVRSACA2018.crt
root@mars:/var/tmp/a# wget http://cacerts.thawte.com/ThawteEVRSACA2018.crt -q
root@mars:/var/tmp/a# openssl x509 -in ThawteEVRSACA2018.crt -inform der -out ThawteEVRSACA2018.pem.crt -outform pem
root@mars:/var/tmp/a# openssl x509 -in online.sberbank.ru.crt -noout -ext authorityKeyIdentifier
X509v3 Authority Key Identifier:
keyid:E7:01:FC:0C:16:18:CA:7D:B2:8C:EC:87:27:A3:6F:61:81:3B:84:39
root@mars:/var/tmp/a# openssl x509 -in ThawteEVRSACA2018.pem.crt -noout -ext subjectKeyIdentifier
X509v3 Subject Key Identifier:
E7:01:FC:0C:16:18:CA:7D:B2:8C:EC:87:27:A3:6F:61:81:3B:84:39
Subject Alternative Name это расширение позволяет перечислить все имена для которых этот сертификат валиден
Если его нет то используется поле CN (Common Name) из Subject
Если расширение Subject Alt Name есть, то Common Name игнорируется и инфа берется только из расширения
root@mars:/var/tmp/a# openssl x509 -in online.sberbank.ru.crt -noout -subject
subject=businessCategory = Private Organization, jurisdictionC = RU, serialNumber = 1027700132195, C = RU, L = Moscow, O = Sberbank of Russia, CN = online.sberbank.ru
root@mars:/var/tmp/a# openssl x509 -in online.sberbank.ru.crt -noout -ext subjectAltName
X509v3 Subject Alternative Name:
DNS:online.sberbank.ru
Ключи и сертификаты могут храниться в разных форматах, поэтому часто можно иметь необходимость преобразовывать одно в другое
- Binary (DER) certificate - Содержит x.509 серт в сырой форме
- ASCII (PEM) certificate - Содержит DER закодированный в Base64 и обрамленный в '-----BEGIN CERTIFICATE-----' и '-----END CERTIFICATE-----'. Обычно используется один серт на один файл, но зависит от ПО
- Binary (DER) key - Содерджит приватный ключ в сыром виде
- ASCII (PEM) key - Ключ в Base64, иногда с дополнительной метадатой
- PKCS#7 certificate - Сложный формат для передачи подписанных или зашифрованных данных
- PKCS#12 (PFX) key and certificate - Сложный формат, позволяет хранить и защищать ключ и полную цепочку сертификатов. Обычно используется в microsoft'овских продуктах
Для конвертации из PEM в DER и наоборот есть очень простые команды
openssl x509 -inform PEM -in fd.pem -outform DER -out fd.der
openssl x509 -inform DER -in fd.der -outform PEM -out fd.pem
Для ключей то же самое
root@mars:/var/tmp/a# openssl rsa -in key.pem -inform PEM -out key.der -outform DER
writing RSA key
root@mars:/var/tmp/a# openssl rsa -in key.der -inform DER -out key.pem2 -outform PEM
writing RSA key
root@mars:/var/tmp/a# diff key.pem key.pem2
Чтобы засунуть PEM серт, ключ и промежуточные сертификаты в PFX
openssl pkcs12 -export \
-name "My Certificate" \
-out fd.p12 \
-inkey fd.key \
-in fd.crt \
-certfile fd-chain.crt
Enter Export Password: ****************
Verifying - Enter Export Password: ****************
Вернуть обратно не так просто
Нужно выполнить команду которая преобразует все в PEM но засунет это в один файл
openssl pkcs12 -in fd.p12 -out fd.pem -nodes
А потом ты вручную все разделишь на серты и ключи
Есть еще такой вариант
$ openssl pkcs12 -in fd.p12 -nocerts -out fd.key -nodes
$ openssl pkcs12 -in fd.p12 -nokeys -clcerts -out fd.crt
$ openssl pkcs12 -in fd.p12 -nokeys -cacerts -out fd-chain.crt
Посмотреть доступные комплекты алгоритмов шифрования можно командой openssl ciphers, ключ -v для вербозности
root@mars:/var/tmp/a# openssl ciphers -v | head -3
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
Вывод содерджит:
| 1. Suite name | 2. Required minimum protocol version | 3. Key exchange algorithm | 4. Authentication algorithm | 5. Cipher algorithm and strength | 6. MAC (integrity) algorithm | 7. Export suite indicator |
|---|---|---|---|---|---|---|
| TLS_AES_256_GCM_SHA384 | TLSv1.3 | Kx=any | Au=any | Enc=AESGCM(256) | Mac=AEAD | |
| TLS_CHACHA20_POLY1305_SHA256 | TLSv1.3 | Kx=any | Au=any | Enc=CHACHA20/POLY1305(256) | Mac=AEAD | |
| TLS_AES_128_GCM_SHA256 | TLSv1.3 | Kx=any | Au=any | Enc=AESGCM(128) | Mac=AEAD |
Можно передать какое-то ключевое слово для поискa:
root@mars:/var/tmp/a# openssl ciphers -v 'SSLv3'
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
...
Есть имена групп, которыми обозначены некоторые часто импользуемые наборы шифров
Например по слову HIGH будут отобраны очень сильные шифры
root@mars:/var/tmp/a# openssl ciphers 'HIGH'
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:...
| Keyword | Meaning |
|---|---|
| DEFAULT | Список дефолтных шифров. Они определяются во время компиляции |
| COMPLEMENTOFDEFAULT | То что есть в ALL но не включено в DEFAULT |
| ALL | Все шифры кроме eNULL |
| COMPLEMENTOFALL | То что не включено в ALL - eNULL |
| HIGH | Сильнокриптильные шифры, сейчас это те у которых длина ключа больше 128 бит |
| MEDIUM | Среднекриптильные шифры |
| LOW | Слабокриптильные шифры, 64 или 56 битные алгоритмы |
| EXP, EXPORT | |
| TLSv1,SSLv3,SSLv2 | Тут понятно |
Можно делать выборку по алгоритму дайджеста
root@mars:/var/tmp/a# openssl ciphers -v 'MD5'
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5
| Keyword | Meaning |
|---|---|
| MD5 | Cipher suites using MD5. Obsolete and insecure |
| SHA, SHA1 | Cipher suites using SHA1 |
| SHA256 (v1.0.0+) | Cipher suites using SHA256 |
| SHA384 (v1.0.0+) | Cipher suites using SHA384 |
| Authentication keyword | Meaning |
|---|---|
| aDH | Cipher suites effectively using DH authentication, i.e., the certificates carry DH keys.(v1.0.2+) |
| aDSS, DSS | Cipher suites using DSS authentication, i.e., the certificates carry DSS keys |
| aECDH (v1.0.0+) | Cipher suites that use ECDH authentication |
| aECDSA (v1.0.0+) | Cipher suites that use ECDSA authentication |
| aNULL | Cipher suites offering no authentication. This is currently the anonymous DH algo-rithms. Insecure |
| aRSA | Cipher suites using RSA authentication, i.e., the certificates carry RSA keys |
| PSK | Cipher suites using PSK (Pre-Shared Key) authentication |
| SRP | Cipher suites using SRP (Secure Remote Password) authentication |
Key exchange algorithms:
| Keyword | Meaning |
|---|---|
| ADH | Anonymous DH cipher suites. Insecure |
| AECDH (v1.0.0+) | UAnonymous ECDH cipher suites. Insecure |
| DH | Cipher suites using DH (includes ephemeral and anonymous DH) |
| ECDH (v1.0.0+) | Cipher suites using ECDH (includes ephemeral and anonymous ECDH) |
| EDH (v1.0.0+) | Cipher suites using ephemeral DH key agreement |
| EECDH (v1.0.0+) | Cipher suites using ephemeral ECDH |
| kECDH (v1.0.0+) | Cipher suites using ECDH key agreement |
| kEDH | Cipher suites using ephemeral DH key agreements (includes anonymous DH) |
| kEECDH (v1.0.0+) | Cipher suites using ephemeral ECDH key agreement (includes anonymous ECDH) |
| kRSA, RSA | Cipher suites using RSA key exchange |
Cipher keywords:
| Keyword | Meaning |
|---|---|
| 3DES | Cipher suites using triple DES |
| AES | Cipher suites using AES |
| AESGCM (v1.0.0+) | Cipher suites using AES GCM |
| CAMELLIA | Cipher suites using Camellia |
| DES | Cipher suites using single DES. Obsolete and insecure |
| eNULL, NULL | Cipher suites that don’t use encryption. Insecure |
| IDEA | Cipher suites using IDEA |
| RC2 | Cipher suites using RC2. Obsolete and insecure |
| RC4 | Cipher suites using RC4. Insecure |
| SEED | Cipher suites using SEED |
Гостовские шифры
| Keyword | Meaning |
|---|---|
| @STRENGTH | Sorts the current cipher suite list in order of encryption algorithm key length |
| aGOST | Cipher suites using GOST R 34.10 (either 2001 or 94) for authentication. Requires aGOST-capable engine |
| aGOST01 | Cipher suites using GOST R 34.10-2001 authentication |
| aGOST94 | Cipher suites using GOST R 34.10-94 authentication. Obsolete. Use GOST R 34.10-2001 instead |
| kGOST | Cipher suites using VKO 34.10 key exchange, specified in RFC 4357 |
| GOST94 | Cipher suites using HMAC based on GOST R 34.11-94 |
| GOST89MAC | Cipher suites using GOST 28147-89 MAC instead of HMAC |
Для поиска можно комбинировать кейворды через '+'
root@mars:/var/tmp/a# openssl ciphers -v 'AES+RSA'
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(256) Mac=AEAD
AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256) Mac=AEAD
...
Через плюс выбирается "пересечение", а через двоеточие или пробел можно сложить два множества
root@mars:/var/tmp/a# openssl ciphers -v 'AES+RSA:AES+DH+SHA'
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(256) Mac=AEAD
AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(128) Mac=AEAD
AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1
Модификаторы
Есть несколько модификаторов с помощью которых можно формировать итоговый список шифров
| Keyword | Meaning |
|---|---|
| Append | Добавит в конец списка. Если такой уже есть в списке, то изменит его положение в нем |
| Delete (-) | Удалит все вхождения шифра в списке |
| Permanently delete (!) | То же что выше, но в добавок еще и не даст добавить удаленный шифр в будущем |
| Move to the end (+) | Переместит в конец списка. Полезно когда ты хочешь чтобы какой-то набор был включен, но использовался в последнюю очередь |
Сортировать по силе шифра можно словом @STRENGTH
Это работает плохо, поэтому вопрос приоритетности различных алгоритмов лучше контролировать вручную
Есть две типичных ошибки которые можно получить при работе с утилитой
root@mars:/var/tmp/a# openssl ciphers -v 'DES-CBC-SHA'
Error in cipher list
139928168608896:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl/ssl_lib.c:2560:
root@mars:/var/tmp/a# openssl ciphers -v '@DES-CBC-SHA'
Error in cipher list
140285746746496:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:ssl/ssl_ciph.c:1193:
Если присмотреться то видно:
- no cipher match
- invalid command
openssl имеет встроенную утилиту для бенчмаркинга speed
Вызов без агрументов выдаст большой вывод в котором мало интересного
root@three:~# openssl speed rc4 aes
Doing md4 for 3s on 16 size blocks: 10747405 md4's in 2.98s
Doing md4 for 3s on 64 size blocks: 9176936 md4's in 3.00s
Doing md4 for 3s on 256 size blocks: 5508233 md4's in 2.99s
Doing md4 for 3s on 1024 size blocks: ^C
root@three:~#
В конце тестинга выдаст такой вывод
...
OpenSSL 1.1.1d 10 Sep 2019
built on: Mon Mar 22 23:08:47 2021 UTC
options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-AWQHHq/openssl-1.1.1d=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
rc4 353922.28k 541043.50k 623075.05k 643742.57k 658066.09k 672067.30k
aes-128 cbc 166991.50k 173247.44k 171517.44k 173914.79k 172188.17k 174058.15k
aes-192 cbc 145605.16k 148606.40k 148814.17k 149922.50k 147187.50k 155242.51k
aes-256 cbc 128802.94k 131946.26k 133212.90k 135339.69k 130652.81k 131705.51k
В первой части вывода содержится всякая инфа о сборке openssl
Это полезно для сравнения разных сборок и разных версий
Вторая часть содержит бенчмарк симетричной криптографии
А третья часть про ассиметричную криптографию
Не стоит полагаться только на результаты, в реальной жизни на перфоманс влияет множетсво факторов
Но можно на них полагаться для того чтобы прикинуть примерные эстимэйты
Также нужно учитывать что по умолчанию команда speed использует один процесс, а сервера имеют много ядер, поэтому можно указать сколько экземпляров speed'a запустить в параллель через опцию -multi
root@three:~# ps aux | grep multi
root 31984 0.0 0.2 6844 5000 pts/0 S+ 07:44 0:00 openssl speed -multi 8 rc4 aes rsa ecdh sha
root 31985 24.8 0.1 6844 2940 pts/0 R+ 07:44 0:23 openssl speed -multi 8 rc4 aes rsa ecdh sha
root 31986 24.8 0.1 6844 2940 pts/0 R+ 07:44 0:23 openssl speed -multi 8 rc4 aes rsa ecdh sha
root 31987 24.8 0.1 6844 2940 pts/0 R+ 07:44 0:23 openssl speed -multi 8 rc4 aes rsa ecdh sha
root 31988 24.8 0.1 6844 2940 pts/0 R+ 07:44 0:23 openssl speed -multi 8 rc4 aes rsa ecdh sha
root 31989 24.8 0.1 6844 2940 pts/0 R+ 07:44 0:23 openssl speed -multi 8 rc4 aes rsa ecdh sha
root 31990 24.8 0.1 6844 2940 pts/0 R+ 07:44 0:23 openssl speed -multi 8 rc4 aes rsa ecdh sha
root 31991 24.8 0.1 6844 2940 pts/0 R+ 07:44 0:23 openssl speed -multi 8 rc4 aes rsa ecdh sha
root 31992 24.9 0.1 6844 2940 pts/0 R+ 07:44 0:23 openssl speed -multi 8 rc4 aes rsa ecdh sha
Еще по дефолту не будет использовать самые быстрые из доступных шифров
Например если сервер поддерживает aes-ni (хардварное ускорение шифрования), то для бенчмарка нужно будет явно указать ключ -evp чтобы использовать его
Если ты захочешь поднять свой собственный CA, то все что тебе понадобится уже есть в openssl
Самое сложное в поднятии приватного ЦА это сохранение безопасности. Например приватный ключ должен оставаться оффлайн, потому что вся безопасность зависит от него
С другой стороны CRL и OCSP должны регулярно обновляться
Создание ЦА ключает несколько шагов:
- Конфигурирование
- Создание структуры директорий
- Создание ключевых файлов
- Генерация корневого ключа и серта
Конфигурационные файлы не нужны большую часть времени, но они необходимы для некоторых операций
Рекомендуется почитать man config -> OpenSSL Config
Root CA Configuration
В первой части описывается базовая инфа об УЦ
[default]
name = root-ca
domain_suffix = example.com
aia_url = http://$name.$domain_suffix/$name.crt
crl_url = http://$name.$domain_suffix/$name.crl
ocsp_url = http://ocsp.$name.$domain_suffix:9080
default_ca = ca_default
name_opt = utf8,esc_ctrl,multiline,lname,align
[ca_dn]
countryName = "GB"
organizationName = "Example"
commonName = "Root CA"
Вторая часть контролирует работу УЦ
Большая часть параметров self-explanatory
Мы просто указываем куда мы хотим складывать наши файлы
А в полиси указываем что CN и ON для подписываемых сертов будут браться из корневого серта (это просто потому что у нас private CA)
[ca_default]
home = .
database = $home/db/index
serial = $home/db/serial
crlnumber = $home/db/crlnumber
certificate = $home/$name.crt
private_key = $home/private/$name.key
RANDFILE = $home/private/random
new_certs_dir = $home/certs
unique_subject = no
copy_extensions = none
default_days = 3650
default_crl_days = 365
default_md = sha256
policy = policy_c_o_match
[policy_c_o_match]
countryName = match
stateOrProvinceName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Третьей частью идет секция которая конфигурирует команду req
Которой мы воспользуемся лишь один раз (для создания корневого сертификата)
Наиболее важная часть это extensions'ы. В них и задается что это CA-cert (basicConstraint) и что им можно подписывать другие серты (keyUsage)
[req]
default_bits = 4096
encrypt_key = yes
default_md = sha256
utf8 = yes
string_mask = utf8only
prompt = no
distinguished_name = ca_dn
req_extensions = ca_ext
[ca_ext]
basicConstraints = critical,CA:true
keyUsage = critical,keyCertSign,cRLSign
subjectKeyIdentifier = hash
Четвертая часть описывает информацию которая будет использована при контруировании сертификатов выпускаемых этим корневым CA
Все выпускаемые сертификаты будут CA (basicConstraints - CA=true), и они не смогут так же как корневой выпускать CA-сертификаты, так как pathlen=0
Также, подписываемые sub-CA сертами серты, смогут использоваться для TLS клиент- и сервер-аутентификации
В теории nameConstraints ограничивает допустимые доменные имена, серты для которых смогут подписать sub-CA
Это позволяет делегировать возможность подписывать сертификаты и быть уверенным что sub-CA не сможет подписывать что-попало
Но на деле на это расширение мало кто смотрит
[sub_ca_ext]
authorityInfoAccess = @issuer_info
authorityKeyIdentifier = keyid:always
basicConstraints = critical,CA:true,pathlen:0
crlDistributionPoints = @crl_info
extendedKeyUsage = clientAuth,serverAuth
keyUsage = critical,keyCertSign,cRLSign
nameConstraints = @name_constraints
subjectKeyIdentifier = hash
[crl_info]
URI.0 = $crl_url
[issuer_info]
caIssuers;URI.0 = $aia_url
OCSP;URI.0 = $ocsp_url
[name_constraints]
permitted;DNS.0=example.com
permitted;DNS.1=example.org
excluded;IP.0=0.0.0.0/0.0.0.0
excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
И наконец пятая часть конфига, она содержит расширения которые будут задействованы в сертификате для подписы OCSP ответов
Мы сгенерим специальный серт и делегируем ему возможность подписывать OCSP
Этот серт не будет CA как другие
[ocsp_ext]
authorityKeyIdentifier = keyid:always
basicConstraints = critical,CA:false
extendedKeyUsage = OCSPSigning
keyUsage = critical,digitalSignature
subjectKeyIdentifier = hash
Root CA Directory Structure
Следующий шаг это создание структуры директорий которую мы описали в конфиге и инициализация некоторых файлов которые будут использоваться на протяжении работы CA
root@three:~/openssl_ca# mkdir root-ca
root@three:~/openssl_ca# cd root-ca/
root@three:~/openssl_ca/root-ca# ls
root@three:~/openssl_ca/root-ca# mkdir certs db private
root@three:~/openssl_ca/root-ca# chmod 700 private/
root@three:~/openssl_ca/root-ca# touch db/index
root@three:~/openssl_ca/root-ca# openssl rand -hex 16 > db/serial # большое число из 16-ти 16-ти-битных чисел (hex 16)
# если смотреть через x509 -text то выглядит так
# Serial Number:
# 9a:9c:cd:76:9c:cb:72:ee:9d:82:80:ac:4b:e7:de:ab
root@three:~/openssl_ca/root-ca# echo 1001 > db/crlnumber
root@three:~/openssl_ca/root-ca# tree
.
├── certs
├── db
│ ├── crlnumber
│ ├── index
│ └── serial
└── private
- certs/ - новые серты будут складываться сюда
- db/
- index - базаданных сертификатов
- crlnumber - серийник для следующего CRL
- serial - серийник для следующего сертификата
- при необходимости openssl может создавать тут дополнительные файлы
- private/ - приватные ключи. Один для CA и другой для OCSP-responder'a. Никакие другие пользователи не должны иметь сюда доступ
Root CA Generation
Мы уже выполнили два шага (собрали конфиг и насоздавали папок)
Теперь генерируем ключ и CSR
root@three:~/openssl_ca/root-ca# openssl req -new -config root-ca.conf -out root-ca.csr -keyout private/root-ca.key
Generating a RSA private key
.......................................................................................................................................................++++
.....................................................++++
writing new private key to 'private/root-ca.key'
Enter PEM pass phrase: #test
Verifying - Enter PEM pass phrase: #test
-----
root@three:~/openssl_ca/root-ca# tree
.
├── certs
├── db
│ ├── crlnumber
│ ├── index
│ └── serial
├── private
│ └── root-ca.key
├── root-ca.conf
└── root-ca.csr
И выпускаем самоподписанный серт
openssl ca -selfsign -config root-ca.conf -in root-ca.csr -out root-ca.crt -extensions ca_ext
После подписи index и serial поменялись сами
root@three:~/openssl_ca/root-ca# tree
.
├── certs
│ └── 9A9CCD769CCB72EE9D8280AC4BE7DEAB.pem
├── db
│ ├── crlnumber
│ ├── index
│ ├── index.attr
│ ├── index.old
│ ├── serial
│ └── serial.old
├── private
│ └── root-ca.key
├── root-ca.conf
├── root-ca.crt
└── root-ca.csr
Как видно серт положился и в certs и в корень
Потому что в конфиге написано "класть в certs", а в опции cli указано "-out root-ca.crt"
Structure of the Database File
root@three:~/openssl_ca/root-ca# cat db/index
V 310403100538Z 9A9CCD769CCB72EE9D8280AC4BE7DEAB unknown /C=GB/O=Example/CN=Root CA
База данных это просто текстовый файл
Содержит информацию о сертах
Одна строка - один серт
Каждая строка содержит 6 полей разделенных табами:
- status: V - valid, R - revoked, E - expired
- expiration date: YYMMDDHHMMSSZ
- дата отзыва серта, пусто пока не отозван
- серийник серта
- путь до файла или unknown если не известно
- Distinguished name
Root CA Operations
Для генерации CRL для нового CA используется -gencrl
openssl ca -gencrl -config root-ca.conf -out root-ca.crl
Вот что получается
root@three:~/openssl_ca/root-ca# cat root-ca.crl
-----BEGIN X509 CRL-----
MIICijB0AgEBMA0GCSqGSIb3DQEBCwUAMDExCzAJBgNVBAYTAkdCMRAwDgYDVQQK
DAdFeGFtcGxlMRAwDgYDVQQDDAdSb290IENBFw0yMTA0MDUxMDI1NTRaFw0yMjA0
MDUxMDI1NTRaoA8wDTALBgNVHRQEBAICEAEwDQYJKoZIhvcNAQELBQADggIBAKGK
be+WkQPWgOQX9N/Yenj8WoCylFDRjIW/6lmTBZ6oO18MWRDnRZ1DAzopStILmuq4
SobGg/BggZJnPaSk7aarwPYVSHRCKoyjEeM1ib/qHjcSEHXfE77i6K9fUiQ8zeNY
Czj+/F2lYVDz+fKkHtQBdL6HErpSAyNQXH7EshWORS2uJ9Kto4YgzId0/yUZUIk8
9daHRy1uJzxzlasFoAKDSl8Ht1iEpv5zyD4KV5i+RtEzhrJiwLEd1yQ8N5FNU4X+
A95iuqRUOLugI4iLM9/l9Xbqvv9E9yyCf1JiUntbTBcHJQ7qsyo7QfJ7fFpGx9Em
YhiM1AHOYObmU9cxsoLFk3g5ZAcr2rpEzJHXoKClbVhzRVLzFL+3VkOUpOOF1pEu
23kOy8v45c/gLDQV+qC/gdmbKd+nWTcRZ+lvOyOVjNTqc8S3oyebKEY3VTJ2H8cx
LYTXFy5oSvTYFsqobRCIaF8U+wu18y6N0RsMlrbw8leU+Z9GN/zfuf/Nzsf7vVzg
Dvk0mgsFLD7+z4X8T6Fy33ZZK7qj2cxk+k2ZauEaNajQKBOsLOaddQVn2lHPzRlY
pO402E1EFYaNUhT9FCPRdXsKc8g49YpQQjzolp/flaoJNstlp3Gdy3VBzWAZII5V
+/X2TbZ6aIcSPGA3QnocJZeUP6Wa+5G9mEFjMh/R
-----END X509 CRL-----
А внутри вот так
root@three:~/openssl_ca/root-ca# openssl crl -in root-ca.crl -text -noout
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = GB, O = Example, CN = Root CA
Last Update: Apr 5 10:25:54 2021 GMT
Next Update: Apr 5 10:25:54 2022 GMT
CRL extensions:
X509v3 CRL Number:
4097
No Revoked Certificates.
Signature Algorithm: sha256WithRSAEncryption
a1:8a:6d:ef:96:91:03:d6:80:e4:17:f4:df:d8:7a:78:fc:5a:
80:b2:94:50:d1:8c:85:bf:ea:59:93:05:9e:a8:3b:5f:0c:59:
10:e7:45:9d:43:03:3a:29:4a:d2:0b:9a:ea:b8:4a:86:c6:83:
f0:60:81:92:67:3d:a4:a4:ed:a6:ab:c0:f6:15:48:74:42:2a:
8c:a3:11:e3:35:89:bf:ea:1e:37:12:10:75:df:13:be:e2:e8:
af:5f:52:24:3c:cd:e3:58:0b:38:fe:fc:5d:a5:61:50:f3:f9:
f2:a4:1e:d4:01:74:be:87:12:ba:52:03:23:50:5c:7e:c4:b2:
15:8e:45:2d:ae:27:d2:ad:a3:86:20:cc:87:74:ff:25:19:50:
89:3c:f5:d6:87:47:2d:6e:27:3c:73:95:ab:05:a0:02:83:4a:
5f:07:b7:58:84:a6:fe:73:c8:3e:0a:57:98:be:46:d1:33:86:
b2:62:c0:b1:1d:d7:24:3c:37:91:4d:53:85:fe:03:de:62:ba:
a4:54:38:bb:a0:23:88:8b:33:df:e5:f5:76:ea:be:ff:44:f7:
2c:82:7f:52:62:52:7b:5b:4c:17:07:25:0e:ea:b3:2a:3b:41:
f2:7b:7c:5a:46:c7:d1:26:62:18:8c:d4:01:ce:60:e6:e6:53:
d7:31:b2:82:c5:93:78:39:64:07:2b:da:ba:44:cc:91:d7:a0:
a0:a5:6d:58:73:45:52:f3:14:bf:b7:56:43:94:a4:e3:85:d6:
91:2e:db:79:0e:cb:cb:f8:e5:cf:e0:2c:34:15:fa:a0:bf:81:
d9:9b:29:df:a7:59:37:11:67:e9:6f:3b:23:95:8c:d4:ea:73:
c4:b7:a3:27:9b:28:46:37:55:32:76:1f:c7:31:2d:84:d7:17:
2e:68:4a:f4:d8:16:ca:a8:6d:10:88:68:5f:14:fb:0b:b5:f3:
2e:8d:d1:1b:0c:96:b6:f0:f2:57:94:f9:9f:46:37:fc:df:b9:
ff:cd:ce:c7:fb:bd:5c:e0:0e:f9:34:9a:0b:05:2c:3e:fe:cf:
85:fc:4f:a1:72:df:76:59:2b:ba:a3:d9:cc:64:fa:4d:99:6a:
e1:1a:35:a8:d0:28:13:ac:2c:e6:9d:75:05:67:da:51:cf:cd:
19:58:a4:ee:34:d8:4d:44:15:86:8d:52:14:fd:14:23:d1:75:
7b:0a:73:c8:38:f5:8a:50:42:3c:e8:96:9f:df:95:aa:09:36:
cb:65:a7:71:9d:cb:75:41:cd:60:19:20:8e:55:fb:f5:f6:4d:
b6:7a:68:87:12:3c:60:37:42:7a:1c:25:97:94:3f:a5:9a:fb:
91:bd:98:41:63:32:1f:d1
openssl req -new -config root-ca.conf -out sub-ca.csr -keyout private/sub-ca.key
openssl ca -config root-ca.conf -in sub-ca.csr -out sub-ca.crt -extensions sub_ca_ext
Отзыв делается так
root@three:~/openssl_ca/root-ca# openssl ca -config root-ca.conf -revoke certs/9A9CCD769CCB72EE9D8280AC4BE7DEAC.pem -crl_reason keyCompromise
Using configuration from root-ca.conf
Enter pass phrase for ./private/root-ca.key:
Revoking Certificate 9A9CCD769CCB72EE9D8280AC4BE7DEAC.
Data Base Updated
root@three:~/openssl_ca/root-ca# cat db/index
V 310403100538Z 9A9CCD769CCB72EE9D8280AC4BE7DEAB unknown /C=GB/O=Example/CN=Root CA
R 310403103149Z 210405103713Z,keyCompromise 9A9CCD769CCB72EE9D8280AC4BE7DEAC unknown /C=GB/O=Example/CN=Root CA
Важно указать правильный резон для ревока
Возможные варианты:
- unspecified
- keyCompromise
- CACompromise
- affiliationChanged
- superseded
- cessationOfOperation
- certificateHold
- removeFromCRL
После отзыва перегенерируем CRL
root@three:~/openssl_ca/root-ca# openssl ca -gencrl -config root-ca.conf -out root-ca.crl
Using configuration from root-ca.conf
Enter pass phrase for ./private/root-ca.key:
И видим наш отозванный серт в CRL
root@three:~/openssl_ca/root-ca# openssl crl -in root-ca.crl -text -noout
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = GB, O = Example, CN = Root CA
Last Update: Apr 5 10:40:26 2021 GMT
Next Update: Apr 5 10:40:26 2022 GMT
CRL extensions:
X509v3 CRL Number:
4098
Revoked Certificates:
Serial Number: 9A9CCD769CCB72EE9D8280AC4BE7DEAC
Revocation Date: Apr 5 10:37:13 2021 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Signature Algorithm: sha256WithRSAEncryption
77:ca:42:a4:97:08:36:00:ad:ba:6b:f6:ed:a6:a4:7f:e5:2e:
b3:7f:3c:63:7b:a7:83:d0:c5:08:ca:2e:3d:1e:2d:51:f7:97:
cb:2a:30:58:3d:32:57:ab:c0:c5:6e:50:cb:00:04:df:43:73:
99:b1:61:2e:d0:ab:5e:bf:e2:a0:9c:e5:42:b1:8b:b0:ad:be:
88:0d:29:34:81:e5:2e:4e:8a:99:19:ec:89:95:b8:dc:17:46:
28:03:ad:88:15:ca:9d:c8:82:53:53:3a:08:23:ae:40:3a:09:
bb:02:cb:9d:c4:45:01:07:4a:0c:d6:58:11:82:5a:4b:13:9d:
49:53:8a:51:10:90:8f:1d:bd:da:34:b4:b2:f3:46:94:84:d0:
05:10:c9:2e:90:be:12:0a:f6:36:de:14:ec:12:d0:f3:5e:9c:
37:ec:57:21:6c:79:dc:45:7b:62:c0:85:26:19:0a:4e:dc:47:
Create a Certificate for OCSP Signing
Выпускаем CSR
openssl req -new -newkey rsa:2048 -subj "/C=GB/O=Example/CN=OCSP Root Responder" -keyout private/root-ocsp.key -out root-ocsp.csr
Подписываем его рутовым сертом
openssl ca -config root-ca.conf -in root-ocsp.csr -out root-ocsp.crt -extensions ocsp_ext -days 30
Лайфтайм уменьшен до 30 дней в отличие от дефолтных 3650 дней потому что этот серт не имеет revocation information и не может быть отозван
Поэтому чем меньше тем лучше
Вот доказательство того что он не может быть отозван
root@three:~/openssl_ca/root-ca# openssl x509 -in sub-ca.crt -noout -ext crlDistributionPoints
X509v3 CRL Distribution Points:
Full Name:
URI:http://root-ca.example.com/root-ca.crl
root@three:~/openssl_ca/root-ca# openssl x509 -in root-ocsp.crt -noout -ext crlDistributionPoints
root@three:~/openssl_ca/root-ca#
Теперь мы имеем все для старта ocsp responder'a
По-уму респондерские серты и ключи нужно уносить с CA на отдельную машину
Но в тестовых целях это не важно
Запускаем респондера
openssl ocsp -port 9080 -index db/index -rsigner root-ocsp.crt -rkey private/root-ocsp.key -CA root-ca.crt -text
Он начинает слушать порт и писать лог в stdout
Дергаем его из сосендей консоли
root@three:~/openssl_ca/root-ca# openssl ocsp -issuer root-ca.crt -CAfile root-ca.crt -cert sub-ca.crt -url http://localhost:9080
Response verify OK
sub-ca.crt: good
This Update: Apr 5 11:11:43 2021 GMT
Получаем ответ что все ок
Отзываем только что проверенный серт
root@three:~/openssl_ca/root-ca# openssl ca -config root-ca.conf -revoke certs/9A9CCD769CCB72EE9D8280AC4BE7DEAF.pem -crl_reason keyCompromise
Using configuration from root-ca.conf
Enter pass phrase for ./private/root-ca.key:
Revoking Certificate 9A9CCD769CCB72EE9D8280AC4BE7DEAF.
Data Base Updated
Перегенерируем CRL
root@three:~/openssl_ca/root-ca# openssl ca -gencrl -config root-ca.conf -out root-ca.crl
Using configuration from root-ca.conf
Enter pass phrase for ./private/root-ca.key:
Проверяем снова и видим что он отoзван
root@three:~/openssl_ca/root-ca# openssl ocsp -issuer root-ca.crt -CAfile root-ca.crt -cert sub-ca.crt -url http://localhost:9080
Response verify OK
sub-ca.crt: revoked
This Update: Apr 5 11:13:33 2021 GMT
Reason: keyCompromise
Revocation Time: Apr 5 11:12:32 2021 GMT
Creating a Subordinate CA
За основу конфига для sub-ca можно взять конфиг корневого ca и изменить некоторые поля
[default]
name = sub-ca
ocsp_url = http://ocsp.$name.$domain_suffix:9081
[ca_dn]
countryName = "GB"
organizationName = "Example"
commonName = "Sub CA"
[ca_default]
default_days = 365
default_crl_days = 30
copy_extensions = copy
В конец добавляем два новых профиля
[server_ext]
authorityInfoAccess = @issuer_info
authorityKeyIdentifier = keyid:always
basicConstraints = critical,CA:false
crlDistributionPoints = @crl_info
extendedKeyUsage = clientAuth,serverAuth
keyUsage = critical,digitalSignature,keyEncipherment
subjectKeyIdentifier = hash
[client_ext]
authorityInfoAccess = @issuer_info
authorityKeyIdentifier = keyid:always
basicConstraints = critical,CA:false
crlDistributionPoints = @crl_info
extendedKeyUsage = clientAuth
keyUsage = critical,digitalSignature
subjectKeyIdentifier = hash
Они отличаются только keyUsage и extendedKeyUsage
Далее можно генерить csr и подписывать его рутовым сертом
openssl req -new -config sub-ca.conf -out sub-ca.csr2 -keyout private/sub-ca.key2
openssl ca -config root-ca.conf -in sub-ca.csr2 -out sub-ca.crt2 -extensions sub_ca_ext
Subordinate CA Operations
Теперь можно подписывать клиентские серты
openssl ca \
-config sub-ca.conf \
-in server.csr \
-out server.crt \
-extensions server_ext # здесь можно указывать нужную директиву из конфига (server_ext, client_ext)
Генерация CRL и отзыв сертов делается аналогично тому что было описано выше для рутового CA
No Comments