SSL в BitrixVM на CentOS: создание и продление Let’s Encrypt по шагам

На BitrixVM без SSL браузер помечает сайт как небезопасный; если сертификат просрочен — страницы перестают открываться по HTTPS. В дистрибутиве уже есть всё необходимое для работы с Let’s Encrypt: остаётся корректно установить certbot, выпустить сертификат и подключить его в nginx. Ниже — по шагам, с примерами команд и конфигов.

---

Как устроен SSL в BitrixVM

Структура в BitrixVM такая:

• конфигурации сайтов nginx лежат в каталоге
  /etc/nginx/bx/site_avaliable/
  (в дистрибутиве папка называется именно так — с опечаткой в слове «available»);
• подключение SSL для домена идёт через файл
  bx_ext_ssl_ДОМЕН.conf;
• сами сертификаты Let’s Encrypt после выпуска лежат в
  /etc/letsencrypt/live/ДОМЕН/.

---

Шаг 1. Установка certbot

Установи пакет и убедись, что certbot доступен в PATH:

yum install certbot -y
which certbot

Ожидаемый вывод — путь к бинарнику, например /usr/bin/certbot.

---

Шаг 2. Выпуск сертификата (webroot — рекомендуемый способ для BitrixVM)

Способ webroot не трогает настройки nginx и подходит для BitrixVM: certbot кладёт challenge в каталог сайта, nginx отдаёт его по запросу от Let’s Encrypt.

Сначала узнай, под каким именем домена лежит сайт:

ls /home/bitrix/ext_www/

Подставь свой домен вместо example.com в команду ниже. Пример для домена example.com и www.example.com:

certbot certonly \
  --webroot \
  -w /home/bitrix/ext_www/example.com/public_html \
  -d example.com \
  -d www.example.com \
  --email admin@example.com \
  --agree-tos \
  --non-interactive

При успехе в конце будет сообщение вроде «Successfully received certificate». Убедиться, что сертификат создан, можно так:

ls -la /etc/letsencrypt/live/example.com/

Должны быть файлы fullchain.pem и privkey.pem. Готовый сниппет с командами и проверкой challenge: Certbot: webroot в BitrixVM.

---

Шаг 3. Создание SSL-конфига nginx

Создай файл конфигурации SSL (подставь свой домен вместо example.com):

nano /etc/nginx/bx/conf/ssl.example.com.conf

Минимальный рабочий вариант:

# Редирект HTTP -> HTTPS при прямом заходе на 443 по HTTP
error_page 497 https://$host$request_uri;

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

ssl_session_cache shared:SSL:10m;

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

---

Шаг 4. Подключение SSL к сайту

Нужно подключить этот конфиг в виртуальном хосте сайта. Открой файл для твоего домена (в BitrixVM он лежит в site_avaliable):

nano /etc/nginx/bx/site_avaliable/bx_ext_ssl_example.com.conf

Добавь в нужный блок server (обычно в тот, где listen 443 ssl;) одну строку:

include bx/conf/ssl.example.com.conf;

Пример фрагмента после правки:

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    include bx/conf/ssl.example.com.conf;
    # ... остальные директивы сайта
}

Подробнее: Nginx в BitrixVM: SSL для Let’s Encrypt.

---

Шаг 5. Проверка конфигурации и перезагрузка nginx

Проверь синтаксис и примени изменения:

nginx -t
systemctl reload nginx

Если nginx -t выводит «syntax is ok» и «test is successful», после reload сайт должен открываться по HTTPS.

---

Продление SSL (обязательная часть настройки)

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

---

Проверка, что продление сработает

Перед тем как полагаться на cron, убедись, что продление в принципе проходит:

certbot renew --dry-run --deploy-hook "echo OK"

Команда не меняет сертификат, а лишь имитирует процесс. Если в выводе появится OK от deploy-hook и не будет ошибок — продление настроено верно.

---

Ручное продление

Обычное ручное продление (когда до окончания срока осталось мало времени или нужно обновить сертификат вручную):

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

Команда проверит срок действия сертификатов и при необходимости продлит их, после чего перезагрузит nginx.

Принудительное продление (например, после смены домена или для проверки — сертификат обновится даже если срок ещё не истёк):

certbot renew --force-renewal --deploy-hook "systemctl reload nginx"

Перевыпуск сертификата через certonly (как при первичном выпуске — те же домены, новый сертификат). Подходит, если renew не срабатывает или нужно заново получить сертификат. Подставь свой webroot и домены:

certbot certonly \
  --webroot \
  -w /home/bitrix/ext_www/example.com/public_html \
  -d example.com \
  -d www.example.com

После успешного выпуска выполни systemctl reload nginx, чтобы nginx подхватил новые файлы.

В обычной работе достаточно автоматического продления по cron; ручные команды нужны для разовой проверки или экстренного обновления.

---

Автоматическое продление через cron (рекомендуется)

Чтобы certbot сам продлевал сертификат и перезагружал nginx, добавь задачу в crontab root:

EDITOR=nano crontab -e

Строка ниже запускает проверку продления каждый день в 03:00 и при успешном обновлении выполняет systemctl reload nginx:

0 3 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx" >/dev/null 2>&1

Если перенаправляешь вывод в лог (например, для отладки), можно использовать:

0 3 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx" >> /var/log/le-renew.log 2>&1

Проверить, что задача выполнилась, можно по логам:

tail -20 /var/log/le-renew.log

Отдельный сниппет с командами и вариантами cron: Certbot: продление и cron с deploy-hook.

---

Краткая проверка статуса nginx и certbot

Убедиться, что nginx запущен и certbot доступен:

systemctl status nginx
which certbot

---

Типовая ошибка — ACME challenge не открывается

Let’s Encrypt проверяет домен по URL вида http://домен/.well-known/acme-challenge/.... Если nginx не отдаёт этот каталог или путь к webroot указан неверно, выпуск сертификата падает с ошибкой проверки.

Проверить доступность каталога вручную (подставь свой домен):

mkdir -p /home/bitrix/ext_www/example.com/public_html/.well-known/acme-challenge
echo test > /home/bitrix/ext_www/example.com/public_html/.well-known/acme-challenge/test.txt
chown -R bitrix:bitrix /home/bitrix/ext_www/example.com/public_html/.well-known

curl -s http://example.com/.well-known/acme-challenge/test.txt

В ответе должно быть слово test. Если пусто или 404 — проверь путь в -w у certbot и конфиг nginx для этого сайта. Сниппет с проверкой challenge и срока сертификата: Certbot: проверка ACME и дат сертификата.

---

Типовая ошибка — нужен location для .well-known

Если при выпуске или продлении сертификата certbot выдаёт ошибку проверки домена (например, «Unable to connect» или «Connection refused» при проверке http://ваш-домен/.well-known/acme-challenge/...), часто причина в том, что в конфиге nginx для этого сайта нет явного location для ACME challenge. Nginx не отдаёт файлы из .well-known/acme-challenge/, и Let’s Encrypt не может подтвердить домен.

Решение: добавь в блок server для нужного домена (в файле вида bx_ext_ssl_ДОМЕН.conf или основном конфиге сайта) location для challenge. Путь в root должен указывать на каталог public_html именно этого сайта. Пример для домена example.com:

location ^~ /.well-known/acme-challenge/ {
    root /home/bitrix/ext_www/example.com/public_html;
    default_type "text/plain";
    try_files $uri =404;
    allow all;
}

Подставь свой домен в путь: /home/bitrix/ext_www/ВАШ_ДОМЕН/public_html. После правки проверь конфиг и перезагрузи nginx:

nginx -t
systemctl reload nginx

Затем снова выполни выпуск или продление сертификата.

---

Типовая ошибка — сертификат обновился, а сайт отдаёт старый

После успешного certbot renew nginx продолжает использовать старые файлы, пока не перечитать конфигурацию. Достаточно перезагрузить nginx без остановки обслуживания:

systemctl reload nginx

Имеет смысл вызывать reload из --deploy-hook, как в примере с cron выше.

---

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

Убедиться, какие даты у сертификата, который реально отдаёт сервер (подставь свой домен):

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

Вывод покажет notBefore и notAfter — срок действия текущего сертификата.

---

Чеклист перед обращением в поддержку

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

• certbot установлен (which certbot выводит путь)
• сертификат выпущен и лежит в /etc/letsencrypt/live/ТВОЙ_ДОМЕН/
• создан файл ssl.ТВОЙ_ДОМЕН.conf в /etc/nginx/bx/conf/
• этот файл подключён через include в bx_ext_ssl_ТВОЙ_ДОМЕН.conf
• после правок выполнен nginx -t и systemctl reload nginx
• в crontab root есть задача на certbot renew с --deploy-hook "systemctl reload nginx"
• команда certbot renew --dry-run выполняется без ошибок

---

Итог

В BitrixVM настройка SSL по Let’s Encrypt сводится к одному разу: установить certbot, выпустить сертификат методом webroot, создать SSL-конфиг nginx, подключить его в виртуальном хосте и настроить автоматическое продление через cron. После этого схема certbot webroot + include в nginx + cron renew годами работает без ручного вмешательства.

---

Связанные сниппеты

• Certbot: выпуск сертификата через webroot в BitrixVM — команда certonly, проверка ACME challenge
• Nginx в BitrixVM: SSL-конфиг для Let’s Encrypt — конфиг и include в виртуальном хосте
• Certbot: продление и cron с deploy-hook для nginx — renew, dry-run, crontab
• Certbot: проверка ACME challenge и срока сертификата — диагностика выпуска и дат по openssl