Чем letsencrypt хуже платных сертификатов? — Хабр Q&A

Почему лучше рассчитывать на sni?

1. Это просто. Вам не нужно постоянно держать в голове факты о выданных сертификатах. Для какого домена сертификат был выдан первым. К какому сертификату нужно добавлять еще домены. И так далее… Ни о чем таком со SNI не нужно думать.

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

Например, так можно посмотреть домены в сертификате Тематических Медиа:

Что произойдет 30 сентября?

Срок действия DST Root CA X3 подходит к концу 30 сентября 2021 14:01:15 GMT, что произойдет после этого?

Те системы, которые недоверяют ISRG Root X1, перестанут доверять сертификатам, выпущенным Let’s encrypt (системы будут выдавать предупреждения при посещении сайтов, использующих сертификаты Let’s Encrypt). За исключением Android >= v2.3.6, т.к. Android не учитывает срок действия своих доверенных корневых сертификатов.

Проблема с доверием возникнет также у систем, использующих OpenSSL версии меньше 1.1.0. Даже если у таких систем ISRG Root X1 входит в список доверенных сертификатов, особенность проверки сертификата в OpenSSL 1.0.x приведёт к тому, что наличие в цепочке истекшего DST Root CA X3, несмотря на наличие доверия к ISRG Root X1, будет приводить к отрицательному результату проверки на доверие. Аналогичная проблема у OpenSSL 1.0.x возникла 20 мая 2020 года с истекшим сертификатом AddTrust External CA Root.

Let’s encrypt начал выдавать wildcard сертификаты

Caveat emptor

Всё знаете про SNI? Читайте сразу про установку.

Linux

Для того, чтобы проверить, как поведёт себя ваша система при обращении к сайтам, использующим сертификаты Let’s Encrypt, после 30 сентября, можно воспользоваться утилитой faketime. В Debian и Ubuntu она доступна в пакете faketime.

Tilda

К сожалению, моя трехдневная переписка со службой поддержки Tilda и попытка протолкнуть вопрос на следующий уровень не увенчались успехом, и на просьбу проверить наличие подозрительного ПО за IP-адресом 185.215.4.10 был получен четкий ответ: “Вредоносного ПО нет”.

Вот и всё

Если вам близки по духу tee и sed, то есть гораздо более короткая инструкция по настройке связки Let’s Encrypt и nginx, при условии корректно настроенного hostname. Только копируй команды и вставляй.

Генерация ключа по алгоритму диффи-хеллмана

Для повышения безопасности вам необходимо сгенерировать ключ по алгоритму Диффи-Хеллмана. Для генерации ключа длиной 2048 бит используйте такую команду:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Процесс может занять несколько минут.

Если нужно добавить поддомен или домен в сертификат

Если вы вдруг забыли указать поддомен www, или вам нужно добавить другой домен или поддомен в сертификат (которых может быть до 100 в одном сертификате), то это легко сделать после получения сертификата. Просто запустите команду еще раз, добавив требуемое имя:

Если нужно получить сертификат для домена без сайта…

Типичный пример — сертификат для выделенных под SMTP или IMAP серверов, на которых вообще нет каких-то сайтов. Либо используйте универсальный переадресатор что выше, либо…

Использование плагина webroot

Алгоритм работы Webroot включает в себя создание специального файла в директории /.well-known. Она размещается в корневом каталоге веб-сервера (document root) и может быть открыта сервисом Let’s Encrypt для проверки. В зависимости от ваших настроек, вам может понадобиться явно разрешить доступ к папке /.well-known.

Если вы ещё не установили Nginx, сделайте это, следуя руководству по установке Nginx на Ubuntu 16.04.

Чтобы убедиться в том, что папка доступна сервису Let’s Encrypt, внесем небольшие изменения в конфигурацию Nginx. По умолчанию файл конфигурации находится в папке /etc/nginx/sites-available/default. Мы будем использовать редактор Nano для внесения изменений:

sudo nano /etc/nginx/sites-available/default

Внутри блока server добавьте такой блок location:

# Добавить в SSL-блок server

location ~ /.well-known {
    allow all;
}

Вам также стоит посмотреть, где расположен корневой каталог веб-сервера (document root), так как этот путь необходим при работе с Webroot. Если вы используете стандартный файл конфигурации, она будет расположена в /var/www/html.

Сохраните и закройте файл.

Проверьте вашу конфигурацию на синтаксические ошибки:

sudo nginx -t

Если ошибок нет, перезапустите Nginx, используя эту команду:

sudo systemctl restart nginx

На стороне сервера

На стороне сервера от вас мало что зависит. Если вы используете сертификаты от Let’s Encrypt на своем сервере, то должны понимать, что после 30 сентября 2021 14:01:15 GMT к вашему серверу смогут без проблем подключиться только клиенты, доверяющие ISRG Root X1 (см. список выше), а также использующие Android >= v2.3.6. При этом, если клиенты используют OpenSSL, то они должны пользоваться версией OpenSSL >= 1.1.0.

При этом, у вас есть выбор – ценой отказа от поддержки старых Android (оставив поддержку Android >= 7.1.1), вы можете сохранить поддержку OpenSSL 1.0.x без манипуляций на стороне клиента.

Для этого нужно использовать предлагаемую Let’s Encrypt альтернативную цепочку доверия для своих сертификатов. В этой цепочке исключен DST Root CA X3 и выглядит она так: 

ISRG Root X1 -> Let’s Encrypt R3 -> Конечный сертификат пользователя

Настраиваем конфигурацию nginx для ssl

Теперь, когда мы подготовили сниппеты, можно обновить нашу конфигурацию Nginx и подключить SSL.

В данном руководстве мы полагаем, что вы используете стандартный файл с блоками server, расположенный в папке /etc/nginx/sites-available. Если вы используете другой файл с блоками server, замените название в представленных ниже командах.

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

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

Теперь откройте файл с блоками server для внесения изменений:

sudo nano /etc/nginx/sites-available/default

Внутри ваш блок server, вероятно, начинается так:

server {
 listen 80 default_server;
 listen [::]:80 default_server;

# Конфигурация SSL

# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;

. . .

Настройка

Открываем конфигурационный файл

ssl.conf

# vim /etc/nginx/bx/conf/ssl.conf

Если у вас уже были установлены сертификаты, удаляем или комментируем строки с ними и вставляем новые:

Немного теории и истории

Не углубляясь в детали, пару слов для неспециалистов, почему окончание срока действия сертификата DST Root CA X3 повлияет на сертификаты, выпущенные Let’s Encrypt. У каждой системы, проверяющей сертификат на валидность, есть своё хранилище доверенных корневых сертификатов.

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

После появления проекта Let’s Encrypt, его корневой сертификат ISRG Root X1 (как и любой новый корневой сертификат) не мог быстро попасть в хранилища доверенных сертификатов заметного количества систем. При этом для успешного функционирования проекта выданным сертификатам с самого начала должно было доверять максимальное количество систем “из коробки” (без дополнительных действий со стороны пользователей этих систем).

К настоящему моменту корневой сертификат ISRG Root X1 существует уже более 5 лет и за это время попал в доверенные в большинстве современных систем, ему доверяют:

Для сертификатов Let’s Encrypt по умолчанию в данный момент предлагается такая цепочка доверия: 

IdenTrust’s DST Root CA X3 -> ISRG Root X1 -> Let’s Encrypt R3 -> Конечный сертификат пользователя

Обновление

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

90 дней

, так что после этого срока нужно будет его обновить. Делается это командой:

Подготовим nginx к получению сертификатов

В общем случае для получения сертификата необходимо во всех блоках server добавить следующий блок до других блоков location:

location /.well-known {
    root /var/www/html;
}

Понятно, что вписывать для каждого сайта такой блок явно — это моветон, потому создадим файл /etc/nginx/acme с содержанием блока выше.

# cat /etc/nginx/acme 
location /.well-known {
    root /var/www/html;
}

Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке server перед всеми блоками location укажем:

include acme;

Хосты-редиректоры (например, с голого домена на www) можно пропустить. ACME сервер обязан учитывать стандартную переадресацию. Подробней об этом ниже.

Перезагрузим nginx и проверим что наш тестовый файл виден:

Предыстория

Одним недавним летним вечером коротал я время за выпуском сертификатов Let’s Encrypt (LE) в кубере, и долго не мог понять с какого перепугу сработало ограничение на количество сертификатов в неделю, т.е. 50 штук.

Проверим полученный сертификат

Убедимся что полученный сертификат — именно тот, что нам нужен:

Продление сертификатов

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

Но нет, не спешите искать платежные средства! Как и было обещано в начале статьи, с обновлением сертификатов проблем нет.

Регистрация в let’s encrypt

Регистрацию нужно сделать только один раз:

Создаем сниппет конфигурации для ssl-ключа и сертификата

Сперва создадим сниппет конфигурации Nginx в папке /etc/nginx/snippets.

Для правильного распознавания назначения файла назовем его ssl-, затем укажем доменное имя и в конце поставим .conf:

Создаем сниппет конфигурации с устойчивыми настройками шифрования

Следующим шагом мы создадим другой сниппет, определяющий некоторые настройки SSL. Это позволит Nginx подключить устойчивый «набор шифров» SSL (англ. cipher suite) и некоторые дополнительные функции, которые помогут обеспечить безопасность нашего сервера.

Прим. перев. Cipher Suite — это совокупность алгоритмов, используемых в конкретной TLS/SSL-сессии:

• алгоритм выработки сессионных ключей шифрования;
• алгоритм, используемый для аутентификации сервера;
• непосредственно сам симметричный алгоритм шифрования трафика;
• и алгоритм контроля целостности (MAC, message authentication code).

Установленные нами параметры могут быть использованы повторно для конфигураций Nginx в будущем, поэтому дадим файлу стандартное название:

sudo nano /etc/nginx/snippets/ssl-params.conf

Для настройки безопасной связки Nginx-SSL мы будем использовать рекомендации сайта Cipherli.st. Он создан для предоставления быстрого доступа к готовым настройкам шифрования популярного программного обеспечения. Дополнительная информация доступна в руководстве по настройке SSL для Nginx.

Примечание. Предлагаемые стандартные настройки на сайте Cipherli.st обеспечивают устойчивую безопасность, но иногда это приводит к ухудшению совместимости. Если вам необходимо поддерживать более старые версии клиентов, используйте альтернативный список настроек, доступный при нажатии на значок «Yes, give me a ciphersuite that works with legacy/old software.» Составить такой список можно и вручную.

Для наших целей можно скопировать предлагаемые настройки целиком. Нам потребуется внести лишь некоторые изменения.

Сперва добавим DNS-резолвер. Используем для нашего руководства тот, что предлагает Google. Затем установим в качестве параметра ssl_dhparam указатель на файл ключа Диффи-Хеллмана, который мы сгенерировали ранее.

Установка

Первое, что необходимо сделать — установить

git

# yum install git

Далее переходим в директорию

/tmp

# cd /tmp

С помощью git скачиваем файлы Let’s Encrypt. Сам скрипт теперь называется

Установка в jessie

Если у вас еще в ходу актуальный на конец 2021 года Debian stable “jessie”, то всё лишь немного сложнее.

Файлы сертификата

После получения сертификата у вас должны появиться следующие файлы в PEM-кодировке:

Чем letsencrypt хуже платных сертификатов?

Шаг 2: создание сертификата

Откройте командную строку (cmd) от имени администратора и поочерёдно введите следующие команды:

1. Выполните C:wacswacs.exe.
2. Далее выберите:
3. Укажите ваше доменное имя и два раза нажмите Enter для подтверждения.
4. Затем последовательно выберите:
5. Укажите папку для сохранения сертификатов C:wacscrt.
6. После этого выберите:
7. Укажите адрес электронной почты для уведомлений об ошибках.
8. На дополнительные вопросы отвечайте следующим образом:

Шаг 3. настраиваем tls/ssl на веб-сервере

Теперь, когда у вас есть SSL-сертификат, необходимо настроить веб-сервер Nginx так, чтобы он начал его использовать.

Внесем некоторые изменения в нашу конфигурацию:

1. Создадим сниппет конфигурации, содержащий расположение нашего SSL-ключа и файлов сертификата.
2. Создадим сниппет конфигурации, содержащий настройки устойчивого SSL, которые можно будет использовать в будущем для любого сертификата.
3. Обновим блоки server в конфигурации Nginx, которые будут управлять SSL-запросами и использовать оба вышеуказанных сниппета.

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

Шаг 4. настраиваем файрвол

Если у вас включен файрвол ufw, вам необходимо обновить настройки и разрешить SSL-трафик. К счастью, Nginx регистрирует несколько профилей с ufw после установки.

Вы можете посмотреть текущие настройки, введя:

sudo ufw status

Шаг 5. подключаем изменения в nginx

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

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

sudo nginx -t

В случае успеха ваш результат должен выглядеть следующим образом:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

sudo systemctl restart nginx

Шаг 6. настраиваем автоматическое обновление

Сертификаты от Let’s Encrypt действуют только в течение 90 дней. Это побуждает пользователей к автоматизации процесса обновления. Нам понадобится создать регулярно запускающуюся команду для проверки и автоматического обновления сертификатов, срок которых истекает.

Для запуска проверки ежедневных обновлений мы будем использовать Cron — стандартный системный сервис для запуска повторяющихся задач. Задачи Cron указываются в файле под названием crontab:

sudo crontab -e

Вставьте следующую строчку в конец файла, затем сохраните и закройте его:

Шаг 0. подготовка

Перед тем, как приступить к работе, вам нужно убедиться в нескольких вещах.

У вас должен быть установлен сервер на Ubuntu 16.04, и создан пользователь (не root), для которого настроены sudo привилегии. Узнать, как это сделать, вы можете, следуя руководству по первичной настройке сервера на Ubuntu 16.04.

Вы должны быть владельцем доменного имени, для которого планируется использовать сертификат, или иметь доступ к его настройке. Если у вас нет зарегистрированного доменного имени, вы можете сделать это, используя один из регистраторов (например, Namecheap или GoDaddy).

Итоги

30 сентября после окончания срока действия сертификата DST Root CA X3 часть пользователей старых устройств столкнутся с тем, что не смогут корректно открывать сайты, использующие сертификаты Let’s Encrypt. Я бы выделил в первую очередь пользователей старых устройств Apple, для которых нет возможности обновиться хотя бы на iOS 10.

В то же время, для администраторов серверов с не очень современным софтом, которые могут взаимодействовать с сервисами, использующими сертификаты Let’s Encrypt, еще есть несколько дней на то, чтобы всё проверить и подготовиться к часу X.

Update: Добавил важное дополнение про необходимость проверки всех используемых контейнеров

Update2: Добавил, как добавить ISRG Root X1 в доверенные сертификаты в Debian/Ubuntu, спасибо @Kenshouten

Update3: Еще один метод решения проблемы для старых OpenSSL, процедура по добавлению сертификата ISRG Root X1 в доверенные в Windows для тех, кто еще не разобрался

Вывод

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

1. Удалите ее

2. Смените A-записи на предыдущие IP-адреса Tilda

P.S. Кстати, именно после возврата на предыдущий IP хостинга Tilda, выпуск подобных сертификатов пока прекратился.