Как сгенерировать самоподписанный сертификат с помощью OpenSSL на Linux | UNLIX

openssl позволяет сгенерировать самоподписанный сертификат с помощью одной команды (-newkey дает указание сгенерировать закрытый ключ, а -x509 дает указание выдать самоподписанный сертификат вместо запроса на подпись) ::

openssl req -x509 -newkey rsa:4096 
-keyout my.key -passout pass:123456 -out my.crt 
-days 365 
-subj /CN=localhost/O=home/C=US/emailAddress=me@mail.internal 
-addext "subjectAltName = DNS:localhost,DNS:web.internal,email:me@mail.internal" 
-addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth

Вы можете сгенерировать закрытый ключ и создать самозаверяющий сертификат в отдельные шаги:

openssl genrsa -out my.key -passout pass:123456 2048

openssl req -x509 
-key my.key -passin pass:123456 -out my.csr 
-days 3650 
-subj /CN=localhost/O=home/C=US/emailAddress=me@mail.internal 
-addext "subjectAltName = DNS:localhost,DNS:web.internal,email:me@mail.internal" 
-addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth

Просмотрите полученный сертификат:

openssl x509 -text -noout -in my.crt

Java keytool создает хранилище PKCS # 12 ::

keytool -genkeypair -keystore my.p12 -alias master 
-storetype pkcs12 -keyalg RSA -keysize 2048 -validity 3650 
-storepass 123456 
-dname "CN=localhost,O=home,C=US" 
-ext 'san=dns:localhost,dns:web.internal,email:me@mail.internal'

Чтобы экспортировать самоподписанный сертификат:

keytool -exportcert -keystore my.p12 -file my.crt 
-alias master -rfc -storepass 123456

Просмотрите полученный сертификат:

keytool -printcert -file my.crt

certtool из GnuTLS не позволяет передавать различные атрибуты из CLI. Не люблю возиться с конфигурационными файлами ((

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

Основная причина, по которой никто не хочет получать подписанный сертификат от центра сертификации, – это стоимость – Symantec плата от $ 995 -! $ 1 999 в год за сертификаты – только для сертификата, предназначенный для внутренней сети, Symantec взимает 399 долларов США в год. Эту стоимость легко оправдать, если вы обрабатываете платежи по кредитной карте или работаете в центре прибыли высокоприбыльной компании. Это больше, чем многие могут себе позволить для личного проекта, который создается в Интернете, или для некоммерческой организации, работающей с минимальным бюджетом, или если кто-то работает в центре затрат организации – центры затрат всегда стараются сделать больше менее.

Альтернативой является использование certbot (см. о certbot ). Certbot – это простой в использовании автоматический клиент, который извлекает и развертывает сертификаты SSL / TLS для вашего веб-сервера.

Если вы настроили certbot, вы можете разрешить ему создавать и поддерживать сертификат, выданный центром сертификации Let’s Encrypt.

Я сделал это на выходных для своей организации. Я установил необходимые пакеты для certbot на свой сервер (Ubuntu 16.04), а затем выполнил команду, необходимую для установки и включения certbot. Вероятно, понадобится плагин DNS для certbot – в настоящее время мы используем < a href = “https://certbot-dns-digitalocean.readthedocs.io/en/stable/” rel = “nofollow noreferrer”> DigitalOcean , хотя может скоро перейти на другую службу.

Обратите внимание, что некоторые инструкции были не совсем правильными, и потребовалось немного времени и времени на выяснение у Google. В первый раз это заняло у меня изрядное количество времени, но теперь я думаю, что смогу сделать это за считанные минуты.

Что касается DigitalOcean, я столкнулся с проблемой, когда мне было предложено ввести путь к вашему INI-файлу учетных данных DigitalOcean. Сценарий имеет в виду страницу Приложения и API и вкладку Токены / Ключ. на этой странице. Вам необходимо иметь или сгенерировать личный токен доступа (чтение и запись) для API DigitalOcean – это шестнадцатеричная строка из 65 символов. Затем эту строку необходимо поместить в файл на веб-сервере, с которого вы запускаете certbot. В первой строке этого файла может быть комментарий (комментарии начинаются с символа #). Вторая строка:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

Как только я понял, как настроить токен чтения и записи для API DigitalOcean, было довольно просто использовать certbot для настройки шаблонный сертификат. Обратите внимание, что не нужно настраивать подстановочный сертификат, вместо этого можно указать каждый домен и поддомен, к которым нужно применять сертификат. Это был шаблонный сертификат, для которого требовался INI-файл учетных данных, содержащий токен личного доступа от DigitalOcean.

Обратите внимание, что сертификаты открытого ключа (также известные как сертификаты идентичности или сертификаты SSL) истекают и требуют обновления. Таким образом, вам нужно будет периодически (повторно) продлевать свой сертификат. Документация по certbot охватывает продление сертификатов.

Я планирую написать сценарий, который будет использовать команду openssl для получения даты истечения срока действия моего сертификата и для запуска обновления, если до истечения срока его действия осталось 30 дней или меньше. Затем я добавлю этот скрипт в cron и буду запускать его раз в день.

Вот команда для чтения даты истечения срока действия вашего сертификата:

root@prod-host:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2021 GMT

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

Итак, шаг за шагом. Создайте файл config_ssl_ca.cnf Обратите внимание, что в файле конфигурации есть опция basicConstraints = CA: true , что означает, что этот сертификат должен быть корневым.

Это хорошая практика, потому что вы создаете его один раз и можете использовать повторно.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=Market(localhost)
organizationalUnitName=roote department
commonName=market.localhost
emailAddress=root_email@root.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost
DNS.5        = *.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = @alternate_names

Следующий файл конфигурации для вашего дочернего сертификата будет называться config_ssl.cnf .

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=market.localhost
emailAddress=email@market.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost
DNS.5        = *.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = @alternate_names
subjectKeyIdentifier = hash

Первый шаг – создать Root-ключ и сертификат

openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf

На втором этапе создается дочерний ключ и файл CSR – Certificate Signing Request. Потому что идея заключается в том, чтобы подписать дочерний сертификат root и получить правильный сертификат.

openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr

Откройте терминал Linux и выполните эту команду

echo 00 > ca.srl
touch index.txt

Текстовый файл ca.srl , содержащий следующий серийный номер в шестнадцатеричном формате. Обязательный. Этот файл должен присутствовать и содержать действительный серийный номер.

На последнем этапе создайте еще один файл конфигурации и назовите его config_ca.cnf .

# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca

[ my_ca ]
#  a text file containing the next serial number to use in hex. Mandatory.
#  This file must be present and contain a valid serial number.
serial = ./ca.srl

# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt

# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./

# the file containing the CA certificate. Mandatory
certificate = ./ca.crt

# the file contaning the CA private key. Mandatory
private_key = ./ca.key

# the message digest algorithm. Remember to not use MD5
default_md = sha256

# for how many days will the signed certificate be valid
default_days = 365

# a section with a set of variables corresponding to DN fields
policy = my_policy

# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy

[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = market.localhost
organizationalUnitName = optional
commonName = supplied

Вы спросите, почему так сложно, зачем нужно создавать еще один конфиг для подписи дочернего сертификата root. Ответ прост, потому что в дочернем сертификате должен быть блок SAN – альтернативные имена субъектов. Если мы подпишем дочерний сертификат с помощью утилит «openssl x509», корневой сертификат удалит поле SAN в дочернем сертификате. Поэтому мы используем openssl ca вместо openssl x509, чтобы избежать удаления поля SAN. Мы создаем новый файл конфигурации и приказываем ему скопировать все расширенные поля copy_extensions = copy .

openssl ca -config config_ca.cnf -out market.crt -in market.csr

Программа задает вам 2 вопроса:

1. Подпишите сертификат? Скажите “Y”
2. 1 из 1 запросов на сертификат подтвержден, совершить? Скажите “Y”

В терминале вы видите предложение со словом «База данных», это означает файл index.txt, который вы создаете командой «touch». Он будет содержать всю информацию обо всех сертификатах, которые вы создаете с помощью утилиты “openssl ca”. Чтобы проверить действительность сертификата, используйте:

openssl rsa -in market.key -check

Если вы хотите посмотреть, что внутри CRT:

openssl x509 -in market.crt -text -noout

Если вы хотите посмотреть, что внутри в CSR:

openssl req -in market.csr -noout -text 

Это сценарий, который я использую в локальных ящиках для установки SAN (subjectAltName) в самозаверяющих сертификатах.

Этот сценарий берет имя домена (example.com) и генерирует SAN для * .example.com и example.com в одном сертификате. В следующих разделах есть комментарии. Назовите сценарий (например, generate-ssl.sh) и дайте ему права на выполнение. Файлы будут записаны в тот же каталог, что и сценарий.

Chrome 58 и более поздних версий требует, чтобы SAN был установлен в самозаверяющих сертификатах.

#!/usr/bin/env bash

# Set the TLD domain we want to use
BASE_DOMAIN="example.com"

# Days for the cert to live
DAYS=1095

# A blank passphrase
PASSPHRASE=""

# Generated configuration file
CONFIG_FILE="config.txt"

cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn

[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster@$BASE_DOMAIN
CN = $BASE_DOMAIN

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF

# The file name can be anything
FILE_NAME="$BASE_DOMAIN"

# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*

echo "Generating certs for $BASE_DOMAIN"

# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2021

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"

# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"

# Protect the key
chmod 400 "$FILE_NAME.key"

Этот сценарий также записывает информационный файл, чтобы вы могли проверить новый сертификат и убедиться, что SAN настроен правильно.

                ...
                28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
                da:3d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
            DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
     3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
     ...

Если вы используете Apache, вы можете ссылаться на вышеуказанный сертификат в своем файле конфигурации следующим образом:

<VirtualHost _default_:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/htdocs

    SSLEngine on
    SSLCertificateFile path/to/your/example.com.crt
    SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>

Не забудьте перезапустить сервер Apache (или Nginx, или IIS), чтобы новый сертификат вступил в силу.

Начиная с 2021 года с OpenSSL ≥ 1.1.1, следующая команда обслуживает все ваши потребности, включая SAN:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes 
  -keyout example.key -out example.crt -subj "/CN=example.com" 
  -addext "subjectAltName=DNS:example.com,DNS:www.example.net,IP:10.0.0.1"

В старых системах с OpenSSL ≤ 1.1.0, таких как Debian ≤ 9 или CentOS ≤ 7, необходимо использовать более длинную версию этой команды:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes 
  -keyout example.key -out example.crt -extensions san -config 
  <(echo "[req]"; 
    echo distinguished_name=req; 
    echo "[san]"; 
    echo subjectAltName=DNS:example.com,DNS:www.example.net,IP:10.0.0.1
    ) 
  -subj "/CN=example.com"

Любая команда создает сертификат, который

Создаются следующие файлы:

• Закрытый ключ: example.key
• Сертификат: example.crt

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

Замечание №1: параметры шифрования

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

В будущем вы, возможно, захотите использовать более 4096 бит для ключа RSA и алгоритм хеширования, более сильный, чем sha256, но с 2021 года это нормальные значения. Они достаточно сильны и поддерживаются всеми современными браузерами.

Замечание №2: параметр “-nodes”

Теоретически вы можете не указывать параметр -nodes (что означает «без шифрования DES»), и в этом случае example.key будет зашифрован паролем. Однако это почти никогда не бывает полезно для установки на сервере, потому что вам придется либо сохранить пароль на сервере, либо вам придется вводить его вручную при каждой перезагрузке.

Замечание №3: см. также