Здесь я покажу вам, как можно создать свой центр сертификации и выпускать свои сертификаты для ваших тестовых или внутренних веб серверов.
Введение
Само-подписанные ssl-сертификаты бывают нужны в некоторых случаях:
Если вы не знаете, что означает доверие к сертификату сайта, то покажу вам следующие скриншоты.
Браузер не доверяет сертификату сайта
А на этом скриншоте браузер доверяет сайту. Об этом говорит то, что сайт открылся без предупреждений и замочек в адресной строке:
Браузер доверяет сертификату сайта
В этой статье я проделаю следующее:
- Покажу что клиенты пока не доверяют этому сертификату.
- Создам центр сертификации на этом же сервере. А именно:создам закрытый корневой ключ и открытый корневой ключ (он же корневой сертификат);с помощью этой пары ключей буду выпускать сертификаты для доменов;установлю выпущенный корневой сертификат на компьютер клиента (на windows);с помощью корневого ключа и сертификата, я выпущу ключ и сертификат для домена (для веб-сервера).
- создам закрытый корневой ключ и открытый корневой ключ (он же корневой сертификат);
- с помощью этой пары ключей буду выпускать сертификаты для доменов;
- установлю выпущенный корневой сертификат на компьютер клиента (на windows);
- с помощью корневого ключа и сертификата, я выпущу ключ и сертификат для домена (для веб-сервера).
- Затем я настрою apache2 на использование созданных мною закрытого ключа и сертификата для веб-сервера. И продемонстрирую вам что клиентский браузер начал доверять сертификату сайту.
Сертификаты SSL используются для облегчения аутентификации и шифрования в Интернете.
Обычно эти сертификаты выдаются доверенными сторонними центрами сертификации, такими как Let’s Encrypt.
Самоподписанный сертификат – это сертификат, который формируется без подтверждения стороннего центра сертификации.
TLS/SSL – это комбинация открытого сертификата и закрытого ключа.
Закрытый ключ надежно хранится на сервере или на балансировщике нагрузки, тогда как сертификат общедоступен.
В этом руководстве мы объясним, как создать самоподписанный сертификат SSL с помощью инструмента OpenSSL.
Предпосылки
Машина Linux и пользователь с привилегиями sudo.
Установка OpenSSL
OpenSSL доступен по умолчанию во всех основных дистрибутивах Linux.
Выполните приведенную ниже команду, чтобы убедиться, что OpenSSL уже установлен на вашем компьютере с Linux.
$ openssl version
Если вы не видите вывода, показывающего подробную информацию о версии OpenSSL, выполните следующую команду, чтобы установить OpenSSL.
Создадим самоподписанный сертификат SSL с помощью OpenSSL
Убедившись, что инструмент OpenSSL установлен на вашем компьютере с Linux, вы можете приступить к созданию сертификата.
Информация CSR требуется для создания закрытого ключа.
Поскольку мы генерируем самоподписанный сертификат, на самом деле не требуется выводить файл CSR, поскольку он требуется только в том случае, если вы отправляете информацию CSR в сторонний удостоверяющий центр.
Чтобы создать самоподписанный сертификат SSL, введите:
$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout my_key.key -out my_cert.crt
Эта команда создаст самоподписанный сертификат, который будет действителен в течение 365 дней.
Сертификат и файл ключа будут созданы в текущем каталоге, если явно не указан другой каталог.
Вот что обозначает каждый флаг:
- req – сделать запрос на подпись сертификата
- -newkey rsa: 4096 – Создает ключ RSA длиной 4096 бит. Если не указано иное, по умолчанию будет создан ключ длиной 2048 бит.
- -keyout – имя файла закрытого ключа, в котором будет храниться ключ
- -out – указывает имя файла для хранения нового сертификата
- -nodes – пропустить шаг по созданию сертификата с парольной фразой.
- -x509 – Создать сертификат формата X.509.
- -days – количество дней, в течение которых сертификат действителен
- C = – Название страны. (двухбуквенный код).
- ST = – Название штата или провинции.
- L = – Название населенного пункта.
- O = – полное название вашей организации.
- OU = – Название организационной единицы.
- CN = – полное доменное имя.
Создадим самоподписанный сертификат, используя существующий закрытый ключ и CSR
В некоторых ситуациях, когда у вас есть закрытый ключ и csr, будет достаточно следующих шагов.
Как создать закрытый ключ OpenSSL
Сначала выполните команду, показанную ниже, чтобы создать и сохранить свой закрытый ключ.
Этот закрытый ключ необходим для подписи вашего SSL-сертификата.
Вы можете изменить my_key в приведенной ниже команде на свое собственное значение.
$ sudo openssl genrsa -out my_key.key
Вот что означают флаги команды:
- genrsa Создать закрытый ключ RSA
- -out Выходной файл
Если вы не указали другое местоположение, ваш закрытый ключ будет храниться в текущем рабочем каталоге.
Как создать запрос на подпись сертификата
Следующим шагом является создание запроса на подпись сертификата (CSR).
CSR – это то, что вы обычно отправляете в УЦ.
Но в этом случае вы собираетесь подписать его самостоятельно.
При создании CSR вас попросят предоставить некоторую информацию.
Некоторые поля можно оставить пустыми, нажав клавишу ETCD_CLIENT_CERT_AUTH
Теперь запустите команду, показанную ниже, чтобы начать создание CSR.
$ sudo openssl req -new -key my_key.key -out my_csr.csr
Вот что обозначает каждый флаг команды
- req Сделать запрос на подпись сертификата
- -new Новый запрос
- -key Путь, где хранится ваш файл закрытого ключа
- -out Выходной файл
Подпишем сертификат самостоятельно
Когда вы запустите команду, показанную ниже, будет создан самоподписанынй сертификат, который будет действителен в течение 365 дней.
$ openssl x509 -req -days 365 -in my_csr.csr -signkey my_key.key -out my_cert.crt
Проверим сертификат
Вы можете проверить детали сертификата в текстовом формате с помощью команды:
openssl x509 -text -noout -in my_cert.crt
Заключение
В этом руководстве мы описали, как создать самоподписанный сертификат SSL с помощью инструмента openssl.
Учитывая, что основные браузеры не доверяют самоподписанным сертификатам, рекомендуется использовать его только для внутренних целей или в целях тестирования.
В этом руководстве объясняется процесс создания ключей и сертификатов CA и их использования для создания сертификатов и ключей SSL / TLS с использованием таких утилит SSL, как openssl и cfssl.
Терминологии, используемые в этой статье:
- PKI – Public key infrastructure
- CA – Certificate Authority
- CSR – Certificate signing request
- SSL – Secure Socket Layer
- TLS – Transport Layer Security
Рабочий процесс создания сертификата
Ниже приведены шаги, необходимые для создания сертификатов CA, SSL / TLS.
CA ключ и создание сертификата
- Создайте файл закрытого ключа CA с помощью утилиты (OpenSSL, cfssl и т. д.)
- Создайте корневой сертификат CA, используя закрытый ключ CA.
Процесс создания сертификата сервера
- Сгенерируйте закрытый ключ сервера с помощью утилиты (OpenSSL, cfssl и т. д.)
- Создайте CSR, используя закрытый ключ сервера.
- Создайте сертификат сервера, используя ключ CA, сертификат CA и CSR сервера.
В этом руководстве мы объясним шаги, необходимые для создания сертификатов CA, SSL / TLS с использованием следующих утилит:
- openssl
- cfssl
Данное руководство посвящено созданию собственных сертификатов CA, SSL / TLS.
Он предназначен для разработки или использования во внутренней сети, где каждый может установить предоставленный вами сертификат корневого УЦ.
Для использования в общедоступных (интернет) службах, вы должны рассмотреть возможность использования любых доступных сторонних служб CA, таких как Digicert и т. д.
Генерация сертификатов с использованием CFSSL и CFSSLJSON
1. Загрузите исполняемые файлы и сохраните их в /usr/local/bin
2. Добавьте права на выполнение для загруженных исполняемых файлов.
3. Проверьте установку, выполнив команду cfssl:
Создайте сертификат CA и его ключ
Шаг 1: Создайте папку с именем cfssl для хранения всех сертификатов и перейдите в папку.
mkdir cfssl
cd cfssl
Шаг 2: Создайте файл ca-csr.json с необходимой информацией.
Вы можете проверить поддерживаемые значения для csr и config, используя следующие команды:
cfssl print-defaults config
cfssl print-defaults csr
Шаг 2. Создайте ключ CA и файл сертификата (ca-key.pem и ca.pem) с помощью файла ca-csr.json.
Шаг 3: Создайте ca-config.json с подписью и данными профиля.
Это будет использоваться для создания сертификатов сервера или клиента, которые можно использовать для настройки аутентификации на основе SSL / TSL.
Генерация сертификатов SSL / TLS
Шаг 1: Создайте server-csr.json с данными вашего сервера.
Шаг 2: Теперь создайте SSL-сертификаты сервера, используя ключи CA, certs и csr сервера.
Это создаст файлы server-key.pem (закрытый ключ) и server.pem (сертификаты).
Генерация сертификатов с использованием OpenSSL
Утилита Openssl присутствует по умолчанию во всех системах на базе Linux и Unix.
Шаг 1: Создайте каталог openssl и CD к нему.
mkdir openssl && cd openssl
Шаг 2: Сгенерируйте файл секретного ключа CA.
Шаг 3: Сгенерируйте файл сертификата CA x509, используя ключ CA.
Вы можете определить срок действия сертификата в днях.
Здесь мы указали 1825 дней.
Следующая команда запросит детали сертификата, такие как имя команды, местоположение, страна и т. д.
Или вы можете передать эту информацию в команду, как показано ниже.
Шаг 1. Создайте закрытый ключ сервера
Шаг 2. Создайте файл конфигурации с именем csr.conf для генерации запроса на подпись сертификата (CSR), как показано ниже.
Замените значения в соответствии с вашими потребностями.
ext
names
names
ext
Шаг 3: Сгенерируйте CSR, используя закрытый ключ и файл конфигурации.
Шаг 4. Создайте SSL-сертификат сервера, используя ca.key, ca.crt и server.csr
Потребовалось мне тут как-то написать небольшой API, в котором необходимо было помимо обычных запросов принимать запросы с «высокой степенью секретности».
Не я первый с этим столкнулся и мир давно уже использует для таких вещей SSL.
Поскольку на моём сервере используется nginx, то был установлен модуль SSL
Гугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.
Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты.
Внимание! В статье для примера используются самоподписанные сертификаты!
Перед стартом создадим папку в конфиге nginx, где будут плоды наших трудов:
cd /path/to/nginx/config/
mkdir ssl && cd ssl
Шаг 1. Создание собственного самоподписанного доверенного сертификата.
Собственный доверенный сертификат (Certificate Authority или CA) необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.
С помощью приведенной ниже команды создается закрытый ключ и самоподписанный сертификат.
Шаг 2. Сертификат сервера
Создадим сертификат для nginx и запрос для него
openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr
Подпишем сертификат нашей же собственной подписью
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
Чтобы nginx при перезагрузке не спрашивал пароль, сделаем для него беспарольную копию сертификата
openssl rsa -in server.key -out server.nopass.key
Конфиг nginx
listen *:443;
ssl on;
ssl_certificate /path/to/nginx/ssl/server.crt;
ssl_certificate_key /path/to/nginx/ssl/server.nopass.key;
ssl_client_certificate /path/to/nginx/ssl/ca.crt;
ssl_verify_client on;
keepalive_timeout 70;
fastcgi_param SSL_VERIFIED $ssl_client_verify;
fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
fastcgi_param SSL_DN $ssl_client_s_dn;
Однако если вы попытаетесь зайти на сайт, он выдаст ошибку:
400 Bad Request
No required SSL certificate was sent
Что ж, логично, в этом-то и вся соль!
Шаг 3. Создание клиентских сертификатов
Создадим конфиг
nano ca.config
со следующим содержимым:
Далее надо подготовить структуру каталогов и файлов, соответствующую описанной в конфигурационном файле
Создание клиентского закрытого ключа и запроса на сертификат (CSR)
Для создания подписанного клиентского сертификата предварительно необходимо создать запрос на сертификат, для его последующей подписи. Аргументы команды полностью аналогичны аргументам использовавшимся при создании самоподписанного доверенного сертификата, но отсутствует параметр -x509.
В результате выполнения команды появятся два файла client01.key и client01.csr.
Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).
При подписи запроса используются параметры заданные в файле ca.config
openssl ca -config ca.config -in client01.csr -out client01.crt -batch
В результате выполнения команды появится файл клиентского сертификата client01.crt.
Для создания следующих сертификатов нужно повторять эти два шага.
Создание сертификата в формате PKCS#12 для браузера клиента
Это на тот случай, если к вашему серверу подключаются не бездушные машины, как в моём случае, а живые люди через браузер.
Запароленный файл PKCS#12 надо скормить браузеру, чтобы он смог посещать ваш сайт.
openssl pkcs12 -export -in client01.crt -inkey client01.key -certfile ca.crt -out client01.p12 -passout pass:q1w2e3
5 Подключение к полученному ssl cерверу с помощью curl
Использована опция -k, потому что сертификат в примере самоподписанный
Использованное ПО
Ubuntu Server 10.10 (Linux 2.6.35-22-server #35-Ubuntu SMP x86_64 GNU/Linux)
nginx 0.9.3
OpenSSL 0.9.8o 01 Jun 2010
Полезные ссылки
Надеюсь, был кому-то полезен.
P.S. Этот пост был моей первой публикацией 16 января 2011 года, старая копия удалена (по желанию администрации сайта и потому, что она не была привязана к моему аккаунту).
В целях безопасности, в частности во избежание перехвата конфиденциальных, персональных или важных данных. Многие владельцы сайтов в сети защищают трафик с помощью SSL-сертификатов. Естественно, защите подлежит только тот трафик, который связан непосредственно с запросами и передачей данных с определённым адресом — адресом сайта. Системные администраторы, сотрудники техподдержки должны ориентироваться в вопросах, касающихся создания и внедрения SSL-сертификатов для хостов. Поскольку предоставляют соответствующие услуги. Для этих целей в системах Linux существует утилита openssl. Она является свободной реализацией методов защиты, протокола SSL, а также генерации сертификатов.На самом деле схема защиты трафика основана на его шифровании открытым ключом и его расшифровке закрытым ключом. Понятие SSL-сертификата применимо в контексте подтверждения того факта, что открытый ключ действительно принадлежит именно тому домену, с которым происходит соединение. Таким образом, в данной схеме присутствуют две составляющие:
- Пара ключей (открытый и закрытый) — для шифрования/расшифровки трафика;
- Подпись открытого ключа. Гарантирующая, что он подлинный и обслуживает именно тот домен, для которого и был создан.
Обе эти составляющие и представляют собой то, что принято обозначать понятием SSL-сертификат. Подпись является гарантией, поскольку выдаётся авторитетным центрами сертификации. Это доступные всем онлайн-сервисы (достаточно воспользоваться любой поисковой системой), которым можно отправить свой ключ, заполнив соответствующую анкету. Далее сервис (центр сертификации) обрабатывает данные из анкеты и сам ключ и высылает уже подписанный ключ обратно его владельцу. Среди самых популярных на сегодняшний день центров сертификации являются такие как Comodo.
Важно заметить, что зашифрованный открытым ключом трафик возможно расшифровать только соответствующим ему закрытым ключом. В свою очередь подпись для открытого ключа от авторитетного цента говорит, что зашифрованный трафик пришёл от «своего» или подлинного узла и его можно принять в обработку, т. е. расшифровать закрытым ключом.Общий порядок создания SSL-сертификата, ключи и подписьВо время создания SSL-сертификата происходит последовательная обработка следующих видов ключей:
- *.key – это сами ключи шифрования, открытий и/или закрытый;
- *.csr – ключ, содержащий сформированный запрос для получения подписи сертификата от центра сертификации, а сам запрос — это открытый ключ и информация о домене и организации, связанной с ним;
- *.crt, *.cer, *.pem – это, собственно, сам сертификат, подписанный центром сертификации по запросу из файла *.csr.
Анонс
Схема PKI остаётся той же, только изменяются компоненты:
Настраиваю веб-сервер Nginx
Ну и наконец я покажу как настроить Nginx на использование наших сертификатов.
Для начала выключу apache2 и установлю nginx:
$ sudo systemctl stop apache2.service
$ sudo apt install nginx
И настрою его. Нужно рас-комментировать и поменять значения некоторых полей:
$ sudo systemctl reload nginx
И наконец, проверю доверие к ssl-сертификату сайта, обновив страничку в браузере.
Здесь apache2 создал свою индексную страничку, поэтому оба веб сервера (nginx и apache2) используют одну и туже страницу. Но как вы помните, я отключил apache2, так что у меня точно отвечает nginx.
Устанавливаю apache2
Устанавливаю web-сервер apache2:
$ sudo apt install apache2
$ sudo a2enmod ssl
$ sudo a2ensite default-ssl.conf
$ sudo systemctl restart apache2
Браузер Chrome не доверяет сертификату с которым работает сайт
Как видите, доверия нет.
Перенастраиваю apache2
Кинем сертификат и ключ в следующие каталоги:
$ sudo cp site.crt /etc/ssl/certs/
$ sudo cp site.key /etc/ssl/private/
И настроим apache2 на использование этих ключей:
$ sudo nano /etc/apache2/sites-enabled/default-ssl.conf
SSLCertificateFile /etc/ssl/certs/site.crt
SSLCertificateKeyFile /etc/ssl/private/site.key
Применим изменение конфига apache2:
$ sudo systemctl reload apache2
И проверим как открывается наш сайт с клиента на котором установлен наш корневой сертификат:
Как видим, браузер начал доверять нашему тестовому сайту.
Установка корневого сертификата на Winows
Устанавливаются сертификаты на Windows очень просто. Дважды щелкаем по сертификату и открывается окно с его свойствами. Дальше нажимаем на кнопку “Установить сертификат“:
Установить можно для текущего пользователя или для всего компьютера. Так как у меня это тестовая установка, я выберу “Текущий пользователь“:
Установка сертификата на Windows 10 для Текущего пользователя
После нажатия на кнопку “Далее” нужно выбрать “Поместить все сертификаты в следующее хранилище” и нажать кнопку “Обзор“:
Установка сертификата на Windows 10. Выбор хранилища
В открывшемся окне выбираем “Доверенные корневые центры сертификации“:
Затем нажимаем кнопку “ОК“, “Далее” и “Готово“.
И наконец, подтверждаем установку сертификата:
Подтверждение установки корневого сертификата
И затем нужно будет ещё раз нажать кнопку “ОК“.
Если вы еще раз откроете свойства сертификата (двойным щелчком по нему), то увидите что система начала ему доверять:
Просмотр свойств сертификата
Практика Self-signed certificate
Начнем с классики криптографии OpenSSL. Сейчас широко используется версия 1.1.1, но ее поддержка заканчивается в 2023. Следующая версия 3.0 будет поддерживаться до 2026 года. Проверка установленной версии:
OpenSSL 1.1.1k FIPS 25 Mar 2021
Если OpenSSL не установлен, то его можно установить на всех востребованных платформах.
Реализация TLS
openssl req -x509 -new -key root_ca.key -days 365 -out root_ca.crt
openssl x509 -text -in root_ca.crt
openssl req -new -key server.key -subj «/CN=xx.xx.xx.xx/CN=server/CN=server.example.com» -out server.csr
openssl req -text -in server.csr
openssl x509 -req -in server.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out server.crt -days 365 -extensions SAN -extfile openssl.cnf
sudo yum groupinstall ‘Development Tools’
sudo yum install nodejs
При первом запросе возникнет ошибка:
curl: (60) SSL certificate problem: self signed certificate in certificate chain
Это значит, что самоподписанный корневой сертификат нашего CA (root_ca.crt) не находится в хранилище доверительных сертификатов. Процесс загрузки сертификатов в это хранилище специфичен для операционной системы. Приведу алгоритм для RH Linux:
openssl x509 -in root_ca.crt -out root_ca.pem -outform PEM
Это значит, что мы установили TLS соединение только с проверкой сертификата сервера, а не клиента. Переходим к mTLS.
Реализация mTLS
Алгоритм генерации клиентских сертификатов аналогичен серверным.
openssl req -new -key client.key -subj «/CN=xx.xx.xx.xx/CN=client/CN=client.example.com» -out client.csr
openssl x509 -req -in client.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out client.crt -days 365 -extensions SAN -extfile openssl.cnf
Файл openssl.cnf — такой же как и для сервера, только вместо «server» пишем «client».
- Копируем следующие файлы на компьютер, на котором будет работать клиент:
- Теперь если просто вызвать curl:
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
Это значит, что мы установили mTLS соединение с проверкой сертификата как сервера, так и клиента. Теперь установим mTLS из браузера.
Реализация mTLS в браузере
Для загрузки в браузер клиентский сертификат и приватный ключ надо сконвертировать в формат p12. Этот формат определяется стандартом PKCS #12 и является архивом для хранения нескольких объектов. В нашем случае файл будет хранить клиентский сертификат и его приватный ключ. Понятно, что приватный ключ — это чувствительная к разглашению информация и ее владелец не должен выкладывать p12 сертификат в открытый доступ. Для конвертации тоже используем OpenSSL:
openssl pkcs12 -inkey client.key -in client.crt -export -out client.p12
Импортируем client.p12 в браузер. Для этого, например в Chrome, идем в меню: Settings / Privacy and security / Manage certificates, в открывшемся окне нажимаем Import, выбираем наш файл client.p12 и место хранения «Personal». Видим, что клиентский сертификат, выданный нашим удостоверяющим центром «My CN», появился в хранилище персональных сертификатов:
Вызываем запрос заново, уже лучше, но браузер все равно пишет, что соединение не безопасно. Это из-за того, что клиентский сертификат выдан удостоверяющим центром «My CN», которого нет в списке доверительных CA (Trusted Root Certification Authorities).
Добавляем корневой сертификат нашего CA (root_ca.crt) в Trusted Root Certification Authorities. Делается с помощью того же вызова Import, что и для клиентского сертификата, но хранилище указываем Trusted Root Certification Authorities. Проверяем, что наш CA «My CN» появился в хранилище:
Дальнейшие вызовы проходят без запросов на подтверждение клиентского сертификата:
Если щелкнуть на замочке а адресной строке, то можно посмотреть сертификат сервера и убедиться, что мы взаимодействуем с правильным сервером (Issued to: server.example.com), сертификат которому выдан нашим удостоверяющим центром (Issued by: My CN) и время действия сертификата еще не прошло (Valid to: 31.05.2023):
Таким образом мы организовали mTLS соединение из браузера. Далее приведу для справки несколько дополнительных возможностей OpenSSL, которые могут пригодиться в процессе работы.
Дополнительные возможности OpenSSL
openssl x509 -outform der -in client.crt -out client.der
openssl x509 -inform der -in client.cer -out client.pem
Отладка с помощью OpenSSL
openssl verify -verbose -x509_strict -CAfile root_ca.pem server.crt
openssl s_server -accept 9443 -cert server.crt -key server.key
openssl s_client -connect xx.xx.xx.xx:9443 -prexit -showcerts -state -status -tlsextdebug -verify 10
- При вызове curl параметр:-k — позволяет подсоединяться к серверу без проверки цепочки сертификатов (certificate path validation). —ssl-no-revoke — предотвращает проверку отозванных сертификатов
- -k — позволяет подсоединяться к серверу без проверки цепочки сертификатов (certificate path validation).
- —ssl-no-revoke — предотвращает проверку отозванных сертификатов
Создаю ключ и сертификат для домена
Утилита openssl не может без конфигурационного файла добавлять некоторые поля. А нам нужно будет в сертификат добавить поле subjectAltName. Без этого поля браузер Chrome не доверяет сертификату.
Поэтому вначале я создаю следующий конфиг:
- default_bits = 2048 – длина ключа по умолчанию.
- distinguished_name = req_distinguished_name – distinguished_name – это поля в сертификате, например Common Name, organizationName и другие. Для этих полей мы создадим блок req_distinguished_name ниже.
- req_extensions = req_ext – расширение для req, здесь мы можем добавить дополнительные поля в сертификат. А в этом параметре мы просто указываем что ниже будет блок req_ext с дополнительными полями.
- basicConstraints = CA:FALSE – полученные сертификаты нельзя будет использовать как центр сертификации. Другими словами, забираем у сертификатов для доменов право создавать дочерние сертификаты.
- keyUsage = nonRepudiation, digitalSignature, keyEncipherment – созданный ключ будет иметь следующие свойства: неотказуемость (если ключом что-то подписали то аннулировать подпись невозможно), цифровая подпись (сертификат можно использовать в качестве цифровой подписи), шифрование ключей (сертификат можно использовать для симметричного шифрования). Об этих свойствах на английском хорошо написано здесь.
Создаю закрытый ключ для домена
Теперь я создам закрытый ключ для домена:
Создаю файл запроса для домена
С помощью закрытого ключа для домена создаю файл запроса на сертификат:
Обратите внимание, все параметры были использованы из конфига, вручную мне не пришлось ничего вписывать.
Создаю сертификат для домена
Теперь, с помощью корневых ключей, подписываю файл запроса и создаю сертификат для домена:
- x509 – создание сертификата путём подписывания;
- -req – если подписывать будем файл запроса, то нужно использовать эту опцию;
- -days 730 – сертификат я делаю на 2 года;
- -CA rootCA.crt -CAkey rootCA.key – указываю корневую пару ключей;
- -in site.csr -out site.crt – файл запроса и файл сертификата.
После проделанного у меня появились три файла связанных с сертификатом для домена:
$ ls -l site.*
-rw-r—r— 1 alex alex 1257 сен 9 14:27 site.crt # сертификат
-rw-r—r— 1 alex alex 1098 сен 9 14:17 site.csr # запрос
-rw——- 1 alex alex 1704 сен 9 14:15 site.key # ключ
Создаю центр сертификации
- закрытый ключ – это обычный ключ шифрования применяемый в асинхронном шифровании.
- открытый ключ – это тоже ключ шифрования. Но он дополнительно содержит некоторую информацию, например имя домена, имя организации и другое. Такой ключ называют сертификатом.
А ещё протокол TLS позволяет создавать цепочки сертификатов. То-есть, если браузер доверяет родительскому сертификату, то он автоматически будет доверять и всем дочерним сертификатам. А чтобы создать дочернюю пару ключей, нужно иметь доступ к родительской паре ключей.
Корневая пара ключей обычно не подтверждает никакой домен. А используется для создания промежуточных сертификатов или сертификатов для доменов (для web-серверов).
Обычно, когда создают ssl-сертификат для домена, то для безопасности отнимают у него право создания дочерних сертификатов.
Корневой ключ обычно защищают паролем. Это уже симметричное шифрование, когда зная один ключ (пароль) можно зашифровать и расшифровать файл закрытого ключа.
Сервер на котором создают корневые сертификаты, а затем с их помощью выпускают сертификаты для доменов называют – центр сертификации.
Создаю корневой закрытый ключ
Для создания ssl/tls сертификатов можно использовать утилиту openssl, она не требует админских прав.
Создаю корневой закрытый ключ:
Разберу эту команду:
- genpkey – команда для создания закрытого ключа;
- -algorithm RSA – алгоритм асинхронного шифрования, именно он используется для выделения открытого ключа из этого закрытого;
- -out rootCA.key – получаемый файл закрытого ключа;
- -aes-128-cbc – алгоритм симметричного шифрования, которым мы зашифруем файл закрытого ключа с помощью пароля. Пароль нужно будет ввести.
Создаю корневой сертификат
Теперь создаю корневой сертификат (открытый ключ):
- req – создаёт сертификаты или запросы на сертификаты;
- -x509 – будем создавать сертификат а не запрос;
- -new – создаём новый сертификат (нужно будет ввести значения некоторых полей в сертификате);
- -key rootCA.key – используемый закрытый ключ, из которого нужно создать открытый;
- -sha256 – алгоритм хеширования, чтобы создать подпись ключа;
- -days 3650 – выпускаем сертификат на 10 лет (обратите внимание что закрытые ключи не имеют срока жизни а сертификаты имеют);
- -out rootCA.crt – получаемый сертификат.
Итак, я создал пару ключей:
$ ls -l root*
-rw-r—r— 1 alex alex 1306 сен 9 11:26 rootCA.crt
-rw——- 1 alex alex 1874 сен 9 11:19 rootCA.key
Когда мы будем создавать дочерние сертификаты для доменов, нам понадобится файл с порядковым номером выпускаемых сертификатов. Он должен быть с тем же именем что и корневой ключ, но иметь расширение srl.
Создаю файл порядковых номеров для выпуска сертификатов, в нём следует указать два нуля:
Дальше нужно передать корневой сертификат на клиентские компьютеры и установить его в доверенные корневые центры сертификации. Я забираю корневой сертификат по протоколу sftp, показывать этот процесс думаю не нужно.
Смотрим на сертификат из Chrome
Нажмите на замочек возле адреса сайта (он виден на скриншоте выше). Дальше нажмите на “Безопасное подключение” и на “Действительный сертификат“. Откроются свойства сертификата:
Свойства сертификата из Chrome
На вкладке “Подробнее” вы можете изучить и остальные свойства.
Например, помните мы указывали алгоритм ассиметричного шифрования – RSA:
Алгоритм подписи сертификатов
А помните, мы создали файл для серийных номеров выпускаемых сертификатов и записали в нём “00”. Давайте посмотрим на серийный номер нашего сертификата:
Серийный номер сертификата
Можем посмотреть на сам открытый ключ:
А в расширениях видно альтернативное имя, которое так нужно браузеру Chrome для доверия к сертификату:
Раньше браузеры проверяли только CN:
А сейчас, если есть альтернативное имя, то они даже не смотрят в параметр Common Name. А Chrome требует это поле и вообще перестал смотреть на Common Name.
Практика CA Smallstep
CA Smallstep — это open source CA, который можно развернуть локально для автоматического получения X.509 сертификатов. На официальном сайте есть ряд инструкций по его установке и настройке. Для экспериментов я использовал вариант с docker:
sudo yum -y update
sudo yum install -y yum-utils
sudo yum -y install docker-ce
sudo systemctl start docker
sudo docker run hello-world
sudo docker pull smallstep/step-ca
docker run -it -v step:/home/step smallstep/step-ca step ca init
должна вернуться строка:
На этом же или другом компьютере по инструкции устанавливаем утилиту CLI step. Краткая выжимка:
tar -xf step_linux_0.19.0_386.tar.gz
step ca health
Все готово для генерации ключей и сертификатов.
Генерация ключей и сертификатов
Также как и в случае с OpenSSL, сначала генерируем ключ и сертификат для сервера и установки TLS соединения, потом для клиента и установки mTLS.
step certificate create —csr —no-password —insecure —kty=RSA —size=2048 «xx.xx.xx.xx» server.csr server.key
step ca sign server.csr server.crt
step certificate inspect server.crt
step ca root root_ca.crt
step certificate inspect root_ca.crt
Все нормально, теперь генерируем ключ и сертификат для клиента.
step certificate create —csr —no-password —insecure —kty=RSA —size=2048 «xx.xx.xx.xx» client.csr client.key
step ca sign client.csr client.crt
step certificate inspect client.crt
- Копируем на клиента:
- Для проверки вызываем curl с параметрами:
Отлично — mTLS тоже работает с выданными CA Smallstep сертификатами!
Дополнительные возможности CA Smallstep
С помощью CLI step можно проверить необходимость обновления сертификата:
step certificate needs-renewal server.crt
certificate does not need renewal
step ca renew server.crt server.key
step ca revoke —cert server.crt —key server.key
step certificate inspect server.crt —bundle
STEPDEBUG=1 step /команда/
Итог
Надеюсь я смог объяснить, как сделать свой центр сертификации и начать выпускать свои собственные сертификаты для доменов. Мы создали следующие файлы:
- rootCA.key – корневой закрытый ключ. Используется для создания дочерних сертификатов. Обычно лежит на сервере центра сертификации и зашифрован с помощью пароля.
- rootCA.srl – корневой сертификат. Используется для создания дочерних сертификатов. Его нужно распространить на все ваши компьютеры и установить в хранилище корневых сертификатов. Его тоже можно защитить паролем, но я этого не делал.
- site.key – ключ для домена (для веб сервера). Его можно было сгенерировать на веб-сервере и не передавать на сервер центра сертификации. Но в моём примере был один сервер и для веб-сервера и для центра сертификации.
- site.csr – файл запроса на сертификат для домена. Его также можно было сделать на веб-сервере и передать в центр сертификации, чтобы там выпустить сертификат.
- site.crt – сертификат для домена (для веб сервера). Этот файл создаётся из файла запроса на сертификат с помощью пары корневых ключей.
Также я показал, как использовать созданные сертификаты для настройки веб серверов: apache2 и nginx.
Если вы интересуетесь настройками веб-серверов на Linux, то возможно вам также понравится эта статья:
Создаём свой центр сертификации на Linux
В данной статье мы рассмотрели две возможности генерации ключей и сертификатов для клиента и сервера:
- С помощью OpenSSL.
- Используя CA Smallstep.
И двумя способами установили TLS и mTLS соединения:
- С помощью curl.
- Из браузера, загрузив в него клиентский и корневой сертификаты.
Теперь у нас есть понимание, как организовать свою систему PKI с помощью CA любого производителя, т.к. логика взаимодействия у всех аналогичная. Более того, большинство CA используют под капотом OpenSSL, оборачивая его в свой API.