Aangepast domein blijft hangen op SSL-validatie

Je hebt het record toegevoegd. dig toont het. Het platform geeft nog steeds aan dat de status in behandeling is, en doet dat al een uur. Een aangepast domein dat blijft hangen tijdens de validatie is juist zo frustrerend omdat elke controle die je zelf kunt uitvoeren lijkt te slagen.

Er zijn vier oorzaken. Ze zijn allemaal mechanisch en met de onderstaande volgorde vind je ze het snelst.

Eerst: wat doet validatie precies?

Voordat een certificate authority een certificaat uitgeeft, moet deze vaststellen dat je controle hebt over de naam. Daarvoor zijn er twee gangbare methoden. Welke methode je platform gebruikt, bepaalt wat er mis kan gaan:

• HTTP-01 — de CA vraagt http://your-domain/.well-known/acme-challenge/<token> op en verwacht een specifieke tekenreeks. Hiervoor moeten gewone HTTP-verzoeken naar je domein het platform bereiken.
• DNS-01 — de CA zoekt naar een TXT-record. Hiervoor moet het record bestaan en zichtbaar zijn voor de resolver van de CA. Dat is niet per se dezelfde resolver die jij hebt bevraagd.

Bij vrijwel elke validatie die blijft hangen, zit er iets tussen de CA en een van deze twee zaken in.

Oorzaak 1: een proxy vóór de challenge

Dit is de meest voorkomende oorzaak wanneer het domein achter een CDN staat. Het is bovendien verwarrend, omdat de proxy meestal juist de voorziening is die je wilde gebruiken.

Als je DNS-record via een proxy loopt in plaats van rechtstreeks naar het platform te verwijzen, eindigt het HTTP-01-verzoek van de CA bij de proxy. De proxy serveert zijn eigen certificaat, past zijn eigen regels toe en kan een redirect, challengepagina of 404 teruggeven — geen daarvan bevat de token waarop de CA wacht.

De oplossing is de challenge door te laten:

• Schakel de proxy uit (zet het record op grey-cloud) totdat het certificaat is uitgegeven en schakel hem daarna weer in.
• Of sluit /.well-known/acme-challenge/* uit van redirect- of toegangsregels.

De valkuil is dat beveiligingen zoals "Always Use HTTPS" en "Under Attack" HTTP-01 allebei kunnen verbreken, terwijl de site vanuit je browser perfect lijkt te werken.

Oorzaak 2: het verkeerde recordtype

Twee fouten zijn verantwoordelijk voor het grootste deel van de overige gevallen:

Een A-record dat verwijst naar een adres dat verandert. Als het platform je een hostname geeft, gebruik dan een CNAME. Het huidige IP-adres in een A-record zetten werkt totdat het adres onder je vandaan verandert.

Een CNAME op de zone-apex. example.com kan volgens de standaardspecificatie geen CNAME bevatten naast zijn SOA- en NS-records. Sommige providers bieden ALIAS, ANAME of "CNAME flattening" als oplossing; andere niet. Als jouw provider dat niet biedt, gebruik dan een subdomein — app.example.com — en stuur de apex door.

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

Als beide opdrachten niets opleveren, zijn de andere punten op deze lijst nog niet relevant.

Oorzaak 3: propagatie die je niet meet

dig zonder argumenten vraagt jouw resolver op. Die kan het antwoord dat je zojuist hebt aangemaakt in de cache hebben staan — of erger nog, de NXDOMAIN van voordat je het record aanmaakte. Een negatieve cache-entry met een lange TTL is een veelvoorkomende reden waarom een validatie een uur lang faalt en daarna zonder ingreep slaagt.

Vraag de authoritative servers rechtstreeks op en gebruik ook een publieke resolver om te zien wat de CA waarschijnlijk te zien krijgt:

# 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

Als het authoritative antwoord correct is en de publieke resolvers een verkeerd antwoord geven, wacht je op de TTL en hoef je niets te herstellen.

Oorzaak 4: CAA weigert de issuer

Deze oorzaak komt zelden voor, is niet zichtbaar bij normale DNS-controles en blijft volledig stil wanneer hij toeslaat.

Een CAA-record op je domein bepaalt welke certificate authorities er certificaten voor mogen uitgeven. Als je zo'n record hebt — vaak overgeërfd uit een oude configuratie of toegevoegd op basis van een aanbeveling uit een securityscan — en het niet de CA bevat die je platform gebruikt, mislukt de uitgifte. De enige plek waar dat wordt gemeld, zijn de logs van de CA, waar je geen toegang toe hebt.

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

Lege uitvoer betekent dat er geen beperking is, en dat is prima. Krijg je wel records terug, voeg dan de CA die je platform gebruikt toe of verwijder de beperking.

De volgorde waarmee je het probleem het snelst vindt

1. Voer dig uit voor het record via een publieke resolver. Geen antwoord betekent dat het record verkeerd is of nog niet is gepropageerd — stop hier.
2. Controleer of het record via een proxy loopt. Zo ja, schakel de proxy uit of sluit het ACME-pad uit.
3. Controleer CAA op zowel de apex als het subdomein.
4. Overweeg pas daarna dat het platform de oorzaak is.

Negentig procent van de validaties die blijven hangen, eindigt bij stap 1 of stap 2.

Zo werkt dit op Dockup

Twee ontwerpkeuzes nemen het meeste giswerk weg.

Het DNS-record wordt voor je aangemaakt. Staat je zone op Cloudflare en heb je het account gekoppeld, dan schrijft het toevoegen van een domein het record automatisch weg. Je hoeft geen waarde handmatig over te nemen:

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

Daarmee verdwijnt de hele categorie fouten door typefouten en verkeerde recordtypes — het platform weet of het een CNAME of A-record nodig heeft en maakt het juiste record aan.

De grant bestaat uit twee permissies. Zone:Read en DNS:Edit, en niets anders. Dockup kan je andere zones niet lezen, geen accountinstellingen wijzigen en niets aanpassen waartoe het geen toegang heeft gekregen. DNS-automatisering koppelen zou niet moeten vereisen dat je een heel account overdraagt.

De verificatie- en certificaatstatus zijn per domein zichtbaar in plaats van als één geaggregeerde status. Daardoor betekent "DNS geverifieerd, maar TLS in behandeling" precies wat het is: twee afzonderlijke stappen, waarvan er één is voltooid.

Veelgestelde vragen

Hoe lang duurt het uitgeven van een certificaat? Meestal minder dan een minuut zodra DNS correct resolveert. Staat de status langer dan ongeveer vijftien minuten op in behandeling, dan blokkeert iets de uitgifte in plaats van dat het proces alleen traag is.

Waarom werkt mijn domein wel in de browser, maar mislukt de validatie? Omdat je browser redirects volgt en HTTPS gebruikt, terwijl de challenge geen van beide doet. Een proxy die je site perfect serveert, kan het gewone HTTP-ACME-verzoek nog steeds onderscheppen.

Kan ik een CNAME op mijn hoofddomein gebruiken? Niet in standaard-DNS. Gebruik een functie van je provider zoals ALIAS of CNAME flattening, of laat de apex naar een subdomein verwijzen met een redirect.

Wat is een CAA-record en heb ik er een nodig? Het beperkt welke certificate authorities certificaten voor je domein mogen uitgeven. Je hebt er geen nodig, maar als je er een hebt waarin de CA van je platform ontbreekt, mislukt de uitgifte stilletjes.