Персонализираният домейн е блокиран при SSL валидация

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

Причините са четири, всички са механични, а редът по-долу ще ви помогне да ги откриете най-бързо.

Първо: какво всъщност прави валидацията

Преди сертифициращ орган да издаде сертификат, той трябва да установи, че контролирате името. Има два често използвани начина и кой от тях използва платформата ви определя какво може да се обърка:

• HTTP-01 — CA изпраща заявка към http://your-domain/.well-known/acme-challenge/<token> и очаква конкретен низ. Това изисква обикновените HTTP заявки към домейна ви да достигат до платформата.
• DNS-01 — CA търси TXT запис. Това изисква записът да съществува и да е видим за resolver-а на CA, който не е задължително същият, който сте заявили вие.

Почти всеки случай на блокирала валидация се дължи на нещо, което стои между CA и една от тези две проверки.

Причина 1: proxy пред challenge-а

Това е най-честата причина, когато домейнът е зад CDN, и е наистина объркващо, защото proxy-то обикновено е точно нещото, което сте искали.

Ако DNS записът ви минава през proxy, вместо да сочи директно към платформата, HTTP-01 заявката на CA приключва в proxy-то. То предоставя собствения си сертификат, прилага собствените си правила и може да върне redirect, challenge страница или 404 — нито едно от тях не съдържа token-а, който CA очаква.

Решението е да пропуснете challenge-а:

• Изключете proxy-то (grey-cloud на записа), докато сертификатът бъде издаден, след което го включете отново.
• Или изключете /.well-known/acme-challenge/* от всички redirect или access правила.

Проблемът е, че защити от типа „Always Use HTTPS“ и „Under Attack“ нарушават HTTP-01, въпреки че от гледна точка на браузъра ви сайтът работи напълно нормално.

Причина 2: грешният тип запис

Две грешки обясняват повечето от останалите случаи:

A запис, сочещ към адрес, който се променя. Ако платформата ви е дала hostname, използвайте CNAME. Копирането на текущия IP адрес в A запис работи само докато адресът не се промени.

CNAME на zone apex. example.com не може съгласно DNS стандарта да съдържа CNAME едновременно със своите SOA и NS записи. Някои доставчици предлагат ALIAS, ANAME или „CNAME flattening“ като решение; други не предлагат такава възможност. Ако вашият доставчик не я предлага, използвайте subdomain — app.example.com — и направете redirect от apex домейна.

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

Ако и двете команди върнат празен резултат, нищо друго в този списък все още няма значение.

Причина 3: propagation, който не измервате

dig без аргументи отправя заявка към вашия resolver, който може да е кеширал отговора, който току-що сте създали — или, още по-лошо, да е кеширал NXDOMAIN от времето преди да създадете записа. Отрицателен кеширан запис с дълъг TTL е наистина честа причина за валидация, която се проваля в продължение на час, а след това успява без никаква намеса.

Заявявайте директно към authoritative сървърите и към публичен resolver, за да видите какво най-вероятно ще види 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

Ако authoritative отговорът е правилен, а публичните resolver-и връщат грешни данни, просто чакате TTL и няма какво да поправяте.

Причина 4: CAA отказва издателя

Това е рядка причина, невидима при обичайни DNS проверки и напълно безшумна, когато се прояви.

CAA записът за домейна ви определя кои сертифициращи органи могат да издават сертификати за него. Ако имате такъв запис — често наследен от стара конфигурация или добавен по препоръка на security scan — и той не включва CA, който използва платформата ви, издаването се проваля. Единственото място, където това се посочва, са log-овете на CA, до които нямате достъп.

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

Празният резултат означава, че няма ограничение, което е нормално. Ако получите записи, добавете CA, който използва платформата ви, или премахнете ограничението.

Редът, в който ще откриете проблема най-бързо

1. Изпълнете dig за записа чрез публичен resolver. Ако няма отговор, записът е грешен или все още не е propagated — спрете дотук.
2. Проверете дали записът минава през proxy. Ако е така, изключете proxy-то или изключете ACME path-а от правилата.
3. Проверете CAA както на apex домейна, така и на subdomain-а.
4. Едва след това приемете, че проблемът е в платформата.

Деветдесет процента от блокираните валидации приключват на стъпка 1 или стъпка 2.

Как работи това в Dockup

Два дизайнерски избора премахват повечето догадки.

DNS записът се създава автоматично. Ако zone-ът ви е в Cloudflare и сте свързали акаунта си, добавянето на домейн записва самия запис, вместо да ви кара да копирате стойност ръчно:

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

Това премахва целия клас грешки, свързани с typo и грешен тип запис — платформата знае дали е необходим CNAME или A запис и създава правилния.

Достъпът се предоставя чрез две permissions. Zone:Read и DNS:Edit, и нищо повече. Dockup не може да чете другите ви zone-ове, да променя настройките на акаунта или да докосва нещо, за което не е получил достъп. Свързването на DNS automation не би трябвало да изисква предоставяне на целия акаунт.

Статусът на валидацията и сертификата се вижда за всеки домейн поотделно, вместо като един общ статус. Така „DNS е потвърден, но TLS е в изчакване“ означава точно това — две отделни стъпки, едната от които е приключила.

Често задавани въпроси

Колко време трябва да отнеме издаването на сертификат? Обикновено под минута, след като DNS резолвира правилно. Ако статусът е в изчакване повече от около петнадесет минути, нещо го блокира, вместо просто да работи бавно.

Защо домейнът ми работи в браузъра, но валидацията се проваля? Защото браузърът следва redirect-и и използва HTTPS, а challenge-ът не прави нито едното, нито другото. Proxy, което предоставя сайта ви без проблеми, все пак може да погълне обикновената HTTP ACME заявка.

Мога ли да използвам CNAME за root домейна си? Не при стандартен DNS. Използвайте функционалност на доставчика като ALIAS или CNAME flattening, или насочете apex домейна към subdomain с redirect.

Какво представлява CAA записът и нужен ли ми е? Той ограничава кои сертифициращи органи могат да издават сертификати за домейна ви. Не е задължително да имате такъв запис, но ако съществува и не включва CA на платформата ви, издаването се проваля без видима грешка.