Как настроить Let’s Encrypt: автообновление и проверка в 2026

Я обычно настраиваю Let’s Encrypt так, чтобы сертификат жил без ручного вмешательства: выпустили, проверили, включили автообновление и забыли про него на 90 дней. Но в 2026 году этого уже мало — на практике важны ещё проверка цепочки, корректный reload веб-сервера, логирование, мониторинг и сценарий на случай, если renewal сломается после обновления PHP 8.2/8.3, nginx или панели хостинга.

Ниже я покажу, как я это делаю на реальных проектах с Debian 12, Ubuntu 24.04, nginx, Apache, Bitrix, WordPress и Laravel. И сразу скажу честно: если у вас сайт на проде, лучше один раз настроить всё нормально, чем потом ловить падение HTTPS в выходной. А если у вас уже есть проблемы с доступом, редиректами или mixed content, то сначала загляните на доработка сайта — иногда там нужно не “чуть-чуть подправить SSL”, а нормально привести в порядок конфиг, редиректы и фронт.

Зачем вообще возиться с Let’s Encrypt в 2026

Let’s Encrypt давно стал стандартом де-факто. Бесплатный, автоматический, нормальный доверенный сертификат, который отлично подходит для большинства сайтов. На деле проблема не в выпуске сертификата, а в сопровождении. Я видел десятки случаев, когда сертификат был получен успешно, а через 2–3 месяца сайт падал с ошибкой из-за того, что cron не сработал, веб-сервер не перезагрузился или кто-то “почистил” systemd timer.

В 2026 году я бы не советовал делать SSL вручную даже на маленьком проекте. Да, можно поставить сертификат руками, прописать пути в nginx и радоваться. Но это плохая идея, если вы не готовы помнить о продлении каждые 60–90 дней. Автообновление — это не удобство, а базовая гигиена. Особенно если сайт коммерческий и у вас идут заявки, оплаты, личные кабинеты, авторизация через Bitrix24, CRM, WordPress-формы или Laravel API.

Если вам нужно не просто включить HTTPS, а сделать это без сюрпризов для SEO и пользователей, я обычно смотрю ещё и на редиректы. Тут полезно держать под рукой материал Как настроить переадресацию с HTTP на HTTPS и WWW в 2026, потому что сам сертификат — это только половина задачи.

Как установить Certbot и подготовить сервер

В 2026 я чаще всего использую certbot. Иногда ставлю через snap, иногда через apt — зависит от дистрибутива и от того, насколько сервер “чистый”. На Ubuntu 24.04 snap обычно самый беспроблемный вариант. На Debian 12 я часто иду через пакеты репозитория или ставлю из backports, если нужна более свежая версия.

На моей практике сначала нужно проверить базовые вещи: домен должен указывать на сервер, порт 80 должен быть открыт, порт 443 тоже, а nginx или Apache — уже обслуживать сайт. И да, если у вас Cloudflare, прокси, нестандартный firewall или включён Fail2Ban с агрессивными правилами, сертификат может не выпуститься. Поэтому я всегда начинаю с простого: DNS, доступность, конфиг веб-сервера, логи.

# Debian / Ubuntu
sudo apt update
sudo apt install certbot python3-certbot-nginx -y

# если Apache
sudo apt install certbot python3-certbot-apache -y

Для nginx выпуск сертификата обычно выглядит так:

sudo certbot --nginx -d example.com -d www.example.com

Для Apache — аналогично, только с apache-плагином. Но я честно говоря чаще предпочитаю не полагаться полностью на магию плагина, а потом руками проверять конфиг. Автоматические правки от certbot не всегда идеально ложатся в сложные проекты, особенно если это Bitrix с несколькими server_name, редиректами и reverse proxy.

Ещё один момент. Если у вас сайт на WordPress, Bitrix или Laravel, не забывайте, что SSL влияет не только на браузерный замок. После включения HTTPS могут всплыть абсолютные ссылки, mixed content, старые пути к картинкам, скриптам и шрифтам. Об этом я отдельно подробно разбираю в статье Настройка SSL без ошибок Mixed Content в 2026 году.

Автообновление сертификата: systemd timer или cron

Теперь к главному. Автообновление Let’s Encrypt в 2026 я бы на 90% случаев делал через systemd timer, если система позволяет. Это аккуратнее, прозрачнее и удобнее для логов. Но cron тоже жив и здравствует, особенно на хостингах и VPS, где systemd ограничен или вы не хотите лишний раз зависеть от дистрибутивной магии.

У меня был клиент на Ubuntu 22.04, который поставил certbot через snap, но поломал timer после ручной правки unit-файла. Формально всё было установлено, а renewal просто не запускался. Сертификат умер в воскресенье вечером, а люди увидели ошибку в браузере только утром в понедельник. Это классика. Поэтому я всегда делаю не просто настройку автообновления, а ещё и тестовый прогон.

# проверить, как отрабатывает продление
sudo certbot renew --dry-run

Если тест проходит — отлично. Но я обычно иду дальше: проверяю, что после renewal веб-сервер корректно перечитывает конфиг. Потому что сертификат может обновиться, а nginx останется на старом файле, если reload не сработал.

Для cron схема обычно такая:

sudo crontab -e

0 4 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"

Если у вас Apache, то вместо nginx — apache2. Если сайт работает в контейнере Docker, тогда hook может быть другим: например, перезапуском контейнера, который держит TLS. Но тут уже бездумно копировать команды нельзя. В Docker-сценариях я часто сначала смотрю архитектуру, а потом уже решаю, где именно должен жить certbot.

Кстати, если вы уже выстраиваете нормальное обслуживание сервера, полезно почитать Настройка cron jobs: автоматические задачи на сайте в 2026 и Как настроить мониторинг сайта: полное руководство. Я обычно делаю это в комплекте: обновление сертификата, мониторинг uptime, проверка логов и уведомления в Telegram или почту.

Проверка продления и работа с логами

Автообновление без проверки — это почти что отсутствие автообновления. На деле самый важный шаг — убедиться, что renewal реально отработал, а не просто “настроен”. Я всегда после установки делаю два уровня проверки: ручной dry-run и регулярный контроль логов.

Основные логи certbot обычно лежат в /var/log/letsencrypt/letsencrypt.log. Там видно, какие сертификаты обновлялись, какие домены не прошли проверку, и почему именно. Очень часто ошибка связана не с certbot, а с окружением: DNS не успел обновиться, CDN не пропустил challenge, временно сломался 80-й порт или Nginx отдал не тот server block.

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

Если хотите проверить срок действия сертификата прямо с сервера, я обычно использую openssl:

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

Эта команда быстро показывает notBefore и notAfter. Для продакшена это очень полезно, особенно если у вас несколько доменов, поддоменов, алиасов и отдельные сертификаты на staging.

У одного клиента на WordPress с PHP 8.3 и nginx сертификат обновлялся, но проверка через браузер всё равно показывала старый срок. Оказалось, что в конфиге было два server block на один и тот же домен, а reload цеплял не тот. Это типичная история. Поэтому я не доверяю только certbot. Я всегда дополнительно проверяю:

• какой конфиг nginx активен;
• какой путь к fullchain.pem и privkey.pem указан;
• что после renewal идёт reload, а не просто запись файла;
• что браузер реально видит новый срок сертификата.

Если вы хотите именно мониторить просрочку и получать уведомления до падения, я советую посмотреть материал Настройка мониторинга SSL-сертификата и уведомлений в 2026. И да, это не лишняя паранойя. Это нормальная эксплуатация.

Настройка Nginx для корректного автообновления

На nginx самое частое место поломки — это не сертификат, а конфиг. Я видел конфигурации, где сертификат лежал правильно, но server block был собран так, что HTTPS цеплялся с ошибкой из-за неправильного server_name, кривого редиректа или забытого listen 443 ssl http2;. В 2026 уже имеет смысл включать HTTP/2 или HTTP/3, если хостинг и стек это позволяют, но сначала надо добиться стабильного HTTPS.

Базовый конфиг выглядит так:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

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

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Тут есть один важный момент: после обновления сертификата нужен reload nginx. Без этого он может продолжать отдавать старую цепочку из памяти. Я обычно добавляю deploy-hook:

sudo certbot renew --deploy-hook "systemctl reload nginx"

И если у вас несколько конфигов, не забывайте тестировать синтаксис перед reload:

sudo nginx -t && sudo systemctl reload nginx

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

Проверка в браузере и на стороне клиента

Когда сертификат обновился, многие просто открывают сайт и смотрят на замок. Я так не делаю. На моей практике визуальная проверка в браузере слишком часто обманывает. Кэш, HSTS, CDN, корпоративные прокси, мобильные сети — всё это может показать не тот результат, который нужен.

Нормальная проверка включает несколько шагов. Сначала я смотрю цепочку через браузер, потом через openssl, затем через внешнюю проверку вроде SSL Labs, а если проект критичный — ещё и из разных точек сети. Особенно это полезно, если домен обслуживается через CDN или балансировщик. Иногда сертификат обновился на origin-сервере, но на edge всё ещё висит старый. И человек думает, что Let’s Encrypt “не работает”. Нет, просто инфраструктура сложнее одного nginx.

Отдельно проверяйте:

• доступ по https://example.com и https://www.example.com;
• редирект с HTTP на HTTPS;
• отсутствие mixed content в консоли браузера;
• срок действия и issuer сертификата;
• совпадение SAN-имен с вашими доменами.

Если вы работаете с WordPress, после установки SSL часто вылезают старые URL в базе данных. В Bitrix — аналогично, особенно если шаблон или модуль хранят абсолютные ссылки. В Laravel проблема бывает в .env, APP_URL и в генерации ссылок через helpers. Тут уже нужна не просто настройка сертификата, а полноценная настройка силами специалиста — потому что чинить это “по месту” бывает дольше и дороже, чем один раз сделать нормально.

Хороший контрольный список для проверки сайта после SSL я обычно совмещаю с общим аудитом. Тут уместно посмотреть и SEO-аудит сайта: что проверить в первую очередь, и Настройка логов сайта: мониторинг и анализ ошибок в 2026. Потому что ошибка в сертификате нередко идёт рядом с ошибкой в редиректах, mixed content и 404 на старых адресах.

Особенности для WordPress, Bitrix и Laravel

Одинаковая схема Let’s Encrypt не всегда одинаково удобна на разных CMS. На WordPress обычно всё проще: nginx или Apache, certbot, затем правка URL сайта и поиск старых абсолютных ссылок. Но даже там я регулярно вижу проблемы из-за кэша плагинов, CDN и неправильно настроенного редиректа.

На Bitrix всё зависит от архитектуры. Если это обычный проект на одном сервере, то всё предсказуемо. Но если там есть кеширование, композитный режим, отдельный nginx перед Apache, несколько доменов и старые настройки в панели, можно легко потерять час-два только на поиск активного server block. Для Bitrix я часто дополнительно проверяю права на файлы сертификатов, потому что после миграций или бэкап-restore бывают странные ACL и ownership.

В Laravel картина тоже своя. Часто сертификат технически работает идеально, а приложение продолжает думать, что оно на HTTP. Причина — proxy headers, TrustProxies middleware, APP_URL и настройки балансировщика. Если после включения SSL где-то генерируются ссылки на HTTP, это не Let’s Encrypt виноват. Это приложение не умеет корректно понимать схему запроса.

Если проект уже вырос и поддержка регулярная, я обычно предлагаю не разовую возню, а нормальную поддержку WordPress или поддержку Битрикс. Потому что SSL — это часть общей инфраструктуры, а не отдельный ритуал. И да, в пакете поддержки проще следить и за сертификатами, и за бэкапами, и за обновлениями PHP 8.2/8.3/8.4.

Отдельно скажу про совместимость. На старых серверах с PHP 7.4 и MySQL 5.7 я ещё встречал хостинги, где certbot работает, но окружение вокруг него уже на честном слове. В 2026 это не лучший вариант. Если сервер давно не обновлялся, то сначала проверьте общую готовность стека — иногда проще сделать миграцию, чем чинить устаревшую систему. Для этого у меня есть отдельные услуги, и иногда я сразу предлагаю клиенту проверка сайта, чтобы найти все слабые места до того, как они начнут ломаться один за другим.

Часто ломающиеся моменты и как их обойти

Самая частая ошибка — забыли открыть порт 80. Let’s Encrypt HTTP-01 challenge без этого не пройдёт. Вторая ошибка — редирект с HTTP на HTTPS настроен так, что он мешает верификации. Третья — в конфиге несколько доменов, а сертификат выпущен только на один. Четвёртая — CDN или прокси не пропускает challenge-запросы.

Ещё один популярный косяк — renewal настроен, но веб-сервер не перезагружается после успешного обновления. Это особенно обидно: сертификат новый есть, но nginx продолжает отдавать старый. Я видел это и в Docker, и на обычных VPS, и на виртуальном хостинге. Поэтому deploy-hook обязателен.

Иногда ломается и сам таймер. После ручной миграции, копирования VPS или восстановления из бэкапа systemd timer может быть отключён. А люди уверены, что всё работает. Поэтому я всегда проверяю не только логи, но и список таймеров:

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

Если у вас особенно чувствительный проект, я советую дополнительно поставить мониторинг окончания срока сертификата и уведомления в Telegram или по email. Для этого можно использовать внешние сервисы, но можно и свои скрипты. Главное — не надеяться на память. Это плохая идея.

Кстати, если вы наводите порядок в технической части сайта комплексно, обратите внимание на Как настроить автопродление SSL-сертификата в 2026 и Как настроить мониторинг сайта: полное руководство. В связке они дают гораздо меньше аварий, чем разрозненные решения.

Что я делаю на практике, когда настраиваю Let’s Encrypt

Если коротко, у меня почти всегда один и тот же порядок. Сначала проверяю DNS и доступность домена. Потом выпускаю сертификат. Затем сразу тестирую renewal через dry-run. После этого смотрю, как веб-сервер подхватывает обновление. И только потом уже включаю мониторинг и, если нужно, HSTS, HTTP/2 и остальные улучшения.

На одном проекте с nginx, PHP 8.3 и MariaDB 10.6 у клиента всё ломалось из-за того, что deployment-скрипт после обновления certbot делал restart всего стека, а не reload только nginx. Из-за этого на короткое время падали очереди, фоновые задачи и webhook-обработчики. Мы заменили restart на reload, добавили dry-run, повесили уведомление о падении таймера — и инциденты закончились. Грубо говоря, проблема была не в Let’s Encrypt, а в том, что обновление сертификата пытались сделать как “перезапусти всё подряд”.

Если сайт уже живёт на серьёзной нагрузке, я рекомендую не ограничиваться ручной настройкой. Тут часто нужна полноценная доработка сайта с учётом nginx, PHP-FPM, кэша, редиректов и логики приложения. И если в проекте есть почта на домене, обязательно проверьте ещё и как настроить SSL для почты домена в 2026 году, потому что веб-сертификат не решает проблемы IMAP/SMTP автоматически.

И ещё один момент. В 2026 году я бы не держал SSL “в голове”. Лучше всего, когда он живёт как часть системной эксплуатации: таймер, лог, уведомление, проверка, резервный план. Если вы так и сделаете, Let’s Encrypt действительно превращается в то, чем он и должен быть: тихим фоновым сервисом, а не источником сюрпризов.