UMGUM.COM (лучше) 

Просто с X.509-сертификатами ( Пример генерации RSA-ключей, формирования CSR-запроса, получения SSL/TLS-сертификата и применения его в web-серверах. )

3 октября 2017  (обновлено 16 ноября 2018)

OS: Linux Debian/Ubuntu.
Application: OpenSSL, Nginx, Apache2.

Здесь простейшая шпаргалка процедуры подготовки к приобретению SSL/TLS-сертификата, проверки его корректности и применения в web-сервисе, расширенная некоторыми пояснениями.


Генерируем закрытый и открытый ключи.

Работы с компонентами сертификата очень желательно проводить в месте, закрытом от доступа посторонних:

$ mkdir -p ./make-cert

Прежде всего необходимо создать "закрытый" (он же "приватный") и "открытый" (он же "публичный") RSA-ключи шифрования, которые в дальнейшем будут использоваться при создании всех остальных компонентов сертификата и подтверждения подлинности такового на стороне web-сервера:

$ cd ./make-cert
$ openssl genrsa -des3 -out ./example.net.key 2048

Мешанина символов, которую мы видим в текстовом файле ключей на самом деле представляет собой контейнер обфусцированного набора блоков сгенерированных в соответствии с алгоритмом RSA уникальных шифров, и один из этих блоков - "modulus" - является "открытым" ключём связки асимметричного шифрования, используемым во всех компонентах сертификата. Всё остальное содержимое - "закрытый" ключ.

Для ознакомления с содержимым блоков контейнера ключей его код можно раскрыть в более структурированном виде:

$ openssl rsa -noout -text -in ./example.net.key

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

Надо отметить, что на практике, когда SSL-сертфикат применяется всего лишь для перевода на HTTPS ряда сайтов, большинство предпочитает не возиться с запароленным контейнером ключей, а сразу освобождает его от этой защиты, создавая рядом ещё один - "беспарольный":

$ cd ./make-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt

Создаем запрос на выпуск X.509-сертификата (CSR).

Сама по себе подсистема защиты потока трафика посредством SSL/TLS обычно реализуется на сессионных симметричных ключах, вырабатываемых web-сервером и браузером клиента при первичном согласовании соединения, и какие-то особые предустановленные ключи шифрования для этого не требуются (хотя и облегчают процедуру согласования - DH-key, например). Сертификат же (стандарта X.509), набор компонентов которого мы здесь поэтапно формируем, предназначен для своего рода подтверждения подлинности web-ресурса в интернет-инфраструктуре, где условно доверенный центр сертификации гарантирует связь указанных в сертификате "открытого" ключа и описания ресурса посредством электронной подписи содержимого такового.

Для передачи центру сертификации нашего "публичного" ключа (не всего содержимого "приватного" ключа, а лишь его блока "modulus"!) и сведений о ресурсе, подлинность которого мы подтверждаем, предназначен специальный CSR-контейнер (Certificate Signing Request). Создаём его, указывая в качестве источника "открытого" ключа контейнер таковых:

$ cd ./make-cert
$ openssl req -new -key ./example.net.key -out ./example.net.csr

В процессе потребуется указать данные о собственнике ресурса, для которого запрашивается сертификат, такие как:

"Country Name" - двухсимвольный код страны согласно ISO-3166 (RU - для России);
"State or Province Name" - название области или региона;
"Locality Name" - название города или населённого пункта;
"Organization Name" - название организации;
"Organizational Unit Name" - название подразделения (необязательное поле);
"Common Name" - полностью определённое доменное имя ресурса (FQDN), для которого запрашивается сертификат;
"Email Address" - контактный e-mail адрес администратора доменного имени (необязательное поле);
"A challenge password" - (необязательное поле, не заполняется);
"An optional company name" - альтернативное имя компании (необязательное поле, не заполняется).

Обращаю внимание, что если действие сертификата должно распространяться на поддомены удостоверяемого ресурса, то FQDN в поле "Common Name" потребуется дополнить маской "*." ("*.example.net" - например).

Любопытствующие могут посмотреть, что скрыто в коде CSR-контейнера:

$ openssl req -noout -text -in ./example.net.csr

CSR-файл "example.net.csr" отправляем в удостоверяющий центр, у которого мы приобретаем сертификат.

Приобретение SSL/TLS-сертификата (X.509).

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

Генерирование самоподписанного X.509-сертификата (опционально).

Как вариант, для использования исключительно в локальной сети, можно создать требуемый сертификат самостоятельно, подписав его своим "закрытым" ключём вместо доверенного центра сертификации - так называемый "self-signed" (самоподписанный):

$ cd ./make-cert
$ openssl x509 -req -days 1095 -in ./example.net.csr -signkey ./example.net.key -out ./example.net.crt

В результате работы вышеприведённой команды в дополнение к имеющимся компонентам мы получим файл "example.net.crt" самодельного сертификата, подлинность которого нельзя проверить в интернет инфраструктуре центров сертификации, хотя функционально он нормален и применим.

Проверка корректности сертификатов и ключей.

В полученном SSL/TLS-сертификате зафиксирована как минимум следующая информация:

Версия сертификата;
Серийный номер сертификата;
Алгоритм подписи;
Полное (уникальное) имя владельца сертификата;
Открытый ключ владельца сертификата;
Дата выдачи сертификата;
Дата окончания действия сертификата;
Полное (уникальное) имя центра сертификации;
Цифровая подпись издателя.

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

$ cd ./make-cert
$ openssl x509 -noout -text -in ./example.net.crt

На практике часто случается так, что некомпетентные клиенты или коллеги предоставляют для применения непосредственно в web-сервисах перепутанные сертификаты и ключи, не связанные между собой. Попытка применения таковых в web-сервере вызовет ошибку вроде "x509 key value mismatch".

Простейший способ проверки корректности связки "приватного" ключа, CSR-запроса и финального X.509-сертификата заключается в сверке контрольной суммы "публичного" ключа (блока "modulus"), содержащегося во всех этих контейнерах:

$ openssl rsa -noout -modulus -in ./example.net.key | openssl md5
$ openssl req -noout -modulus -in ./example.net.csr | openssl md5
$ openssl x509 -noout -modulus -in ./example.net.crt | openssl md5

Строка MD5-хеша короткая, и выявление различий между ними не составит труда.

Формируем типовой набор файлов сертификатов и ключей.

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

В общем, в процессе у нас может скопиться несколько файлов, которые я именую соответственно их функционалу, примерно так:

"example.net.key" - контейнер с "закрытым" и "открытым" ключами (защищённый паролем);
"example.net.key.decrypt" - незащищённый паролем контейнер с "закрытым" и "открытым" ключами;
"example.net.csr" - CSR-запрос, использовавшийся при заказе сертификата;
"example.net.crt" - непосредственно наш X.509-сертификат;
"intermediate.crt" - сертификат (или цепочка таковых) центра сертификации;
"root.crt" - сертификат корневого центра, от которого начинается цепь доверия.

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

$ cd ./make-cert
$ cat ./example.net.crt >> ./example.net-chain.crt
$ сat ./intermediate.crt >> ./example.net-chain.crt
$ cat ./root.crt >> ./example.net-chain.crt

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

В Linux-е для сертификатов и ключей шифрования уже предусмотрены места в файловой системе. Распределяем файлы и защищаем их от доступа посторонних:

# mkdir -p  /etc/ssl/certs
# mkdir -p  /etc/ssl/private

# cp ./example.net-chain.crt /etc/ssl/certs/
# cp ./example.net.key.decrypt /etc/ssl/private/

# chown -R root:root /etc/ssl
# chmod -R o-rwx /etc/ssl

SSL-сертификат в web-сервере Nginx.

В самом простом случае применение SSL-сертификата в web-сервере "Nginx" реализуется примерно следующим образом:

# vi /etc/nginx/sites-enabled/example.net.conf

....
# Описание рабочего окружения доступного по HTTPS web-сайта
server {
  listen  443 ssl;
  server_name example.net;
  ....

  # Рекомендуемые обобщённые настройки протокола
  ssl on;
  ssl_dhparam          /etc/nginx/ssl/dhparam.pem;
  ssl_protocols        SSLv3 TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers          AES256-SHA:RC4:HIGH:!aNULL:!MD5:!kEDH;
  ssl_prefer_server_ciphers on;
  ssl_session_cache    shared:SSL:30m;
  ssl_session_timeout  1h;

  # Файлы сертификатов и ключей
  ssl_certificate      /etc/ssl/certs/example.net-chain.crt;
  ssl_certificate_key  /etc/ssl/private/example.net.key.decrypt;
  ....
}
....

SSL-сертификат в web-сервере Apache.

В web-сервере "Apache" SSL-сертификат применяется примерно так:

# vi /etc/apache2/sites-enabled/example.net.conf

....
# Описание рабочего окружения доступного по HTTPS web-сайта
<VirtualHost example.net:443>
  ServerName example.net
  ....

  <IfModule mod_ssl.c>
    # Рекомендуемые обобщённые настройки протокола
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLHonorCipherOrder on
    SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM
    SSLOptions +StrictRequire
    SSLCompression off

    # Файлы сертификатов и ключей
    SSLCertificateFile     /etc/ssl/certs/example.net-chain.crt
    SSLCertificateKeyFile  /etc/ssl/certs/example.net.key.decrypt
  </IfModule>
  ....

</VirtualHost>
....


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )