Brugerdefineret domæne sidder fast under SSL-validering

Du har tilføjet recorden. dig viser den. Platformen viser stadig, at den afventer, og det har den gjort i en time. Et brugerdefineret domæne, der sidder fast under validering, er frustrerende netop fordi alle de kontroller, du selv kan køre, ser ud til at lykkes.

Der er fire årsager, og de er alle mekaniske. Rækkefølgen nedenfor finder dem hurtigst.

Først: hvad valideringen faktisk gør

Før en certificate authority udsteder et certifikat, skal den fastslå, at du har kontrol over navnet. Der er to almindelige metoder, og hvilken metode din platform bruger, afgør, hvad der kan gå galt:

• HTTP-01 — CA'en sender en forespørgsel til http://your-domain/.well-known/acme-challenge/<token> og forventer en bestemt tekststreng. Det kræver, at almindelige HTTP-forespørgsler til dit domæne når frem til platformen.
• DNS-01 — CA'en leder efter en TXT-record. Det kræver, at recorden findes og er synlig for CA'ens resolver, som ikke nødvendigvis er den, du selv forespurgte.

Næsten al validering, der sidder fast, skyldes noget, der står mellem CA'en og en af disse to ting.

Årsag 1: en proxy foran challenge-anmodningen

Dette er den mest almindelige årsag, når domænet ligger bag en CDN, og det er oprigtigt forvirrende, fordi proxyen normalt er det, du ønskede.

Hvis din DNS-record er proxied i stedet for at pege direkte på platformen, terminerer CA'ens HTTP-01-forespørgsel ved proxyen. Proxyen leverer sit eget certifikat, anvender sine egne regler og kan returnere en redirect, en challenge-side eller en 404 — ingen af delene indeholder det token, CA'en venter på.

Løsningen er at lade challenge-anmodningen passere:

• Slå proxyen fra (skift recorden til grey-cloud), indtil certifikatet er udstedt, og slå den derefter til igen.
• Eller undtag /.well-known/acme-challenge/* fra alle redirects eller access rules.

Fælden er, at beskyttelser som "Always Use HTTPS" og "Under Attack" begge ødelægger HTTP-01, selv om siden fra din browser ser ud til at fungere perfekt.

Årsag 2: den forkerte record-type

To fejl står for størstedelen af resten:

En A-record, der peger på en adresse, som ændrer sig. Hvis platformen har givet dig et hostname, skal du bruge en CNAME. Hvis du kopierer den aktuelle IP-adresse ind i en A-record, virker det lige indtil adressen ændres under dig.

En CNAME på zone-apex. example.com kan ikke lovligt have en CNAME sammen med sine SOA- og NS-records. Nogle udbydere tilbyder ALIAS, ANAME eller "CNAME flattening" som workaround; andre gør ikke. Hvis din udbyder ikke gør, skal du bruge et subdomæne — app.example.com — og redirecte apex-domænet.

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

Hvis begge kommandoer returnerer tomt, er intet andet på denne liste relevant endnu.

Årsag 3: propagation, som du ikke måler

dig uden argumenter spørger din resolver, som kan have cached det svar, du netop oprettede — eller endnu værre have cached NXDOMAIN fra før, du oprettede det. En negativ cache-entry med en lang TTL er en meget almindelig årsag til, at en validering fejler i en time og derefter lykkes uden indgriben.

Forespørg de autoritative servere direkte, og forespørg en offentlig resolver, så du kan se, hvad CA'en sandsynligvis ser:

# 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

Hvis det autoritative svar er korrekt, og de offentlige resolvere viser noget andet, venter du på TTL, og der er ikke noget, du kan rette.

Årsag 4: CAA afviser udstederen

Denne årsag er sjælden, usynlig ved normale DNS-kontroller og fuldstændig tavs, når den rammer.

En CAA-record på dit domæne angiver, hvilke certificate authorities der må udstede certifikater til det. Hvis du har en sådan — ofte nedarvet fra en gammel opsætning eller tilføjet efter en anbefaling fra en security scan — og den ikke inkluderer den CA, din platform bruger, mislykkes udstedelsen. Det eneste sted, hvor det står, er i CA'ens logs, som du ikke kan se.

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

Tomt output betyder, at der ikke er nogen begrænsning, hvilket er fint. Hvis du får records tilbage, skal du enten tilføje den CA, din platform bruger, eller fjerne begrænsningen.

Rækkefølgen, der finder fejlen hurtigst

1. Kør dig mod en offentlig resolver. Intet svar betyder, at recorden er forkert eller endnu ikke er propagated — stop her.
2. Kontrollér, om recorden er proxied. Hvis den er, skal du slå proxyen fra eller undtage ACME-stien.
3. Kontrollér CAA på både apex-domænet og subdomænet.
4. Først derefter bør du overveje, om fejlen ligger hos platformen.

Halvfems procent af alle valideringer, der sidder fast, ender ved trin 1 eller trin 2.

Sådan fungerer det på Dockup

To designvalg fjerner det meste af gætværket.

DNS-recorden oprettes for dig. Hvis din zone ligger på Cloudflare, og du har forbundet kontoen, skriver tilføjelsen af et domæne selv recorden i stedet for at lade dig kopiere en værdi manuelt:

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

Det eliminerer hele klassen af tastefejl og fejl i record-typen — platformen ved, om den skal bruge en CNAME eller en A-record, og opretter den rigtige.

Adgangen består af to tilladelser. Zone:Read og DNS:Edit, og ikke andet. Dockup kan ikke læse dine andre zoner, ændre kontoindstillinger eller røre noget, som den ikke har fået adgang til. Tilslutning af DNS-automatisering bør ikke kræve, at du udleverer en hel konto.

Verifikation og certifikatstatus vises pr. domæne i stedet for som én samlet status, så "DNS verified but TLS pending" vises som det, det er — to separate trin, hvoraf det ene er afsluttet.

Ofte stillede spørgsmål

Hvor lang tid bør det tage at udstede et certifikat? Normalt under et minut, når DNS resolver korrekt. Hvis status har afventet i mere end cirka femten minutter, er der sandsynligvis noget, der blokerer, i stedet for at processen blot er langsom.

Hvorfor virker mit domæne i browseren, men fejler under validering? Fordi din browser følger redirects og bruger HTTPS, mens challenge-anmodningen ikke gør nogen af delene. En proxy, der leverer din side perfekt, kan stadig sluge den almindelige HTTP ACME-forespørgsel.

Kan jeg bruge en CNAME på mit root-domæne? Ikke i standard-DNS. Brug en funktion som ALIAS eller CNAME flattening hos din udbyder, eller peg apex-domænet på et subdomæne med en redirect.

Hvad er en CAA-record, og har jeg brug for en? Den begrænser, hvilke certificate authorities der må udstede certifikater til dit domæne. Du har ikke brug for en, men hvis du har en, som ikke inkluderer din platforms CA, mislykkes udstedelsen uden en synlig fejl.