Let's Encrypt Wildcard: автопролонгація сертифіката

Wildcard SSL-сертифікат (*.example.com) покриває всі піддомени одного рівня. Let's Encrypt видає їх безкоштовно, але лише через DNS-верифікацію (не через HTTP). Це вимагає або ручного додавання TXT-запису, або автоматизації через DNS API.

Отримання Wildcard через Certbot (ручний DNS)

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

# Certbot попросить додати TXT-запис:
# _acme-challenge.example.com → "значення"
# Додайте запис у DNS-панелі та натисніть Enter

Автоматизація через Cloudflare API (рекомендовано)

pip install certbot-dns-cloudflare

# Створити файл з API-токеном Cloudflare
mkdir -p /etc/letsencrypt/cloudflare
cat > /etc/letsencrypt/cloudflare/credentials.ini << 'EOF'
dns_cloudflare_api_token = ВАШ_CLOUDFLARE_API_TOKEN
EOF
chmod 600 /etc/letsencrypt/cloudflare/credentials.ini

# Отримати Wildcard сертифікат
certbot certonly   --dns-cloudflare   --dns-cloudflare-credentials /etc/letsencrypt/cloudflare/credentials.ini   -d example.com   -d "*.example.com"   --preferred-challenges dns-01

Налаштування автопролонгації

systemctl status certbot.timer
systemctl list-timers | grep certbot

# Тест пролонгації (без реального оновлення)
certbot renew --dry-run

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

# Перегляд усіх сертифікатів
certbot certificates

acme.sh як альтернатива Certbot

>curl https://get.acme.sh | sh -s email=admin@example.com

export CF_Token="ВАШ_CLOUDFLARE_API_TOKEN"
acme.sh --issue --dns dns_cf -d example.com -d "*.example.com"

acme.sh --install-cert -d example.com   --key-file /etc/ssl/example.com.key   --fullchain-file /etc/ssl/example.com.pem   --reloadcmd "systemctl reload nginx"

Моніторинг закінчення терміну дії сертифікатів

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>&1 | grep "notAfter"
certbot certificates | grep -E "Expiry|Domains"

Часті помилки під час випуску Wildcard

Certbot чи acme.sh: що обрати

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

• На сервері всього 1-2 піддомени — простіше і швидше випустити звичайний SAN-сертифікат на конкретні імена
• DNS домену керується третьою стороною без доступу до API — ручне подовження TXT-запису кожні 90 днів перетворюється на постійну рутину
• Перед origin уже стоїть проксі на кшталт Cloudflare, який термінує TLS для відвідувачів — часто досить Origin-сертифіката між Cloudflare і сервером
• Потрібен EV або OV сертифікат з перевіркою організації — Let's Encrypt видає лише DV-сертифікати

Перевірка автопролонгації

# Логи останніх спроб подовження
journalctl -u certbot.timer --since "7 days ago"

# Свіжість TXT-запису очима зовнішнього DNS
dig TXT _acme-challenge.example.com +short @1.1.1.1

Якщо journalctl показує успішні запуски таймера, а сертифікат не оновився — перевірте історію через certbot certificates і порівняйте дату Expiry із сьогоднішньою. Суміжна тема — SSL і Certbot у Nginx та Origin-сертифікат Cloudflare як альтернатива для сайтів за проксі.

Зберігання API-токена: як не підставити домен

Файл з Cloudflare API-токеном, використаний у прикладах вище, фізично лежить на диску сервера, і його потрібно захищати так само, як приватний ключ сертифіката. Токен з правами Zone:DNS:Edit дозволяє керувати всіма DNS-записами зони — якщо він витече, зловмисник зможе не лише читати записи, а й підміняти їх, включно з MX-записами пошти. Обмежуйте токен конкретною зоною під час створення в панелі Cloudflare, а не випускайте токен з доступом до всіх зон акаунта одразу.

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

Чи працюватиме автопролонгація, якщо wildcard-сертифікат отримано через ручний DNS-виклик, а не через API Cloudflare?

Ні, ручний режим вимагає вручну додавати новий TXT-запис під час кожного продовження, тому автоматичний таймер certbot не зможе пройти перевірку без участі людини. Для справжньої автопролонгації потрібен спосіб, який сам додає і видаляє TXT-запис у DNS, тобто плагін на кшталт dns-cloudflare чи подібний скрипт в acme.sh, а не ручний режим challenge.

Як не потрапити під ліміт запитів Let's Encrypt під час тестування налаштування?

Потрібно тестувати випуск сертифіката з прапорцем staging, який використовує окреме тестове середовище з власними, значно м'якшими обмеженнями і не витрачає ліміт бойових запитів. Перемикатися на справжній (production) випуск варто лише тоді, коли весь процес через staging пройшов без помилок — інакше невдалі спроби на бойовому середовищі швидко впруться в тижневий ліміт.

Чи безпечніше мати окремі сертифікати для кожного піддомену, ніж один wildcard?

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

Чи можна одночасно використовувати Certbot і acme.sh на одному сервері?

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