Сертификаты
Одной из наиболее распространенных форм криптографии сегодня является криптография на открытых ключах. Криптография на открытых ключах использует открытый (public) и закрытый (secret) ключи. Система выполняет шифрование с использованием открытого ключа. Расшифрована такая информация может быть только с использованием закрытого ключа.
Обычное использование криптографии на открытых ключах — шифрование трафика приложений с использованием соединений по протоколам SSL и TLS. Например, настройка Apache для предоставления HTTPS, протокола HTTP поверх SSL . Это позволяет применить шифрование трафика с протоколом, который сам по себе шифрование не поддерживает.
Сертификат — это метод, используемый для распространения открытого ключа и другой информации о сервере и организации, ответственной за него. Сертификаты могут иметь цифровую подпись, сделанную Центром сертификации или CA. CA — это третья сторона, которая подтверждает, что информация, содержащаяся в сертификате, верна.
Типы сертификатов
Для установки безопасного сервера с использованием криптографии на открытых ключах в большинстве случаев вы посылаете свой запрос на сертификат (включающий ваш открытый ключ), подтверждение идентичности вашей компании и оплату центру сертификации. Центр проверяет запрос на сертификат и вашу идентичность, и затем отсылает в ответ сертификат для вашего сервера. В качестве альтернативы вы можете использовать самоподписанный сертификат.
Обратите внимание, что самоподписанный сертификат не может быть использованным в большинстве производственных сред.
Продолжая пример с HTTPS, сертификат, подписанный CA, предоставляет два важных свойства в отличие от самоподписанного сертификата:
Браузеры (обычно) автоматически распознают такой сертификат и позволяют устанавливать защищенные соединения без предупреждения пользователя.
Когда CA выпускает подписанный сертификат, он гарантирует идентичность организации, которая предоставляет интернет страницы браузеру.
Большинство интернет браузеров и компьютеров, которые поддерживают SSL имеют список центров сертификации, чьи сертификаты они автоматически принимают. Если браузер встречает сертификат, чей заверяющий центр не попал в этот список, он запрашивает пользователя на подтверждение или запрет соединения. При этом другие приложения могут выдавать сообщения об ошибке, когда используется самоподписанный сертификат.
Процесс получения сертификата из CA довольно прост. Короткий обзор его приведен ниже:
Создайте пару из открытого и закрытого ключей.
Создайте запрос на сертификат на основе открытого ключа. Запрос на сертификат содержит информацию о вашем сервере и управляющей им компании.
Пошлите запрос на сертификат вместе с документами, подтверждающими вашу идентичность, в CA. Мы не можем сказать вам какой центр сертификации выбрать. Ваше решение может основываться на вашем прошлом опыте, опыте ваших друзей и коллег или исключительно на факторе цены. Как только вы определитесь с CA, вам надо следовать их инструкциям по тому, как получить у них сертификат.
Когда центр убедится, что вы действительно тот, за кого себя выдаете, они отправят вам цифровой сертификат.
Установите это сертификат на ваш защищенный сервер и настройте соответствующие приложения на его использование.
Создание запроса на подпись сертификата (CSR)
Вне зависимости от того получаете ли вы сертификат от CA или создаете самоподписаный, первым шагом будет создание ключа.
Если сертификат будет использоваться системными сервисами такими, как Apache, Postfix, Dovecot и т.п., уместно создать ключ без пароля. Отсутствие пароля позволяет сервису стартовать с минимальным ручным вмешательством, обычно это предпочтительный вариант запуска сервиса.
В этой секции показано как создать ключ с кодовым словом (паролем) и без него. Беспарольный ключ затем будет использован для создания сертификата, который можно использовать для различных системных сервисов.
Запуск вашего защищенного сервиса без кодовой фразы удобен потому, что вам не потребуется вводить ее при каждом старте данного сервиса. Однако это небезопасно и компрометация ключа будет означать и компрометацию сервера.
Для генерации ключей CSR запроса, запустите следующую команду из терминала:
openssl genrsa -des3 -out server.key 2048
Generating RSA private key, 2048 bit long modulus . ++++++ . ++++++ e is 65537 (0x10001) Enter pass phrase for server.key:
Теперь вы можете ввести вашу кодовую фразу. Для лучшей безопасности рекомендуется использовать не менее восьми символов. Минимальная длина при использовании -des3 — 4 символа. Фраза должна включать цифры и/или знаки препинания и не должно быть словом из словаря. Также не забывайте, что ваша фраза будет чувствительна к регистру.
Повторите ввод для проверки. В случае корректного ввода ключ сервера будет создан и записан в файл server.key.
Теперь создадим небезопасный ключ, без кодовой фразы и поменяем имена ключей:
openssl rsa -in server.key -out server.key.insecure mv server.key server.key.secure mv server.key.insecure server.key
Небезопасный ключ теперь называется server.key и вы можете использовать его для создания CSR без кодовой фразы.
Для создания CSR выполните следующую команду в терминале:
openssl req -new -key server.key -out server.csr
У вас будет запрошена кодовая фраза (при использовании ключа с паролем — прим. пер.). Если введена корректная фраза, у вас запросят название компании, имя сайта, email и пр. Как только вы введете все эти подробности, будет создан запрос CSR и сохранен в файл server.csr.
Теперь вы можете оправить CSR файл в центр сертификации для обработки. CA использует этот файл для выпуска сертификата. С другой стороны, вы можете создать и самозаверенный сертификат, используя этот же CSR.
Создание самоподписанного сертификата
Для создания самоподписанного сертификата, запустите следующую команду в терминале:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Эта команда попросит вас ввести кодовую фразу. Как только вы введете корректную фразу, ваш сертификат будет создан и сохранен в файл server.crt.
Если ваш защищенный сервер будет использован в производстве, вам, возможно, потребуется сертификат, подписанный центром сертификации. В этом случае использование самоподписанных сертификатов не рекомендуется.
Установка сертификата
Вы можете установить файлы ключа server.key и сертификата server.crt (или файл сертификата, выданный вашим CA), запуском следующих команд в терминале:
sudo cp server.crt /etc/ssl/certs sudo cp server.key /etc/ssl/private
Теперь просто настройте любое приложение с возможностью использования криптографии на открытых ключах для использования этих файлов ключа и сертификата. Например, Apache может предоставить HTTPS, Dovecot предоставляет IMAPS и POP3S, и т.д.
Центр сертификации
Если сервисы вашей сети требуют больше чем самозаверенные сертификаты, может быть полезным дополнительное усилие по установке вашего собственного внутреннего центра сертификации (CA). Использование сертификатов, подписанных вашим центром, позволяют различным сервисам использовать сертификаты для простого доверия другим сервисам, использующих сертификаты, выданные тем же CA.
1. Сначала создайте каталоги для хранения сертификата CA и необходимых файлов:
sudo mkdir /etc/ssl/CA sudo mkdir /etc/ssl/newcerts
2. Центр сертификации требует несколько дополнительных файлов для своей работы; один для хранения последнего серийного номера, использованного CA, другой для записи какие сертификаты были выпущены:
sudo sh -c "echo '01' > /etc/ssl/CA/serial" sudo touch /etc/ssl/CA/index.txt
3. Третий файл — это файл настроек CA. Хотя он не строго обязателен, но очень удобен для выпуска множества сертификатов. Отредактируйте /etc/ssl/openssl.cnf, изменив секцию [ CA_default ]:
dir = /etc/ssl/ # Where everything is kept database = $dir/CA/index.txt # database index file. certificate = $dir/certs/cacert.pem # The CA certificate serial = $dir/CA/serial # The current serial number private_key = $dir/private/cakey.pem# The private key
4. Далее создайте самоподписанный сертификат:
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650
Вам будут заданы вопросы по деталям сертификата.
5. Теперь установим корневой сертификат и ключ:
sudo mv cakey.pem /etc/ssl/private/ sudo mv cacert.pem /etc/ssl/certs/
6. Теперь вы готовы приступить к выпуску сертификатов. Первое, что вам потребуется — запрос на сертификат (CSR). Смотрите детали в разделе Создание запроса на подпись сертификата (CSR). Получив CSR, введите следующую команду для создания сертификата, подписанного нашим центром:
sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnf
После ввода пароля для ключа CA у вас запросят подтверждение на подпись сертификата и еще одно на сохранение нового сертификата. Затем вы сможете увидеть нечто с объемным выводом, относящееся к созданию сертификата.
7. Теперь у вас должен появиться новый файл /etc/ssl/newcerts/01.pem, с таким же содержанием, что и в предыдущем выводе. Выделите и скопируйте все, начиная со строки ——BEGIN CERTIFICATE—— и до строки ——END CERTIFICATE—— в файл с названием по сетевому имени сервера, где он будет установлен. Например, mail.example.com.crt — вполне хорошее описательное имя.
Последующие сертификаты будут иметь имена 02.pem, 03.pem и т.д.
Замените mail.example.com.crt на ваше собственное описательное имя.
8. Наконец, скопируйте новый сертификат на компьютер, для которого он выпущен, и настройте соответствующие приложения на его использование. Место по умолчанию для установки сертификатов — каталог /etc/ssl/certs. Это позволяет многим сервисам использовать один и тот же сертификат без чрезмерного усложнения прав доступа к файлу.
Для приложений, которые могут быть настроены на использование сертификата CA, вы можете скопировать файл /etc/ssl/certs/cacert.pem в каталог /etc/ssl/certs/ на каждом сервере.
Ссылки
Для более детальных инструкций по использованию криптографии смотрите SSL Certificates HOWTO на tlpd.org.
Как создать ключ для авторизации по SSH и добавить его на сервер?
На клиентской стороне должен быть установлен пакет ssh (openssh). На серверах FirstVDS с шаблонами по умолчанию необходимое ПО уже установлено.
Для ОС CentOS, AlmaLinux или RockyLinux выполните команду:
# yum -y install openssh-server openssh-clients
Для ОС Debian или Ubuntu выполните команду:
# apt -y install openssh-server
Дальнейшая инструкция будет одинаковая для всех ОС.
На клиентском компьютере в командной строке выполните команду генерации ключей:
# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase):
Введите путь файла, в который будут помещены ключи. Каталог по умолчанию указан в скобках, в примере /домашний_каталог/.ssh/id_rsa . Если хотите оставить расположение по умолчанию, нажмите Enter.
Пароль (passphrase) используется для ограничения доступа к закрытому ключу. Пароль усложнит использование ключа третьими лицами в случае утраты. Если не хотите использовать секретную фразу, нажмите Enter без заполнения строки.
Успешно сгенерировав пару ключей, вы увидите уведомление:
Your identification has been saved in /root/.ssh/id_rsa Your public key has been saved in /root/.ssh/id_rsa.pub The key fingerprint is: SHA256:JPDzeSan06C9+osd+sKXWP0RmPk4UbSESaTvYn0aXVk root@test-server1.com The key's randomart image is: +---[RSA 3072]----+ |. oo+o | | o .o. | | + o =. E | | = o= . o | | S.=+ .o | | o.@+.o. | | ..oB.=oo. | | +=o= +. | | +**.. | +----[SHA256]-----+
По умолчанию в современных ОС генерация ключей происходит по умолчанию с такими настройками: тип аутентификации — RSA, число бит в ключе — 2048 или 3072.
Рекомендуем позаботится о безопасности ключей. В первую очередь обязательно необходимо задавать пароль (passphrase), который не должен быть простым. С помощью параметра -a можно увеличить время проверки пароля ключа, чтобы усложнить взлом методом грубого перебора (в случае, если ключ будет утерян, у вас будет больше времени на смену ключа на сервере).
Будьте внимательны, слишком большое значение приведет к тому, что вам придется ждать каждый раз при входе на сервер по ключу. Значение по умолчанию — 3 секунды, можно задать 15 секунд. С помощью параметра -b можно задать число бит в ключе — 4096. Получаем такую команду:
# ssh-keygen -b 4096 -a 15
Выбираем директорию, вводим пароль и видим ключ RSA 4096.
Открытый ключ хранится в файле /домашний_каталог/.ssh/id_rsa.pub , закрытый — /домашний_каталог/.ssh/id_rsa .
Никогда и никому не передавайте, не показывайте свой закрытый ключ и не выкладывайте его на публично доступные сервисы (в т.ч. GitLab, GitHub и пр.).
Скопируйте открытый ключ на сервер в файл /домашний_каталог/.ssh/authorized_keys . Одной строкой:
cat ~/.ssh/id_rsa.pub | ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'
Или откройте этот файл на сервере редактором vi и вставьте строку с открытым ключом после ssh-rsa .
Ещё один способ скопировать ключ в authorized_keys — команда echo , которая помещает строку в конец файла.
echo ssh-rsa строка-публичного-ключа >> /root/.ssh/authorized_keys
Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.
Создание SSH-ключей на Windows с PuTTYgen
Если вы используете ОС Windows, то подключиться по SSH к вашему (Linux) серверу можно через PuTTY или OpenSSH . Генерация ключей в этом случае выполняется также при помощи этих программ. В примере мы используем клиент PuTTY.
Запустите приложение PuTTYgen , которое устанавливается вместе с PuTTY.
Выберите тип ключа SSH2-RSA и нажмите Generate .
В процессе генерации ключей несколько раз произвольно проведите мышкой по экрану приложения для создания случайных величин, используемых для ключей.
После завершения создания ключей открытый ключ выводится на экран, закрытый хранится в памяти приложения. Чтобы сохранить эти ключи нажмите Save public key и Save private key . Укажите расположение файлов с ключами.
При сохранении закрытого ключа, если не заполнено поле Key passphrase , появится запрос «Хотите ли вы сохранить ключ без секретной фразы?»
Теперь открытый ключ необходимо скопировать на сервер в файл authorized_keys . Используйте WinSCP или другой клиент для работы с файлами на удалённом Linux-сервере. Вы можете скопировать файл с открытым ключом целиком на сервер, чтоб его копия хранилась в папке .ssh
Откройте файл authorized_keys через WinSCP и файл, в который вы сохранили открытый ключ (public), на локальном компьютере текстовым редактором. Скопируйте значение ключа, сохраните и закройте файл в WinSCP.
При запуске PuTTY укажите путь к закрытому ключу на локальном компьютере. Для этого во вкладке Connections → Auth выберите необходимый путь.
Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.
Отключение аутентификации по паролю
Подключитесь к серверу по SSH, используя пароль, и откройте файл sshd_config для редактирования (например, с помощью текстового редактора Vi).
# vi /etc/ssh/sshd_config
Убедитесь, что указан правильный путь к открытым ключам SSH, поставьте значение параметра PasswordAuthentication no .
Перезапустите службу sshd:
# systemctl restart sshd
Подключитесь к серверу по SSH без использования пароля. Например, запустите PuTTY, проверьте, что во вкладке Connections -> Auth содержится путь к закрытому ключу и откройте подключение.
Login as: root Authenticating with public key “rsa-key-20230205” Last login: Sun Feb 5 13:11:24 2023 from 1.1.1.1
В случае успешной аутентификации по SSH-ключу вы получите доступ к командной строке сервера и сообщение вида Authenticating with public key «rsa-key-20230205», где rsa-key-20230205 — имя применённого закрытого ключа, указанное вами в файле authorized_keys.
Добавляем корневой доверенный сертификат в Linux
28.09.2022
itpro
CentOS, Linux, Ubuntu
комментариев 5
В этой статье мы покажем, как добавить (установить) новый сертификат в список доверенных корневых сертификатов в Linux.
Например, вы используете на своем сайте самоподписанный SSL/TLS сертификат и не хотите, чтобы на клиентах при открытии сайта появлялась ошибка SEC_ERROR_UNKNOWN_ISSUER.
В данном примере мы установим в Linux корневой сертификат Минцифры (Russian Trusted Sub CA), на базе которого сейчас выпускаются сертификаты для сайтов многих компаний и гос-органов РФ.
Или это может быть самоподписанный сертификат с сайта IIS на Windows.
Чтобы проверить, что ваш хост Linux не может проверить (и соответственно не доверяет) SSL сертификату на определенном сайте, выполните команду:
$ curl –I https://www.sberbank.ru
curl: (60) SSL certificate problem: unable to get local issuer certificate. More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.
В данном случае нам нужно добавить корневой центр сертификации этого сайта в список доверенных корневых сертификатов Linux.
Установка корневого сертификата в Linux
Для обновления хранилища доверенных сертификатов в Linux вам нужен файл сертификата в формате PEM с расширением файла .crt. PEM сертификат представляет собой текстовый файл в формате base64, который содержит в начале файла строку —-BEGIN CERTIFICATE—- и в конце ——END CERTIFICATE——.
Если ваш файл сертификата в формате DER, вы можете конвертировать его в PEM формат с помощью утилиты openssl:
$ openssl x509 -in my_trusted_sub_ca.der -inform der -out my_trusted_sub_ca.cer
Сначала рассмотрим, как добавит корневой сертификат вашего CA в доверенные в дистрибутивах Linux на базе DEB (Ubuntu, Debian, Mint, Kali Linux).
Скопируйте файлы ваших сертификаты в хранилище сертификатов в каталог usr/local/share/ca-certificates/:
$ sudo cp my_trusted_sub_ca.crt /usr/local/share/ca-certificates/
$ sudo cp my_trusted_root_ca.crt /usr/local/share/ca-certificates/
Обновите хранилище сертификатов командой:
$ sudo update-ca-certificates -v
Если команда не найдена, установите пакет в Ubuntu:
$ sudo apt-get install -y ca-certificates
Если сертификаты успешно добавлены, появится сообщение о том, что сертфикат скопирован в /etc/ssl/certs/:
Updating certificates in /etc/ssl/certs… 2 added, 9 removed; done. Running hooks in /etc/ca-certificates/update.d
Также вы можете добавить новые сертификаты в хранилище с помощью команды:
$ sudo dpkg-reconfigure ca-certificates
Выберите из списка сертификаты, которые нужно добавить в доверенные.
В Linux список доверенных сертификатов содержится в файле /etc/ssl/certs/ca-certificates.crt. Обе рассмотренные выше команды обновят этот файл и добавят в информацию о новых сертификатах.
Вы можете проверить, что ваши сертификаты были добавлены в доверенные с помощью команды:
Укажите часть Common Name вашего сертификата вместо YourCASubj для поиска в хранилище по subject.
Вы можете убедиться, что ваша ОС доверяет сертификату с помощью команду:
$ openssl verify my_trusted_sub_ca.crt
Если Linux не доверяет сертификату, появится ошибка:
error 20 at 0 depth lookup: unable to get local issuer certificate error my_trusted_sub_ca.crt: verification failed
Теперь проверьте, что на сайте используется доверенный SSL сертификат с помощью curl:
$ curl –I https://www.sberbank.ru
Все ок, сертификат доверенные < HTTPOnly: secure >.
Можно также вручную добавить путь к сертификату:
$ sudo mkdir /usr/share/ca-certificates/extra
$ sudo cp my.crt /usr/share/ca-certificates/extra/mycert1.crt
$ sudo vim /etc/ca-certificates.conf
exta/mycert1.crt
Чтобы удалить сертификат, удалите ваш crt файл:
$ sudo rm /usr/local/share/ca-certificates/yourcert.crt
И обновите хранилище:
$ sudo update-ca-certificates —fresh
В дистрибутивах Linux на базе RPM (CentOS, Oracle, RHEL, Rocky Linux, Fedora) для добавления сертификата в доверенные:
- Установите пакет ca-certificates: # yum install ca-certificates
- Скопируйте файл сертификата в каталог /etc/pki/ca-trust/source/anchors/: # cp mycert.crt /etc/pki/ca-trust/source/anchors/
- Обновите хранилище:
# update-ca-trust force-enable
# update-ca-trust extract
Аналогичная статья по управлению хранилищем корневых доверенных сертификатов в Windows.
Добавить корневой доверенный сертификат для браузеров Mozilla, Chrome
Теперь все системные утилиты будут доверять сайтам, использующим данный CA. Но это не повлияет на веб браузеры Mozilla Firefox или Google Chrome. Они по-прежнему будут показывать предупреждение о недоверенном сертификате.
Дело в том, что браузеры Firefox, Chromium, Google Chrome, Vivaldi и даже почтовый клиент Mozilla Thunderbird не используют системное хранилище сертификатов Linux. Хранилище сертификатов для этих программ находится в директории пользователя в файле cert8.db (для Mozilla) или cert9.db (для Chromium и Chrome). Для обновления этих хранилищ сертификатов используется утилита certutil из пакета libnss3-tools.
$ sudo apt install libnss3-tools
Теперь выполните следующие скрипты для добавления ваших сертификатов в хранилище через NSS:
#!/bin/bash
certfile=»my_rusted_root_ca.crt»
certname=»My Root CA1″
for certDB in $(find ~/ -name «cert8.db»)
do
certdir=$(dirname $);
certutil -A -n «$» -t «TCu,Cu,Tu» -i $ -d dbm:$
done
for certDB in $(find ~/ -name «cert9.db»)
do
certdir=$(dirname $);
certutil -A -n «$» -t «TCu,Cu,Tu» -i $ -d sql:$
done
После запуска скрипта, сайтам с данным CA будут доверять все браузеры.
Предыдущая статья Следующая статья 
Коротко о главном¶
Удостоверяющий центр (по-английски Certification authority, сокращённо CA) — это единый центр генерации цифровых сертификатов. У конечных клиентов (например, веб-браузеров) имеется база публичных ключей разных CA и они проверяют ими приходящие, например, от сайтов сертификаты. Нас интересуют сертификаты, используемые в сеансах, защищённых протоколом SSL/TLS.
Собственно, всю процедуру можно разбить на такие шаги:
- генерим приватный ключ (сильно случайный набор байтов);
- генерим на основе приватного ключа пару сертификатов для CA (публичный и приватный);
- генерим пару сертификатов для домена, подписанных созданным на прошлом шаге CA.
Создаём CA¶
Для начала сгенерим приватный ключ (файл ca.key), если хотите зашифровать приватный ключ с паролем, добавьте аргумент -des3 :
$ openssl genrsa -out ca.key 4096 Теперь сгенерим пару сертификатов для нашего CA (вместо 365 можно подставить любое другое значение, это срок годности пары сертификатов в днях):
$ openssl req -new -x509 -days 365 -key ca.key -out ca.crt Вводим пароль к ключу (если ключ был зашифрован) и затем аккуратно заполняем поля субъекта (subject). По этим данным можно будет потом идентифицировать публичный сертификат среди списка других, например. На выходе получаем файл ca.crt — это публичный сертификат нашего CA.
Можно создать ключ и сертификат одной командой, причём в эту же команду можно включить параметры субъекта:
$ openssl req -x509 -newkey rsa:2048 -keyout ca.key -nodes -out ca.crt -subj '/CN=example.com/L=Novosibirsk/C=RU' К сожалению, эта команда генерит невалидный ключ. Openssl и основанные на этой библиотеке приложения его понимает корректно, однако другие программы могут его не принять. Решается это такой командой (мы просто считываем и снова записываем файл):
$ openssl rsa -in ca.key -out ca.key Содержимое параметра -subj состоит из сегментов вида /$KEY=$VALUE , где $KEY может принимать такие значения:
- L — locality, обычно это город
- ST — state, обычно это регион, область, район и т.д.
- C — country, двухбуквенный код страны, например, RU или US
- O — organization, название организации
- OU — organization unit, отдел в организации
- CN — common name, обычно это адрес веб-сайта
- emailAddress — email
Создаём пару сертификатов для домена¶
Итак, у нас есть некий домен (к примеру, example.com) и мы хотим выписать для него SSL-сертификат, подписанный только что созданным CA. Сертификат дальше использовать в браузере. Шаги примерно такие же, как и в случае создания CA:
- создаём новый приватный ключ (нужен новый приватный ключ, тот, нельзя использовать тот, который мы делали для CA);
- создаём Certificate signing request (CSR), который потом нужно отправить CA;
- со стороны CA генерим сертификат на основе Certificate signing request;
- устанавливаем полученный сертификат на сервер.
Итак, генерим ключ (можете добавить -des3 , чтобы зашифровать ключ паролем):
$ openssl genrsa -out server.key 4096 Приватный ключ хранится на стороне владельца сервера и не должен никогда никому отдаваться. На базе приватного ключа server.key генерится так называемый запрос на подпись сертификата (по-английски certificate signing request (csr)), в запросе заполняются параметры субъекта (имя, адрес, домены итп), затем этот файл отправляется CA и тот создаёт сертификат на основе данных из CSR, подписывает его своим приватным ключом, в результате получаем подписанный публичный сертификат.
Вот простейший способ создать csr:
$ openssl req -new -key server.key -out server.csr В процессе работы нужно ответить на несколько вопросов (страна, город, имя домена итп), в результате получится csr-файл, который можно отправлять CA. Однако у такого способа есть несколько существенных недостатков — запрос данных идёт по заранее заданному шаблону, в который не входят некоторые важные поля, например, subjectAltName (это расширение для включения нескольких DNS-имён в сертификат).
Единственный мне известный способ указать расширение subjectAltName — это воспользоваться собственным конфигом для openssl. Вот, например, таким:
############################################### # Remaining options below should not be edited ############################################### [ req ] default_bits = 4096 distinguished_name = req_distinguished_name req_extensions = req_ext [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = RU stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Russia localityName = Locality Name (eg, city) localityName_default = Irkutsk organizationName = Organization Name (eg, company) organizationName_default = Example, Co. commonName = Common Name (eg, YOUR name or FQDN) commonName_max = 64 [ req_ext ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment ############################################### # Edit this line to set subjectAltName contents ############################################### subjectAltName = DNS:example.com, DNS:www.example.com, DNS:example.net Сохраните его в файл openssl-csr.cnf и отредактируйте (нужно прописать в поле subjectAltName свои домены, если вы в конфиге openssl разбираетесь, то можно и другие опции изменить/добавить), после чего выполните вот такую команду:
openssl req -new -key server.key -config openssl-csr.cnf -reqexts req_ext -out server.csr Полученный файл server.csr теперь нужно «отправить» CA, чтобы там его подписали. Поскольку CA наш собственный, то подписывать будем сами. И здесь тоже есть нюанс, связанный с X509v3-расширениями — команда создания сертификата по умолчанию не включает расширения, указанные в csr (то есть указанные в csr значения для subjectAltName в сертификат не попадут). Мы пойдём по самому простому пути — будем использовать тот же конфиг (openssl-csr.cnf), что и для генерации csr, из него нам понадобится только секция [ req_ext ] :
$ openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -set_serial 01 -extfile openssl-csr.cnf -extensions req_ext -in server.csr -out server.crt В данном случае «срок годности» сертификата устанавливаем в один год (365 дней).
Теперь у нас есть практически полный комплект всех нужных сертификатов. Иногда в сервере нужно использовать незашифрованный ключ, вот как его можно вытащить в файл server.key.insecure, если в server.key лежит зашифрованный ключ:
$ openssl rsa -in server.key -out server.key.insecure Для удобства использования можно немного переименовать файлы:
$ mv server.key server.key.secure $ mv server.key.insecure server.key Используем сертификаты¶
Для начала полезные команды, позволяющие «посмотреть» сертификаты и csr:
$ openssl rsa -noout -text -in server.key $ openssl req -noout -text -in server.csr $ openssl rsa -noout -text -in ca.key $ openssl x509 -noout -text -in ca.crt Теперь нужно положить сгенерированные сертификаты (server.crt и server.key) в нужное место на сервере. Конкретные детали уже выходят за рамки заметки.
Чтобы браузер не ругался на сертификат, нужно добавить в его репозиторий CA только что созданный CA, а именно файл ca.crt, импортируем, смотрим, что в списке он появился. Также можно сертификат положить в общесистемный репозиторий CA-сертификатов.