Как настроить SSL Let’s Encrypt для сайта в 2026 году

16 июля 2026 · Время чтения: 10 мин

Я на практике ставил Let’s Encrypt на десятки сайтов — от простых лендингов на WordPress до тяжёлых проектов на Bitrix и Laravel. И честно говоря, в 2026 году SSL уже не про «галочку для SEO», а про нормальную базу безопасности, доверие и отсутствие лишних проблем с браузерами, API и интеграциями.

Зачем SSL вообще нужен в 2026 году

Если коротко, SSL-сертификат шифрует соединение между браузером и сервером. Без него сайт отдаётся по HTTP, а это значит, что логины, пароли, формы, cookies и вообще весь трафик идут в открытом виде. На деле это плохая идея уже лет десять как, но в 2026 году без HTTPS сайт выглядит просто устаревшим. Браузеры помечают такие страницы как небезопасные, а пользователи уходят, не дождавшись даже загрузки формы заявки.

У меня был клиент с интернет-магазином на WordPress 6.5 и PHP 8.2, который долго тянул с переходом на HTTPS. У них работал приём заказов, но часть платежного модуля, интеграция с CRM и вебхуки падали из-за смешанного контента. В итоге потратили полдня не на сертификат как таковой, а на поиски старых ссылок на картинки и скрипты. Поэтому я обычно говорю так: SSL — это не только про «включить сертификат», это ещё и про аккуратную настройку всего сайта после переезда.

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

ℹ️

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

Как работает Let’s Encrypt и что изменилось к 2026 году

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

На моей практике проблемы почти никогда не возникают на этапе выпуска сертификата. Проблемы начинаются потом: кривой cron, отключённый acme-клиент, забытый DNS после переезда, старый Nginx, который не умеет нормально отдавать challenge-файл, или хостинг с кастомной панелью, где сертификат обновился, но сайт продолжает слушать другой виртуальный хост. Грубо говоря, сертификат сам по себе — это половина дела.

В 2026 году в продакшене чаще всего используют certbot или acme.sh. Я лично чаще ставлю certbot на классические VPS с Ubuntu 22.04/24.04 или Debian 12, а acme.sh беру там, где удобнее управлять многими доменами и нужен более тонкий контроль. Если у вас Bitrix на PHP 8.1 или 8.2, WordPress на PHP 8.3, Laravel на Nginx + PHP-FPM — схема одна и та же: получили сертификат, подключили, настроили редиректы, проверили mixed content, включили автопродление.

💡

Совет: если вы не администрируете сервер руками, сначала уточните у хостинга, поддерживает ли он автоустановку Let’s Encrypt. На shared-хостинге это часто делается из панели, а на VPS лучше сразу идти через консоль. И да, если у вас уже есть статья про выбор хостинга, вспомните её перед переездом — слабый хостинг ломает SSL чаще, чем сам сертификат.

Подготовка перед настройкой SSL

Перед установкой сертификата я всегда проверяю несколько вещей. Без этого можно попасть в очень неприятную ситуацию: сертификат выпущен, а сайт открывается с ошибкой 502, редирект уводит в бесконечный цикл, или панель CMS перестаёт авторизовывать пользователя.

Первое — домен должен быть корректно направлен на сервер. Если DNS ещё не обновился, Let’s Encrypt не сможет подтвердить владение доменом через HTTP-01 challenge. Второе — у вас должен быть доступ к конфигам веб-сервера: Nginx, Apache или связка Nginx + Apache. Третье — на порту 80 должен отвечать ваш сайт, хотя бы временно. И четвёртое — проверьте, что на сервере не заблокирован доступ к каталогам, где ACME-клиент будет писать challenge-файлы.

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

⚠️

Предупреждение: не ставьте SSL «в лоб» на боевом сайте без проверки редиректов, путей к картинкам и настроек CMS. У меня был случай на Bitrix 24.0 с PHP 8.1 и MySQL 8.0, где сертификат поставили за пять минут, а потом три часа искали причину бесконечной авторизации. Виноват оказался неправильный адрес в настройках сайта и старый URL в базе.

Установка сертификата через Certbot: рабочая схема

Самый типовой путь в 2026 году — поставить certbot. Ниже покажу вариант для Nginx на Ubuntu/Debian. Если у вас Apache, логика похожая, просто команды и конфиги будут немного другие.

На чистом сервере я обычно делаю так:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.ru -d www.example.ru

После этого Certbot сам подхватывает Nginx-конфиг, выпускает сертификат и может предложить редирект с HTTP на HTTPS. Я, честно говоря, почти всегда включаю редирект сразу, если нет каких-то особых причин оставить HTTP. Оставлять две версии сайта — это лишний шум и источник ошибок. Это особенно критично, если у вас уже настроены HTTPS-редиректы и HSTS.

Если хотите поставить сертификат без автоматической правки конфига, можно использовать webroot-метод:

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

Этот вариант я люблю, когда конфигурация сервера уже сложная, а вносить туда автоматические изменения не хочется. Например, на проде у клиента Nginx выполнял роль reverse proxy, а приложение крутилось в Docker-контейнере. Там certbot лучше запускать отдельно, чтобы не ломать существующую схему.

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

/etc/letsencrypt/live/example.ru/fullchain.pem
/etc/letsencrypt/live/example.ru/privkey.pem

И вот эти пути уже надо прописать в конфиге Nginx или Apache. Если у вас мультидоменный проект, загляните ещё в настройку мультидоменного сайта — там часто бывают нюансы с отдельными сертификатами на каждый домен или wildcard-выпусками через DNS-челлендж.

Настройка Nginx с SSL

На моих проектах Nginx используется чаще всего. Для WordPress, Bitrix и Laravel это очень нормальная схема. Главное — не писать конфиг «на коленке». Небольшая ошибка в редиректе или расположении блока server может превратить рабочий сайт в головную боль.

Вот базовый пример конфига для HTTPS:

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

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

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

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers off;

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

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    location ~* \.(jpg|jpeg|png|gif|svg|webp|avif|css|js|woff2)$ {
        expires 30d;
        access_log off;
        add_header Cache-Control "public, no-transform";
    }
}

Если у вас PHP 8.3, socket будет один, если 8.2 — другой. На деле это мелочь, но именно из-за таких мелочей я часто вижу ошибки 502 после «быстрой» настройки. У одного клиента на Laravel 11 и PHP 8.2 сертификат встал идеально, а сайт не открывался из-за того, что в конфиге остался сокет от старой версии PHP 8.1. Сертификат тут вообще ни при чём, но пользователь видит нерабочий сайт и думает, что «сломали SSL».

Для повышения безопасности я обычно добавляю ещё несколько заголовков, но без фанатизма. Иначе можно наделать ошибок и сломать сторонние сервисы. Если вам интересна тема глубже, посмотрите статью настройка заголовков безопасности HTTP и материал про Content Security Policy. SSL и CSP — это не одно и то же, но вместе они дают очень хороший уровень защиты.

Настройка Apache и .htaccess

Apache до сих пор живёт на многих shared-хостингах и старых VPS, особенно у клиентов с WordPress. Там установка Let’s Encrypt обычно проще всего через панель хостинга или через certbot --apache. Но если нужно руками, логика понятная: включаете SSL-модуль, выпускаете сертификат и прописываете виртуальный хост на 443 порту.

Типовой пример:

<VirtualHost *:80>
    ServerName example.ru
    ServerAlias www.example.ru
    Redirect permanent / https://example.ru/
</VirtualHost>

<VirtualHost *:443>
    ServerName example.ru
    ServerAlias www.example.ru

    DocumentRoot /var/www/example.ru/public

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.ru/privkey.pem

    <Directory /var/www/example.ru/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

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

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Если вы работаете с WordPress, после переезда на HTTPS обязательно проверьте адрес сайта в настройках, ссылки в базе и внешний кэш. Я часто делаю поиск по базе на старый http:// через SQL, но осторожно. Лучше сначала тестовая замена на staging-стенде. Кстати, у меня есть полезная статья про staging-сайт для безопасной проверки обновлений. Это особенно актуально, если сайт уже коммерческий и падать ему нельзя.

Автопродление сертификата: без этого всё бессмысленно

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

Проверить ручное обновление можно так:

sudo certbot renew --dry-run

Если тест проходит, дальше надо убедиться, что в системе есть автоматический запуск. Обычно Certbot сам создаёт systemd timer или cron, но я всё равно проверяю это руками. Одной команды мало. Откройте таймеры:

systemctl list-timers | grep certbot

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

⚠️

Предупреждение: если у вас в проде сертификат обслуживается вручную, заведите мониторинг срока действия. За 7, 14 и 3 дня до окончания. Иначе однажды утром сайт просто откроется с красной ошибкой, а вы узнаете об этом от клиента, а не от системы.

Чтобы не пропустить проблему, я обычно настраиваю мониторинг вместе с уведомлениями. Тут полезна статья как настроить мониторинг сайта и, если хочется совсем по-взрослому, Uptime Robot для сайта. SSL — это часть общей стабильности, а не изолированная штука.

WWW, non-WWW, mixed content и HSTS

После установки сертификата я всегда проверяю три вещи: как сайт открывается с www и без него, нет ли mixed content, и включён ли корректный редирект на единую версию домена. Если вы это пропустите, можно получить дубли, просадку SEO и лишние проблемы в аналитике.

Про редиректы между www и без www у меня есть отдельная статья: как настроить SSL для www и без www. Там я подробно показывал, как выбрать основную версию и не наделать редирект-цепочек. В 2026 году это особенно важно, потому что Google и Яндекс хорошо видят кривую каноникализацию, а пользователи просто не любят лишние задержки.

Mixed content — это когда страница уже открылась по HTTPS, но часть ресурсов тянется по HTTP. Обычно это картинки, CSS, JS, шрифты, iframe или старые ссылки в базе данных. Иногда проблема сидит в теме WordPress, иногда — в шаблоне Bitrix, иногда — в коде Laravel Blade. На деле всё лечится поиском и заменой, но сначала надо понять масштаб.

Если у вас после переезда на HTTPS внезапно поехала верстка, загляните ещё в настройку SSL без ошибок mixed content. А если сайт очень чувствителен к скорости, полезно совместить SSL с современными протоколами из статьи HTTP/2 и HTTP/3 для ускорения сайта.

HSTS — хороший инструмент, но с ним надо аккуратно. Я включаю его только после того, как убедился, что весь сайт стабильно работает по HTTPS, включая поддомены, почту, админку и внешние интеграции. Иначе можно отрезать себе путь назад, а это уже ненужный риск.

ℹ️

Инфо: если у вас есть поддомены, сначала проверьте их вручную. Например, mail., api., crm., static.. Очень часто основной домен уже на HTTPS, а поддомены нет. Потом ломаются вебхуки, API и интеграции с CRM.

Проверка после настройки и типовые ошибки

Когда сертификат уже подключён, я делаю минимум четыре проверки. Первая — открываю сайт в браузере и смотрю, нет ли предупреждений. Вторая — прогоняю домен через SSL Labs. Третья — проверяю редиректы с HTTP, www, без www и старых URL. Четвёртая — смотрю логи веб-сервера и PHP-FPM.

На практике самые частые ошибки такие:

неправильный путь к сертификату;
истёкший или не обновившийся сертификат;
mixed content в шаблоне или базе;
редирект-цикл между http и https;
ошибка 403/404 для ACME challenge;
не тот виртуальный хост в Nginx или Apache;
старый кэш CDN или плагина кеширования.

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

У одного клиента на Bitrix был очень неприятный случай: сертификат корректно обновлялся, но часть страниц всё равно выдавалась через старый edge-кэш CDN. В браузере сертификат новый, а картинка — из старого HTTP-адреса. Это выглядело как странная смесь из прошлой и текущей конфигурации. Решили очисткой CDN, пересборкой кеша Bitrix и проверкой всех абсолютных ссылок в шаблоне.

Особенности настройки для Bitrix, WordPress и Laravel

Если говорить по-честному, у каждой CMS есть свои типичные грабли. В WordPress чаще всего проблема в базе и плагинах кеширования. В Bitrix — в настройках главного модуля, композитном кеше и старых шаблонах. В Laravel — в прокси, переменных окружения и конфиге приложения.

Для WordPress я обычно после установки SSL проверяю:

адреса сайта в wp_options;
настройки плагинов кеша;
ссылки в Elementor, WPBakery или старых коротких кодах;
медиафайлы с абсолютными http:// URL.

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

Для Laravel обычно важны переменные APP_URL и доверие к прокси. Если приложение сидит за Nginx reverse proxy, нужно корректно передавать заголовки X-Forwarded-Proto, иначе Laravel может считать, что запрос пришёл по HTTP, даже когда в браузере HTTPS. И вот тут начинаются странные редиректы, сбросы сессии и проблемы с авторизацией. Это одна из тех штук, которую потом долго ищут, если забыли сразу поставить галочку в конфиге.

Если проект крупный, советую вместе с SSL сразу проверить безопасность в целом. Уместно смотреть как защитить сайт от взлома, защиту базы данных сайта и защиту wp-login.php и XML-RPC для WordPress-проектов.

Когда лучше не мучиться самому

Если у вас простой сайт на одном домене и доступ к серверу есть, настройка Let’s Encrypt обычно занимает 10–20 минут. Но если сайт уже живой, с интеграциями, CRM, поддоменами, CDN, несколькими версиями PHP и старой базой на MySQL 5.7 или 8.0, можно легко потратить полдня и всё равно оставить хвосты. Я не люблю делать вид, что это «пара кликов». Иногда это реально инженерная работа.

На моей практике лучше всего работает подход, когда SSL настраивается вместе с проверкой редиректов, mixed content, HSTS, кеша и мониторинга. Тогда сайт после переезда не просто получает замочек в браузере, а становится чуть более надёжным в целом. И это уже нормальный результат, а не формальная галочка.

Если нужен аккуратный переход на HTTPS без потери позиций, с проверкой редиректов, кэша и CMS, я могу помочь с этим на поддержке Битрикс, поддержке WordPress или в рамках доработки сайта. На деле часто достаточно одной нормальной настройки, чтобы убрать половину будущих проблем.

И ещё момент. SSL — это не разовая история. Если у вас есть автопродление, мониторинг, нормальные логи и понятная схема деплоя, всё работает тихо и незаметно. А если этого нет, любой сертификат однажды превращается в ночной форс-мажор. Так что однозначно стоит сделать настройку один раз правильно, а не «потом как-нибудь исправить».

Хотите настроить SSL без ошибок?

Обратитесь к специалистам, чтобы быстро подключить Let’s Encrypt и обеспечить сайту безопасный HTTPS.

Павел

Веб-разработчик · 10+ лет опыта · Bitrix, WordPress, Laravel