SSL-сертификат на VPS устанавливается не “на сервер вообще”, а на конкретный домен или поддомен. Перед выпуском сертификата домен должен указывать на IP VPS, веб-сервер должен отвечать по HTTP, а порты 80 и 443 должны быть открыты.
Общая схема выглядит так: домен → DNS → веб-сервер → ACME challenge → выпуск сертификата → автообновление
Let’s Encrypt через ACME challenge проверяет, что вы действительно контролируете домен. После успешной проверки выпускается сертификат, а веб-сервер начинает отдавать сайт по HTTPS.
Для Nginx и Apache чаще всего используют Certbot. Он может автоматически найти конфиг сайта, выпустить сертификат, добавить SSL-настройки и включить редирект с HTTP на HTTPS.
Для Nginx базовый сценарий обычно выглядит так: sudo certbot --nginx -d example.com -d www.example.com
Для Apache: sudo certbot --apache -d example.com -d www.example.com
После установки сертификата нужно проверить не только зелёный замок в браузере, но и несколько технических вещей:
- Сайт открывается по HTTPS;
- HTTP корректно перенаправляется на HTTPS;
- Сертификат выпущен именно для нужного домена;
- www и non-www версии работают правильно;
- Автообновление Certbot проходит без ошибок;
- На страницах не осталось mixed content;
- Бэкенд, API, изображения, стили и скрипты тоже загружаются по HTTPS.
Если SSL ставится через панель управления VPS, логика похожая: панель запускает выпуск сертификата через Let’s Encrypt, а затем прописывает его в конфигурацию сайта. Но панель не отменяет базовые проверки. DNS, порты, редиректы и mixed content всё равно нужно проверить вручную.
Wildcard-сертификат нужен, если требуется защитить сразу все поддомены вида *.example.com: например, app.example.com, api.example.com, dev.example.com. Для него обычно используется DNS challenge, потому что Let’s Encrypt должен проверить контроль над всей DNS-зоной домена.
Главные ошибки при установке SSL на VPS — закрытый 80 или 443 порт, домен указывает не на тот IP, веб-сервер не отвечает по HTTP, редирект HTTP → HTTPS настроен неправильно, сертификат выпущен не для того домена, автообновление не проверено, а на сайте после установки остался mixed content.
Правильный порядок такой: сначала проверить DNS и веб-сервер, затем выпустить сертификат, включить HTTPS, проверить редиректы, протестировать автообновление и только после этого считать SSL настроенным.
Как работает выпуск SSL на VPS
SSL-сертификат нужен, чтобы сайт открывался по HTTPS, а браузер мог проверить: пользователь действительно подключается к нужному домену, а соединение шифруется.
На VPS сертификат часто выпускают через Let’s Encrypt. Это бесплатный центр сертификации, который работает по протоколу ACME. Владелец сервера запускает Certbot или использует панель управления, а Let’s Encrypt проверяет, что домен действительно принадлежит этому серверу или управляется его владельцем. Альтернативы в виде платных сертификатов или ZeroSSL тоже существуют и активно используются, но LE остаётся самым популярным вариантом.
Главное — понять цепочку проверки. Если в ней сломан хотя бы один шаг, выпуск сертификата завершится ошибкой.
Домен → DNS → веб-сервер → ACME challenge → сертификат
Процесс выпуска SSL-сертификата можно представить как последовательность: домен → DNS → веб-сервер → ACME challenge → выпуск сертификата → автообновление
Сначала домен должен указывать на IP-адрес VPS. Это настраивается в DNS-зоне домена через A-запись для IPv4 или AAAA-запись для IPv6.
Затем веб-сервер на VPS должен принимать запросы для этого домена. Обычно это Nginx или Apache с настроенным виртуальным хостом.
После этого Certbot отправляет запрос в Let’s Encrypt. Let’s Encrypt проверяет домен через ACME challenge. В стандартном сценарии сервер должен отдать специальный проверочный файл по HTTP, поэтому важно чтобы сервер отвечал по HTTP на 80 порту. Если проверка проходит, Let’s Encrypt выпускает сертификат.
Дальше Certbot прописывает сертификат в конфигурацию веб-сервера или показывает, где лежат файлы сертификата, если настройка выполняется вручную.
После установки сайт начинает открываться по HTTPS. Но на этом работа не заканчивается: нужно проверить редирект, домены в сертификате, mixed content и автообновление.
Что проверяет Let’s Encrypt
Let’s Encrypt не проверяет, кто владелец бизнеса, где находится сервер и кому принадлежит сайт по документам. В базовом сценарии он проверяет контроль над доменом.
Для обычного сертификата чаще всего используется HTTP-01 challenge. Let’s Encrypt обращается к домену по HTTP и проверяет, может ли сервер отдать специальный файл с нужным содержимым.
Если файл доступен, значит человек, запускающий выпуск сертификата, контролирует сервер, на который указывает домен. После этого сертификат может быть выпущен.
Для wildcard-сертификатов используется другой подход — DNS challenge. В этом случае нужно добавить специальную TXT-запись в DNS-зону домена. Так Let’s Encrypt проверяет контроль не над конкретным веб-сервером, а над DNS домена.
Поэтому перед установкой SSL важно убедиться, что домен уже смотрит на правильный IP, DNS успели обновиться, а веб-сервер отдаёт нужный сайт.
Почему важны порты 80 и 443
Для выпуска и работы SSL важны два порта: 80 и 443.
Порт 80 используется для HTTP. Он нужен не только для обычного открытия сайта без HTTPS, но и для проверки Let’s Encrypt в сценарии HTTP-01 challenge. Если порт 80 закрыт firewall, провайдером или настройками сервера, Certbot может не пройти проверку домена.
Порт 443 используется для HTTPS. После выпуска сертификата именно через него браузер подключается к защищённой версии сайта.
Частая ошибка — закрыть 80 порт слишком рано, потому что “сайт же должен работать только по HTTPS”. На практике HTTP-порт обычно оставляют открытым, но настраивают редирект: пользователь заходит на http://example.com, а сервер перенаправляет его на https://example.com.
Если порт 443 закрыт, сертификат может быть выпущен, но сайт по HTTPS не откроется. Если закрыт порт 80, выпуск или обновление сертификата через HTTP challenge может сломаться.
Поэтому перед установкой SSL нужно проверить три вещи: домен указывает на VPS, веб-сервер отвечает по HTTP, а firewall пропускает 80 и 443 порты. После этого можно переходить к подготовке сервера и установке сертификата.
Что подготовить перед установкой SSL
Домен должен указывать на IP VPS
Перед установкой SSL нужно убедиться, что домен уже привязан к VPS. Для этого в DNS-зоне домена должна быть A-запись с IPv4-адресом сервера. Если используется IPv6, дополнительно настраивается AAAA-запись.
Например, для домена example.com A-запись должна вести на IP вашего VPS: example.com → 203.0.113.10
Если нужен сертификат и для версии с www, отдельная запись должна быть и для www.example.com: www.example.com → 203.0.113.10
Проверить, куда сейчас указывает домен, можно через dig:
dig +short example.com
dig +short www.example.com
Или через nslookup: nslookup example.com
Если в ответе отображается не IP вашего VPS, выпуск сертификата может завершиться ошибкой. Let’s Encrypt будет обращаться к домену, попадать на другой сервер и не сможет пройти проверку.
Также нужно учитывать время обновления DNS. После изменения записей домен не начинает указывать на новый IP мгновенно. Поэтому нужно подождать, пока изменения распространятся.
Веб-сервер должен отвечать на HTTP
После DNS нужно проверить, что веб-сервер на VPS отвечает по HTTP. Для Let’s Encrypt важно, чтобы домен был доступен снаружи и запросы доходили до Nginx или Apache. Естественно, пока нет сертификата, HTTPS работать не будет.
Проверить это можно в браузере: http://example.com
Или через curl: curl -I http://example.com
Если сервер отвечает кодом 200, 301 или 302, это уже хороший знак. Значит домен доступен, веб-сервер принимает запросы и отдаёт ответ.
Если вместо ответа ошибка подключения, таймаут или страница другого сайта, сначала нужно исправить базовую настройку. Certbot не должен быть первым инструментом диагностики. Сначала должен работать обычный HTTP.
Важно проверить и основной домен, и www, если сертификат выпускается для обеих версий:
curl -I http://example.com
curl -I http://www.example.com
Если одна версия работает, а другая нет, Certbot может выпустить сертификат только для части доменов или завершить проверку с ошибкой.
Firewall должен пропускать 80 и 443 порты
Даже если DNS настроен правильно, а веб-сервер установлен, SSL не заработает при закрытых портах.
Для HTTP нужен порт 80, для HTTPS — порт 443. Они должны быть открыты и на самом сервере, и в firewall у провайдера, если у VPS есть отдельные сетевые правила в панели облака.
На Ubuntu с UFW можно проверить статус так: sudo ufw status
Если используется Nginx, часто открывают профиль: sudo ufw allow 'Nginx Full'
Для Apache: sudo ufw allow 'Apache Full'
Можно открыть порты явно:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
Порт 80 не стоит закрывать после перехода на HTTPS. Он часто нужен для редиректа с HTTP на HTTPS и для автообновления сертификата через HTTP challenge.
Стоит отметить, что помимо HTTP-01 (запрос по 80 порту) и DNS-01 (проверка записи в DNS) есть ещё вариант проверки TLS-ALPN-01, который использует только 443 порт - но этот вариант подходит не всем, как более сложный, требующий использования специального протокола ALPN. Поэтому наиболее простой вариант - использовать проверку по HTTP.
Если порт 443 закрыт, сайт не откроется по HTTPS даже при корректно выпущенном сертификате. Если закрыт порт 80, Certbot может не пройти проверку домена или не сможет обновить сертификат в будущем.
Конфиг сайта должен быть рабочим до установки SSL
Certbot не исправляет сломанную конфигурацию сайта. Перед выпуском сертификата нужно убедиться, что Nginx или Apache уже понимает, какой домен обслуживать и из какой директории отдавать сайт.
Для Nginx обычно проверяют конфигурацию командой: sudo nginx -t
Если ошибок нет, можно перезагрузить веб-сервер: sudo systemctl reload nginx
Для Apache используют: sudo apachectl configtest
И затем перезагружают сервис: sudo systemctl reload apache2
Если конфиг сайта сломан, Certbot может не найти нужный virtual host, не сможет корректно прописать SSL-настройки или выпустит сертификат, но сайт всё равно не откроется.
Перед установкой SSL стоит проверить:
- Домен прописан в конфиге веб-сервера;
- Сайт открывается по HTTP;
- Нет ошибок в конфигурации Nginx или Apache;
- document root указывает на правильную папку;
- www и non-www версии настроены осознанно;
- Старые редиректы не мешают проверке Let’s Encrypt.
Когда DNS, HTTP, firewall и конфиг сайта в порядке, можно переходить к установке SSL через Certbot. Дальше сценарий будет немного отличаться для Nginx и Apache, но логика остаётся одинаковой: Certbot проверяет домен, выпускает сертификат и подключает его к веб-серверу.
Установка SSL на VPS с Nginx
Установка Certbot
Для Nginx чаще всего используют Certbot с nginx-плагином. Он может сам найти конфигурацию сайта, выпустить сертификат Let’s Encrypt, прописать SSL-настройки и при необходимости добавить редирект с HTTP на HTTPS.
На Ubuntu/Debian Certbot часто устанавливают через apt:
sudo apt update
sudo apt install certbot python3-certbot-nginx
После установки стоит убедиться, что Nginx работает, а конфигурация сайта не содержит ошибок:
sudo nginx -t
sudo systemctl status nginx
Если nginx -t показывает ошибку, сначала нужно исправить конфиг. Иначе Certbot может не найти нужный server block или не сможет безопасно изменить настройки.
Перед выпуском сертификата также проверьте, что в конфиге Nginx указан нужный домен: server_name example.com www.example.com;
Именно эти имена потом нужно передать Certbot через параметр -d.
Выпуск сертификата для домена
Когда DNS, firewall и конфиг Nginx готовы, можно запускать выпуск сертификата.
Для домена без www команда будет такой: sudo certbot --nginx -d example.com
Если сертификат нужен и для основной версии, и для www, укажите оба имени: sudo certbot --nginx -d example.com -d www.example.com
Certbot проверит домен через Let’s Encrypt, выпустит сертификат и предложит настроить редирект с HTTP на HTTPS, если это применимо для вашей версии и конфигурации.
После успешного выпуска сертификаты обычно сохраняются в каталоге Let’s Encrypt: /etc/letsencrypt/live/example.com/
Там находятся основные файлы:
fullchain.pem
privkey.pem
Обычно вручную прописывать эти пути не нужно, если используется команда certbot --nginx. Certbot сам добавляет их в конфигурацию Nginx. Но знать расположение полезно для диагностики и ручных настроек.
После выпуска сертификата проверьте конфигурацию и перезагрузите Nginx:
sudo nginx -t
sudo systemctl reload nginx
Если Certbot завершился ошибкой, не стоит повторять команду много раз подряд. Let's Encrypt имеет ограничения на количество неудачных запросов, и адрес попадёт в блокировку. Лучше сначала проверить DNS, открытые порты, server_name, доступность сайта по HTTP и логи ошибки.
Проверка HTTPS и редиректа
После выпуска сертификата нужно проверить, что сайт действительно открывается по HTTPS: curl -I https://example.com
В ответе не должно быть ошибки сертификата. Если сервер возвращает 200, 301 или 302, HTTPS отвечает.
Затем проверьте HTTP-версию: curl -I http://example.com
Если включён редирект, сервер должен перенаправлять запрос на HTTPS. Обычно это ответ 301 или 302 с заголовком Location: https://example.com/....
Также нужно проверить все домены, которые указаны в сертификате:
curl -I https://example.com
curl -I https://www.example.com
Частая ошибка — выпустить сертификат только для example.com, а потом открыть www.example.com. В таком случае браузер может показать предупреждение, потому что www не включён в сертификат.
Дополнительно стоит открыть сайт в браузере и проверить, нет ли предупреждения о mixed content. Оно появляется, когда сама страница загружается по HTTPS, но изображения, скрипты, стили или API-запросы всё ещё идут по HTTP.
Проверка автообновления
Сертификаты Let’s Encrypt выпускаются на ограниченный срок, поэтому их нужно регулярно обновлять. Certbot обычно настраивает автоматическое обновление через systemd timer или cron, но это всё равно нужно проверить.
Для теста автообновления используется dry-run: sudo certbot renew --dry-run
Эта команда не заменяет рабочий сертификат, а проверяет, сможет ли Certbot пройти процесс обновления. В официальных инструкциях Certbot также используется именно sudo certbot renew --dry-run для проверки автоматического продления.
Если dry-run проходит успешно, значит базовая схема обновления работает. Если появляется ошибка, нужно проверить DNS, доступность домена по HTTP, 80 порт, конфигурацию Nginx и способ, которым был выпущен сертификат.
На сервере с systemd можно посмотреть таймеры Certbot: systemctl list-timers | grep certbot
Или проверить статус сервиса: systemctl status certbot.timer
После проверки автообновления полезно зафиксировать это в документации проекта: какой домен защищён, где лежит конфиг Nginx, как проверять renew и кто отвечает за SSL.
Если HTTPS работает, редирект настроен, www и non-www версии проверены, а certbot renew --dry-run проходит без ошибок, установку SSL для Nginx можно считать завершённой.
Установка SSL на VPS с Apache
Установка Certbot
Для Apache используется Certbot с apache-плагином. Он помогает выпустить сертификат Let’s Encrypt и автоматически подключить его к нужному virtual host.
На Ubuntu/Debian Certbot и плагин для Apache обычно устанавливают так:
sudo apt update
sudo apt install certbot python3-certbot-apache
Перед выпуском сертификата нужно проверить, что Apache установлен, запущен и не содержит ошибок в конфигурации:
sudo apachectl configtest
sudo systemctl status apache2
Если команда apachectl configtest возвращает ошибку, сначала нужно исправить конфиг. Certbot не должен накладываться поверх сломанной настройки Apache.
Также стоит убедиться, что для сайта создан virtual host и в нём указан нужный домен:
ServerName example.com
ServerAlias www.example.com
Именно эти домены затем передаются Certbot через параметр -d.
Выпуск сертификата для домена
Когда DNS, firewall и virtual host готовы, можно запускать выпуск сертификата.
Для одного домена команда будет такой: sudo certbot --apache -d example.com
Если сертификат нужен и для основной версии, и для www, укажите оба домена: sudo certbot --apache -d example.com -d www.example.com
Certbot проверит домен через Let’s Encrypt, выпустит сертификат и предложит настроить редирект с HTTP на HTTPS, если это доступно для текущей конфигурации.
После успешного выпуска Certbot обычно сам добавляет SSL-настройки в конфигурацию Apache. Сертификаты сохраняются в каталоге Let’s Encrypt:
/etc/letsencrypt/live/example.com/
Основные файлы сертификата:
fullchain.pem
privkey.pem
Если настройка выполнялась через certbot --apache, вручную прописывать эти пути обычно не нужно. Но они могут пригодиться для диагностики, ручной настройки или переноса конфигурации.
После выпуска сертификата проверьте Apache и перезагрузите сервис:
sudo apachectl configtest
sudo systemctl reload apache2
Если Certbot не смог выпустить сертификат, сначала проверьте DNS, доступность сайта по HTTP, открытый 80 порт, ServerName, ServerAlias и корректность virtual host.
Проверка HTTPS и редиректа
После установки сертификата нужно проверить, что сайт открывается по HTTPS: curl -I https://example.com
Если всё настроено правильно, сервер вернёт ответ без ошибки сертификата. Обычно это будет 200, 301 или 302.
Затем проверьте HTTP-версию: curl -I http://example.com
Если включён редирект на HTTPS, в ответе должен быть код 301 или 302, а в заголовке Location — адрес с https://.
Отдельно проверьте все варианты домена, которые должны работать:
curl -I https://example.com
curl -I https://www.example.com
Если сертификат выпущен только для example.com, а сайт открывается ещё и как www.example.com, браузер может показать ошибку. Поэтому www и non-www версии лучше продумать заранее.
Также после установки SSL нужно открыть сайт в браузере и проверить mixed content. Если страница загружается по HTTPS, но картинки, стили, скрипты или API-запросы идут по HTTP, браузер может показывать предупреждение или блокировать часть контента.
Проверка автообновления
Let’s Encrypt-сертификаты нужно регулярно обновлять. Certbot обычно добавляет автоматическое обновление через systemd timer или cron, но после установки SSL это обязательно нужно проверить.
Для теста используется команда: sudo certbot renew --dry-run
Она имитирует обновление сертификата и показывает, сможет ли Certbot пройти проверку домена без реальной замены сертификата.
Если dry-run проходит успешно, автообновление, скорее всего, настроено корректно. Если появляется ошибка, нужно проверить доступность домена, открытый 80 порт, DNS, Apache virtual host и редиректы.
Проверить таймер Certbot на сервере с systemd можно так: systemctl list-timers | grep certbot
Или так: systemctl status certbot.timer
После проверки полезно записать в документации проекта, какие домены защищены сертификатом, где находится virtual host Apache и как проверить автообновление.
Если HTTPS работает, HTTP корректно перенаправляется на HTTPS, все доменные версии включены в сертификат, а certbot renew --dry-run проходит без ошибок, установку SSL для Apache можно считать завершённой.
Установка SSL через панель управления VPS
Как это обычно работает в панели
В панели управления VPS установка SSL обычно выглядит проще, чем через консоль. Пользователь открывает настройки сайта, выбирает выпуск SSL-сертификата Let’s Encrypt, указывает домен и запускает установку.
Внутри логика остаётся такой же: панель обращается к Let’s Encrypt, проходит проверку домена, получает сертификат и подключает его к конфигурации веб-сервера.
Обычно в панели можно:
- Выбрать сайт или домен;
- Включить SSL;
- Выпустить сертификат Let’s Encrypt;
- Добавить www-версию домена;
- Включить редирект с HTTP на HTTPS;
- Настроить автообновление;
- Посмотреть дату окончания сертификата.
В HestiaCP, CyberPanel, aaPanel и других панелях названия пунктов могут отличаться, но общий сценарий похожий: сначала сайт должен существовать в панели, затем к нему подключается домен, после этого выпускается сертификат.
Панель удобна тем, что не нужно вручную редактировать конфиги Nginx или Apache. Но она не отменяет базовые условия: домен должен указывать на VPS, веб-сервер должен отвечать, а порты 80 и 443 должны быть открыты.
Что проверить после выпуска сертификата
После успешного сообщения в панели не стоит сразу считать задачу завершённой. Сертификат мог выпуститься, но редирект, домены или контент страницы всё ещё могут работать неправильно.
Сначала откройте сайт по HTTPS: https://example.com
Затем проверьте HTTP-версию: http://example.com
Если редирект включён, HTTP должен автоматически перенаправлять на HTTPS.
Также проверьте обе версии домена, если они используются:
Если сертификат выпущен только для example.com, а сайт открывается как www.example.com, браузер может показать ошибку сертификата.
После этого стоит проверить:
- Дата окончания сертификата отображается корректно;
- В панели включено автообновление;
- HTTP перенаправляется на HTTPS;
- www и non-www версии работают как задумано;
- Нет циклического редиректа;
- В браузере нет предупреждения о mixed content;
- Формы, изображения, стили, скрипты и API-запросы работают по HTTPS.
Если панель показывает, что сертификат установлен, но браузер всё равно пишет “Not secure”, причина часто не в Let’s Encrypt. Проблема может быть в mixed content, неправильном домене, кэше, редиректах или старом сертификате, который продолжает отдавать веб-сервер.
Почему панель не отменяет проверку DNS и портов
Панель управления упрощает выпуск SSL, но не может обойти правила Let’s Encrypt. Чтобы сертификат был выпущен, домен всё равно должен проходить проверку.
Если домен указывает на другой IP, панель не сможет доказать контроль над нужным сервером. Let’s Encrypt обратится к домену, попадёт не на ваш VPS и проверка завершится ошибкой.
Если закрыт порт 80, может сломаться HTTP challenge. Если закрыт порт 443, сертификат может быть установлен, но сайт не откроется по HTTPS.
Поэтому перед установкой SSL через панель всё равно нужно проверить:
dig +short example.com
curl -I http://example.com
И убедиться, что firewall пропускает нужные порты: sudo ufw status
Если у провайдера есть отдельный cloud firewall или security group, нужно проверить правила не только внутри VPS, но и в панели провайдера.
Ещё одна частая проблема — сайт создан в панели, но домен не привязан к нужному виртуальному хосту. В этом случае запросы приходят на сервер, но попадают не в тот сайт или в дефолтную страницу.
Поэтому панель лучше воспринимать как удобный интерфейс, а не как замену диагностики. Если DNS, HTTP, порты и конфиг сайта в порядке, выпуск SSL через панель обычно проходит быстро. Если хотя бы один из этих элементов сломан, кнопка “Install SSL” не решит проблему сама по себе.
Wildcard-сертификат Let’s Encrypt
Обычный SSL-сертификат выпускают для конкретных доменов: например, example.com и www.example.com. Если поддоменов много, такой подход становится неудобным: каждый новый app.example.com, api.example.com или client.example.com нужно добавлять отдельно.
В таких случаях используют wildcard-сертификат. Он защищает сразу набор поддоменов одного уровня.
Когда нужен wildcard-сертификат
Wildcard-сертификат нужен, когда у проекта много поддоменов или они создаются регулярно.
Например: *.example.com
Такой сертификат подойдёт для:
app.example.com
api.example.com
dev.example.com
client1.example.com
client2.example.com
Это удобно для SaaS-проектов, личных кабинетов клиентов, тестовых окружений, API, staging-серверов и сервисов, где поддомены создаются динамически.
Но wildcard закрывает только один уровень поддоменов. Сертификат *.example.com подойдёт для api.example.com, но не подойдёт для v1.api.example.com. Для такого вложенного поддомена нужен отдельный сертификат или другой wildcard под нужный уровень.
Также wildcard не заменяет сертификат для основного домена. Если нужно защитить и example.com, и все поддомены, обычно указывают оба имени: -d example.com -d "*.example.com"
Почему для wildcard нужен DNS challenge
Для обычного сертификата часто используют HTTP-01 challenge: Let’s Encrypt обращается к сайту по HTTP и проверяет специальный файл на сервере.
С wildcard так не работает. Let’s Encrypt не может проверить каждый возможный поддомен через HTTP, потому что поддоменов может быть бесконечно много. Поэтому для wildcard используется DNS challenge.
В этом сценарии нужно добавить специальную TXT-запись в DNS-зону домена. Так Let’s Encrypt проверяет, что вы контролируете не конкретный веб-сервер, а DNS домена.
Команда Certbot для ручного DNS challenge может выглядеть так: sudo certbot certonly --manual --preferred-challenges dns -d example.com -d "*.example.com"
После запуска Certbot покажет TXT-запись, которую нужно добавить в DNS. Обычно она создаётся для имени вида: _acme-challenge.example.com
После добавления записи нужно дождаться, пока DNS обновится, и только потом продолжить выпуск сертификата.
Главный минус ручного DNS challenge — его неудобно обновлять автоматически. Каждый раз вручную добавлять TXT-запись для продления сертификата нельзя считать нормальным production-сценарием, но если ваш DNS-сервер (у регистратора или свой) поддерживает автоматизацию, то проверка DNS-01 может существенно облегчить жизнь и работу сайтов, особенно если сайты внутренние.
Что учесть при автообновлении wildcard
Wildcard-сертификат нужно обновлять так же, как обычный сертификат. Но из-за DNS challenge автообновление сложнее.
Чтобы продление работало без ручного участия, Certbot должен уметь автоматически создавать и удалять TXT-записи в DNS-зоне домена. Для этого используют DNS-плагин под конкретного DNS-провайдера или отдельный ACME-клиент с поддержкой API.
Логика такая:
- Certbot запускает обновление сертификата.
- DNS-плагин создаёт TXT-запись _acme-challenge.
- Let’s Encrypt проверяет DNS-запись.
- Сертификат продлевается.
- TXT-запись удаляется или обновляется.
Перед использованием wildcard нужно проверить, поддерживает ли ваш DNS-провайдер API и есть ли для него подходящий плагин. Если API нет, автообновление wildcard может превратиться в ручную процедуру каждые несколько месяцев.
Также важно безопасно хранить API-токен от DNS. Такой токен может давать доступ к управлению DNS-зоной, поэтому его нельзя оставлять в открытом виде, коммитить в Git или передавать подрядчикам без ограничений.
После настройки wildcard-сертификата обязательно проверьте автообновление: sudo certbot renew --dry-run
Если dry-run не проходит, wildcard-сертификат формально выпущен, но через некоторое время может истечь и сломать HTTPS на всех поддоменах.
Wildcard удобен, когда поддоменов много. Но если у проекта всего один-два поддомена, проще выпустить обычный сертификат для конкретных имён и не усложнять схему DNS challenge.
Автообновление SSL-сертификата
Сертификаты Let’s Encrypt выпускаются на ограниченный срок, поэтому их нужно регулярно продлевать. Вручную следить за датой окончания неудобно и небезопасно: если забыть про обновление, сайт начнёт показывать ошибку HTTPS.
Поэтому после установки SSL важно сразу проверить автообновление. Сертификат должен не только выпуститься один раз, но и продлеваться без ручного вмешательства.
Как работает renew у Certbot
Certbot хранит информацию о выпущенных сертификатах и умеет продлевать их командой:
sudo certbot renew
Эта команда проверяет установленные сертификаты и обновляет те, которым скоро потребуется продление. Обычно Certbot не перевыпускает сертификат каждый раз, а продлевает только те сертификаты, которые подходят под условия обновления.
На большинстве современных систем автообновление запускается через systemd timer или cron. То есть администратору не нужно каждый день вручную выполнять certbot renew.
Проверить таймер можно так: systemctl list-timers | grep certbot
Или так: systemctl status certbot.timer
Если используется cron, задачу можно искать в системных cron-каталогах или через настройки пакета Certbot. Конкретная схема зависит от дистрибутива и способа установки Certbot.
Важно помнить: автообновление обновляет сертификат, но сайт должен начать использовать новый сертификат. Обычно Certbot сам выполняет нужные reload-действия для Nginx или Apache, но это тоже стоит проверить.
Как проверить автообновление
Проверять автообновление нужно сразу после установки SSL, а не за день до окончания сертификата.
Для этого используется dry-run: sudo certbot renew --dry-run
Эта команда имитирует продление сертификата. Она проходит почти тот же путь, что и обычное обновление, но не заменяет рабочий сертификат.
Если dry-run завершается успешно, значит Certbot может пройти проверку домена, получить тестовый сертификат и выполнить процедуру обновления.
После успешной проверки стоит убедиться, что веб-сервер продолжает работать:
sudo nginx -t
sudo systemctl reload nginx
Для Apache:
sudo apachectl configtest
sudo systemctl reload apache2
Затем можно проверить HTTPS: curl -I https://example.com
Также полезно посмотреть список сертификатов: sudo certbot certificates
Так можно увидеть, какие домены входят в сертификат, где лежат файлы и когда сертификат истекает.
Что делать, если обновление не проходит
Если certbot renew --dry-run завершился ошибкой, не стоит игнорировать проблему. Это значит, что в момент реального продления сертификат тоже может не обновиться.
Сначала нужно прочитать текст ошибки. Часто причина находится не в самом Certbot, а в окружении:
- Домен больше не указывает на IP VPS;
- Закрыт порт 80;
- Сломан HTTP-редирект;
- Веб-сервер не отдаёт ACME challenge;
- Изменился конфиг Nginx или Apache;
- Сертификат выпускался для старого домена;
- wildcard-сертификат не может обновиться без DNS API;
- firewall или security group блокирует запросы Let’s Encrypt.
Для обычных сертификатов через HTTP challenge особенно важно, чтобы домен был доступен по HTTP. Если весь HTTP-трафик заблокирован или перенаправляется некорректно, проверка может не пройти.
Для wildcard-сертификатов нужно отдельно проверять DNS challenge. Если Certbot не может автоматически создать TXT-запись через DNS API, продление не сработает без ручного участия.
После исправления проблемы dry-run нужно запустить повторно: sudo certbot renew --dry-run
И только после успешного результата считать автообновление настроенным.
Автообновление SSL — это не просто удобная функция. Это часть нормальной эксплуатации VPS. Если срок действия сертификата истечёт, сайт может остаться доступным технически, но браузеры начнут показывать предупреждение, а пользователи будут считать ресурс небезопасным.
Хорошая практика - настраивать систему мониторинга на отсылку уведомлений когда срок жизни сертификата подходит и когда сертификат изменился, чтоб можно было заранее принять меры если сертификат не обновился во время.
Типовые ошибки при установке SSL на VPS
Не открыт 80 или 443 порт
Одна из самых частых причин ошибки при выпуске SSL — закрытый порт 80. Он нужен для HTTP-01 challenge, когда Let’s Encrypt проверяет домен через обычный HTTP-запрос.
Если порт 80 закрыт firewall, security group у провайдера или настройками сервера, Certbot не сможет подтвердить контроль над доменом. В результате сертификат не выпустится или не обновится.
Порт 443 нужен уже для работы HTTPS. Если он закрыт, сертификат может быть установлен корректно, но сайт всё равно не откроется по защищённому соединению.
Проверять нужно два уровня:
- Firewall внутри VPS;
- Сетевые правила в панели облачного провайдера.
На Ubuntu с UFW можно посмотреть правила так: sudo ufw status
И при необходимости открыть порты:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
После этого стоит повторно проверить сайт по HTTP и HTTPS. Если запросы не доходят до веб-сервера, выпуск SSL начинать рано.
Домен указывает не на тот IP
Вторая типовая ошибка — DNS-запись домена ведёт не на тот сервер. Пользователь запускает Certbot на своём VPS, но Let’s Encrypt при проверке домена попадает на другой IP.
Так бывает после переезда сайта, смены VPS, ошибки в DNS-зоне или попытки выпустить сертификат сразу после изменения записей.
Проверить текущий IP можно так:
dig +short example.com
dig +short www.example.com
Если домен должен открываться и с www, и без www, нужно проверить обе версии. Они могут указывать на разные IP или одна из записей может отсутствовать.
Также стоит помнить про DNS propagation. После изменения A-записи или AAAA-записи обновление не всегда происходит мгновенно. Иногда нужно подождать, пока новые записи начнут отдаваться у разных DNS-резолверов.
Если домен указывает не на VPS, Certbot не сможет пройти проверку. Сначала нужно исправить DNS, дождаться обновления записей и только потом снова запускать выпуск сертификата.
Сломан редирект HTTP → HTTPS
Редирект с HTTP на HTTPS нужен почти всегда, но его легко настроить неправильно.
Проблема может выглядеть по-разному: бесконечный цикл редиректов, переход на неправильный домен, редирект с www на non-www без учёта сертификата или перенаправление до того, как Let’s Encrypt смог пройти HTTP challenge.
Проверить редирект можно через curl: curl -I http://example.com
Если всё работает правильно, сервер обычно вернёт 301 или 302 и заголовок Location с HTTPS-адресом:
Location: https://example.com/
Но редирект должен быть логичным. Если http://example.com ведёт на https://www.example.com, то www.example.com тоже должен быть включён в сертификат. Если редирект ведёт на другой домен, сертификат должен быть выпущен уже для него.
Особенно внимательно нужно проверять сайты за reverse proxy, CDN или балансировщиком. Там цикл редиректов может появиться из-за того, что один слой считает соединение HTTP, а другой уже работает с HTTPS.
Сертификат выпущен не для того домена
SSL-сертификат действует только для тех доменных имён, которые были указаны при выпуске. Если сертификат выпущен для example.com, он не будет автоматически подходить для www.example.com, api.example.com или другого домена.
Проверить список сертификатов Certbot можно так: sudo certbot certificates
Там будет видно, какие домены включены в сертификат и когда он истекает.
Частая ситуация: сайт открывается и как example.com, и как www.example.com, но сертификат выпущен только для одной версии. В браузере это может выглядеть как ошибка безопасности на одной из версий домена.
Чтобы избежать проблемы, домены нужно продумать заранее. Например: sudo certbot --nginx -d example.com -d www.example.com
Или для Apache: sudo certbot --apache -d example.com -d www.example.com
Если используются поддомены, их тоже нужно указывать отдельно или использовать wildcard-сертификат, если поддоменов много.
Запускать команду на выпуск\обновление сертификата часто
У Let's Encrypt есть лимиты на запросы сертификата, в частности при ошибках подтверждения домена более 5 раз в час адрес попадает в блок и надо ожидать разблокировки.
Поэтому необходимо внимательно читать сообщения об ошибках, проверять конфигурацию веб-сервера и сетевых доступов и только потом запускать команду повторно.
Для отладки можно использовать ACME v2 staging environment, при помощи опций --test-cert или --dry-run, там лимиты значительно больше, например ошибки авторизации - 200 в час вместо 5.
Но даже если обновление проходит без ошибок, не стоит выполнять его слишком часто, ограничение на выпуск сертификатов с одинаковым списком имён - не более 5 в неделю. Обычно достаточно обновлять сертификаты раз в 1,5-2,5 месяца.
Автообновление не проверено
После успешной установки SSL легко решить, что всё готово. Но сертификат Let’s Encrypt нужно продлевать. Если автообновление не работает, проблема проявится позже — когда сертификат истечёт.
Поэтому после установки нужно обязательно выполнить: sudo certbot renew --dry-run
Если проверка проходит успешно, Certbot сможет обновить сертификат в будущем. Если появляется ошибка, её нужно исправить сразу, а не откладывать до даты окончания сертификата.
Причины сбоя автообновления часто те же, что и при первичном выпуске:
- Домен больше не указывает на VPS;
- Закрыт порт 80;
- Изменился конфиг веб-сервера;
- Сломался редирект;
- Был удалён нужный virtual host;
- wildcard-сертификат не может обновиться без DNS API.
Также стоит проверить, что на сервере есть systemd timer или cron-задача для Certbot: systemctl list-timers | grep certbot
Автообновление нельзя считать настроенным только потому, что Certbot установлен. Его нужно проверить dry-run и периодически контролировать дату окончания сертификата.
Mixed content остался после установки SSL
Даже если сертификат установлен правильно, сайт всё равно может показывать предупреждение в браузере. Частая причина — mixed content.
Mixed content появляется, когда страница загружается по HTTPS, но часть ресурсов остаётся на HTTP. Это могут быть изображения, CSS, JavaScript, шрифты, iframe, видео, API-запросы или внешние виджеты.
Например, страница открывается так: https://example.com
А изображение внутри неё загружается так: http://example.com/uploads/image.jpg
Браузер может заблокировать такой ресурс или показать предупреждение, что соединение защищено не полностью.
После установки SSL нужно проверить исходный код страниц, консоль браузера и настройки CMS. В WordPress, например, часто приходится обновить адрес сайта, заменить старые HTTP-ссылки в базе и проверить плагины кеширования.
Также нужно проверить внешние ресурсы: CDN, аналитика, виджеты, шрифты, iframe и API. Если внешний сервис не поддерживает HTTPS, его лучше заменить или убрать.
Установка SSL — это не только выпуск сертификата. Сайт должен полностью перейти на HTTPS: страницы, стили, скрипты, изображения, формы, API и все внутренние ссылки.
Когда порты открыты, DNS указывает на правильный IP, редиректы работают, сертификат выпущен для нужных доменов, автообновление проверено, а mixed content исправлен, SSL-настройку можно считать завершённой.
Заключение
Установка SSL на VPS — это не только команда Certbot и не только кнопка в панели управления. Сертификат выпускается для конкретного домена, а вся цепочка должна работать корректно: DNS, веб-сервер, открытые порты, ACME challenge, HTTPS-конфигурация и автообновление.
Для Nginx и Apache удобнее всего использовать Certbot с соответствующим плагином. Он может выпустить сертификат Let’s Encrypt, подключить его к веб-серверу и помочь настроить редирект с HTTP на HTTPS.
Если VPS управляется через панель, выпуск SSL обычно проще: сертификат можно установить через интерфейс. Но панель не отменяет базовую диагностику. Домен всё равно должен указывать на правильный IP, веб-сервер должен отвечать по HTTP, а порты 80 и 443 должны быть открыты.
Wildcard-сертификат нужен не всем. Он полезен, когда у проекта много поддоменов, но требует DNS challenge и более внимательной настройки автообновления.
Главное после установки SSL — не остановиться на факте выпуска сертификата. Нужно проверить HTTPS, редирект, домены в сертификате, mixed content и автообновление через certbot renew --dry-run.
Если всё это работает, SSL можно считать настроенным правильно: сайт открывается по HTTPS, браузер не показывает предупреждений, а сертификат сможет продлеваться без ручного вмешательства.
FAQ
Можно ли установить SSL на VPS бесплатно?
Да. Let’s Encrypt — бесплатный автоматизированный центр сертификации, через который можно выпускать SSL/TLS-сертификаты для доменов. Обычно для установки на VPS используют Certbot или встроенный выпуск сертификатов в панели управления.
Сам сертификат бесплатный, но остаётся работа по настройке: DNS, веб-сервер, firewall, редиректы, автообновление и проверка mixed content.
Нужен ли порт 80 для Let’s Encrypt?
Да, если используется HTTP-01 challenge. В этом сценарии Let’s Encrypt обращается к домену по HTTP и проверяет специальный файл на сервере. Для этого порт 80 должен быть доступен снаружи.
После установки SSL порт 80 обычно не закрывают, а используют для редиректа с HTTP на HTTPS. Если закрыть его без понимания схемы, можно сломать выпуск или продление сертификата.
Чем HTTP challenge отличается от DNS challenge?
HTTP challenge проверяет контроль над доменом через веб-сервер. Let’s Encrypt обращается к сайту по HTTP и проверяет, может ли сервер отдать нужный проверочный файл.
DNS challenge проверяет контроль над DNS-зоной. Для этого нужно добавить специальную TXT-запись в DNS. Такой способ подходит для wildcard-сертификатов и для ситуаций, когда веб-сервер не должен быть доступен из интернета напрямую.
Проще говоря: HTTP challenge проверяет сайт через порт 80, а DNS challenge проверяет домен через DNS-запись.
Когда нужен wildcard-сертификат?
Wildcard-сертификат нужен, если нужно защитить много поддоменов одного уровня. Например, *.example.com подойдёт для app.example.com, api.example.com, dev.example.com и других похожих поддоменов.
Но он не покрывает основной домен автоматически. Если нужно защитить и example.com, и все поддомены, обычно указывают оба имени: example.com и *.example.com.
Let’s Encrypt выпускает wildcard-сертификаты, но для них требуется DNS-01 challenge.
Почему сайт всё равно показывает “Not secure” после установки SSL?
Причин может быть несколько. Сертификат мог быть выпущен не для того домена, сайт может открываться через www, а сертификат быть только для non-www, или браузер может видеть mixed content.
Mixed content появляется, когда страница открывается по HTTPS, но часть ресурсов загружается по HTTP: изображения, стили, скрипты, шрифты, iframe или API-запросы.
Также стоит проверить редиректы, кэш браузера, CDN, настройки CMS и то, какой сертификат реально отдаёт веб-сервер.
Как проверить автообновление Certbot?
Для проверки используется команда: sudo certbot renew --dry-run
Она имитирует продление сертификата и показывает, сможет ли Certbot пройти обновление без реальной замены рабочего сертификата. В официальных инструкциях Certbot эта команда используется именно для теста автоматического обновления.
Также можно проверить systemd timer: systemctl list-timers | grep certbot
Если dry-run проходит успешно, автообновление настроено корректно. Если появляется ошибка, её нужно исправить до истечения сертификата.
Можно ли использовать Let’s Encrypt для нескольких доменов на одном VPS?
Да. На одном VPS можно использовать Let’s Encrypt для нескольких доменов и сайтов. Каждый домен должен указывать на этот VPS, а веб-сервер должен правильно обслуживать соответствующий virtual host или server block.
Например, для одного сайта можно выпустить сертификат сразу для двух имён: sudo certbot --nginx -d example.com -d www.example.com
Потенциально в один сертификат может быть включено до 100 дополнительных имён.
Для другого сайта на том же VPS можно выпустить отдельный сертификат. Главное — не путать домены, конфиги веб-сервера и пути к сертификатам.
Список источников
1. Let’s Encrypt — Getting Started
