Wildcard SSL через Certbot: сертифікат для всіх субдоменів

Звичайний сертифікат Let's Encrypt видається на конкретний домен. Wildcard-сертифікат (*.yourdomain.com) покриває будь-яку кількість субдоменів — зручно для багатосайтових проєктів.

Встановлення Certbot

sudo apt update && sudo apt install -y certbot python3-certbot-dns-cloudflare

Certbot + Cloudflare DNS (рекомендується)

# Створити API-токен Cloudflare:
# Dashboard → Profile → API Tokens → Create Token
# Permissions: Zone.DNS → Edit

# Зберегти токен
sudo mkdir -p /etc/letsencrypt
sudo nano /etc/letsencrypt/cloudflare.ini

dns_cloudflare_api_token = ВАШ_CLOUDFLARE_TOKEN

sudo chmod 600 /etc/letsencrypt/cloudflare.ini

# Отримати wildcard-сертифікат
sudo certbot certonly   --dns-cloudflare   --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini   -d "yourdomain.com"   -d "*.yourdomain.com"   --agree-tos --non-interactive

Без Cloudflare: ручний DNS challenge

sudo certbot certonly --manual   --preferred-challenges dns   -d "*.yourdomain.com" -d "yourdomain.com"

# Certbot видасть TXT-запис для DNS:
# Додайте: _acme-challenge.yourdomain.com TXT "xxx..."
# Зачекайте 60 сек і натисніть Enter

Підключення до Nginx

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

Автопродовження

sudo certbot renew --dry-run
# Додати в cron:
0 3 * * * certbot renew --quiet --post-hook "systemctl reload nginx"

✅ Wildcard-сертифікат Let's Encrypt видається на 90 днів і автоматично оновлюється через certbot renew.

Розбір типових помилок

Помилка DNS problem: NXDOMAIN looking up TXT record під час ручного DNS challenge означає, що TXT-запис _acme-challenge ще не видно публічним DNS-серверам — або він доданий з опискою, або не минуло достатньо часу на поширення.

Domain: yourdomain.com
Type:   dns
Detail: DNS problem: NXDOMAIN looking up TXT record for _acme-challenge.yourdomain.com

Перевірте запис незалежно від certbot, перш ніж натиснути Enter: dig TXT _acme-challenge.yourdomain.com +short з іншого сервера або через публічний резолвер на кшталт 8.8.8.8. Якщо запис не видно ззовні через кілька хвилин — проблема в самій DNS-панелі, а не в таймінгу.

Помилка Error creating new order :: too many failed authorizations у Let's Encrypt зʼявляється після кількох невдалих спроб поспіль для одного домену і блокує нові спроби на годину. Для налагодження DNS-валідації без витрати денного ліміту використовуйте прапорець --staging, який видає тестові сертифікати без обмежень бойового середовища.

Порівняння DNS-плагінів Certbot

Плагін	Автоматизація	Коли використовувати
dns-cloudflare	Повна, через API-токен	DNS вже на Cloudflare
dns-route53	Повна, через IAM-права	DNS в AWS Route 53
--manual	Немає, ручна вставка TXT-запису	Будь-який DNS-провайдер без готового плагіна

Без API-плагіна автопродовження wildcard-сертифіката не спрацює: certbot не може сам вставити новий TXT-запис при --manual, тому кожні 90 днів доведеться повторювати процес руками, якщо DNS-провайдер не підтримується напряму.

Коли wildcard-сертифікат не потрібен

У вас один-два піддомени, а не десятки — простіше і надійніше випустити звичайний сертифікат на конкретні імена через Certbot з HTTP-валідацією, без вовтузіння з DNS API.
DNS керується через панель без API або через стороннього реєстратора без підтримки в certbot — тоді кожне продовження вимагає ручного втручання, і звичайний сертифікат з автопродовженням через HTTP надійніший.
Піддомени випускаються динамічно під кожного клієнта (SaaS з довільними іменами) — DNS-01 для wildcard не підходить для доменів третього рівня, що створюються на льоту; для цього випадку потрібна окрема автоматизація видачі сертифікатів через ACME API під час реєстрації клієнта.

Перевірка результату

Перевірте, що сертифікат справді wildcard: openssl x509 -in /etc/letsencrypt/live/yourdomain.com/cert.pem -noout -text | grep DNS має показати і yourdomain.com, і *.yourdomain.com.
Відкрийте будь-який випадковий піддомен у браузері, якого раніше не існувало в конфігу Nginx явно, — замок має бути закритим без попереджень.
Перевірте автопродовження сухим прогоном: certbot renew --dry-run має завершитися без помилок DNS-плагіна.
Якщо використовуєте --manual, позначте в календарі дату наступного продовження за тиждень до завершення — автоматика тут не спрацює сама.

Звичайний (не wildcard) випуск і автопродовження сертифіката через Nginx-плагін розібрано в статті про Certbot і Nginx. Якщо сайт стоїть за Cloudflare, спершу погляньте статтю про режими SSL/TLS у Cloudflare — вона впливає на вибір способу валідації.

Спосіб 1: Ручний DNS challenge

sudo certbot certonly   --manual   --preferred-challenges dns   -d "*.example.com"   -d "example.com"

# Certbot попросить додати TXT-запис:
# _acme-challenge.example.com → вказане значення
# 
# Додайте запис у DNS і зачекайте на propagation (1–5 хв)
# Потім натисніть Enter

Спосіб 2: Автоматичний через Cloudflare API

# Створити файл із токеном Cloudflare
sudo nano /etc/letsencrypt/cloudflare.ini
# Вміст:
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN

sudo chmod 600 /etc/letsencrypt/cloudflare.ini

# Отримати сертифікат
sudo certbot certonly   --dns-cloudflare   --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini   -d "*.example.com"   -d "example.com"   --email admin@example.com   --agree-tos   --non-interactive

✅ З Cloudflare API автопродовження працює повністю автоматично — certbot timer у systemd оновить сертифікат за 30 днів до закінчення терміну дії.

Налаштування Nginx з wildcard SSL

server {
    listen 443 ssl http2;
    server_name *.example.com example.com;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

Перевірка та оновлення

# Перевірити сертифікат
sudo certbot certificates

# Тест автооновлення
sudo certbot renew --dry-run

# Примусове оновлення
sudo certbot renew --force-renewal

⚠️ Токен Cloudflare API повинен мати лише дозвіл Zone → DNS → Edit для вашого домену. Не використовуйте Global API Key — він надає повний доступ до акаунта.

Часті питання

Чи можна отримати wildcard-сертифікат через звичайну HTTP-валідацію, без звернення до DNS?

Ні, протокол ACME вимагає саме DNS-валідацію для wildcard-сертифікатів — HTTP-01 challenge підтверджує володіння конкретним іменем через файл на вебсервері, а для довільного піддомену такий файл фізично неможливо розмістити заздалегідь. Тому Certbot під час видачі wildcard-сертифіката завжди запитує TXT-запис у DNS, незалежно від того, автоматизовано процес через API чи виконується вручну.

Чи покриває сертифікат *.domain.com сам голий домен domain.com без піддомену?

Ні, запис wildcard покриває лише піддомени першого рівня і не включає сам голий домен автоматично — його потрібно вказувати окремим іменем під час видачі сертифіката, як показано у прикладах команд certbot із двома прапорцями -d. Якщо забути додати голий домен окремо, браузер показуватиме попередження саме під час заходу без піддомену.

Що станеться, якщо сертифікат спливе, а автопродовження не було налаштоване?

Браузери відвідувачів почнуть показувати попередження про недійсний сертифікат на всіх піддоменах одразу, а не лише на одному сайті — адже один wildcard-сертифікат обслуговує їх усі одночасно. Уникнути цього допомагає саме налаштування автопродовження через DNS API, а за ручного способу дату наступного продовження варто позначити заздалегідь, а не залишати на останній момент.

Чи можна використовувати один і той самий wildcard-сертифікат одразу на кількох серверах?

Так, один і той самий файл сертифіката та приватного ключа можна скопіювати й використовувати на кількох серверах одночасно — обмежень за кількістю машин для одного сертифіката немає. Важливо лише синхронізувати продовження: якщо сертифікат оновлюється на одному сервері, оновлені файли потрібно поширити на решту, інакше частина серверів продовжить віддавати застарілий сертифікат.