Сертификаты OpenSSL

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

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

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

Как определить что этот открытый ключ именно ваш и ему можно доверять?

Все просто, достаточно чтобы кто-то из авторитетных источников, например, Comodo или LetsEncrypt подписал ваш ключ. Это так называемые центры сертификации.

Создание CA (корневой сертификат)

CA это корневой сертификат, по сути третья сторона, которой при шифровании данных доверяют клиент и сервер. На его основе будут выпускаться все остальные сертификаты. Для каждого нового домена верхнего уровня необходимо будет выпускать свой сертификат.

Чтобы сгенерировать любой x509 сертификат, необходима пара ключей, открытый и закрытый. В рассматриваемом примере будем использовать RSA ключ.

Создаем закрытый ключ

В результате выполнения команды, в каталоге появится файл ca-key.pem, приватный ключ, он же закрытый ключ:

openssl genrsa -out ca-key.pem 2048

Генерируем CA, корневой сертификат

openssl req -x509 -new -key ca-key.pem -days 10000 -out ca.pem

В процессе генерации будут заданы вопросы, ответить на которые можно, например так:

Country Name (2 letter code) []:RU
State or Province Name (full name) []:Moscow
Locality Name (eg, city) []:Moscow
Organization Name (eg, company) []:Hmarketing
Organizational Unit Name (eg, section) []:DevOps
Common Name (eg, fully qualified host name) []:
Email Address []:info@hmarketing.ru

На выходе будет получен файл ca.pem, корневой CA которым мы будем подписывать конечные сертификаты.

Генерация конечных сертификатов

Создаем ключ

Создаем ключ для конечного сертификата:

openssl genrsa -out cert-key.pem 2048

Создаем конфиг

Создаем файл tls.cnf следующего вида:

tls.cnf[req]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no

[req_distinguished_name]
# страна
C = RU
# область/регион
ST = Moscow
# населённый пункт
L = Moscow
# организация
O = Hmarketing
# подразделение
OU = DevOps
# доменное имя
CN = www.site1.loc

[req_ext]
keyUsage = keyEncipherment, dataEncipherment, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = www.site1.loc
DNS.2 = '*.site1.loc'
IP.1 = 127.0.0.1

В конфиге, указываем интересующие нас домены, ip-адреса и информацию о сертификате.

Запрос на сертификат

Генерируем запрос на сертификат:

openssl req -new -sha256 -out cert.csr -key cert-key.pem -config tls.cnf

В результате появится файл cert.csr, который можно проверить:

openssl req -text -noout -in cert.csr | grep 'DNS'

Генерация сертификата

Генерируем сам сертификат на 1000 дней:

openssl x509 -req -in cert.csr -CA ca.pem -CAkey \
  ca-key.pem -CAcreateserial -out cert.pem \
  -days 1000 -extensions req_ext -extfile tls.cnf

Проверка сертификата

Проверяем что в сертификате есть все необходимые данные:

openssl x509 -in cert.pem -text | grep -E '(Issuer:|Subject:|DNS:)'

Должена быть выведена следующая информация:

Issuer данные с CA
Subject данные из конфига tls.cnf
DNS собственно alternative names

Итоговый результат

После выполнения описанных выше действий должны получить следующий набор файлов:

ca.pem ставим на клиентские машины, в систему, в браузер
cakey.pem храним в секрете
cert.pem и cert-key.pem должны находиться на ресурсе, который хотим перевести на HTTPS