Egendefinert domene sitter fast under SSL-validering

Du la til recorden. dig viser den. Plattformen viser fortsatt «venter», og har gjort det i en time. Et egendefinert domene som sitter fast under validering er frustrerende nettopp fordi alle kontrollene du kan kjøre selv, ser ut til å lykkes.

Det finnes fire årsaker. De er alle mekaniske, og rekkefølgen nedenfor finner dem raskest.

Først: hva valideringen faktisk gjør

Før en sertifikatutsteder utsteder et sertifikat, må den bekrefte at du kontrollerer navnet. Det finnes to vanlige metoder, og hvilken plattformen bruker, avgjør hva som kan gå galt:

• HTTP-01 — CA-en sender en forespørsel til http://your-domain/.well-known/acme-challenge/<token> og forventer en bestemt tekststreng. Dette krever at vanlige HTTP-forespørsler til domenet ditt når plattformen.
• DNS-01 — CA-en ser etter en TXT-record. Dette krever at recorden finnes og er synlig for CA-ens resolver, som ikke nødvendigvis er den du spurte.

Nesten all validering som sitter fast, skyldes noe som står mellom CA-en og én av disse to tingene.

Årsak 1: en proxy foran challenge-forespørselen

Dette er den vanligste årsaken når domenet ligger bak et CDN, og det er genuint forvirrende fordi proxyen vanligvis er det du ønsket å bruke.

Hvis DNS-recorden din er proxied i stedet for å peke direkte på plattformen, avsluttes CA-ens HTTP-01-forespørsel hos proxyen. Proxyen leverer sitt eget sertifikat, bruker sine egne regler og kan returnere en redirect, en challenge-side eller en 404 — ingen av delene inneholder tokenet CA-en venter på.

Løsningen er å slippe challenge-forespørselen gjennom:

• Slå av proxyen (sett recorden til grå sky) til sertifikatet er utstedt, og slå den deretter på igjen.
• Eller unnta /.well-known/acme-challenge/* fra alle redirect- eller tilgangsregler.

Fellen er at beskyttelser som «Always Use HTTPS» og «Under Attack» begge kan ødelegge HTTP-01, samtidig som nettstedet ser ut til å fungere perfekt i nettleseren din.

Årsak 2: feil record-type

To feil står for det meste av resten:

A-record som peker på en adresse som endres. Hvis plattformen ga deg et hostname, bør du bruke en CNAME. Å kopiere den nåværende IP-adressen inn i en A-record fungerer helt til adressen endres under deg.

En CNAME på zone-apexet. example.com kan ikke lovlig ha en CNAME samtidig som den har SOA- og NS-recorder. Noen leverandører tilbyr ALIAS, ANAME eller «CNAME flattening» som en løsning på dette, mens andre ikke gjør det. Hvis din leverandør ikke gjør det, bruker du et subdomene — app.example.com — og redirecter apexet.

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

Hvis begge kommer tilbake tomme, er ingenting annet på denne listen relevant ennå.

Årsak 3: propagasjon du ikke måler

dig uten argumenter spør resolveren din, som kan ha bufret svaret du nettopp opprettet — eller, enda verre, bufret NXDOMAIN fra før du opprettet det. En negativ cache-entry med lang TTL er en svært vanlig årsak til at en validering mislykkes i en time og deretter lykkes uten at du gjør noe.

Spør de autoritative serverne direkte, og spør en offentlig resolver, for å se hva CA-en sannsynligvis vil se:

# 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 svaret er riktig og de offentlige resolverne er feil, venter du på TTL, og det er ingenting å fikse.

Årsak 4: CAA avviser utstederen

Denne årsaken er sjelden, usynlig i vanlige DNS-kontroller og fullstendig taus når den slår inn.

En CAA-record på domenet ditt angir hvilke sertifikatutstedere som kan utstede sertifikater for det. Hvis du har en slik record — ofte arvet fra et gammelt oppsett eller lagt til etter en anbefaling fra en sikkerhetsskanning — og den ikke inkluderer CA-en plattformen bruker, mislykkes utstedelsen. Det eneste stedet dette står, er i loggene til CA-en, som du ikke kan se.

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

Tomt resultat betyr at det ikke finnes noen begrensning, noe som er greit. Hvis du får records tilbake, legger du enten til CA-en plattformen bruker, eller fjerner begrensningen.

Rekkefølgen som finner feilen raskest

1. Kjør dig mot en offentlig resolver. Ingen svar betyr at recorden er feil eller ikke er propagert ennå — stopp her.
2. Sjekk om recorden er proxied. Hvis den er det, slår du av proxyen eller unntar ACME-stien.
3. Sjekk CAA både på apexet og subdomenet.
4. Først da bør du vurdere om feilen ligger hos plattformen.

Nitti prosent av valideringer som sitter fast, ender i trinn 1 eller trinn 2.

Slik fungerer dette på Dockup

To designvalg fjerner det meste av gjettingen.

DNS-recorden opprettes for deg. Hvis sonen din ligger på Cloudflare og du har koblet til kontoen, skriver det å legge til et domene recorden automatisk i stedet for at du må kopiere inn en verdi manuelt:

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

Det eliminerer hele klassen av skrivefeil og feil record-typer — plattformen vet om den trenger en CNAME eller en A-record, og oppretter den riktige.

Tilgangen består av to tillatelser. Zone:Read og DNS:Edit, og ingenting annet. Dockup kan ikke lese de andre sonene dine, endre kontoinnstillinger eller gjøre noe den ikke har fått tilgang til. Automatisering av DNS bør ikke kreve at du gir fra deg en hel konto.

Bekreftelses- og sertifikatstatus vises per domene i stedet for som én samlet status. Dermed betyr «DNS bekreftet, men TLS venter» det det faktisk er — to separate trinn, der det ene er fullført.

Ofte stilte spørsmål

Hvor lang tid bør det ta å utstede sertifikatet? Vanligvis under ett minutt når DNS-resolusjonen fungerer som den skal. Hvis statusen har stått som «venter» i mer enn omtrent femten minutter, er det sannsynligvis noe som blokkerer prosessen, ikke at den bare er treg.

Hvorfor fungerer domenet mitt i nettleseren, men ikke under validering? Fordi nettleseren din følger redirecter og bruker HTTPS, mens challenge-forespørselen ikke gjør noen av delene. En proxy som leverer nettstedet ditt perfekt, kan fortsatt sluke ACME-forespørselen over vanlig HTTP.

Kan jeg bruke en CNAME på rotdomenet mitt? Ikke i standard DNS. Bruk en funksjon hos leverandøren, som ALIAS eller CNAME flattening, eller pek apexet til et subdomene med en redirect.

Hva er en CAA-record, og trenger jeg en? Den begrenser hvilke sertifikatutstedere som kan utstede sertifikater for domenet ditt. Du trenger ikke en slik record, men hvis du har en som utelater CA-en til plattformen din, mislykkes utstedelsen uten noen tydelig feilmelding.