Anpassad domän fastnar vid SSL-validering

Du lade till recorden. dig visar den. Plattformen visar fortfarande väntande och har gjort det i en timme. En anpassad domän som fastnar i valideringen är frustrerande just eftersom alla kontroller du själv kan köra verkar lyckas.

Det finns fyra orsaker. Alla är mekaniska, och ordningen nedan hittar dem snabbast.

Först: vad valideringen faktiskt gör

Innan en certifikatutfärdare utfärdar ett certifikat måste den fastställa att du kontrollerar namnet. Det finns två vanliga metoder, och vilken din plattform använder påverkar vad som kan gå fel:

• HTTP-01 — CA:n begär http://your-domain/.well-known/acme-challenge/<token> och förväntar sig en specifik sträng. Det kräver att vanliga HTTP-anrop till din domän når plattformen.
• DNS-01 — CA:n letar efter en TXT-record. Det kräver att recorden finns och är synlig för CA:ns resolver, vilket inte nödvändigtvis är samma resolver som du frågade.

Nästan alla valideringar som fastnar beror på något som står mellan CA:n och en av dessa två saker.

Orsak 1: en proxy framför challenge-sökvägen

Det här är den vanligaste orsaken när domänen ligger bakom ett CDN, och det är genuint förvirrande eftersom proxyn oftast är just det du ville ha.

Om din DNS-record proxas i stället för att peka direkt på plattformen avslutas CA:ns HTTP-01-anrop vid proxyn. Proxyn tillhandahåller sitt eget certifikat, tillämpar sina egna regler och kan returnera en redirect, en challenge-sida eller en 404 — inget av detta innehåller token som CA:n väntar på.

Lösningen är att släppa igenom challenge-anropet:

• Stäng av proxyn (gråmarkera recorden) tills certifikatet har utfärdats och slå sedan på den igen.
• Eller undanta /.well-known/acme-challenge/* från alla redirect- eller accessregler.

Fällan är att skydd som "Always Use HTTPS" och "Under Attack" båda kan bryta HTTP-01, samtidigt som webbplatsen ser ut att fungera perfekt i din webbläsare.

Orsak 2: fel record-typ

Två misstag står för det mesta av resten:

En A-record som pekar på en adress som ändras. Om plattformen gav dig ett hostname ska du använda en CNAME. Att kopiera den aktuella IP-adressen till en A-record fungerar bara tills adressen ändras.

En CNAME på zonens apex. example.com kan enligt standard inte ha en CNAME tillsammans med sina SOA- och NS-records. Vissa leverantörer erbjuder ALIAS, ANAME eller "CNAME flattening" som en lösning; andra gör det inte. Om din leverantör saknar detta kan du använda en subdomän — app.example.com — och redirecta apex-domänen.

# Vad omvärlden faktiskt ser, inte vad din dashboard visar
dig +short app.example.com CNAME
dig +short app.example.com A

Om båda kommandona returnerar tomt spelar inget annat på den här listan någon roll ännu.

Orsak 3: propagation som du inte mäter

dig utan argument frågar din resolver, som kan ha cachat svaret du precis skapade — eller ännu värre, cachat NXDOMAIN från tiden innan du skapade det. En negativ cachepost med lång TTL är en mycket vanlig anledning till att en validering misslyckas i en timme och sedan lyckas utan någon åtgärd.

Fråga de auktoritativa servrarna direkt och fråga en publik resolver för att se vad CA:n sannolikt kommer att se:

# Fråga zonens egna namnservrar
dig +short app.example.com @$(dig +short NS example.com | head -1)

# Fråga en resolver utanför ditt nätverk
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8

Om det auktoritativa svaret är korrekt men de publika resolverna visar fel svar väntar du på TTL, och det finns inget att åtgärda.

Orsak 4: CAA vägrar utfärdaren

Det här är ovanligt, osynligt i normala DNS-kontroller och helt tyst när det inträffar.

En CAA-record på din domän anger vilka certifikatutfärdare som får utfärda certifikat för den. Om du har en sådan — ofta kvar från en gammal konfiguration eller tillagd efter en rekommendation från en säkerhetsskanning — och den inte inkluderar den CA som din plattform använder, misslyckas utfärdandet. Den enda platsen där det framgår är i CA:ns loggar, som du inte kan se.

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

Tom output betyder att det inte finns någon begränsning, vilket är helt okej. Om du får tillbaka records kan du antingen lägga till den CA som plattformen använder eller ta bort begränsningen.

Ordningen som hittar felet snabbast

1. Kör dig mot en publik resolver. Inget svar betyder att recorden är fel eller ännu inte har propagerats — sluta här.
2. Kontrollera om recorden proxas. Om den gör det kan du stänga av proxyn eller undanta ACME-sökvägen.
3. Kontrollera CAA på både apex-domänen och subdomänen.
4. Först därefter bör du överväga att felet ligger hos plattformen.

Nittio procent av alla valideringar som fastnar tar slut vid steg 1 eller steg 2.

Så här fungerar det på Dockup

Två designval tar bort det mesta av gissandet.

DNS-recorden skapas åt dig. Om din zon finns på Cloudflare och du har anslutit kontot lägger ett domänanrop till recorden automatiskt, i stället för att du själv måste kopiera ett värde:

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

Det eliminerar hela kategorin av stavfel och misstag med record-typer — plattformen vet om den behöver en CNAME eller en A-record och skapar rätt record.

Åtkomsten består av två behörigheter. Zone:Read och DNS:Edit, och inget annat. Dockup kan inte läsa dina andra zoner, ändra kontoinställningar eller röra något som du inte har gett åtkomst till. Att ansluta DNS-automation ska inte kräva att du lämnar över ett helt konto.

Verifierings- och certifikatstatus visas per domän i stället för som en enda samlad status. Därför betyder "DNS verifierad men TLS väntar" exakt vad det säger — två separata steg, där det ena är klart.

Vanliga frågor

Hur lång tid bör det ta att utfärda ett certifikat? Vanligtvis mindre än en minut när DNS-resolutionen fungerar korrekt. Om statusen har varit väntande i mer än ungefär femton minuter är det något som blockerar utfärdandet, inte att processen bara är långsam.

Varför fungerar min domän i webbläsaren men inte vid valideringen? Eftersom webbläsaren följer redirects och använder HTTPS, medan challenge-anropet inte gör något av detta. En proxy som visar webbplatsen perfekt kan ändå svälja ACME-anropet över vanlig HTTP.

Kan jag använda en CNAME på min root-domän? Inte med standard-DNS. Använd en funktion som ALIAS eller CNAME flattening hos din leverantör, eller peka apex-domänen på en subdomän med en redirect.

Vad är en CAA-record och behöver jag en sådan? Den begränsar vilka certifikatutfärdare som får utfärda certifikat för din domän. Du behöver ingen, men om du har en som inte inkluderar plattformens CA misslyckas utfärdandet utan någon tydlig felindikering.