Let’s Encrypt всегда проверял только доменные имена. Однако с развитием микросервисных архитектур, API-взаимодействий и IoT-устройств возникла необходимость защищать трафик серверов, у которых нет домена. 15 января 2026 года стал общедоступным профиль shortlived с 6-дневными сертификатами для «чистых» IP-адресов. Теперь не нужно тратить деньги и время на покупку и регистрацию бесполезных доменных имен.

На Хабре уже есть подробные статьи и руководства на тему настройки HTTPS, выпуска сертификатов и конфигурации веб-серверов, но в большинстве случаев они объясняют, как защитить сайт с доменом. Мы же разберём, как обойтись без него и выпустить официальный доверенный TLS-сертификат прямо на «голый» IPv4-адрес.

В основе TLS лежит двухэтапный процесс, начинающийся с «рукопожатия» (TLS Handshake): стороны согласовывают протоколы, сервер предъявляет сертификат, и с помощью асимметричного шифрования генерируется общий симметричный сессионный ключ. Как только хэндшейк завершён, TLS переходит к защите сессии — все последующие HTTP-запросы и ответы шифруются исключительно этим общим ключом, что гарантирует высокую скорость работы из-за низкой ресурсоемкости симметричных алгоритмов.

Подробнее о нём написано в этой статье.

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

На своём VPS с помощью встроенной утилиты openssl можно одной командой сгенерировать пару ключей. Достаточно заполнить несколько полей об организации, чтобы выпустить приватный ключ и сам сертификат по указанному пути:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/lighttpd/server.key -out /etc/lighttpd/server.crt

Теоретически ограничения у параметра -days на количество дней нет, можно выдать самому себе сертификат хоть на 100 лет, хотя начиная с версии OpenSSL 3.x максимальный срок действия самоподписанного сертификата ограничен 825 днями.

Чаще всего это используется в закрытых корпоративных сетях, на стадиях локальной разработки или в личных админках, куда заходит только сам создатель.

При попытке установить защищённое соединение браузер проверяет цепочку сертификатов сайта на соответствие своему встроенному списку корневых доверенных центров. Поскольку самоподписанный сертификат выпущен и заверен неизвестным центром, браузер не может подтвердить подлинность ресурса. В результате механизм безопасности прерывает TLS-рукопожатие до передачи какого-либо контента и отображает предупреждение с кодом ошибки NET::ERR_CERT_AUTHORITY_INVALID (или аналогом в других браузерах). Доступ к сайту блокируется.

Чтобы это обойти, нужно отметить выпущенный нами сертификат как доверенный. Это делается или в самом браузере, или в операционной системе, тогда сертификатом сможет пользоваться любое приложение на вашем компьютере.

Когда центр сертификации подписывает наш сертификат, браузер видит эту подпись, сверяет её со своим списком доверенных лиц и пускает пользователя на сайт.

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

Главные изменения от Let’s Encrypt:

• Доступность: любой человек в мире может получить доверенный сертификат бесплатно.

• Полная автоматизация: утилита Certbot сама общается с Let’s Encrypt по открытому протоколу ACME.

Для начала выбираем дата-центр RUVDS.

Страница будет простейшей, так что хватит минимальных конфигураций

После того как создали сервер и получили данные для доступа, можно приступать к работе, но, перед тем как разворачивать веб-сервер и генерировать TLS-сертификаты, чистую операционную систему необходимо минимально подготовить.

Для взаимодействия с сервером будем использовать программу PuTTY.

Вводим IP-адрес и подключаемся к 22-му порту (он используется для безопасного удалённого управления, выполнения команд и передачи файлов).

Теперь подключаемся к VPS: пользователь root (главный администратор в UNIX-подобных системах) и пароль.

Первое, что сто́ит сделать на любом новом сервере — обновить список пакетов до последних стабильных версий.

sudo apt update && sudo apt upgrade

Дальше синхронизируем время. Утилита Certbot общается с серверами Let’s Encrypt, которые жёстко контролируют время выпуска и срок действия сертификатов. Если системное время нашего VPS будет сильно рассинхронизировано с реальным временем, Let’s Encrypt прервёт проверку по протоколу ACME и выдаст ошибку.

sudo timedatectl set-timezone Europe/Moscow

Проверяем командой date

И, наконец, настроим файрвол, чтобы случайные боты-сканеры не стучались в наш SSH-порт сразу после его запуска. Оставляем доступными только те порты, что необходимы для работы нашего будущего сайта.

Примечание. Для защиты от ботов в SSH лучше сменить порт со стандартного 22 или использовать Fail2Ban, но самая надёжная защита — это ключи вместо паролей.

В Ubuntu для этого есть очень простой и понятный инструмент — UFW (Uncomplicated Firewall).

По умолчанию он может быть отключён. Последовательно разрешаем три типа трафика:

1. Порт 2222 (SSH) — чтобы мы сами не потеряли доступ к управлению сервером (нужно сначала разрешить новый порт в UFW (sudo ufw allow 2222/tcp), потом поменять порт в /etc/ssh/sshd_config, и только потом перезапустить SSH, чтобы не заблокировать самого себя). Не закрывая текущую сессию, открываем новое окно терминала и пробуем подключиться по порту 2222. Если всё прошло успешно, тогда закрываем старый порт: sudo ufw deny 22/tcp.

2. Порт 80 (HTTP) — для первоначальной проверки Certbot и нашего будущего редиректа.

3. Порт 443 (HTTPS) — для защищённого TLS-трафика. Выполняем команды

sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

После добавления правил активируем файрвол:

sudo ufw enable

Система выдаст предупреждение, что это может прервать текущую SSH-сессию, но мы явно разрешили порт 2222, поэтому нажимаем y и Enter.

Проверить статус портов можно командой sudo ufw status.

Даже если сервер скрыт за файрволом и доступен только по IP-адресу, на него всё равно могут наткнуться поисковые роботы. Чтобы сказать легитимным ботам обходить наш сервер стороной, нужно настроить файл robots.txt.

Для этого переходим по пути cd /var/www/html и создаём файл robots.txt.

cd /var/www/html
sudo nano robots.txt

Далее прописываем в нём:

User-agent: *
Disallow: /

Теперь поисковые системы увидят запрет и не станут тратить ресурсы нашего VPS.

В качестве веб-сервера я выбрал Lighttpd, поскольку он не будет потреблять много ресурсов нашего и без того скромного оборудования.

sudo apt install lighttpd -y
sudo snap install --classic certbot

Загружаем файл-страницу с локального компьютера (команду выполняем на нём).

scp /путь/к/вашему/index.html root@IP-ВАШЕГО-VPS:/var/www/html/

Проверяем, действительно ли он там есть.

Готово, теперь мы можем увидеть нашу страницу по адресу http://IP-ВАШЕГО-VPS, но пока соединение с ней не защищено.

Теперь запускаем команду Certbot, используя профиль shortlived, который позволяет выпустить легитимный сертификат не на домен, а на IPv4-адрес

sudo certbot certonly \
  --preferred-profile shortlived \
  --ip-address IP-ВАШЕГО-VPS \
  --webroot --webroot-path /var/www/html/

Нас попросят ввести почту. Можно пропустить, нажав Enter (хотя это плохая практика, на всякий случай лучше указать почту) и согласиться с условиями пользования.

Сертификаты успешно созданы и лежат в папке /etc/letsencrypt/live/IP-ВАШЕГО-VPS/. Теперь отредактируем конфигурационный файл Lighttpd, чтобы он начал принимать зашифрованные соединения (HTTPS) на порту 443. Открываем файл конфигурации

sudo nano /etc/lighttpd/lighttpd.conf

В server.modules добавляем “mod_openssl”.

server.modules = (
        "mod_indexfile",
        "mod_access",
        "mod_alias",
        "mod_redirect",
        "mod_openssl",
)

И в конец файла добавляем блок:

$SERVER["socket"] == ":443" {
    ssl.engine = "enable"
    ssl.pemfile = "/etc/letsencrypt/live/IP-ВАШЕГО-VPS/fullchain.pem"
    ssl.privkey = "/etc/letsencrypt/live/IP-ВАШЕГО-VPS/privkey.pem"
    ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2")
}

Сохраняем изменения и перезапускаем веб-сервер, чтобы всё заработало:

sudo systemctl restart lighttpd

Готово, теперь наш сайт 191.44.37.174 защищён.

Осталось только настроить cron для автоматизации обновления сертификатов, поскольку они выдаются всего на 6 дней.

Для этого прописываем sudo crontab -e и добавляем в конец следующую строку:

0 */3 * * * certbot renew --quiet --deploy-hook "systemctl restart lighttpd"

Если сейчас открыть современный браузер и ввести в адресную строку наш чистый IP-адрес без каких-либо префиксов, сайт, скорее всего, сразу откроется по защищённому соединению. Дело в том, что современные браузеры по умолчанию используют механизм HTTPS Upgrades. Они сразу пытаются постучаться на безопасный порт 443. И только если сервер там не отвечает, они откатываются на старый порт 80.

Но если явно указать http://, как это могут делать старый мобильный браузер, встроенное веб-вью из какого-нибудь приложения, поисковый бот или консольный скрипт (например, утилиты curl или wget), то они попадут на незащищённую версию.

Чтобы предотвратить загрузку на незащищённый сайт, настроим принудительный редирект на стороне самого веб-сервера. Модуль “mod_redirect” уже подключён в секцию server.modules, теперь добавим логику перенаправления.

Открываем /etc/lighttpd/lighttpd.conf и дополняем его ещё одним условием:

$SERVER["socket"] == ":80" {
    $HTTP["host"] =~ "([0-9.]+)" {
        url.redirect = ( "^/(.*)" => "https://%1/$1" )
    }
}

Как это работает:

• Условие $SERVER["socket"] == ":80" отлавливает все подключения, идущие на незакрытый порт 80.

• Регулярное выражение ~ "([0-9.]+)" изолирует из запроса наш цифровой IP-адрес и сохраняет его в переменную %1.

• Команда url.redirect берёт эту переменную, добавляет к ней хвост из пути запроса ($1) и возвращает клиенту принудительный ответ 301 Moved Permanently (Перемещено навсегда). Получив такой код ответа, браузер запомнит, что по HTTP ходить больше не нужно, и при всех следующих визитах будет переключаться на HTTPS самостоятельно.

Перед применением настроек проверяем конфигурационный файл на синтаксические ошибки:

sudo lighttpd -tt -f /etc/lighttpd/lighttpd.conf

И перезапускаем Lighttpd, чтобы изменения вступили в силу:

sudo systemctl restart lighttpd

Для уверенности, что сайт не сканируют, включим модуль логирования запросов. Чтобы активировать запись всех посещений в реальном времени, выполните команду:

sudo /usr/sbin/lighty-enable-mod accesslog

Затем перезапускаем Lighttpd systemctl restart lighttpd. Теперь все обращения фиксируются в файле /var/log/lighttpd/access.log. Посмотреть на поступающий трафик можно с помощью утилиты tail:

tail -f /var/log/lighttpd/access.log

Появление поддержки IP-адресов в Let’s Encrypt — важный шаг, который делает инфраструктуру интернета безопаснее. Больше не нужно выбирать между самоподписанными сертификатами и покупкой домена-заглушки для бесплатного TLS.

Правда, сертификаты для IP действительны всего 6 дней. Автоматизация через cron и certbot renew — необходимое условие работы сервиса. Тем не менее, это удобное решение для технических узлов и быстрых деплоев HTTPS на IP.

© 2026 ООО «МТ ФИНАНС»