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

Обновлено: 07.07.2024

Блог про Linux, Bash и другие информационные технологии

Что такое SSL и что такое TLS?

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

Принцип работы SSL и TLS

Установка соединения обеспечивается в несколько этапов:

1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.

3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.

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

6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.

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

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

Запрос на подпись (CSR, Certificate Sign Request)

Клиентский сертификат

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

Цепочка действий по генерации сертификатов

Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.

Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.

Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.

Серверный сертификат

Для подписи сертификата для сервера нам нужно выполнить следующие действия:

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

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

Установка SSL/TLS-сертификата на сервер с nginx

Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:

2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

3) Перезапустить nginx

Установка SSL/TLS-сертификата на сервер с Apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

4) Перезапустить веб-сервер Apache

Создание клиентского сертификата

Клиентский сертификат создается примерно так же, как серверный.

Если необходим клиентский сертификат в формате PKCS12, создаем его:

Теперь можно использовать клиентский сертификат для работы с нашим сервером.

Настройка nginx на использование клиентских сертификатов

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

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

Настройка Apache на использование клиентских сертификатов

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

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Со стороны сервера ошибка выглядит так:

Со стороны клиента так:

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.

Безопасность

В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.

В данной статье речь пойдёт о том как проверить и собрать цепочку сертификатов с помощью консоли. О том что такое SSL сертификат Вы можете узнать из нашей статьи «SSL сертификаты — особенности и отличия».

Примеры описанные в данной статье выполнены на OS семейства Debian / Ubuntu.

Все описанные ниже команды выполняются в терминале (консоле), из директории в которой расположены все необходимые нам файлы.

Обязательным условием для проверки является наличие установленного пакета openssl, проверить наличие очень легко, достаточно ввести команду:

При наличии пакетов Вы получите следующий вывод на экран:

Проверка наличия openssl.

В ином случае Вам стоит установить данный пакет, для этого выполните команду

apt install openssl

Итак, сперва проверим корректность содержимого CSR, выполняем команду

openssl req -text -noout -verify -in server.csr

Стоит обратить внимание на строку

verify — статус корректного файла должен иметь значение «OK»

Немнго о значениях поля Subject:

  • C — сокращённое название страны
  • ST — область, в которой расположена организация
  • L — город, в которой расположена организация
  • O — наименование организации
  • OU — обозначение отрасли в которой работает компания
  • CN — адрес сайта (доменное имя) Вашей компании
  • emailAddress — это поле думаю понятно всем, это контактный адрес электронной почты

Значения полей Subject

Далее необходимо проверить корректность ключа, для этого требуется выполнить

openssl rsa -in server.key -check

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

Опять таки для нас наиболее важной информацией является статус в поле RSA key, если
статус «ok» - с ключом всё в порядке.

Проверяем SSL сертификат:

openssl x509 -in crt.crt -text -noout

Проверка SSL сертификата

В листинге вывода мы видим данные сертификата:

  • срок действия сертификата описан в блоке периода действия (Validity)
    • Not Before обозначают дату начала действия (не ранее чем)
    • Not After дату конца действия (не позже)

    После проделанных действий необходимо сравнить соответствие полученных ключа,
    сертификата и CSR.

    Выполняется это сравнением MD5 сумм.

    openssl x509 -noout -modulus -in crt.crt |md5sum

    openssl rsa -noout -modulus -in key.key |md5sum

    openssl req -noout -modulus -in csr.csr | md5sum

    Сверка данніх ключа и CSR

    Если ключ, сертификат и CSR созданы друг для друга — хешсуммы будут одинаковыми.

    Соберем цепочку сертификатов.

    Чтобы понять в какой последовательности должны быть добавлены данные необходимо
    выполнить команду :

    openssl x509 -in имя_сертификата.crt -noout -text | egrep "Subject:|Issuer:"

    для каждого сертификата, который был прислан в архиве.

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

    Последовательность добавления данных

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

    cat sics_com_ua.crt > ./bundle.bundle

    cat SectigoRSADomainValidationSecureServerCA.crt >> ./bundle.bundle

    cat USERTrustRSAAddTrustCA.crt >> ./bundle.bundle

    cat AddTrustExternalCARoot.crt >> ./bundle.bundle

    Стоит обратить внимание на символы > и >>.

    Одинарный знак будет перезаписывать файл в то время как двойной дописывать.

    После проведённых действий производим проверку сертификатов и bundle на соответствие
    по хешсумме.

    Хешсумма проверки совпадает

    В том случае если цепочка будет собрана не верно, сумма совпадать не будет.

    Хэшсумма проверки не совпадает

    Для проверки полной цепочки установленной на сайте необходимо выполнить команду:

    Проверка полной цепочки SSL сертификата

    В разделе Certificate chain описывается цепочка.

    У нас Вы можете заказать VPS c ОС Debian и Ubuntu. Если во время использования инструкции у Вас возникнут вопросы, наша техническая поддержка готова прийти на помощь в любое время.

    Вопрос только один как выстроить цепочку.

    oleg_sidorenkov

    Видел это решением на других пабликах, но пошел по другому пути:
    1. С помощью текстового редактора:
    a. откройте файлы
    b. создайте новый документ
    c. скопируйте в новый документ содержание каждого из файлов в последовательности: сертификат посредника 1, сертификат посредника 2, сертификат посредника 3, корневой сертификат
    d. сохраните файл

    Должно получиться что-то вроде:
    -----BEGIN CERTIFICATE-----
    MIICBzCCAXACCQDBBdYCGkYdkDANBgkqhkiG9w0BAQUFADBIMS owKAYJKoZIhvcN
    AQkBFht3ZWJtYXN0ZXJAYmlsbG1ncnNlcnZlci5jb20xGjAYBg NVBAMTEWJpbGxt
    Z3JzZXJ2ZXIuY29tMB4XDTEzMDQxNDE2MzgyNloXDTIzMDQxMj E2MzgyNlowSDEq
    MCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQGJpbGxtZ3JzZXJ2ZX IuY29tMRowGAYD
    VQQDExFiaWxsbWdyc2VydmVyLmNvbTCBnzANBgkqhkiG9w0BAQ EFAAOBjQAwgYkC
    gYEA00K2OIK5rsHToFmv2lqAPsmQs3BYKhADm7sC69FqIUWQtf EzGNa24Wts/SAp
    7tjPWb7couX0+6pekekc6lfJitUd27M2yhblzpF3eYIhAT5o7F X/K54S3B4vT7Ky
    WXC7I1LXC9xAHnErhpIc97wPS7R0IKQ8J5rWdsaOdYx79s0CAw EAATANBgkqhkiG
    9w0BAQUFAAOBgQArdad2hqOORfYeV0xcbFSyLkVHVgeuF9ulBo E7qsd777ylBySi
    0Pg1WGnkaByBGmhphzwfj7cWE75o0p955z4VPNv+4fHNli9Hz4 vTQjQIbQ+iCGBK
    XLIvfWmbzOW8orPhk2cULY1uQboQK+TUTm0Fj/2/DR/cSbFUSo2Wn66WPg==
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    MIICBzCCAXACCQDBBdYCGkYdkDANBgkqhkiG9w0BAQUFADBIMS owKAYJKoZIhvcN
    AQkBFht3ZWJtYXN0ZXJAYmlsbG1ncnNlcnZlci5jb20xGjAYBg NVBAMTEWJpbGxt
    Z3JzZXJ2ZXIuY29tMB4XDTEzMDQxNDE2MzgyNloXDTIzMDQxMj E2MzgyNlowSDEq
    MCgGCSqGSIb3DQEJARYbd2VibWFzdGVyQGJpbGxtZ3JzZXJ2ZX IuY29tMRowGAYD
    VQQDExFiaWxsbWdyc2VydmVyLmNvbTCBnzANBgkqhkiG9w0BAQ EFAAOBjQAwgYkC
    gYEA00K2OIK5rsHToFmv2lqAPsmQs3BYKhADm7sC69FqIUWQtf EzGNa24Wts/SAp
    7tjPWb7couX0+6pekekc6lfJitUd27M2yhblzpF3eYIhAT5o7F X/K54S3B4vT7Ky
    WXC7I1LXC9xAHnErhpIc97wPS7R0IKQ8J5rWdsaOdYx79s0CAw EAATANBgkqhkiG
    9w0BAQUFAAOBgQArdad2hqOORfYeV0xcbFSyLkVHVgeuF9ulBo E7qsd777ylBySi
    0Pg1WGnkaByBGmhphzwfj7cWE75o0p955z4VPNv+4fHNli9Hz4 vTQjQIbQ+iCGBK
    XLIvfWmbzOW8orPhk2cULY1uQboQK+TUTm0Fj/2/DR/cSbFUSo2Wn66WPg==
    -----END CERTIFICATE-----

    Full-stack development: Python, PostgreSQL, JavaScript, Linux, Git e t.c.

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

    Чтобы не писать кучу команд всякий раз, напишем bash-скрипт. Для начала, зададим несколько настроечных констант:

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

    Все готово к созданию фальшивой, но технически корректной пары корневой сертификат / приватный ключ:

    Хорошо, теперь создадим промежуточный сертификат с ключом:

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

    Ну а теперь, собственно, итог:

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

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

    Строго говоря, проверка корректности уже была произведена в процессе создания. Но так как мне нужно было делать это в Python, я использовал библиотеку pyOpenSSL, а именно модуль crypto. Для примера покажу, как это можно сделать без затей:

    Для X509Store можно добавить флаги проверок, которые все сломают. К примеру, если добавить вот такой флаг, то получим исключение OpenSSL.crypto.X509StoreContextError :

    А все потому, что будет предпринята попытка скачать CRL-файл, указанный в дополнениях сертификата, и эта попытка провалится. Как с этим бороться, как добавить Issuer URL и т.п. - это совсем другая история, которая в принципе вся решается через конфигурацию openssl .

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

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

    Установка сертификата от Comodo

    По умолчанию, Центр сертификации отправляет корневой (Root) и промежуточный (Intermediate) сертификаты вместе с основным в архиве. Стоит отметить, что в архиве может быть не один, а несколько промежуточных сертификатов. Данный факт зависит от типа заказанного SSL сертификата. На текущий момент, Центр Сертификации предоставляет следующую цепочку сертификатов.

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • COMODOAddTrustServerCA.crt - промежуточный сертификат (вставлять в третье поле).
    • COMODOExtendedValidationSecureServerCA.crt - промежуточный сертификат (вставлять четвертое поле).
    • AddTrustExternalCARoot.crt - корневой сертификат (вставлять в пятое поле).

    GoGetSSL Domain SSL

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • вашдомен.crt - сертификат для вашего домена (вставлять в второе поле).
    • USERTrust_RSA_Certification_Authority.crt - промежуточный сертификат (вставлять в третье поле).
    • AddTrust_External_CA_Root.crt - корневой сертификат (вставлять в четвертое поле).

    Sectigo SSL

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • AAA_Certificate-Services.crt - промежуточный сертификат (вставлять в третье поле).
    • USERTrust_RSA_Certification_Authority.crt - промежуточный сертификат (вставлять в четвертое поле).

    Sectigo

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • AAACertificateServices.crt - промежуточный сертификат (вставлять в третье поле).
    • USERTrustRSAAAACA.crt - промежуточный сертификат (вставлять в четвертое поле).
    • SectigoRSADomainValidationSecureServerCA.crt - промежуточный сертификат (вставлять в пятое поле).

    GoGetSSL от Comodo

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • AAACertificateServices.crt - промежуточный сертификат (вставлять в третье поле).
    • USERTrustRSAAAACA.crt - промежуточный сертификат (вставлять в четвертое поле).
    • GoGetSSLRSADVCA.crt - промежуточный сертификат (вставлять в пятое поле).
    • Приватный RSA PRIVATE KEY - вставить в первое поле.
    • Ваш SSL сертификат - вставить в второе поле.
    • Промежуточный сертификат - вставить в третье поле.
    • Корневой сертификат - добавьте четвертое поле и в него вставьте.

    InstantSSL

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • ComodoHigh-AssuranceSecureServerCA.crt - промежуточный сертификат (вставлять в третье поле).
    • AddTrustExternalCARoot.crt - корневой сертификат (вставлять в четвертое поле).

    ComodoSSL / ComodoSSL Wildcard

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • ComodoSSLCA.crt - промежуточный сертификат (вставлять в третье поле).
    • AddTrustExternalCARoot.crt - корневой сертификат (вставлять в четвертое поле).

    EssentialSSL

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • UTNAddTrustSGCCA.crt - промежуточный сертификат (вставлять в третье поле).
    • ComodoUTNSGCCA.crt - промежуточный сертификат (вставлять в четвертое поле).
    • EssentialSSLCA_2.crt - промежуточный сертификат (вставлять в пятое поле).
    • AddTrustExternalCARoot.crt - корневой сертификат (вставлять в шестое поле).

    В uCoz / uWeb ограничение всего на 5 полей, в данной ситуации вам придется написать в техподдержку с панели управления сайтом (предоставить им файлы сертификата) и вам прикрепит сертификат сотрудник техподдержки.

    PositiveSSL

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • PositiveSSLCA2.crt - промежуточный сертификат (вставлять в третье поле).
    • AddTrustExternalCARoot.crt - корневой сертификат (вставлять в четвертое поле).

    Comodo PositiveSSL

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • sitename_com.crt - сертификат для вашего домена (вставлять в второе поле).
    • sitename_com.ca-bundle - промежуточный сертификат (вставлять в третье поле).

    Comodo

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • COMODORSADomainValidationSecureServerCA - промежуточный сертификат (вставлять в третье поле).
    • COMODORSAAddTrustCA - промежуточный сертификат (вставлять в четвертое поле).
    • AddTrustExternalCARoot - корневой сертификат (вставлять в пятое поле).

    Comodo может предоставить файлы сертификата

    • private.key - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • name_domain.crt - сертификат для вашего домена (вставлять в второе поле).
    • SectigoRSADomainValidationSecureServerCA - промежуточный сертификат (вставлять в третье поле).
    • USERTrustRSAAddTrustCA - промежуточный сертификат (вставлять в четвертое поле).
    • AddTrustExternalCARoot - корневой сертификат (вставлять в пятое поле).

    Digi Sert может предоставить такие файлы

    • key.txt - приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
    • sitename_ru_2022_10_13.crt - сертификат для вашего домена (вставлять в второе поле).
    • intermediate_pem_thawte_ssl123_1.crt - промежуточный сертификат (вставлять в третье поле).
    • root_pem_thawte_ssl123_1.crt - корневой сертификат (вставлять в четвертое поле).

    При установке SSL сертификата, содержимое каждого из файлов нужно копировать вместе с текстом:

    то есть не нужно отдельно выбирать что копировать, а что нет. Открыли файл текстовым редактором (блокнотом) Notepad и копируете все содержимое, далее вставляете в нужное поле.

    Читайте также: