Niestandardowa domena zatrzymana na etapie walidacji SSL

Dodałeś rekord. dig go pokazuje. Platforma nadal wyświetla status oczekiwania — i robi to już od godziny. Niestandardowa domena zatrzymana na etapie walidacji frustruje właśnie dlatego, że wszystkie sprawdzenia, które możesz wykonać samodzielnie, wydają się przechodzić pomyślnie.

Przyczyny są cztery, wszystkie mają charakter mechaniczny, a kolejność poniżej pozwala znaleźć problem najszybciej.

Po pierwsze: co właściwie robi walidacja

Zanim urząd certyfikacji wystawi certyfikat, musi potwierdzić, że kontrolujesz daną nazwę. Istnieją dwa popularne sposoby, a to, którego używa platforma, wpływa na to, co może pójść nie tak:

• HTTP-01 — CA wysyła żądanie do http://your-domain/.well-known/acme-challenge/<token> i oczekuje określonego ciągu znaków. Wymaga to, aby zwykłe żądania HTTP do Twojej domeny docierały do platformy.
• DNS-01 — CA wyszukuje rekord TXT. Wymaga to, aby rekord istniał i był widoczny dla resolvera CA, który nie musi być tym samym resolverem, którego używasz do zapytania.

Niemal każda zatrzymana walidacja wynika z czegoś, co znajduje się między CA a jednym z tych dwóch elementów.

Przyczyna 1: proxy przed mechanizmem challenge

To najczęstsza przyczyna, gdy domena znajduje się za CDN-em. Jest też naprawdę myląca, ponieważ proxy zwykle jest właśnie tym, czego chciałeś użyć.

Jeśli rekord DNS jest proxowany, zamiast wskazywać bezpośrednio na platformę, żądanie CA w ramach HTTP-01 kończy się na proxy. Proxy serwuje własny certyfikat, stosuje własne reguły i może zwrócić przekierowanie, stronę challenge albo błąd 404 — żadna z tych odpowiedzi nie zawiera tokenu, na który czeka CA.

Rozwiązaniem jest przepuszczenie challenge:

• Wyłącz proxy (ustaw szarą chmurkę przy rekordzie) do czasu wystawienia certyfikatu, a następnie włącz je ponownie.
• Albo wyklucz /.well-known/acme-challenge/* ze wszystkich reguł przekierowań i kontroli dostępu.

Pułapka polega na tym, że zabezpieczenia w stylu „Always Use HTTPS” i „Under Attack” mogą przerwać HTTP-01, mimo że z perspektywy przeglądarki strona działa bez zarzutu.

Przyczyna 2: nieprawidłowy typ rekordu

Za większość pozostałych przypadków odpowiadają dwa błędy:

Rekord A wskazujący na zmieniający się adres. Jeśli platforma podała Ci hostname, użyj CNAME. Skopiowanie bieżącego adresu IP do rekordu A działa tylko do momentu, gdy adres zmieni się bez Twojej wiedzy.

CNAME w apexie strefy. example.com nie może zgodnie ze standardem DNS zawierać rekordu CNAME obok rekordów SOA i NS. Niektórzy dostawcy oferują ALIAS, ANAME albo „CNAME flattening” jako obejście tego ograniczenia, a niektórzy nie. Jeśli Twój dostawca nie oferuje takiej funkcji, użyj subdomeny — app.example.com — i przekieruj na nią apex.

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

Jeśli oba polecenia zwracają pusty wynik, pozostałe punkty z tej listy nie mają jeszcze znaczenia.

Przyczyna 3: propagacja, której nie mierzysz

dig bez argumentów pyta Twój resolver, który mógł zachować w cache odpowiedź dotyczącą właśnie utworzonego rekordu — albo, co gorsza, zbuforować NXDOMAIN z czasu sprzed jego utworzenia. Negatywny wpis w cache z długim TTL-em to naprawdę częsta przyczyna sytuacji, w której walidacja kończy się niepowodzeniem przez godzinę, a następnie przechodzi bez żadnej ingerencji.

Odpytaj bezpośrednio autorytatywne serwery oraz publiczny resolver, aby sprawdzić, co prawdopodobnie zobaczy 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

Jeśli odpowiedź autorytatywna jest prawidłowa, a publiczne resolvery zwracają błędne dane, pozostaje Ci czekać na wygaśnięcie TTL-u — nie ma tu niczego do naprawienia.

Przyczyna 4: CAA odrzuca wystawcę

Ta przyczyna występuje rzadko, jest niewidoczna podczas standardowych kontroli DNS i całkowicie niema, gdy się pojawi.

Rekord CAA w Twojej domenie określa, które urzędy certyfikacji mogą wystawiać dla niej certyfikaty. Jeśli taki rekord istnieje — często został odziedziczony po starej konfiguracji albo dodany na podstawie rekomendacji skanera bezpieczeństwa — i nie obejmuje CA używanego przez platformę, wystawienie certyfikatu kończy się niepowodzeniem. Jedynym miejscem, w którym znajdziesz informację o przyczynie, są logi CA, do których nie masz dostępu.

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

Pusty wynik oznacza brak ograniczeń, co jest prawidłowe. Jeśli otrzymasz rekordy, dodaj CA używany przez platformę albo usuń ograniczenie.

Kolejność, która pozwala znaleźć problem najszybciej

1. Wykonaj dig dla rekordu, korzystając z publicznego resolvera. Brak odpowiedzi oznacza, że rekord jest nieprawidłowy albo jeszcze się nie rozpropagował — na tym etapie zakończ sprawdzanie.
2. Sprawdź, czy rekord jest proxowany. Jeśli tak, wyłącz proxy albo wyklucz ścieżkę ACME.
3. Sprawdź CAA zarówno dla apexu, jak i subdomeny.
4. Dopiero wtedy rozważ, że problem leży po stronie platformy.

Dziewięćdziesiąt procent zatrzymanych walidacji kończy się na kroku 1 albo 2.

Jak działa to w Dockup

Dwa rozwiązania projektowe eliminują większość zgadywania.

Rekord DNS jest tworzony automatycznie. Jeśli Twoja strefa znajduje się w Cloudflare i konto zostało połączone, dodanie domeny zapisuje rekord automatycznie, zamiast zmuszać Cię do ręcznego kopiowania wartości:

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

Eliminuje to całą klasę błędów związanych z literówkami i typem rekordu — platforma wie, czy potrzebuje CNAME, czy rekordu A, i tworzy właściwy rekord.

Integracja wymaga dwóch uprawnień. Zone:Read i DNS:Edit — i niczego więcej. Dockup nie może odczytywać pozostałych stref, zmieniać ustawień konta ani modyfikować czegokolwiek, do czego nie otrzymał dostępu. Automatyzacja DNS nie powinna wymagać przekazania całego konta.

Stan weryfikacji i certyfikatu jest widoczny osobno dla każdej domeny, a nie jako jeden zbiorczy status. Dzięki temu komunikat „DNS zweryfikowany, ale TLS oczekuje” pokazuje sytuację taką, jaka jest — to dwa osobne kroki, z których jeden został zakończony.

Najczęściej zadawane pytania

Ile powinno trwać wystawienie certyfikatu? Zwykle mniej niż minutę, gdy DNS poprawnie rozwiązuje nazwę. Jeśli status oczekiwania utrzymuje się dłużej niż około piętnaście minut, coś blokuje proces — to nie kwestia powolnego działania.

Dlaczego moja domena działa w przeglądarce, ale nie przechodzi walidacji? Ponieważ przeglądarka obsługuje przekierowania i korzysta z HTTPS, a mechanizm challenge nie robi ani jednego, ani drugiego. Proxy, które bez problemu serwuje Twoją stronę, nadal może przechwycić żądanie ACME przez zwykłe HTTP.

Czy mogę użyć CNAME dla domeny głównej? Nie w standardowym DNS. Użyj funkcji dostawcy, takiej jak ALIAS albo CNAME flattening, albo skieruj apex na subdomenę za pomocą przekierowania.

Czym jest rekord CAA i czy go potrzebuję? Ogranicza listę urzędów certyfikacji, które mogą wystawiać certyfikaty dla Twojej domeny. Nie musisz go mieć, ale jeśli istnieje i nie obejmuje CA Twojej platformy, wystawienie certyfikatu zakończy się po cichu niepowodzeniem.