Выдать сертификат — одна команда. Инструментов, которые её выполняют, десяток, и все они работают. Поэтому статья про первичную выдачу бесполезна: с ней справится любая шпаргалка.
Ломается другое, и ломается предсказуемо: на третий месяц. Сертификат бесплатного удостоверяющего центра живёт недолго — на момент написания это 90 дней, актуальный срок проверяйте у самого центра, — и продлевается автоматически. Ровно до того дня, когда что-то в этой автоматике меняется, а вы этого не замечаете, потому что она была настроена и забыта.
Ниже — про продление, про диагностику уже просроченного сертификата и про одну проверку, которая делает всю эту статью почти ненужной.
#Что понадобится
- Домен, чьи записи указывают на ваш сервер. Если домен только что перенаправлен — подождите распространения; типовые ошибки на этом шаге разобраны в гайде про настройку DNS без боли.
- Открытый снаружи порт 80 (для проверки через HTTP) или доступ к API вашего DNS-провайдера (для проверки через DNS).
- Права на установку системного таймера или задачи расписания.
#Шаг 1. Выбрать способ подтверждения — от этого зависит всё продление
Удостоверяющему центру нужно убедиться, что домен ваш. Способов подтверждения два, и выбор между ними определяет, как именно у вас потом сломается продление.
| Через HTTP | Через DNS | |
|---|---|---|
| Что требуется | открытый порт 80 | токен к API DNS-провайдера |
| Подстановочные сертификаты | ✗ | ✓ |
| Работает за туннелем | часто ✗ | ✓ |
| Что ломает продление | закрылся порт, изменился маршрут | протух или сменился токен |
| Требует остановки веб-сервера | иногда | никогда |
Практическое правило: если порт 80 у вас открыт и останется открытым — берите HTTP-подтверждение, оно проще и не требует секретов. Если сервис живёт за туннелем, за NAT или вам нужен сертификат на все поддомены сразу — DNS, и тогда сразу заведите себе напоминание про срок жизни токена.
#Шаг 2. Выдать сертификат
Вариант с автоматикой внутри веб-сервера — самый надёжный, потому что там нечему рассинхронизироваться. Caddy получает и продлевает сертификат сам, без единой строки конфигурации сверх имени домена.
Отдельным инструментом (пример для nginx):
# HTTP-подтверждение, nginx правится автоматически
sudo certbot --nginx -d example.com -d www.example.com
# то же, но без правки конфигурации: только получить файлы
sudo certbot certonly --webroot -w /var/www/html -d example.com
Куда лягут файлы и как их подключить к прокси — в гайде про обратный прокси перед ИИ-сервисом. Там же важная строка X-Forwarded-Proto: без неё приложение за прокси считает, что работает по обычному HTTP, и не выставляет заголовок принудительного HTTPS.
#Шаг 3. Настроить продление и — главное — проверить его
Продление в большинстве установок настраивается само: пакет ставит системный таймер или задачу. Проблема в том, что «настроено» и «работает» — разные утверждения.
# 1. таймер существует и запланирован
systemctl list-timers | grep -i certbot
# 2. СУХОЙ ПРОГОН — главная команда этой статьи
sudo certbot renew --dry-run
Сухой прогон делает всё то же, что настоящее продление, но обращается к тестовому окружению центра. Он ловит именно то, что ломается на третий месяц: закрывшийся порт, изменившийся корень сайта, протухший токен, конфликт с веб-сервером.
Делайте сухой прогон не один раз при настройке, а после каждого изменения инфраструктуры — смены прокси, переезда, правки правил межсетевого экрана.
Хуки — вторая частая точка отказа. Продление обновляет файлы, но веб-сервер продолжает держать в памяти старый сертификат, пока его не перезагрузят:
sudo certbot renew --deploy-hook "systemctl reload nginx"
Симптом отсутствующего хука очень характерный: сертификат на диске свежий, а браузер показывает просроченный. Ищут при этом, естественно, в удостоверяющем центре.
#Шаг 4. Поставить проверку срока в мониторинг
Это тот случай, когда одна строка отменяет весь класс происшествий.
# сколько дней осталось
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -enddate
Проверка ходит снаружи, по сети, а не смотрит файл на диске. Разница принципиальная: файл может быть свежим, а отдаваться при этом старый — тот самый случай с забытой перезагрузкой сервера.
Порог тревоги — 14 дней. Этого хватает, чтобы разобраться без спешки, и достаточно поздно, чтобы не шуметь зря. Куда встроить эту и остальные проверки — в статье про мониторинг личного сервиса.
#Проверка результата
# 1. цепочка и срок
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
# 2. отдаётся ли полная цепочка (не только конечный сертификат)
echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null \
| grep -c 'BEGIN CERTIFICATE' # должно быть больше одного
# 3. обычный HTTP перенаправляет на HTTPS
curl -sI http://example.com/ | head -1
# 4. сухой прогон продления проходит
sudo certbot renew --dry-run
Критерий приёмки — все четыре пункта, а не первый. Пункт 2 проваливают чаще всего: браузер настольного компьютера умеет достраивать цепочку сам и покажет зелёный замок, а мобильное приложение или клиентская библиотека на том же сертификате получат ошибку доверия. Симптом при этом выглядит как «на компьютере работает, на телефоне нет».
#Что может пойти не так
Сертификат на диске новый, браузер видит старый. Не выполнен перезапуск или перезагрузка веб-сервера после продления. Добавьте хук.
Продление не сработало, а вы узнали от пользователя. Проверки срока нет. Это, а не само продление, — настоящая причина происшествия.
Упёрлись в лимит запросов центра. У бесплатных центров есть ограничения на число выдач для одного домена за период. Возникает при отладке циклом «не получилось — попробую ещё раз». Отлаживайтесь в тестовом окружении центра, для этого оно и есть.
Порт 80 закрыт, а подтверждение через HTTP. Частый случай после переезда за туннель или после ужесточения правил межсетевого экрана. Переходите на DNS-подтверждение.
Токен DNS-провайдера истёк. Продление молча падает месяцами. Ловится только проверкой срока сертификата снаружи.
Сервис за туннелем, и сертификат выдаёт туннель. Тогда сертификат не ваш, срок жизни им управляет провайдер туннеля, и половина этой статьи неприменима. Ограничения такой схемы — в разборе туннелей вместо белого IP.
После включения HTTPS часть страниц не грузится. Смешанное содержимое: страница по HTTPS тянет ресурсы по HTTP. Ищите в консоли браузера; заодно это подходящий момент, чтобы заняться политикой безопасности контента.
#Частые вопросы
#Нужен ли платный сертификат?
Для личного сервиса — нет. Бесплатный сертификат от общедоступного удостоверяющего центра шифрует так же и признаётся браузерами так же. Платные отличаются условиями поддержки, страховкой и наличием типов, подтверждающих организацию, — то есть вещами, которые к шифрованию отношения не имеют.
#Что даёт заголовок принудительного HTTPS?
Он запрещает браузеру ходить на ваш домен по обычному HTTP в течение указанного срока. Ставить его стоит только когда HTTPS уже работает стабильно: откатить его нельзя — браузер запомнил, и до истечения срока пользователь не сможет открыть сайт по HTTP, даже если у вас всё сломалось.
#Можно ли выпустить сертификат на локальный адрес?
Публичный удостоверяющий центр — нет, ему нужен домен, который он может проверить. Для локальной сети используют собственный внутренний центр и добавляют его в доверенные на своих устройствах. Это отдельная работа, и для сервиса, доступного снаружи, она не нужна.
#Как быть с сертификатом при переезде на другой сервер?
Проще выпустить новый, чем переносить. Порядок: направить записи домена на новый сервер, дождаться распространения, выпустить сертификат там, проверить, и только потом гасить старый.
#Что делать прямо сейчас, если сертификат уже просрочен?
По порядку: продлить принудительно; убедиться, что веб-сервер перезагружен; проверить снаружи, что отдаётся новый; и только затем выяснять, почему не сработала автоматика. Восстановление доступности — раньше расследования.
#Куда HTTPS встраивается в общую картину?
Это четвёртый этап из шести в маршруте о том, как поднять свой ИИ-сервис: после домена, до прокси и эксплуатации. Каждый следующий этап предполагает, что предыдущий не отвалится сам по себе через три месяца.