Власний домен завис на перевірці SSL

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

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

Спочатку: що саме робить перевірка

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

• HTTP-01 — CA надсилає запит до http://your-domain/.well-known/acme-challenge/<token> і очікує певний рядок. Для цього звичайні HTTP-запити до вашого домену мають доходити до платформи.
• DNS-01 — CA шукає TXT-запис. Для цього запис має існувати й бути видимим резолверу CA, а це не обов’язково той самий резолвер, який використовували ви.

Майже завжди перевірці заважає щось, що стоїть між CA та одним із цих двох ресурсів.

Причина 1: проксі перед challenge

Це найпоширеніша причина, коли домен працює за CDN, і вона справді може збивати з пантелику, адже проксі зазвичай встановлюють саме навмисно.

Якщо ваш DNS-запис проходить через проксі, а не вказує безпосередньо на платформу, HTTP-01-запит CA завершується на проксі. Проксі використовує власний сертифікат, застосовує власні правила й може повернути редирект, сторінку перевірки або 404 — але жодна з цих відповідей не містить токена, на який очікує CA.

Виправлення — пропустити challenge:

• Вимкніть проксі (перемкніть запис у режим сірого хмарного значка) до випуску сертифіката, а потім увімкніть його знову.
• Або виключіть /.well-known/acme-challenge/* з усіх правил редиректів і контролю доступу.

Проблема в тому, що захисти на кшталт "Always Use HTTPS" і "Under Attack" ламають HTTP-01, хоча у вашому браузері сайт виглядає повністю справним.

Причина 2: неправильний тип запису

За більшість решти випадків відповідають дві помилки:

A-запис указує на адресу, яка змінюється. Якщо платформа надала вам hostname, використовуйте CNAME. Копіювання поточної IP-адреси в A-запис працює лише доти, доки адреса не зміниться.

CNAME на вершині зони. example.com не може коректно містити CNAME разом із записами SOA та NS. Деякі провайдери пропонують ALIAS, ANAME або "CNAME flattening" як обхідне рішення, а деякі — ні. Якщо ваш провайдер цього не підтримує, використовуйте субдомен — app.example.com — і налаштуйте редирект із домену верхнього рівня.

# What the world actually sees, not what your dashboard shows
dig +short app.example.com CNAME
dig +short app.example.com A

Якщо обидві команди повертають порожній результат, решту пунктів поки що перевіряти немає сенсу.

Причина 3: ви не вимірюєте пропагацію

dig без аргументів звертається до вашого резолвера, який міг закешувати щойно створену відповідь — або, що ще гірше, закешувати NXDOMAIN, отриманий до створення запису. Негативний запис у кеші з довгим TTL — цілком поширена причина, через яку перевірка не проходить протягом години, а потім раптово успішно завершується без жодного втручання.

Надішліть запити безпосередньо до авторитетних серверів і до публічного резолвера, щоб побачити, що, найімовірніше, побачить CA:

# Ask the zone's own nameservers
dig +short app.example.com @$(dig +short NS example.com | head -1)

# Ask a resolver outside your network
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8

Якщо авторитетна відповідь правильна, а публічні резолвери повертають неправильну, залишається лише чекати завершення TTL — виправляти тут нічого.

Причина 4: CAA відхиляє видавця

Ця причина трапляється рідко, непомітна під час звичайних DNS-перевірок і проявляється повністю безшумно.

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

dig +short example.com CAA
dig +short app.example.com CAA

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

Порядок, який допоможе знайти проблему найшвидше

1. Виконайте dig для запису через публічний резолвер. Немає відповіді — запис неправильний або ще не поширився, зупиніться на цьому кроці.
2. Перевірте, чи проходить запис через проксі. Якщо так, вимкніть проксі або виключіть ACME-шлях.
3. Перевірте CAA і для домену верхнього рівня, і для субдомену.
4. І лише після цього припускайте, що проблема на боці платформи.

Дев’яносто відсотків перевірок, які зависли, завершуються на кроці 1 або кроці 2.

Як це працює в Dockup

Два архітектурні рішення усувають більшість невизначеності.

DNS-запис створюється автоматично. Якщо ваша зона розміщена в Cloudflare і ви підключили обліковий запис, додавання домену одразу створює запис, а не змушує вас вручну копіювати значення:

dockup domain add app.example.com my-project/my-api --port 3000 --cloudflare

Це усуває весь клас помилок із друкуванням і типом запису — платформа знає, чи потрібен їй CNAME, чи A-запис, і створює правильний.

Доступ надається через два дозволи. Zone:Read і DNS:Edit, і нічого більше. Dockup не може читати інші ваші зони, змінювати налаштування облікового запису або працювати з будь-чим, до чого ви не надали доступ. Підключення автоматизації DNS не має вимагати передачі всього облікового запису.

Стан перевірки та сертифіката відображається окремо для кожного домену, а не як один загальний статус. Тому повідомлення "DNS підтверджено, але TLS очікує" відображає реальний стан — це два окремі кроки, один із яких уже завершено.

Поширені запитання

Скільки має тривати випуск сертифіката? Зазвичай менше хвилини після того, як DNS починає правильно розв’язуватися. Якщо перевірка триває понад п’ятнадцять хвилин, найімовірніше, щось її блокує, а не просто працює повільно.

Чому мій домен відкривається в браузері, але не проходить перевірку? Тому що браузер переходить за редиректами й використовує HTTPS, а challenge не робить ні того, ні іншого. Проксі може чудово обслуговувати ваш сайт і водночас перехоплювати звичайний HTTP-запит ACME.

Чи можна використовувати CNAME для кореневого домену? Не в стандартному DNS. Використовуйте функцію провайдера на кшталт ALIAS або CNAME flattening чи налаштуйте редирект із домену верхнього рівня на субдомен.

Що таке CAA-запис і чи потрібен він мені? Він обмежує перелік центрів сертифікації, яким дозволено випускати сертифікати для вашого домену. Він необов’язковий, але якщо такий запис є й у ньому немає CA вашої платформи, випуск завершується безшумною помилкою.