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

Я регулярно настраиваю автопродление SSL-сертификатов на проектах на Bitrix, WordPress и Laravel, и честно говоря, это одна из тех вещей, которые лучше один раз сделать нормально, чем потом каждый 60–90 дней ловить просрочку и красный замок в браузере. В 2026 году схема стала проще: Let’s Encrypt, ACME-клиенты, cron, systemd timers, панели управления и автопродление через хостинг уже закрывают 90% задач. Но на деле проблемы всё ещё всплывают — то сертификат выпустили не для того домена, то webroot неверный, то DNS-валидация не проходит, то nginx после renewal не перезагрузили.

Как вообще работает автопродление SSL

Если по-простому, автопродление SSL — это не магия, а обычная автоматизация процесса перевыпуска сертификата до момента его истечения. В большинстве случаев речь идёт про Let’s Encrypt, потому что у него срок действия 90 дней. Это сделано специально: короткий срок жизни повышает безопасность, а автопродление убирает ручную рутину. Я обычно настраиваю renewal так, чтобы сертификат обновлялся каждые 60 дней, а не впритык. Это нормальный запас, и он спасает, если ночью упал DNS, закончился доступ по SSH или что-то сломалось в deploy-скриптах.

С технической стороны всё строится вокруг ACME-протокола. Клиент, например certbot, acme.sh или lego, доказывает, что вы контролируете домен. Делается это через HTTP-01 challenge, DNS-01 challenge или TLS-ALPN-01 challenge. На практике чаще всего используют HTTP-01 и DNS-01. HTTP-01 проще, если сайт уже живёт на сервере и доступен из интернета. DNS-01 удобнее для wildcard-сертификатов вида *.example.com, но требует API-доступа к DNS-провайдеру. На одном клиентском проекте в 2024 году мы именно на DNS-01 перевели всё, потому что у них было 17 поддоменов, и вручную выпускать сертификаты — это плохая идея.

Если вам уже приходилось настраивать переход на HTTPS, то логика будет знакома. Автопродление — это продолжение той же истории, только уже без ручного участия. И чем сложнее инфраструктура, тем важнее не надеяться на память администратора. У меня был случай, когда сертификат на интернет-магазине с PHP 8.2 и nginx истёк в пятницу вечером. Продажи остановились, обращения пошли в мессенджеры, а владелец сайта был уверен, что “там же всё автоматически”. Автоматически — только если это реально настроено.

Какие варианты автопродления бывают в 2026 году

Я обычно делю все варианты на четыре группы. Первая — автопродление через панель хостинга. Это удобно для небольших сайтов и лендингов: включили SSL в cPanel, ISPmanager, Plesk или у нормального хостинга, и всё. Вторая — через ACME-клиент на сервере, это мой основной вариант для VPS и выделенных машин. Третья — через DNS API, когда нужен wildcard или когда сайт спрятан за CDN. Четвёртая — через managed SSL у CDN или облачного провайдера, например когда сертификат ставится на уровне Cloudflare, а до origin сервер общается уже по отдельному каналу.

Но если говорить откровенно, я не люблю полагаться только на панель хостинга, если у проекта есть хоть какая-то критичность. Панели иногда обновляются, ломают планировщик, меняют пути к бинарникам или не так обрабатывают webroot. На WordPress-сайтах это всплывает особенно часто: плагинов много, nginx может быть нестандартный, а права на каталог под challenge выставлены неаккуратно. Для Bitrix ситуация похожая: сайт на бою, cron нужен и для сертификата, и для внутренних задач, и если там бардак, сертификат однажды просто не обновится.

На практике я почти всегда смотрю на хостинг, версию ОС и стек. Например, Debian 12, Ubuntu 22.04/24.04, PHP 8.1–8.3, nginx 1.24+ или Apache 2.4 — это уже нормальная база. Если сервер старый, с PHP 7.4 и MySQL 5.7, я сначала привожу его в порядок, а уже потом настраиваю автопродление. Иначе получается “костыль на костыле”, а это плохая идея. Кстати, если проект уже упирается в старый стек, рекомендую почитать обновление PHP на сервере и настройку лимитов памяти PHP и MySQL — без нормальной базы автопродление иногда тоже ведёт себя странно.

Certbot, acme.sh или панель: что выбрать

Если нужен мой честный ответ, то для большинства серверов я беру certbot. Он понятный, хорошо документирован, стабильно работает на Debian и Ubuntu, а для nginx и Apache у него есть готовые интеграции. Когда нужно что-то более гибкое, особенно с DNS-провайдерами или wildcard, я часто выбираю acme.sh. Этот инструмент легче, не всегда требует Python-зависимости, и с ним удобно жить в минималистичных окружениях. lego тоже встречается, но в реальной практике я ставлю его реже.

Панель управления — это хороший вариант, когда у клиента обычный корпоративный сайт, нет DevOps в штате и нужен максимально простой процесс. Например, в Plesk можно включить автопродление почти в два клика. Но если вы делаете сайт на Laravel, деплоите через Git, используете Docker и CI/CD, я бы всё равно вынес выпуск сертификата в инфраструктурный скрипт. Так надёжнее, и это хорошо сочетается с настройкой окружения разработчика: Docker, Git, CI/CD.

У одного клиента был проект на WordPress с 8 доменами и 4 поддоменами, причём часть сайтов сидела на одном сервере, а часть — за Cloudflare. Сначала они использовали панель хостинга, потом начали расти, и панель стала мешать. Мы перевели всё на acme.sh с DNS API у провайдера. В результате перестали ловить ручные ошибки, а renewal стал занимать вообще ноль времени после первичной настройки. Вот это нормальная автоматизация, а не иллюзия автоматизации.

Настройка автопродления на nginx и certbot

Если сервер на nginx, то классическая схема выглядит так: certbot выпускает сертификат, кладёт его в /etc/letsencrypt/live/, а затем renewal-скрипт обновляет сертификат и перезагружает nginx. На деле чаще всего достаточно даже не reload, а nginx -s reload или systemctl reload nginx. Но я всегда проверяю конфиг заранее. Один неправильный блок server_name — и HTTP-01 challenge не пройдёт.

Вот рабочий пример для Ubuntu 22.04 / Debian 12 с nginx и certbot. Я обычно делаю так, если нужен обычный домен без wildcard:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

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

sudo systemctl status certbot.timer
sudo certbot renew --dry-run

После установки certbot обычно сам добавляет systemd timer или cron-задачу. Но я на это не надеюсь слепо. Всегда запускаю тест:

sudo certbot renew --dry-run

Если dry-run прошёл, значит цепочка в целом рабочая. Если нет — смотрю в логи, права на каталог, маршрутизацию challenge и наличие редиректов. Частая ошибка: сайт сразу гонит всё на HTTPS, а challenge-файл недоступен по HTTP. Тогда ACME-клиент не может подтвердить домен. Для таких случаев полезно отдельно проверить HTTPS редиректы и HSTS, потому что иногда именно они мешают выпуску сертификата.

Если нужен webroot-вариант, я часто делаю отдельный location в nginx:

server {
    listen 80;
    server_name example.com www.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/example.com/public;
        allow all;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

После этого certbot можно запускать через webroot:

sudo certbot certonly --webroot \
  -w /var/www/example.com/public \
  -d example.com -d www.example.com

Дальше автопродление обычно проходит автоматически. Но я всё равно добавляю свой deploy-hook, который проверяет конфиг и делает reload. Это особенно полезно, если на сервере несколько виртуальных хостов и одна ошибка может затронуть сразу весь nginx.

DNS-01 и wildcard-сертификаты

Когда нужен сертификат на *.example.com, HTTP-01 уже не подходит. Тут нужен DNS-01 challenge. И вот здесь автопродление становится одновременно мощнее и чувствительнее. Мощнее — потому что можно закрыть сразу все поддомены. Чувствительнее — потому что вы зависите от DNS API провайдера, токена доступа и корректной записи TXT.

На моих проектах DNS-01 особенно полезен для мультидоменов, SaaS-платформ и сайтов, где поддомены генерируются динамически. Например, если у вас есть личные кабинеты вида client123.example.com, wildcard снимает кучу головной боли. Но надо понимать: wildcard не покрывает корневой домен сам по себе. Обычно нужен ещё и отдельный сертификат или SAN-сертификат с перечислением домена и wildcard.

Пример с acme.sh и DNS API у Cloudflare выглядит так:

curl https://get.acme.sh | sh
source ~/.bashrc

export CF_Token="your_api_token"
export CF_Account_ID="your_account_id"

acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'

acme.sh --install-cert -d example.com \
  --key-file       /etc/ssl/example.com.key \
  --fullchain-file /etc/ssl/example.com.crt \
  --reloadcmd     "systemctl reload nginx"

И вот тут есть важный момент: автопродление должно быть не только “выпустить сертификат”, но и корректно доставить его в nginx, Apache, балансировщик или панель. Я видел случаи, когда renewal отрабатывал, файл обновлялся, а сервис продолжал читать старый сертификат из кэша. Поэтому всегда добавляю reload, а иногда ещё и проверку даты истечения через скрипт мониторинга. Если у вас уже стоит мониторинг сайта, добавьте туда и контроль SSL — это реально спасает.

Автопродление через cron, systemd и скрипты

Если говорить про надёжность, то в 2026 году systemd timer я считаю лучшим выбором для Linux-серверов. Cron тоже работает, и работает давно, но systemd удобнее для логов, зависимостей и контроля состояния. На VPS с Ubuntu 24.04 я обычно вижу certbot.timer уже из коробки. Но если нужно собственное решение, я создаю отдельный unit и timer, чтобы процесс был прозрачным.

Вот пример простой cron-задачи для certbot:

0 3 * * * root certbot renew --quiet --deploy-hook "systemctl reload nginx"

А вот пример systemd timer, если хочется чуть более аккуратную схему:

# /etc/systemd/system/certbot-renew.service
[Unit]
Description=Renew Let's Encrypt certificates

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet --deploy-hook /usr/bin/systemctl reload nginx

# /etc/systemd/system/certbot-renew.timer
[Unit]
Description=Run certbot renew daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Дальше включаем:

sudo systemctl daemon-reload
sudo systemctl enable --now certbot-renew.timer
sudo systemctl list-timers | grep certbot

На практике я всегда ставлю проверку после renewal. Если это сложный проект, я дополнительно запускаю curl-запрос к сайту и проверяю дату сертификата через OpenSSL. Простейший вариант:

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

Такой контроль особенно полезен, если сайт на Laravel или Bitrix деплоится через автоматические пайплайны. Автопродление не должно конфликтовать с релизами. Если у вас есть CI/CD и задачи уже автоматизированы, посмотрите ещё настройку cron jobs и версионирование и откат обновлений сайта — я часто связываю эти темы в одном проекте.

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

На WordPress автопродление обычно самое простое, если сайт не перегружен нестандартными правилами. Но тут есть нюанс: некоторые плагины безопасности, кеширования или редиректов могут вмешиваться в путь /.well-known/acme-challenge/. Особенно это касается наборов вроде Wordfence, Really Simple SSL и редирект-плагинов. На одном сайте у клиента certbot вообще не мог достучаться до challenge, потому что плагин безопасности подменял ответы для всего HTTP-трафика. Мы убрали конфликт, и renewal пошёл нормально.

В Bitrix ситуация часто сложнее. Там могут быть свои правила в .htaccess, дополнительный nginx-конфиг, прокси, несколько доменов, а ещё cron занят не только сертификатами, но и агентами. Я обычно советую держать логику renewal вне Bitrix-кода. Не в ядре, не в шаблоне, не в каком-нибудь “служебном” PHP-скрипте внутри /local/. Это неправильное место. Лучше отдельный системный процесс, который вообще не зависит от работы CMS. Если у вас уже есть обновление Битрикс без потери данных или настройка кеширования в Битрикс, автопродление нужно делать на том же уровне аккуратности.

Laravel обычно живёт в более чистой инфраструктуре. Но там часто используется Docker, Nginx proxy, отдельный контейнер для app и отдельный для web. В таком случае я не кладу сертификаты внутрь контейнера “на постоянку” без понимания жизненного цикла. Лучше либо монтировать volume, либо выпускать сертификат на хосте и прокидывать в контейнер. Иначе после пересборки контейнера вы получите сюрприз. Кстати, для Laravel-проектов очень полезна тема Laravel для бизнес-проекта — там хорошо видно, почему инфраструктура и приложение должны быть разделены.

Типичные ошибки и как их избежать

Самая частая ошибка — проверить выпуск сертификата вручную и успокоиться. А потом забыть, что renewal в автоматическом режиме не проверялся ни разу. Я всегда советую делать --dry-run и проверять логи. Вторая ошибка — забыть reload сервиса после обновления сертификата. Третья — сделать неправильный редирект с HTTP на HTTPS, который ломает ACME challenge. Четвёртая — не учесть CDN или обратный прокси. Пятая — выпустить сертификат, но не проверить, какой именно vhost его подхватил.

Иногда я вижу и совсем странные вещи. Например, сертификат обновился на сервере, а на клиенте в браузере всё равно показывается старый. Причина банальна: перед сайт стоит балансировщик или CDN, а origin-сервер обновили, но внешний слой продолжает отдавать старый cert. Это уже не задача certbot, это задача всей цепочки доставки. И здесь полезно заранее изучить настройку CDN для сайта и обратный прокси Nginx, если у вас такая схема.

Ещё одна ошибка — игнорировать мониторинг срока действия сертификата. Да, автопродление должно работать само. Но я на своих проектах всё равно ставлю внешний контроль: хотя бы уведомление за 14, 7 и 3 дня до окончания. Это особенно полезно для интернет-магазинов и корпоративных порталов, где простой на час уже ощутим. Если у вас есть настройка логов сайта, добавьте туда события ACME-обновлений. Это потом экономит массу времени.

Проверка после настройки и постоянный контроль

После того как автопродление настроено, я не ставлю галочку “готово” и не закрываю задачу. Я проверяю минимум три вещи: срок действия сертификата, доступность сайта по HTTPS и перезагрузку сервиса после renewal. В идеале ещё тестирую заголовки безопасности, потому что обновление SSL — хороший повод убедиться, что HSTS, CSP и редиректы не сломались. Если тема безопасности вам близка, загляните в статьи про заголовки безопасности HTTP и Content Security Policy.

На больших проектах я люблю автоматизировать проверку через bash-скрипт и внешний мониторинг. Например, скрипт может раз в сутки ходить на сайт, вытаскивать дату окончания сертификата и отправлять уведомление в Telegram или email. Если у вас уже настроена SMTP для отправки писем с сайта, можно использовать её для алертов. Это несложно, а пользу даёт огромную.

Пример простого PHP-проверщика, если нужен контроль прямо в инфраструктуре:

<?php
$host = 'example.com';
$context = stream_context_create([
    'ssl' => [
        'capture_peer_cert' => true,
        'verify_peer' => false,
        'verify_peer_name' => false,
    ],
]);

$client = @stream_socket_client("ssl://{$host}:443", $errno, $errstr, 30, STREAM_CLIENT_CONNECT, $context);
if (!$client) {
    exit("Connection failed: {$errstr}\n");
}

$params = stream_context_get_params($client);
$cert = openssl_x509_parse($params['options']['ssl']['peer_certificate']);
echo "Valid to: " . date('Y-m-d H:i:s', $cert['validTo_time_t']) . PHP_EOL;

Этот код не заменяет полноценный мониторинг, но для быстрых проверок подходит отлично. И да, если у вас проект на PHP 8.3, всё это работает без проблем. На PHP 8.1 тоже работает. Главное — не запускать такой контроль там, где всё ещё сидит древний стек с выключенными расширениями и сломанным openssl. Тогда сначала нужно навести порядок в сервере и, возможно, сделать миграцию сайта на новый хостинг.

Мой рабочий подход в 2026 году

Если коротко, я обычно строю автопродление так: Let’s Encrypt, certbot или acme.sh, отдельный системный процесс, reload веб-сервера после обновления, dry-run перед запуском и внешний мониторинг срока действия. Для обычных сайтов на WordPress я часто иду через certbot и nginx. Для Bitrix — через серверный уровень, без самодеятельности в CMS. Для Laravel и Docker — через хостовую автоматизацию и понятные volume-монтирования. И это действительно работает.

Если проект маленький, можно использовать панель хостинга. Если проект средний или крупный — лучше сразу делать нормальную автоматизацию. Не экономьте на этой настройке. SSL-сертификат — это не просто “замочек в браузере”, а часть доверия, SEO, безопасности и стабильности. А если у вас уже настроены бэкапы, мониторинг, редиректы и защита от взлома, автопродление SSL становится логичным финальным штрихом в общей инфраструктуре. Для комплексной защиты полезно почитать ещё как защитить сайт от взлома и как делать бэкапы сайта правильно.

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