цепочка ssl сертификатов что это
О том как правильно создать цепочку сертификатов SSL
В данной статье речь пойдёт о том как проверить и собрать цепочку сертификатов с помощью консоли. О том что такое SSL сертификат Вы можете узнать из нашей статьи «SSL сертификаты — особенности и отличия».
Примеры описанные в данной статье выполнены на OS семейства Debian / Ubuntu.
Все описанные ниже команды выполняются в терминале (консоле), из директории в которой расположены все необходимые нам файлы.
Обязательным условием для проверки является наличие установленного пакета openssl, проверить наличие очень легко, достаточно ввести команду:
При наличии пакетов Вы получите следующий вывод на экран:
В ином случае Вам стоит установить данный пакет, для этого выполните команду
apt install openssl
Итак, сперва проверим корректность содержимого CSR, выполняем команду
Стоит обратить внимание на строку
verify — статус корректного файла должен иметь значение «OK»
Немнго о значениях поля Subject:
Далее необходимо проверить корректность ключа, для этого требуется выполнить
Проверяем SSL сертификат:
В листинге вывода мы видим данные сертификата:
После проделанных действий необходимо сравнить соответствие полученных ключа,
сертификата и CSR.
Выполняется это сравнением MD5 сумм.
Если ключ, сертификат и CSR созданы друг для друга — хешсуммы будут одинаковыми.
Соберем цепочку сертификатов.
Чтобы понять в какой последовательности должны быть добавлены данные необходимо
выполнить команду :
для каждого сертификата, который был прислан в архиве.
Вывод на экран получается следующего вида:
Сопоставив полученные данные делаем вывод о том, что сертификаты должны идти в
следующем порядке, ссразу добавляем их в bundle.
Стоит обратить внимание на символы > и >>.
Одинарный знак будет перезаписывать файл в то время как двойной дописывать.
После проведённых действий производим проверку сертификатов и bundle на соответствие
по хешсумме.
В том случае если цепочка будет собрана не верно, сумма совпадать не будет.
Для проверки полной цепочки установленной на сайте необходимо выполнить команду:
В разделе Certificate chain описывается цепочка.
Также цепочку можно проверить на сайте https://www.sslshopper.com введя необходимое
доменное имя.
У нас Вы можете заказать VPS c ОС Debian и Ubuntu. Если во время использования инструкции у Вас возникнут вопросы, наша техническая поддержка готова прийти на помощь в любое время.
Шпоры по сертификатам X.509
Чудище обло, озорно, огромно, стозевно и лаяй.
Кстати что общего между LDAP, SNMP и X.509 ну кроме того, что им еще не скоро предстоит собрать стадионы фанатов? Их объединяет ASN.1 — мета-язык описания объектов древности. Если бы эти технологии создавали сейчас, в ход бы пошли XML, DTD или какой-нибудь другой ML. Но в то время стандарты создавались титанами, для которых даже SNMP был простым делом.
Словарный запас
Определение X.509 сертификатов есть в архиве ITU-T
Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1 SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.
Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.
Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.
Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией. Полгода назад Гугл пригрозил компании Симантек, что перестанет доверять их сертификатам из-за того, что те выпустили аж 30,000 неисправных сертификатов.
Номенклатура сертификатов
Давайте рассмотрим, какие сертификаты X.509 встречаются в природе, если рассматривать их по расположению в пищевой цепочке доверия.
По степени крутизны дороговизны и надежности сертификаты делятся на 3 вида: DV, OV и EV.
Редко, кто на это готов раскошелиться. Навскидку Яндекс, StackOverflow.com и Хабр могут жить и без него. Но те, кто готов пойти ради этого на жертвы должны выполнить следующие требования:
По свои свойствам сертификаты бывают следующих типов.
В России понятие КС квалифицированного сертификата определено законодательно в связи с доступом к ГосУслугам. По ссыске Хабрапост с былиной об извлечении персональных данных из КС.
Откуда берутся сертификаты?
Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.
Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:
Следует серия вопросов, чтобы было чем запомнить поля owner и issuer
Конвертируем связку ключей из проприетарного формата в PKCS12.
Смотрим на результат:
LetsEncrypt
Сценарий №1 — найти следующего в связке
Так и есть, SKI сертификат DigiCert имеет то же значение.
Сценарий №2 — используй subjectAltnName, Люк
Откройте файл openssl.cnf и в секции req добавьте следующие линии.
Далее, в секции [ v3_ca ] укажите.
А дальше все как обычно, создаем закрытый ключ и подписываем сертификат.
Ускорение и защита сайта | Айри
Сшиваем SSL-сертификаты правильно на bash
Использование SSL-шифрование на сайтах приобретает уже почти обязательный характер: Google с этого года начал агрессивно предупреждать о небезопасном соединении с сайтами, ряд платежных шлюзов требуют безопасное подключение на сайтах (например, Яндекс.Касса). Установка SSL-сертификата на сайт требует достаточно сложной технической настройки веб-сервера (nginx, например). Одним из аспектов этой настройки является использование «сшивания» (stapling) SSL-сертификатов вплоть до корневого для ускорения установления безопасного соединения из браузеров к сайтам.
SSL stapling позволяет сэкономить для нового посетителя сайта 0,1-1 секунду (за счет экономии 1-2 запросов за промежуточными сертификатами с учетом DNS-запросов, установления соединения и получения данных, каждый из запросов может выполняться до 500 мс в случае 95 перцентиля пользователей). По умолчанию, SSL stapling выполняется для всех сертификатов, загруженных в Айри.
Обычно цепочка SSL-сертификатов, которую должен запросить браузер, выглядит следующим образом:
SSL-сертификат сайта — Промежуточный SSL-сертификат [- Промежуточный SSL-сертификат 2] — Корневой SSL-сертификат
Корневые SSL-сертификаты загружены в браузер (в целях избежания их подделки при передачи по сети). Промежуточные SSL-сертификаты могут быть получены из SSL-сертификата сайта («родительский» сертификат, которым подписан данный сертификат, внесен в соответствующем поле данного сертификата). Как это корректно сделать, чтобы сшить все сертификаты и ускорить загрузку сайта в браузере?
Openssl
Основным рабочим инструментом будет библиотека openssl: она позволяет реализовать преобразование сертификатов и извлечение необходимой информации в текстовом формате (в сертификате информация закодирована либо в бинарном формате (DER), либо в base64 (PEM)).
Если на сервере вы подключаете SSL-шифрование для сайта, то сама библиотека, скорее всего, у вас уже установлена. Проверить, например, для какого домена (Canonical name) выпущен сертификат (если он в PEM формате, обычно в таком формате сертификаты выпускаются и передаются для установки на сервер) можно так:
Здесь x509 — входящий формат сертификата, in — ключ для входного файла, subject — указание вывести CN сертификата, а noout — запрет на вывод самого сертификата (в PEM формате).
Получаем «родительский» сертификат
Алгоритм «сшивки» сертификатов достаточно простой: нам нужно из сертификата извлечь путь к «родительскому» сертификату (тому сертификату, которым подписанный данный) и получить этот «родительский» сертификат по извлеченному пути. Простого набора ключей для openssl найти не удалось, поэтому сделаем это с помощью вывода всей информации о сертификате в тестовом формате с помощью ключа text :
После этого нам нужно лишь выделить поле Issuers и получить из него URL. Это можно сделать, например, так:
Получив URL сертификата, скачиваем его любым удобным образом. Например, через curl:
Запускаем рекурсию
Описанную выше процедуру можно выполнять в цикле, пока из сертификата извлекается путь к «родительскому». Но есть один нюанс. Подписывающие сертификаты удостоверяющих центров обычно хранятся в бинарном формате, поэтому нам нужно будет проверить формат сертификата и преобразовать его к текстовому (чтобы корректно включить в финальную цепочку сертификатов, которая будет записана в PEM формате).
Для проверки формата сертификата воспользуемся verify от openssl:
В случае возникновения ошибки чтения загруженного сертификата нам нужно будет его преобразовать из бинарного формата в base64:
После преобразования сертификата мы можем спокойной скопировать его в конец нашей цепочки, определить путь к «родительскому» сертификату и продолжить составление цепочки (если требуется).
Правильный порядок сертификатов в цепочке
В финале должен получиться файл с цепочкой сертификатов следующего содержания:
Для составления цепочки сертификатов из данного требуются следующие действия:
1. Скопировать данный сертификат в начало цепочки (cat).
2. Получить URL «родительского» сертификата (openssl + awk / sed).
3. Загрузить «родительский» сертификат (curl / wget).
4. Переформатировать «родительский» сертификат (openssl).
5. Скопировать «родительский» сертификат в цепочку (cat).
6. Повторить шаги 2-5 или завершить.
MNorin.com
Блог про Linux, Bash и другие информационные технологии
TLS и SSL: Необходимый минимум знаний
TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.
Что такое SSL и что такое TLS?
SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.
Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:
SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года
Принцип работы SSL и TLS
Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:
Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.
Установка соединения обеспечивается в несколько этапов:
1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.
2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать
3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.
4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.
5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.
6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.
Корневой сертификат
Чуть выше я упомянул корневой сертификат. Это сертификат авторизационного центра, подпись которым подтверждает, что сертификат, который подписан, является именно тем, который принадлежит соответствующему сервису. В самом сертификате обычно содержится ряд информационных полей, в которых содержится информация об имени сервера, которому выдан сертификат, и сроках действия этого сертификата. Если срок действия сертификата истек, он признается недействительным.
Запрос на подпись (CSR, Certificate Sign Request)
Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.
Клиентский сертификат
Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.
Цепочка действий по генерации сертификатов
Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.
Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.
Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.
Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.
Просмотр информации о сертификате
Содержимое сертификата можно просмотреть таким образом:
Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.
Серверный сертификат
Для подписи сертификата для сервера нам нужно выполнить следующие действия:
1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно
В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата
Таким образом сертификат сервера подписан и мы будем знать, какой организацией выдан этот сертификат. После подписи готовый сертификат можно использовать по назначению, например, установить на веб-сервер.
Установка SSL/TLS-сертификата на сервер с nginx
Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:
2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):
3) Перезапустить nginx
4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.
Установка SSL/TLS-сертификата на сервер с Apache
Установка SSL/TLS-сертификата на Apache выглядит примерно так же.
1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории
2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен
3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:
При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:
Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку
Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf
4) Перезапустить веб-сервер Apache
Создание клиентского сертификата
Клиентский сертификат создается примерно так же, как серверный.
Если необходим клиентский сертификат в формате PKCS12, создаем его:
Теперь можно использовать клиентский сертификат для работы с нашим сервером.
Настройка nginx на использование клиентских сертификатов
Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:
После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.
Настройка Apache на использование клиентских сертификатов
Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:
Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.
«Прослушка» информации о сертификате при помощи openssl
Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.
На стороне сервера запускаем прослушку порта при помощи openssl:
На стороне клиента обращаемся к серверу, например, culr’ом:
В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.
Со стороны сервера ошибка выглядит так:
Со стороны клиента так:
Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):
Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.
Безопасность
При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.
В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.
Что такое корневой сертификат (СА)
Термин «корневой сертификат» хорошо знаком тем, кто занимается продвижением веб-ресурсов. Это объясняется легко – попадают в топ-10 поисковых систем преимущественно «доверенные» сайты, с подключенным SSL-сертификатом (протокол HTTPS). Без него тот же Google Chrome ставит в адресной строке метку с открытым замком, а то и вовсе блокирует вход на страницу.
Что представляет собой корневой сертификат (CA)
Защищенное соединение гарантирует шифрование информации, передаваемой между сервером и клиентом. Кроме того, оно подтверждает подлинность ресурса, обеспечивая тем самым защиту от фишинга с целью кражи персональных данных (от ФИО до номера банковской карты вместе с секретным CVC-кодом). Шифрование «обесценивает» перехват, который возможен как локально, на уровне роутера в квартире, так и на удаленном сервере.
Корневой сертификат (CA) представляет собой часть ключа SSL, которым центр сертификации подписывает выпускаемые сертификаты. Наличие CA гарантирует, что выдавшая его организация верифицирована и легальна.
Именные сертификаты, выдаваемые центрами вроде Comodo или Symantec, ценятся больше.
Ценность сертификата очень важна, потому что распространенные браузеры умеют идентифицировать лицо, выпускающее CA, и проверять его легитимность. Если у сайта нет «поручителя», он будет считаться недостоверным, даже несмотря на полную безопасность для конечного пользователя. Такое иногда происходит с бесплатными сертификатами типа Let’s Encrypt (генерируются автоматически после регистрации домена в панели управления хостингом).
Корневой сертификат зависит от остальных «частей» SSL – промежуточной и индивидуальной. Они выдаются одновременно и вносятся в соответствующие поля при ручной настройке безопасности. Фактически создается цепочка взаимной проверки, когда корневой сертификат подтверждает иные части ключа. Если ответ на запрос верен, браузер помечает веб-ресурс как защищенный (замочек в адресной строке) и открывает его без каких-либо предупреждений.
Где взять корневой сертификат
SSL-сертификат (вместе с CA) выдается удостоверяющими центрами. К наиболее популярным центрам сертификации относятся Let’s Encrypt, Comodo, Symantec, Digicert, GeoTrust. Купить сертификат можно на сайте одного из центров или воспользоваться панелью управления хостинг-провайдера.
Разновидности сертификатов (на примере провайдера Timeweb):
Сертификаты из трех последних пунктов высылаются в виде ZIP-архива или текстового сообщения с указанием всех «частей» SSL, в том числе корневого. То же происходит при продлении услуги (после оплаты) – за 30 дней до завершения периода ранее купленного сертификата обычно становится доступной функция продления.
Можно ли создать корневой сертификат самостоятельно?
Рядовому пользователю выпустить корневой сертификат нереально. Все существующие варианты для этого применяются только на период локального тестирования веб-ресурса, когда нет разницы, как воспринимает браузер такой CA. Чтобы создать легитимный ключ безопасности, понадобится самому стать «центром сертификации». Это хлопотное и затратное дело, поэтому проще обратиться к одной из существующих организаций.
Технология создания простейшего CA в ОС Windows:
Последнее выполняется выбором нужного доменного имени в подразделе «Подключения» раздела «Сертификаты сервера». В столбце «Действия» нужно нажать на «Привязки…», в открывшемся окне «Добавление привязки сайта» ввести сведения о привязке и нажать «ОК». После создания сертификата остается экспортировать приватный ключ и задать пароль на выполнение изменений.