Fullchain-сертификаты и как их добыть

Что такое сертификаты безопасности?

Фантастические твари и где они... Если совсем просто: те, что нам понадобятся - PEM (с расширениями .pem .crt .cer, и .key)- самые обычные текстовые файлы с зашифрованными данными внутри, которые позволяют сторонам убедиться, что их "собеседники" на другом конце именно те, за кого себя выдают. Их можно открыть Блокнотом и увидеть что-то вроде:

Таких блоков в файле может быть один или больше, в зависимости от длины цепочки.

Каждый сертификат начинается строкой "BEGIN CERTIFICATE" и заканчивается "END CERTIFICATE" с пятью тире до и после текста. Другие форматы имеют свои заголовки; например, P7B - "BEGIN PKCS7", а блок приватного ключа (о нём ниже) - "BEGIN RSA PRIVATE KEY".

Файл будет работоспособен при любом порядке блоков, но всё же желательно его соблюдать.
Неправильная последовательность снизит рейтинг SSLLabs вашего сайта (если он вам нужен; для навыков Алисы этот фактор не имеет значения).

Более важная деталь: в файле не должно быть пустых строк! Также, в зависимости от операционной системы, на которой работает веб-сервер, могут быть разные требования к символам переноса строки. И, конечно, недопустимы никакие комментарии, пометки, посторонние символы.

Сертификаты можно разделить на степени - или уровни - доверия.

• Корневые сертификаты. Выпущены специальными удостоверяющими центрами, имеют наивысшую доверительность. Могут удостоверять собой любые другие виды сертификатов.
• Промежуточные сертификаты. Любые виды цепочек сертификатов. Тоже имеют право удостоверять (подписывать) другие сертификаты.
• Конечные сертификаты. Самая низкая степень доверия. Ими нельзя подписывать никакие другие сертификаты.

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

Теперь легко понятны ещё два термина:

• fullchain ("полная цепочка") сертификат - тот, который хранит всю цепочку, включая корневой и конечный сертификаты (и все промежуточные, если они участвуют).
  Физически fullchain-сертификат - тот же текстовый файл, который хранит все подписи, участвующие в цепочке.
• самозаверенный (чаще говорят "самоподписанный") - конечный сертификат, который удостоверяет сам себя на манер корневого.
  Кроме того, из-за того, что самоподписанные сертификаты невозможно отозвать, возникают различные риски ("атака посредника" итд).

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

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

Публичный (открытый)	Приватный (закрытый)
Можно и нужно открывать в доступ	Ни в коем случае никому нельзя отдавать
Используется только для проверки подписи и идентичности владельца	Используется для создания цифровых подписей

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

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

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

fullchain-сертификаты в навыках Алисы

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

• обязательная работа через HTTPS,
• обязательное использование fullchain-сертификатов.

Благо, сегодня вряд ли удастся встретить хостинг без поддержки SSL/HTTPS, зато бесплатных сертификатов в достатке (да, те самые Lets' Encrypt, SSL For Free, CAcert итд).

Как получить такой сертификат?

Вариантов и инструкций в Интернете достаточно много. В том числе у нас на вики в статье " Алиса управляет Умным домом через Node-RED".

В следующих разделах - краткие инструкции по самым популярным сервисам:

Lets' Encrypt и certbot

Потребуется установить программу certbot. Под *nix- системами это сделать проще, но под Windows тоже не потребуется сверхъестественных усилий.

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

Предположим, что certbot у вас установлен. Что дальше? Запускаем несколько консольных команд.

Зарегистрироваться:

certbot register -m emailадминистратора@вашдомен.com

Сгенерировать сертификат:

certbot certonly --webroot -w /var/www/папкасервера -d вашдомен.com -d www.вашдомен.com

Если опасаетесь, что что-то не так и хотите сначала потренироваться, добавьте опцию --dry-run (режим эмуляции для отладки ошибок)

certbot certonly --dry-run --webroot -w /var/www/папкасервера -d вашдомен.com -d www.вашдомен.com

После успешной генерации сертификата у вас появятся 4 файла (их расположение также сильно зависит от вашей операционной системы):

1. cert.pem (конечный сертификат),
2. chain.pem (цепочка доверия от корневого сертификата, не включающая конечный),
3. fullchain.pem (нужная нам полная цепочка, включая конечный сертификат, по сути это сложение cert.pem + chain.pem),
4. privkey.pem (ваш приватный ключ, который никому нельзя ни показывать, ни отсылать).

Для веб-сервера необходимы два из них: fullchain.pem и privkey.pem.

Ещё несколько полезных команд certbot

Проверка и обновление сертификатов (полезно поставить запуск этой команды по расписанию):

certbot -q renew

Для проверки и обновления также есть тестовый режим (чтобы убедиться. что ваши домены будут обновляться):

certbot renew --dry-run

Добавление новых доменов и поддоменов к сертификату:

certbot certonly --webroot -w /var/www/папкасервера --expand -d вашдомен.com -d test.вашдомен.com -d www.вашдомен.ru

Изменение адреса администратора:

certbot register --update-registration -m newemail@вашдомен.ru

SSL For Free

Получить сертификат через онлайн-сервис намного быстрее и проще, ничего устанавливать не нужно:

1. Регистрация на сайте https://sslforfree.com/
2. Выбор настроек (обычно ничего трогать не нужно, просто жмите "Next Step")
3. Подтверждение прав на домен, для которого получаете сертификат, любым из способов:
   • на почту его владельца (список готовый, посторонний адрес вписать не получится) - вам должен быть доступен один из перечисленных email.
   • изменением полей DNS (CNAME) - для новичков этот способ самый запутанный, но не требует доступности почты и http.
   • скачиванием подтверждающего файла и размещением его в подпапке сайта - к домену должен быть http-доступ из Интернета в момент проверки.
4. После подтверждения останется выбрать формат: предлагается список шаблонов (Default, Tomcat, AWS, cPanel, Google App, Heroku. nginx, Plesk, итд) - но во всех случаях, кажется, скачивается идентичный архив.

Сертификат готов, но... сервис SSL For Free создаёт три файла:

• ca_bundle.crt (цепочка, исключая конечный сертификат)
• certificate.crt (сам конечный сертификат)
• private.key (ваш приватный ключ, который никому нельзя ни показывать, ни отсылать).

Поэтому fullchain мы склеим вручную из двух первых файлов (сначала certificate.crt, затем ca_bundle.crt), и назовём его fullchain.crt (имена на самом деле могут быть любыми, но принято - и нужно - использовать "говорящие" названия: fullchain.crt/fullchain.pem, или domain.ca-bundle)

Сделать это можно как консольными командами, так и в обычном Блокноте Windows. Пример консольной команды:

cat domain.crt Intermediate1.crt Intermediate2.crt <все промежуточные что есть через пробел> CARoot.crt > fullchain.crt

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

Серверу отдаём, соответственно, fullchain.crt и private.key.

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

Средствами Windows, например, при помощи штатной certutil можно получить корневые сертификаты в формате sst ("certutil.exe -generateSSTFromWU roots.sst"), а распаковкой регулярно обновляемого файла authrootstl.cab - в формате stl и затем сконвертировать при необходимости в нужный тип.

Немного паранойи

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

Как понять, что всё хорошо

Очень просто: вы скопировали файлы сертификатов в нужную папку, указали вашему веб-серверу пути к ним, и всё работает! :)

Как понять, что всё плохо

При попытке верифицироваться с неполноценным сертификатом вы получите сообщение "Endpoint URL: Некорректный SSL-сертификат".

Возвращайтесь к началу инструкции, по которой вы его выпускали и проверьте, всё ли вы сделали правильно. Сравните с любой другой инструкцией из Интернета. Возможно, где-то вкралась ошибка, или другое объяснение окажется для вас более полным и понятным.

Как проверить сертификат на валидность

Онлайн

Вот несколько популярных сервисов для онлайн-проверки валидности сертификатов:

• SSL Shopper.
• Wormly.
• ImmuniWeb.

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

Ещё раз: ни в коем случае никогда и никому не отправляйте файлы, которые содержат ваши приватные ключи!
К онлайн-сервисам проверки сертификатов это тоже относится.

Офлайн (без доступа к Интернету)

Да, в изолированных сетях и сетях без доступа к Интернету тоже бывают нужны SSL-сертификаты. И значит, должен быть способ их проверки без выхода в Интернет.

Такой способ есть, использует криптографический пакет OpenSSL (что-то вроде "openssl x509 -in myserver.crt -text -noout", "openssl x509 -noout -modulus -in server.crt | openssl md5", "openssl verify -CAfile RootCert.pem -untrusted Intermediate.pem UserCert.pem", итд - в тематику инструкции эта тема уже не входит).

Небольшой пример проверки того, что сертификаты правильно собраны в один файл (в примере назван "domain.ca-bundle"):

openssl x509 -noout -modulus -in domain.crt | openssl md5
openssl x509 -noout -modulus -in domain.ca-bundle | openssl md5
openssl x509 -noout -modulus -in <ещё какой-то из файлов, полученных от вашего провайдера> | openssl md5

Команды возвращают хэш-суммы сертификатов. Для bundle, cert, private_key и всех промежуточных сертификатов они должны совпадать.

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