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

Let’s Encrypt обновил пользовательское соглашение и добавил туда пункт про санкции США. Новость выглядит юридической, но на практике касается вполне технических вещей: HTTPS, Certbot, acme.sh, Nginx, WordPress-сайтов и спокойного сна администратора.

Если коротко: в новой версии Subscriber Agreement 1.7 от 4 июня 2026 года Let’s Encrypt прописал, что сертификаты не должны запрашивать и использовать физические лица и организации, которые находятся, зарегистрированы или обычно проживают в странах и территориях под полномасштабными санкциями США.

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

Что произошло

Let’s Encrypt внёс изменения в своё пользовательское соглашение для получателей сертификатов. В соглашение добавили пункт, связанный с санкционными и экспортными ограничениями США.

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

Важный момент: формулировка завязана не на доменную зону сама по себе. Не написано, что запрещены все домены в зоне .ru, все кириллические домены или все серверы с определёнными IP. Речь именно о получателе сертификата и его статусе.

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

Почему это важно для сайтов

Let’s Encrypt за последние годы стал почти стандартом для бесплатных TLS-сертификатов. На VPS, WordOps, обычном Nginx, Apache, панелях хостинга и куче WordPress-сайтов схема часто одна и та же: поставили Certbot или acme.sh, настроили автообновление и забыли.

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

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

Для WordPress-сайтов это особенно неприятно тем, что сам WordPress тут почти ни при чём. Сертификат живёт на уровне веб-сервера, панели, CDN или балансировщика. Но если HTTPS ломается, пользователь видит не «ошибка Certbot», а «сайт небезопасен». Для бизнеса разница между этими формулировками не важна. Он просто теряет доверие, заявки и иногда рекламный бюджет.

Это запрет для всех российских сайтов?

Нет, из текста соглашения не следует автоматический запрет на все российские сайты или все домены в зоне .ru. Доменная зона, место размещения сервера и статус получателя сертификата это разные вещи.

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

Поэтому главный вопрос не «какой домен», а «кто именно запрашивает сертификат». Где зарегистрирована организация, где находится человек, не действует ли он от имени запрещённой стороны, не попадает ли под конкретные ограничения.

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

Что может сломаться на практике

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

Типовая цепочка такая:

• сертификат заканчивается через несколько дней;
• certbot renew или acme.sh --renew запускается автоматически;
• ACME-клиент не может выпустить или продлить сертификат;
• уведомление никто не читает или оно вообще не настроено;
• сертификат истекает;
• браузер показывает предупреждение;
• клиент пишет: «У нас сайт не открывается».

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

Поэтому TLS нужно контролировать так же, как бэкапы, обновления WordPress, место на диске и логи Nginx. Не героически, а регулярно.

Как проверить текущий сертификат через OpenSSL

Начать можно с простой проверки срока действия сертификата. В примерах ниже замените example.com на свой домен.

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

В выводе будут две строки:

notBefore=... notAfter=...

Нас интересует notAfter. Это дата окончания сертификата.

Можно сразу посмотреть издателя, subject и срок действия:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Для Let’s Encrypt в издателе обычно будет видно Let’s Encrypt или один из промежуточных сертификатов их цепочки. Конкретные названия промежуточных сертификатов могут меняться. Здесь важнее не запоминать красивую аббревиатуру, а понимать, кто реально выпустил сертификат и когда он истекает.

Как проверить Certbot

Если сертификаты на сервере выпускались через Certbot, сначала смотрим список сертификатов:

sudo certbot certificates

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

sudo certbot renew --dry-run

Если Certbot установлен через systemd timer, проверяем таймер:

systemctl list-timers | grep certbot systemctl status certbot.timer

Логи можно смотреть через journalctl:

sudo journalctl -u certbot --since "7 days ago"

А ещё полезно посмотреть основной лог Let’s Encrypt:

sudo tail -n 100 /var/log/letsencrypt/letsencrypt.log

Если dry-run проходит без ошибок, это хороший знак. Если нет, лучше разбираться сейчас, а не в день окончания сертификата. Сертификаты любят заканчиваться в самый неудобный момент. Видимо, это у них встроенная функция.

Как проверить acme.sh

Если используется acme.sh, список сертификатов можно посмотреть так:

~/.acme.sh/acme.sh --list

Информация по конкретному домену:

~/.acme.sh/acme.sh --info -d example.com

Принудительная попытка обновления:

~/.acme.sh/acme.sh --renew -d example.com --force

С acme.sh нужно отдельно смотреть, какой ACME CA выбран сейчас. У этого клиента есть возможность работать с разными удостоверяющими центрами. Это удобно, если нужен резервный вариант. Но переключать боевой сайт на другой CA без понимания процесса не стоит.

Перед любыми экспериментами с сертификатами на боевом сервере полезно понять, где лежат текущие файлы, как они подключены в Nginx и чем вы будете откатываться назад. Сертификат можно заменить за минуту. А можно потом час искать, почему Nginx не стартует. Второй вариант тоже обучающий, но нервный.

Как проверить конфигурацию Nginx

На сервере с Nginx сертификаты обычно прописаны в конфигурации сайта через директивы ssl_certificate и ssl_certificate_key.

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Найти, где именно они подключены, можно через grep:

sudo grep -R "ssl_certificate" -n /etc/nginx/

После любых изменений в сертификатах или конфиге Nginx обязательно проверяем синтаксис:

sudo nginx -t

Если всё нормально, перезагружаем Nginx:

sudo systemctl reload nginx

И снова проверяем сертификат снаружи через OpenSSL или браузер. Не надо верить только тому, что команда отработала без ошибки. В инфраструктуре доверяй, но проверяй. Особенно если дело касается HTTPS.

Что делать владельцу WordPress-сайта

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

Минимальный план такой:

• посмотреть, какие сайты используют Let’s Encrypt;
• проверить даты окончания сертификатов;
• запустить тестовое продление через Certbot или acme.sh;
• проверить, приходят ли уведомления об ошибках;
• понять, как быстро заменить сертификат вручную;
• подумать о резервном удостоверяющем центре;
• настроить мониторинг срока действия сертификата.

Для одного сайта это займёт немного времени. Для сервера с десятками доменов лучше сделать отдельный список и пройтись спокойно. Особенно если на сервере клиентские сайты, формы заявок, рекламный трафик и всё то, что начинает стоить денег, когда HTTPS внезапно ломается.

Что с российскими сертификатами

В России есть собственная инфраструктура TLS-сертификатов, включая сертификаты Минцифры. Но для публичных сайтов тут есть важная проблема: доверие браузеров и операционных систем.

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

Поэтому для публичного сайта важен не только сам факт наличия сертификата, а его доверие в Chrome, Firefox, Safari, Android, iOS, Яндекс Браузере и других клиентах. Сертификат, которому не доверяет браузер, для обычного пользователя выглядит почти так же, как его отсутствие.

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

Какие есть альтернативы Let’s Encrypt

Let’s Encrypt остаётся удобным и массовым вариантом для бесплатных TLS-сертификатов. Но резервный план теперь выглядит не паранойей, а нормальной админской привычкой.

Варианты зависят от проекта:

• другой ACME-совместимый удостоверяющий центр;
• сертификат от хостинг-провайдера;
• платный коммерческий сертификат;
• сертификат через CDN или балансировщик;
• корпоративный вариант для внутренней инфраструктуры.

Универсальной кнопки «заменить Let’s Encrypt и забыть» нет. У каждого варианта будут свои условия, ограничения, стоимость, сроки и требования к доверию браузеров.

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

Простой скрипт для проверки срока сертификата

Для ручной проверки одного домена можно использовать короткий bash-скрипт:

#!/usr/bin/env bash DOMAIN="example.com" echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" 2>/dev/null \ | openssl x509 -noout -issuer -subject -enddate

Сохраняем файл, например, как check-cert.sh:

nano check-cert.sh

Даём права на запуск:

chmod +x check-cert.sh

Запускаем:

./check-cert.sh

Для нескольких доменов можно сделать список. Например, файл domains.txt:

example.com www.example.com blog.example.com

И простой цикл:

#!/usr/bin/env bash while read -r DOMAIN; do [ -z "$DOMAIN" ] && continue echo "=== $DOMAIN ===" echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" 2>/dev/null \ | openssl x509 -noout -issuer -subject -enddate echo done < domains.txt

Это не полноценный мониторинг, но для ревизии уже полезно. Если доменов много, лучше использовать нормальную систему мониторинга: Uptime Kuma, Zabbix, Prometheus, Grafana, внешние сервисы или хотя бы cron с уведомлением.

Что я бы сделал на своих серверах

На своих серверах я бы не стал срочно выдирать Let’s Encrypt отовсюду, если всё работает и продлевается. Но я бы сделал ревизию.

План простой:

• собрать список всех доменов на сервере;
• проверить даты окончания сертификатов;
• проверить certbot renew --dry-run или аналог в acme.sh;
• посмотреть логи последних продлений;
• проверить доступы к DNS и панели регистратора;
• документировать, где лежат сертификаты и конфиги;
• подготовить резервный вариант для критичных сайтов.

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

Что это значит для бизнеса

Для бизнеса эта новость не про политику и не про тонкости ACME-протокола. Она про устойчивость сайта. Если сайт принимает заявки, продаёт услуги, ведёт клиентов в личный кабинет или крутит рекламу, HTTPS должен работать предсказуемо.

Наличие резервного плана по сертификатам это такая же часть обслуживания, как бэкапы и обновления. Никому не интересно, что «сертификат не продлился из-за юридического изменения». Пользователь видит предупреждение браузера. Клиент видит падение заявок. Рекламный кабинет продолжает списывать деньги. Вот и вся романтика.

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

Вывод

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

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

Let’s Encrypt остаётся важным и удобным инструментом. Но слепо полагаться на один источник сертификатов для всех проектов становится всё менее разумно. Интернет взрослеет, усложняется и иногда неприятно напоминает, что «бесплатно и автоматически» не значит «навсегда и без условий».

А сайт с рабочим HTTPS это не роскошь. Это базовая гигиена. Как обновления WordPress, бэкапы и привычка сначала делать nginx -t, а уже потом перезагружать сервер.

Источники