Какие файлы нужны для установки SSL-сертификата | FirstSSL

Что делать, когда все файлы готовы

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

1. Загрузка на сервер файлов сертификата, которые мы рассмотрели: секретный ключ, сертификат, цепочка сертификатов.
2. Переключение сайта на работу через защищенное соединение.

Конкретные шаги зависят от панели управления хостингом или типа сервера. Вы можете уточнить детали установки у своего хостинг-провайдера или воспользоваться инструкциями по ссылкам ниже.

Openssl

Основным рабочим инструментом будет библиотека openssl: она позволяет реализовать преобразование сертификатов и извлечение необходимой информации в текстовом формате (в сертификате информация закодирована либо в бинарном формате (DER), либо в base64 (PEM)).

Если на сервере вы подключаете SSL-шифрование для сайта, то сама библиотека, скорее всего, у вас уже установлена. Проверить, например, для какого домена (Canonical name) выпущен сертификат (если он в PEM формате, обычно в таком формате сертификаты выпускаются и передаются для установки на сервер) можно так:

openssl x509 -in ФАЙЛ_СЕРТИФИКАТА -subject -noout

Здесь x509 — входящий формат сертификата, in — ключ для входного файла, subject — указание вывести CN сертификата, а noout — запрет на вывод самого сертификата (в PEM формате).

Где взять файлы сертификатов

Для установки SSL-сертификата потребуются специальные файлы.

Дёргаем цепочку сертификатов

$ uname -or
FreeBSD 10.3-STABLE
$ openssl version
OpenSSL 1.0.2h  3 May 2021
$ `echo $SHELL` --version
tcsh 6.18.01 (Astron) 2021-02-14 (x86_64-amd-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec
$ /usr/local/bin/bash --version
GNU bash, version 4.3.25(1)-release (amd64-portbld-freebsd10.0)

$ echo | openssl s_client -connect ya.ru:443 | openssl x509 -certopt ca_default -out ya.pem -outform PEM

$ openssl x509 -in ./ya.pem -noout -text | grep 'Authority Information Access' -A 2
            Authority Information Access:
                OCSP - URI:http://yandex.ocsp-responder.com
                CA Issuers - URI:http://repository.certum.pl/ycasha2.cer

$ fetch http://repository.certum.pl/ycasha2.cer

$ openssl x509 -inform der -in ./ycasha2.cer -out ./ycasha2.pem

$ openssl x509 -in ./ycasha2.pem -noout -text | grep 'Authority Information Access' -A 2
            Authority Information Access:
                OCSP - URI:http://subca.ocsp-certum.com
                CA Issuers - URI:http://repository.certum.pl/ctnca.cer

$ fetch http://repository.certum.pl/ctnca.cer

$ openssl x509 -inform der -in ./ctnca.cer -out ./ctnca.pem

$ openssl x509 -in ./ctnca.pem -noout -text | grep 'X509v3 extensions' -A 6
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

$ cat ya.pem ycasha2.pem ctnca.pem > chain0.pem

$ echo | openssl s_client -connect ya.ru:443 | grep Verify
    Verify return code: 0 (ok)

$ echo | openssl s_client -connect ya.ru:443 -CApath . | grep Verify
    Verify return code: 20 (unable to get local issuer certificate)

$ openssl x509 -noout -hash -in ./ctnca.pem
48bec511

$ ln -s `pwd`/ctnca.pem `pwd`/48bec511.0

$ echo | openssl s_client -connect ya.ru:443 -CApath . | grep Verify
DONE
    Verify return code: 0 (ok)

$ ./issuers.sh ./ya.pem
0
http://repository.certum.pl/ycasha2.cer
tmp.der                                       100% of 1196  B   16 MBps 00m00s
IS PEM: [0]
DER(tmp.der) -> PEM(./ya.pem0.pem)
/usr/bin/openssl  x509 -inform der -in tmp.der -out ./ya.pem0.pem
1
http://repository.certum.pl/ctnca.cer
tmp.der                                       100% of  959  B   13 MBps 00m00s
IS PEM: [0]
DER(tmp.der) -> PEM(./ya.pem1.pem)
/usr/bin/openssl  x509 -inform der -in tmp.der -out ./ya.pem1.pem
cat ././ya.pem* > chain.pem
Certificate chain:
-rw-r--r--  1 root  wheel  5842 Jun 30 15:46 chain.pem

$ md5 chain0.pem ; md5 chain.pem
MD5 (chain0.pem) = 6d32b0798d48d14764cd26cc4f730444
MD5 (chain.pem) = 6d32b0798d48d14764cd26cc4f730444

Запускаем рекурсию

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

Для проверки формата сертификата воспользуемся verify от openssl:

openssl verify /tmp/stapling.crt 2>&1 | grep "unable to load")

В случае возникновения ошибки чтения загруженного сертификата нам нужно будет его преобразовать из бинарного формата в base64:

openssl x509 -inform der -in /tmp/stapling.crt -out /tmp/stapling.crt

или из pkcs7

openssl pkcs7 -inform der -print_certs -in /tmp/stapling.crt -out /tmp/stapling.crt

После преобразования сертификата мы можем спокойной скопировать его в конец нашей цепочки, определить путь к «родительскому» сертификату и продолжить составление цепочки (если требуется).

Как создать файл цепочки ssl сертификатов

Корневые сертификаты

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

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

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

В данном примере сертификаты «Б» и «В» называются промежуточными.

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

При определённых усилиях и наличии доступа к атакуемому компьютеру злоумышленник может включить в число корневых сертификатов свой и использовать его для расшифровки данных пользователя.

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

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

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

Корневые сертификаты эцп уц — установка корневых сертификатов на

Получаем «родительский» сертификат

Алгоритм «сшивки» сертификатов достаточно простой: нам нужно из сертификата извлечь путь к «родительскому» сертификату (тому сертификату, которым подписанный данный) и получить этот «родительский» сертификат по извлеченному пути. Простого набора ключей для openssl найти не удалось, поэтому сделаем это с помощью вывода всей информации о сертификате в тестовом формате с помощью ключа text:

openssl x509 -in "ФАЙЛ_СЕРТИФИКАТА" -text -noout

После этого нам нужно лишь выделить поле Issuers и получить из него URL. Это можно сделать, например, так:

Поручители

В роли поручителя-удостоверителя выступает центр сертификации, который выпустил SSL-сертификат по запросу владельца сайта.

Сертификат и сайт, для которого он выпущен, удостоверяются электронной цифровой подписью (ЭЦП). Эта подпись, во-первых, указывает, кому принадлежит она сама, а во-вторых, фиксирует содержимое сертификата, то есть позволяет проверить, не был ли он кем-то изменён после выпуска и подписания.

Пусть некто «Б» удостоверил личность некоего «А».

Проблему можно считать преодолённой, если вы знаете и доверяете «Б», а что, если — нет: не знаете или не доверяете.

«Б», в свою очередь, может сообщить, что его знает «В».

В принципе, длина цепочки удостоверений не ограничена. Главное, чтобы в ней оказался тот, кому мы доверяем.

Мишу знает Боря, Борю знает Дима, Диму знает Вова, а вот уж Вову мы знаем сами. Помните шуточную теорию о шести рукопожатиях между двумя любыми людьми, одновременно живущими на Земле?

Однако в реальной жизни в цепочке знакомых между собой людей может долго не быть знакомого лично нам. Или эта цепочка может оказаться слишком длинной. Или потребовать слишком много ресурсов на свою обработку.

Правильный порядок сертификатов в цепочке

В финале должен получиться файл с цепочкой сертификатов следующего содержания:

-----BEGIN CERTIFICATE-----
сертификат сайта в формате base64
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
промежуточный сертификат в формате base64
-----END CERTIFICATE-----
[-----BEGIN CERTIFICATE-----
возможно, еще один промежуточный сертификат
-----END CERTIFICATE-----]
-----BEGIN CERTIFICATE-----
корневой сертификат в формате base64
-----END CERTIFICATE-----

Браузерам сам корневой сертификат в цепочке не требуется: он у них уже есть. Но он требуется для верификации цепочки самому nginx с включенной настройкой ssl_stapling.

Секретный ключ

Секретный ключ — это файл с расширением .key. Иногда секретный ключ отсутствует в Личном кабинете. Это может произойти, если при создании запроса на сертификат вы выбрали настройку «Не сохранять ключ». Если у вас нет ключа, сертификат необходимо перевыпустить.

Секретный ключ, открытый в текстовом редакторе, представляет собой набор символов. Они заключены между пометками «Begin RSA private key» — (начало ключа) и «End RSA private key» (конец ключа). Секретный ключ используется для расшифровки данных, поступающих на сервер, поэтому не передавайте его посторонним.

Сертификат

Файл «сертификат», скачанный из личного кабинета, представляет собой архив zip. Распакуйте его. Внутри вы найдёте ещё два файла: сертификат и цепочку сертификатов.

Сертификат — это файл с расширением .crt. Он же является публичным ключом.

Внутри содержится заголовок «Begin certificate» — начало сертификата, тело сертификата и отметку «End certificate» — конец сертификата:

Цепочка сертификатов

Цепочка сертификатов — файл с расширением .ca-bundle

В текстовом редакторе цепочка сертификатов выглядит как набор символов. Начало и конец помечены «Begin certificate» и «End certificate».

Цепочки сертификатов для comodo

CA_BUNDLE PositiveSSL (SHA-1)  Подходит для сертификатов COMODO PositiveSSL и PositiveSSL Wildcard (смотреть все SSL-сертификаты Wildcard)

CA_BUNDLE EssentialSSL (SHA-1) Подходит для сертификатов COMODO EssentialSSL, EssentialSSL Wildcard

CA_BUNDLE PositiveSSL и EssentialSSL (SHA-2) Подходит для сертификатов COMODO PositiveSSL, EssentialSSL, PositiveSSL/EssentialSSL Wildcard

CA_BUNDLE InstantSSL/PremiumSSL/InstantSSL Pro (SHA-1) Подходит для сертификатов COMODO InstantSSL, PremiumSSL, InstantSSL Pro и PremiumSSL Wildcard

CA_BUNDLE InstantSSL/PremiumSSL/InstantSSL Pro (SHA-2) Подходит для сертификатов COMODO InstantSSL, PremiumSSL, InstantSSL Pro и PremiumSSL Wildcard

CA_BUNDLE Comodo EVSSL (SHA-1) Подходит для сертификтатов COMODO EV SSL

CA_BUNDLE Comodo EVSSL (SHA-2) Подходит для сертификтатов COMODO EV SSL

Цепочки сертификатов для geotrust

RapidSSL/Wildcard (SHA-1) Подходит для сертификатов GeoTrust RapidSSL и RapidSSL Wildcard

RapidSSL/Wildcard (SHA-2 under SHA-1 root) Подходит для сертификатов GeoTrust RapidSSL и RapidSSL Wildcard

QuickSSL Premium (SHA-1)

QuickSSL Premium (SHA-2 under SHA-1 root)

TrueBusinessID (SHA-1)

TrueBusinessID (SHA-2 under SHA-1 root)

TrueBusinessID (SHA-2 under SHA-2 root)

TrueBusinessID with EV (SHA-1)

TrueBusinessID with EV (SHA-2 under SHA-1 root)

TrueBusinessID with EV (SHA-2 under SHA-2 root)

Цепочки сертификатов для thawte

SSL 123 (SHA-1)

SSL 123 (SHA-2 under SHA-1 root)

SSL 123 (SHA-2 under SHA-2 root)

SSL WebServer (SHA-1)

SSL WebServer (SHA-2 under SHA-1 root)

SSL WebServer (SHA-2 under SHA-2 root)

SSL WebServer with EV (SHA-1)

SSL WebServer with EV (SHA-2 under SHA-1 root)

SSL WebServer with EV (SHA-2 under SHA-2 root)

Цепочки сертификатов для verisign

Secure Site (SHA-1)

Secure Site Pro (SHA-1)

Secure Site и Secure Site Pro (SHA-2 under SHA-1 root)

Secure Site и Secure Site Pro (SHA-2 under SHA-2 root)

Secure Site with EV (SHA-1)

Secure Site Pro with EV (SHA-1)

Secure Site with EV и Secure Site Pro with EV (SHA-2 under SHA-1 root)

Secure Site with EV и Secure Site Pro with EV (SHA-2 under SHA-2 root)

Читайте здесь,

Заключение

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

P.S. Что еще можно почитать на тему SSL-сертификатов: