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

Что такое сертификаты?

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

Если вы смогли расшифровать отправленное сообщение, зашифрованное с помощью вашего открытого ключа, то значит — это вы. Ключи работают только в паре, и вы не сможете расшифровать ничего другим ключом. Но еще остался один момент. Как определить что этот открытый ключ именно ваш, например, принадлежит вашему домену? Все просто, достаточно, чтобы кто-то из авторитетных источников, например, Comodo или LetsEncrypt подписал ваш ключ. Это так называемые центры сертификации.

В этой инструкции мы будем иметь дело с такими видами ключей:

.pem, .crt, .cer — готовый, подписанный центром сертификации сертификат, расширения разные, но означают одно и то же. Если совсем просто, то сертификат, это подписанный открытый ключ, плюс немного информации о вашей компании;
.key — закрытый или открытый ключ;
.csr — запрос на подпись сертификата, в этом файле хранится ваш открытый ключ плюс информация, о компании и домене, которую вы указали.

А теперь рассмотрим как создать сертификат openssl, как его подписать и что для этого нужно сделать. Генерация ключей openssl — это довольно простая задача, если во всем разобраться.

Creating a Self-Signed SSL Certificate

25 Мая 2020
|

Терминал

Что такое самоподписанный сертификат SSL?

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

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

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

Предпосылки

Инструментарий openssl необходим для создания самозаверяющего сертификата.

Чтобы проверить, установлен ли пакет openssl в вашей системе Linux, откройте ваш терминал, введите и нажмите Enter. Если пакет установлен, система распечатает версию OpenSSL, в противном случае вы увидите нечто подобное .

Если пакет openssl не установлен в вашей системе, вы можете установить его, выполнив следующую команду:

Ubuntu и Debian
Чентос и Федора

Создание самоподписанного SSL-сертификата

Чтобы создать новый самоподписанный сертификат SSL, используйте команду:

Давайте разберем команду и разберемся, что означает каждая опция:

— Создает новый запрос сертификата и 4096-битный ключ RSA. Значение по умолчанию составляет 2048 бит.
— Создает сертификат X.509.
— Используйте 265-битный SHA (алгоритм безопасного хэширования).
— Количество дней для сертификации сертификата. 3650 — это 10 лет. Вы можете использовать любое положительное целое число.
— Создает ключ без ключевой фразы.
— Указывает имя файла, в который будет записан вновь созданный сертификат. Вы можете указать любое имя файла.
— Задает имя файла, в который будет записан вновь созданный закрытый ключ. Вы можете указать любое имя файла.

Для получения дополнительной информации о параметрах команды посетите страницу документации OpenSSL req.

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

Введите запрашиваемую информацию и нажмите Enter.

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

Это оно! Вы создали новый самозаверяющий сертификат SSL.

Всегда полезно создать резервную копию нового сертификата и ключа для внешнего хранилища.

Создание самоподписанного SSL-сертификата без запроса

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

Поля, указанные в строке, перечислены ниже:

— Название страны. Двухбуквенное сокращение ISO.
— Название штата или провинции.
— Название населенного пункта. Название города, в котором вы находитесь.
— Полное название вашей организации.
— Организационная единица.
— Полное доменное имя.

В этом руководстве мы показали, как создать самозаверяющий сертификат SSL с помощью инструмента openssl. Теперь, когда у вас есть сертификат, вы можете настроить приложение для его использования.

Генерирование запроса на подпись сертификата

Генерирование закрытого ключа и запроса

Этот метод позволяет вам подписать сертификат в ЦС и защитить веб-сервер Apache или Nginx с помощью HTTPS. Сгенерированный запрос на подпись можно отправить в ЦС, чтобы получить подписанный сертификат. Если ЦС поддерживает SHA-2, добавьте опцию -sha256.

Следующая команда создаст 2048-битный закрытый ключ (domain.key) и CSR (domain.csr):

Заполните поля в запросе на подпись.

Опция -newkey rsa:2048 создаст 2048-битный RSA-ключ. Опция –nodes отключает пароль для закрытого ключа.

Генерирование запроса для существующего закрытого ключа

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

Следующая команда создаст запрос сертификата (domain.csr) для существующего ключа (domain.key):

Ответьте на запросы программы, чтобы продолжить. Опция –new указывает, что запрос нужно сгенерировать.

Генерирование запроса для существующего сертификата и ключа

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

Следующая команда создаст запрос (domain.csr) на основе существующего сертификата (domain.crt) и закрытого ключа (domain.key):

Опция -x509toreq создаст сертификат X509.

Генерация самоподписанного сертификата с помощью OpenSSL

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

Для тех, кого не интересуют подробности генерации, приводим строку, которая выполнит автоматическую генерацию секретного ключа (private key) и самоподписанного сертификата (self-signed certificate) в текущем каталоге сервера.

Обратите внимание, что для корректной генерации Вам необходимо указать полное имя сервера (FQDN) в начале этой последовательности команд, изменив значение переменной HOSTNAME (подставить свое значение вместо YOUR_SERVER_NAME):

# HOSTNAME="YOUR_SERVER_NAME" ; \
OPENCFG=`openssl version -a | sed -n 's#OPENSSLDIR: "\(.*\)"#\1#p'`/openssl.cnf ; \
openssl req -subj "/C=EU/CN=$HOSTNAME" -extensions "v3_ca_ext" \
-config <(cat $OPENCFG <(printf "\n\nsubjectAltName=DNS:$HOSTNAME\nbasicConstraints=critical,CA:TRUE\nkeyUsage=critical,cRLSign,digitalSignature,keyCertSign\nextendedKeyUsage=critical,serverAuth\n") \
-nodes -new -x509 -sha256 -newkey rsa:4096 -keyout $HOSTNAME.key -out $HOSTNAME.crt -days 730

Теперь давайте разберем эту последовательность команд.

Во-первых, объявляется переменная HOSTNAME, содержащая имя вашего сервера: HOSTNAME=’YOUR_SERVER_NAME’

Далее, основываясь на выводе утилиты openssl, находим и запоминаем путь к файлу конфигурации этой утилиты (можно пойти более сложным путем, но для большинства систем такой способ будет рабочим): OPENCFG=`openssl version -a | sed -n ‘s#OPENSSLDIR: «$.*$»#\1#p’`/openssl.cnf

И, собственно, генерация ключа, с необходимыми нам параметрами:openssl req – вызов OpenSSL на генерацию ключа и самоподписанного сертификата (PKCS#10 X.509 Certificate Signing Request)-extensions «v3_ca_ext» – указываем необходимость использования новой секции vs_sa_ext, в который мы определим дополнительные параметры сертификата-config – указываем оригинальный файл конфигурации OpenSSL, который мы дополним новой секцией с требуемыми параметрами — дополняем файл конфигурации новой секцией — имя секцииsubjectAltName=DNS:$HOSTNAME — определяем subjectAltNamebasicConstraints=critical,CA:TRUE — определяем basicConstraintskeyUsage=critical,cRLSign,digitalSignature,keyCertSign — определяем keyUsageextendedKeyUsage=critical,serverAuth»)) — определяем extendedKeyUsage-nodes — не шифровать полученный ключ-new — запрос на генерацию нового ключа-x509 — выводить сразу сертификат в формате x509, вместо запроса на сертификацию-sha256 — тип и длина сертификата-newkey rsa:4096 — генерация нового ключа указанного типа и длины-keyout $HOSTNAME.key — файл, куда будет записан секретный ключ-out $HOSTNAME.crt — файл, куда будет записан полученный самоподписанный сертификат -days 730 — срок действия сертификата.

Идентификаторы ключа

Для идентификации ключей используется два типа идентификации:

человекочитаемый, но не уникальный идентификатор пользователя (user ID, UID)
уникальный, но неудобный для ввода цифровой отпечаток ключа (fingerprint, key ID)

Отпечаток ключа — это хэш SHA-1 длиной 160 бит, вычисляемый на основе открытого ключа и метки времени создания ключа. Для ввода/вывода отпечатка в интерфейсе пользователя используется шестнадцатеричная запись. Длина отпечатка — 40 шестнадцатеричных цифр, которые для удобства разбивают на 10 групп по 4 цифры.

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

Для экономии времени на ввод идентификатора (или его диктовку по телефону) могут использоваться младшие байты цифрового отпечатка. 16 последних шестнадцатеричных цифр отпечатка называются длинным идентификатором (long ID), а последние 8 символов — коротким идентификатором (short ID). Использование длинного и короткого идентификатора считается плохой практикой, поскольку для них легко сгенерировать коллизии — т.е. различные ключи с совпадающими укороченными ID (но с несовпадающими отпечатками).

В некоторых случаях в начале идентификатора нужно добавлять символы 0x, чтобы подчеркнуть, что это число в шестнадцатеричном виде.

Для того, чтобы не пересчитывать символы руками, команда просмотра публичных ключей —list-keys (-k) позволяет указать опцию —keyid-format, которая может принимать значения 0xLONG, LONG, 0xSHORT, SHORT.

Известные уязвимости [ править | править код ]

Уязвимость в реализации дистрибутива Debian

В Debian версии 0.9.8c-1 к OpenSSL был применён патч, преднамеренно повреждавший генератор случайных чисел. Эта версия OpenSSL была включена в релиз Debian 17 сентября 2006. Все ключи, сгенерированные через эту версию генератора, и все данные, зашифрованные такими ключами, могут считаться скомпрометированными. Проблема была исправлена в версии 0.9.8c-4etch3 дистрибутива Debian 4.0; в версии 0.9.8g-9 дистрибутива Debian 5.0.

Heartbleed bug

7 апреля 2014 года было объявлено о критической уязвимости OpenSSL 1.0.2-beta и всех версий OpenSSL 1.0.1, кроме 1.0.1g. Уязвимость связана с расширением TLS Heartbeat и позволяет считывать до 64Кб оперативной памяти приложения с каждым heartbeat-запросом. В списке CVE она значится под номером CVE-2014-0160.

Уязвимость существует с 31 декабря 2011 года; уязвимый код был распространён с выпуском версии OpenSSL 1.0.1 14 марта 2012 года. Читая оперативную память веб-сервера, атакующий может получить доступ к конфиденциальной информации как сервера, так и пользователей, позволяя перехватить приватные ключи, cookies и пароли. На момент объявления около 17 % из полумиллиона защищённых веб-серверов предполагались уязвимыми.

Запускаем HTTPS

Первым делом идем на страницу настройки шифрования, кликнув значок в виде замка.

Тут справа в выпадающем списке выбираем «Flexible».

Спускаемся чуть ниже до пункта «Always Use HTTPS».

Кликаем переключатель, он должен позеленеть.

Спускаемся ещё ниже до пункта «Automatic HTTPS Rewrites» и также включаем этот режим.

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

Этим самым мы говорим cloudflare что хотим использовать SSL для своего сайта.

В этом разделе все. Переходим в раздел «Page Rules».

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

Для создания правила нам необходимо нажать кнопку «Create Page Rule».

Теперь переходим к нужному пункту.

Для домена без www

Создаем правило. В верхнем поле пишем имя домена с www. В списке ниже выбираете пункт «Forwarding URL», рядом в списке выбираете пункт «301 — Permanent Redirect». Во второе поле пишите адрес сайта с https и с $1 на конце.

Жмем кнопку «Save and Deploy».

Для домена с www

Если вам необходимо чтобы сайт работал на домене с www, то поля необходимо заполнить как на скриншотах ниже.

Через несколько минут все наши настройки начнут работать.

ОБЗОР ФОРМАТОВ SSL CЕРТИФИКАТОВ

ФОРМАТ СЕРТИФИКАТА PEM

PEM – наиболее популярный формат среди сертификационных центров. PEM сертификаты могут иметь расширение .pem, .crt, .cer, и .key (файл приватного ключа). Она представляют собой ASCII файлы, закодированные по схеме Base64. Когда вы открываете файл pem формата в текстовом редакторе, вы можете увидеть, что текст кода в нем начинается с тега «—— BEGIN CERTIFICATE ——» и заканчивая тегом «—— END CERTIFICATE ——«. Apache и другие подобные серверы используют сертификаты в PEM формате

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

Как правило, для установки SSL сертификата на Apache, сертификаты и приватный ключ должны быть в разных файлах.

ФОРМАТ СЕРТИФИКАТА DER

DER формат – это бинарный тип сертификата вместо формата PEM. В PEM формате чаще всего используется расширение файла .cer, но иногда можно встретить и расширение файла .der. Поэтому чтобы отличить SSL сертификат в формате PEM от формата DER, следует открыть его в текстовом редакторе и найти теги начала и окончания сертификата (BEGIN/END). DER SSL сертификаты, как правило, используются на платформах Java.

PKCS # 7 / P7B СЕРТИФИКАТ

SSL сертификаты в формате PKCS # 7 или P7B — это файлы, которые хранятся в формате Base64 ASCII и имеют расширение файла .p7b или .p7c. P7B сертификаты содержат теги начала сертификата «—— BEGIN PKCS7 ——» и его конца «—— END PKCS7 ——«. Файлы в формате P7B включают в себя только ваш SSL сертификат и промежуточные SSL сертификаты. Приватный ключ при этом идет отдельным файлом. SSL сертификаты в формате PKCS # 7 / P7B поддерживают следующие платформы: Microsoft Windows и Java Tomcat.

PFX СЕРТИФИКАТ (ФОРМАТ PKCS # 12)

Формат SSL сертификата PKCS # 12 или, как его еще называют, PFX сертификат — бинарный формат, при использовании которого в одном зашифрованном файле хранится не только ваш личный сертификат сервера и промежуточные сертификаты центра сертификации, но и ваш закрытый ключ. PFX файлы, как правило, имеют расширение .pfx или .p12. Обычно, файлы формата PFX используются на Windows серверах для импорта и экспорта файлов сертификатов и вашего приватного ключа.

Форматы хранения сертификатов

Основной формат хранения сертификатов X.509 — DER, однако для удобства пересылки по электронной почте его часто дополнительно кодируют в формат PEM (Privacy Enhanced Mail RFC 1421). PEM сам по себе довольно большой стандарт, но из взято только кодирование по алгоритму Base64 и обрамление полученного текста границами:

Для секретных ключей RSA (PKCS#1) используется традиционная форма label, похоже, не описанная в стандартах — RSA PRIVATE KEY.

RFC 7468 описывает форматы label для разных типов ключей и сертификатов

CERTIFICATE — сертификат X.509
PUBLIC KEY — публичный ключ X.509
X509 CRL — список отозванных сертификатов
PKCS7 — PKCS#7
PRIVATE KEY — PKCS#8
ENCRYPTED PRIVATE KEY — RFC 5958
CERTIFICATE REQUEST — PKCS#10

За пределами границ BEGIN и END в файл с сертификатом может быть добавлена человекочитаемая версия данных.

Lab Environment

We will need RootCA certificate and Private key to sign the certificates. I have already created these certificates to demonstrate this article. I will share the commands to create the same, but if you are interested then you should check other articles on similar topic from the LEFT Sidebar MENU:

## create a directory structure for storing the rootca certificates
mkdir /root/tls/{private,certs}

## navigate inside your tls path
cd /root/tls

## generate rootca private key
openssl genrsa  -out private/cakey.pem 4096

## generate rootCA certificate
openssl req -new -x509 -days 3650  -config openssl.cnf  -key private/cakey.pem -out certs/cacert.pem

## Verify the rootCA certificate content and X.509 extensions
openssl x509 -noout -text -in certs/cacert.pem

You can collect my .

Смысл создания подключей

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

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

Мастер-ключ извлекается из хранилища и используется в следующих случаях:

когда вы подписываете чужой ключ или отзываете существующую подпись
когда вы создаете новый подключ
когда вы добавляете новый UID или помечаете существующий UID как основной
когда вы меняете настройки (например, с помощью setpref) для UID
когда вы меняете дату истечения срока действия вашего мастер-ключа или любого его подключа
когда вы отзываете существующий UID или подключ
когда вы отзываете или генерируете сертификат отзыва для ключа со всеми подключами

Verify SAN Extensions in the certificate

Once the certificate is generated, let’s verify if our SAN fields are retained inside the certificate:

# openssl x509 -text -noout -in server.crt | grep -A 1 "Subject Alternative Name"

We get an empty output. The SAN Extensions are missing from our certificate.

Missing SAN Extensions from the Certificate

This is an expected behaviour. As per

Due to this, the extensions which we added in our CSR were not transferred by default to the certificate. So these extensions must be added to the certificate explicitly.

Generate SAN Certificates with X509 extensions

We need to use argument with the name of the extension to be used from the configuration file. We have defined our SAN fields under extension so we will use the same and re-generate the certificate:

# openssl x509 -req -days 365 -in server.csr -CA /root/tls/certs/cacert.pem -CAkey /root/tls/private/cakey.pem -CAcreateserial -out server.crt -extensions req_ext -extfile server_cert.cnf
Signature ok
subject=C = IN, ST = Karnataka, L = Bengaluru, O = GoLinuxCloud, OU = R&D, CN = ban21.example.com
Getting CA Private Key

Re-verify the SAN Extensions in the certificate

Now let us re-verify the SAN extension in our certificate:

# openssl x509 -text -noout -in server.crt | grep -A 1 "Subject Alternative Name"                            
X509v3 Subject Alternative Name:
                IP Address:10.10.10.13, IP Address:10.10.10.14, IP Address:10.10.10.17, DNS:centos8-2.example.com, DNS:centos8-3.example.com

So this time our certificates are properly generated with the SAN fields.

Наш маленький CA

Создаём приватный ключ и публичный сертификат нашего «удостоверяющего центра»:

# openssl genrsa -aes256 -out mail-ca.key 8192
# chmod 0400 mail-ca.key

Приватный ключ (mal-ca.key) — самый важный файл из всего, что мы в этот раз создаем. Пароль secret1 естественно должен быть значительно сложнее, ведь если произойдет утечка приватного ключа то только пароль ключа будет защищать вас от поддельных сертификатов. Заранее подумайте, какие данные вы введете в сведения о сертификате, ведь этот сертификат будет потом установлен на всех клиентских устройствах в роли удостоверяющего центра. Если изменить сертификат одного клиента будет просто, то изменить этот сертификат будет совсем не просто.

Создаём публичный сертификат (mail-ca.crt), который будет установлен на всех клиентских устройствах (он будет подтверждать корректность сертификатов на устройствах пользователей):

# openssl req -new -x509 -sha512 -days 3650 -key mail-ca.key -out mail-ca.crt

Преобразуем сертификат в формат DER для дальнейшего импорта в разные почтовые программы:

# openssl x509 -outform der -in mail-ca.crt -out mail-ca.der

About OpenSSL

Secure Sockets Layer is an application-level protocol which was developed by the Netscape Corporation for the purpose of transmitting sensitive information, such as Credit Card details, via the Internet. SSL works by using a private key to encrypt data transferred over the SSL-enabled connection, thus thwarting eavesdropping of the information. The most popular use of SSL is in conjunction with web browsing (using the HTTP protocol), but many network applications can benefit from using SSL. By convention, URLs that require an SSL connection start with https: instead of http:.

OpenSSL is a robust, commercial-grade implementation of SSL tools, and related general purpose library based upon SSLeay, developed by Eric A. Young and Tim J. Hudson. OpenSSL is available as an Open Source equivalent to commercial implementations of SSL via an Apache-style license.

About X.509

X.509 is a specification for digital certificates published by the International Telecommunications Union — Telecommunication (ITU-T). It specifies information and attributes required for the identification of a person or a computer system, and is used for secure management and distribution of digitally signed certificates across secure Internet networks. OpenSSL most commonly uses X.509 certificates.

КОНВЕРТАЦИЯ SSL СЕРТИФИКАТОВ В OPENSSL

Данные команды OpenSSL дают возможность преобразовать сертификаты и ключи в разные форматы. Для того чтобы сделать их совместимыми с определенными видами серверов, либо ПО. К примеру, Вам необходимо конвертировать обыкновенный файл PEM, который будет работать с Apache, в формат PFX (PKCS # 12) с целью применения его с Tomcat, либо IIS.

Конвертировать PEM в DER openssl x509 -outform der -in certificate.pem -out certificate.der
Конвертировать PEM в P7B openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer
Конвертировать PEM в PFX openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
Конвертировать DER в PEM openssl x509 -inform der -in certificate.cer -out certificate.pem
Конвертировать P7B в PEM openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
Конвертировать P7B в PFX openssl pkcs7 -print_certs -in certificate.p7b -out certificate.ceropenssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer
Конвертировать PFX в PEM openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes