Wildcard-сертификат

nab0y · 30.Июнь.2025 07:29:05

Люди добрые расскажите с картинками или снимите видео как в NPM получить wildcard сертификат, ну тот который со звездочкой? Я знаю что так можно, но руки не дошли.

admin · 01.Июль.2025 10:11:10

Особенность выпуска *.domain.ru wildcard через NPM в том, что нужно использовать при его выпуске DNS челендж.
И тут токность в том, что NPM должен поддерживать интеграцию c доменным регистратром, который вы используете.

Процедура ни чем не отличается от того, что мы делали для получения сертификата через днс челендж у duckdns

А тем, у кого с английским нормально - вот ролик Christian Lempa через CF выпускает

PS
не смотря на наличие reg.ru в списке, я последний раз трогал года полтора назад - не работало, разбираться не стал, мне wild был не критичен.

KRom · 01.Июль.2025 13:22:15

Добавлю свои 2 копейки:

Для неподдерживаемых регистраторов я поднял AcmeDNS и уже через эту штуку делал автообновление LE сертификатов. Есть и не self hosted решение, там еще проще

nab0y · 01.Июль.2025 15:15:49

Я сделаль!!!

Рассказываю про reg.ru
Идем в Настройки → Настройки API

И там прописываем пароль API, можно не прописывать, а ходить своим логином и паролем от reg.ru, но мне ссыкотно, поэтому я прописал. Пароль пишем длинный и складываем в менеджер паролей.
Так же прописываем IP адрес с которого придет certbot в нашем случает Nginx Proxy Manager, я указал свой белый IP

В NPM дальше все по инструкциям что выше, выбираем из списка reg.ru, логин - ежу понятно от админки, а пароль тот который установили в настройках API

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

Спасибо, всем причастным.

admin · 01.Июль.2025 16:10:01

Круто! спасибо, что поделился.
Другим будет полезно.

Snipset · 03.Июль.2025 11:51:23

Я для себя пришел к решению выпуска и перевыпуска сертификатов через acme, выше уже упоминали как раз)
Он и для классического веб-сервера удобен и для случаев когда запрос сертификата происходит на одном сервере, а его фактическое использование на другом (как раз мой случай), еще умеет работать с api популярных хостеров для dns челленджа
Список API
При желании можно и телеграм бота прикрутить.

qazard · 21.Октябрь.2025 18:54:43

Может видео или пост сделать как работать с [AcmeDNS] или [Аcme] для локального использования, и когда есть свое доменное имя. Я с reg.ru запыхался. Вроде и TXT записи к домену подтянулись, а сертификат никак не получается выпустить

qazard · 21.Октябрь.2025 19:09:24

Получилось выпустить по инструкции (ниже ссылка) для reg.ru доменного имени:

./acme.sh --set-default-ca --server letsencrypt
./acme.sh --issue --dns dns_regru -d example.com -d *.example.com --debug

–debug добавил чтобы видеть что происходит. Минут 20 прошло, пока получил сертификаты

Amofess · 27.Октябрь.2025 01:38:39

А как быть, если у меня серый IP (у меня интернет мобильный)?

KRom · 27.Октябрь.2025 06:14:17

Для reg.ru или получения wildcard сертификата?

Для reg.ru либо

Открыть доступ из всей сети провайдера
Проксировать запросы через какой-то внешний сервер со статическим IP
Использовать промежуточный сервис acme-dns

Для wildcard сертификатов http challenge нельзя использовать, только dns challenge, а это значит, что IP адрес конечного получателя сертификата значения не имеет

Amofess · 29.Октябрь.2025 02:49:14

Ситуация у меня такая: сижу на мобильном интернет и, в силу этого, все входящие порты закрыты + мой IP-адрес постоянно меняется.
Пробовал получить wildcard сертификат у Beget при помощи Nginx Proxy Manager, но проблемма в закрытом 443-порту(

KRom · 29.Октябрь.2025 06:35:55

Так, еще раз

wildcard сертификаты получаются только правкой dns записей, никаких обращений к сайту не происходит
при стандартной проверке через https challenge используется обращение на 80. а не 443 порт (читал, что в тестовом режиме вводится 443, но там надо сначала указывать временный сертификат
Если 80 порт закрыт, то либо запрашивается не wildcard сертификат, либо не настроена валидация через файлы на сайте
если таки 443, то может нет доступа к регистратору?

Amofess · 30.Октябрь.2025 14:08:50

так у меня все входящие порты закрыты(

KRom · 30.Октябрь.2025 15:18:48

Подробные шаги (пошагово)

Запрос сертификата (Order)

Ваш ACME-клиент (например, certbot, acme.sh, lego, win-acme) создаёт Order у Let’s Encrypt, указывая имя(я) домена(ов) (например example.com, *.example.com).
В ответ CA возвращает список challenge-ов для каждого домена; для DNS-01 CA просит доказать владение через TXT-запись.

Клиент получает параметры challenge

Для DNS-01 CA обычно даёт token (challenge token) и / или keyAuthorization (в зависимости от протокола).
Клиент вычисляет значение TXT-записи, которое нужно опубликовать. Формула (обобщённо):
- value = base64url( SHA256( keyAuthorization ) ) — ACME-клиент делает это сам, вам обычно приходит уже готовое значение.

Публикация TXT-записи в DNS

Запись должна иметь имя:
_acme-challenge.example.com (если проверяется example.com)
Для сабдоменов аналогично: _acme-challenge.sub.example.com.
Значение записи — вычисленный token (строка).
Способы публикации:
- Автоматически через API провайдера DNS (рекомендуется для автоматизации и renew). Большинство клиентов имеют плагины: certbot-dns-cloudflare, certbot-dns-route53, acme.sh --dns dns_cf, lego --dns.
- Вручную: вставить запись в веб-интерфейс провайдера (подходит только для разовых/ручных выписок).

Ожидание репликации (propagation)

CA начнёт проверку только после того как TXT-запись доступна в публичной DNS-системе.
Если автоматизированный клиент — обычно делает проверку сам через DNS-lookup; при ручной работе может потребоваться подождать — зависит от TTL и кэширования. Многие клиенты умеют делать несколько проверок/паузы.

Проверка от Let’s Encrypt (validation)

Let’s Encrypt делает DNS lookup для _acme-challenge.example.com и сравнивает значение с ожидаемым.
Если значения совпадают — challenge считается valid.

Финализация заказа и выдача сертификата

После прохождения всех необходимых challenge-ов клиент отправляет CSR (Certificate Signing Request) или ключи, и CA формально finalize—итоговый шаг.
CA выдаёт сертификат (PEM), который клиент загружает и устанавливает на сервер (web server, reverse proxy и т. п.).

Cleanup

Клиент удаляет TXT-запись (если делал автоматически) — хорошая практика.
Сертификат ставится и настраивается; клиент обычно обновляет записи о сроке жизни (renewal schedule).

Примеры команд (практика)

Certbot — автоматический DNS плагин (пример Cloudflare)
(примерный — для Cloudflare нужно установить certbot-dns-cloudflare и создать credentials файл)

# файл /etc/letsencrypt/cloudflare.ini
dns_cloudflare_email = user@example.com
dns_cloudflare_api_token = 0123456789abcdef

# команда
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d example.com -d '*.example.com' \
  --preferred-challenges dns-01 \
  --non-interactive --agree-tos -m admin@example.com

acme.sh — пример для Cloudflare

export CF_Token="0123456789abcdef"
export CF_Account_ID="..."   # иногда требуется
acme.sh --issue --dns dns_cf -d example.com -d '*.example.com' --keylength 4096

certbot — ручной (manual) способ

certbot certonly --manual --preferred-challenges dns \
  -d example.com -d www.example.com
# certbot выдаст строку, которую нужно поместить в _acme-challenge.*

Пример того, что увидите (TXT-запись)

Имя: _acme-challenge.example.com
Тип: TXT
Значение: X1a2B3cD... (строка, сгенерированная ACME-клиентом)

Особые случаи и пояснения

Wildcard сертификаты (*.example.com) требуют именно DNS-01. HTTP-01 не подходит для wildcard.
TTL и propagation. Если ваш DNS провайдер кэширует записи с большим TTL или использует CDN/Anycast, иногда нужно подождать; при автоматизации лучше уменьшать TTL заранее (например 60–300s) перед выпуском.
API vs ручная публикация. Для автоматического продления (renew) необходимо API провайдера. Ручной метод потребует вмешательства при каждом renew.
Rate limits Let’s Encrypt. Есть ограничения на количество запросов/ошибок; при отладке учитывайте их.
Безопасность API-ключей. Храните креды для DNS-API в защищённом файле с правами 600 и в переменных окружения/секретах CI.
Проблемы с проверкой: проверьте, что запись доступна публично (use dig или nslookup):

dig TXT _acme-challenge.example.com +short

Ответ должен содержать ваш token.

Типичные причины ошибок и как их решать

Ошибка: TXT запись не найдена — проверьте имя записи (включая точку в конце зоны), подождите репликацию, проверьте DNS-кэш/используйте dig к разным рекурсивным серверам.
Ошибка: несоответствие значения — возможно, записали неправильное значение (старый токен) или запись содержит кавычки/лишние пробелы.
Проблемы с API: неверные права токена, двухфакторная аутентификация, IP-блокировка API.
Wildcard и поддомены: не добавляйте _acme-challenge.www.example.com для домена example.com — правило всегда такое: challenge имя — _acme-challenge.<зона, для которой выписываете>.