Domeniul personalizat a rămas blocat la validarea SSL

Ai adăugat înregistrarea. dig o afișează. Platforma încă arată că este în așteptare și face asta de o oră. Un domeniu personalizat blocat la validare este frustrant tocmai pentru că toate verificările pe care le poți face singur par să treacă.

Există patru cauze, toate de natură mecanică, iar ordinea de mai jos te ajută să le găsești cel mai rapid.

Mai întâi: ce face de fapt validarea

Înainte ca o autoritate de certificare să emită un certificat, trebuie să stabilească faptul că deții controlul asupra numelui. Există două metode uzuale, iar metoda folosită de platforma ta schimbă lucrurile care pot cauza probleme:

• HTTP-01 — CA solicită http://your-domain/.well-known/acme-challenge/<token> și așteaptă un anumit șir de caractere. Este necesar ca solicitările HTTP simple către domeniul tău să ajungă la platformă.
• DNS-01 — CA caută o înregistrare TXT. Este necesar ca înregistrarea să existe și să fie vizibilă pentru resolverul CA, care nu este neapărat cel interogat de tine.

Aproape orice validare blocată se datorează unui element aflat între CA și unul dintre aceste două lucruri.

Cauza 1: un proxy în fața challenge-ului

Aceasta este cea mai frecventă cauză atunci când domeniul se află în spatele unui CDN și este cu adevărat derutantă, deoarece proxy-ul este, de obicei, exact ceea ce ți-ai dorit.

Dacă înregistrarea DNS este proxied în loc să indice direct către platformă, solicitarea HTTP-01 a CA ajunge la proxy. Proxy-ul își folosește propriul certificat, aplică propriile reguli și poate returna o redirecționare, o pagină de challenge sau un 404 — niciuna dintre acestea nu conține tokenul pe care îl așteaptă CA.

Soluția este să lași challenge-ul să treacă:

• Dezactivează proxy-ul (activează „grey cloud” pentru înregistrare) până la emiterea certificatului, apoi reactivează-l.
• Sau exclude /.well-known/acme-challenge/* din orice regulă de redirecționare sau de control al accesului.

Capcana este că protecții precum „Always Use HTTPS” și cele de tip „Under Attack” întrerup ambele HTTP-01, deși, din browser, site-ul pare să funcționeze perfect.

Cauza 2: tipul greșit de înregistrare

Două greșeli explică majoritatea cazurilor rămase:

O înregistrare A care indică spre o adresă schimbătoare. Dacă platforma ți-a oferit un hostname, folosește un CNAME. Copierea IP-ului curent într-o înregistrare A funcționează până când adresa se schimbă fără să observi.

Un CNAME la apex-ul zonei. example.com nu poate conține legal un CNAME împreună cu înregistrările SOA și NS. Unii furnizori oferă ALIAS, ANAME sau „CNAME flattening” pentru a evita această limitare; alții nu. Dacă furnizorul tău nu oferă această opțiune, folosește un subdomeniu — app.example.com — și redirecționează apex-ul.

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

Dacă ambele comenzi returnează un rezultat gol, nimic altceva din această listă nu contează încă.

Cauza 3: propagarea pe care nu o măsori

dig fără argumente interoghează resolverul tău, care este posibil să fi memorat în cache răspunsul pe care tocmai l-ai creat — sau, mai rău, să fi memorat în cache răspunsul NXDOMAIN de dinainte să-l creezi. O intrare negativă în cache cu un TTL lung este un motiv foarte frecvent pentru care o validare eșuează timp de o oră, apoi reușește fără nicio intervenție.

Interoghează direct serverele autoritative și un resolver public pentru a vedea ce este probabil să observe 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

Dacă răspunsul autoritativ este corect, iar resolverele publice returnează informații greșite, aștepți expirarea TTL-ului și nu ai nimic de reparat.

Cauza 4: CAA refuză emitentul

Această cauză este rară, invizibilă în verificările DNS obișnuite și complet silențioasă atunci când apare.

O înregistrare CAA de pe domeniul tău specifică ce autorități de certificare pot emite certificate pentru acesta. Dacă ai o astfel de înregistrare — moștenită adesea dintr-o configurație veche sau adăugată la recomandarea unei scanări de securitate — și nu include CA folosit de platforma ta, emiterea eșuează, iar singurul loc în care apare motivul este în jurnalele CA, la care nu ai acces.

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

Un rezultat gol înseamnă că nu există nicio restricție, ceea ce este în regulă. Dacă primești înregistrări, adaugă CA folosit de platforma ta sau elimină restricția.

Ordinea care te ajută să găsești problema cel mai rapid

1. Folosește dig pentru a verifica înregistrarea printr-un resolver public. Dacă nu există niciun răspuns, înregistrarea este greșită sau nu s-a propagat încă — oprește-te aici.
2. Verifică dacă înregistrarea este proxied. Dacă este, dezactivează proxy-ul sau exclude calea ACME.
3. Verifică CAA atât pentru apex, cât și pentru subdomeniu.
4. Abia apoi ia în calcul că problema este la platformă.

Nouăzeci la sută dintre validările blocate se opresc la pasul 1 sau la pasul 2.

Cum funcționează acest lucru în Dockup

Două alegeri de design elimină cea mai mare parte a incertitudinii.

Înregistrarea DNS este creată pentru tine. Dacă zona ta este pe Cloudflare și ai conectat contul, adăugarea unui domeniu scrie direct înregistrarea, în loc să te lase să copiezi manual o valoare:

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

Astfel elimini întreaga categorie de greșeli de scriere și de tip de înregistrare — platforma știe dacă are nevoie de un CNAME sau de o înregistrare A și o creează pe cea corectă.

Acordarea accesului se bazează pe două permisiuni. Zone:Read și DNS:Edit, nimic altceva. Dockup nu poate citi celelalte zone ale tale, nu poate modifica setările contului și nu poate interveni asupra lucrurilor pentru care nu i-ai acordat acces. Conectarea automatizării DNS nu ar trebui să necesite cedarea unui cont.

Starea verificării și a certificatului este vizibilă pentru fiecare domeniu, nu ca un singur status agregat, astfel încât „DNS verificat, dar TLS în așteptare” exprimă exact situația — doi pași separați, dintre care unul s-a încheiat.

Întrebări frecvente

Cât ar trebui să dureze emiterea certificatului? De obicei, mai puțin de un minut după ce DNS-ul se rezolvă corect. Dacă statusul este în așteptare de peste aproximativ cincisprezece minute, ceva îl blochează, nu este doar lent.

De ce funcționează domeniul în browser, dar validarea eșuează? Pentru că browserul urmează redirecționările și folosește HTTPS, iar challenge-ul nu face niciuna dintre aceste operațiuni. Un proxy care îți servește site-ul perfect poate totuși să înghită solicitarea ACME simplă prin HTTP.

Pot folosi un CNAME pentru domeniul rădăcină? Nu în DNS standard. Folosește o funcție oferită de furnizor, precum ALIAS sau CNAME flattening, sau direcționează apex-ul către un subdomeniu cu ajutorul unei redirecționări.

Ce este o înregistrare CAA și am nevoie de una? Aceasta limitează autoritățile de certificare care pot emite certificate pentru domeniul tău. Nu ai nevoie de una, dar dacă ai o înregistrare care nu include CA al platformei tale, emiterea eșuează în tăcere.