Mukautettu verkkotunnus jumittuu SSL-validointiin

Lisäsit tietueen. dig näyttää sen. Alusta ilmoittaa silti tilaksi odottavan, ja sama tila on pysynyt jo tunnin. Validointiin jumittuva mukautettu verkkotunnus on erityisen turhauttava juuri siksi, että kaikki itse tekemäsi tarkistukset näyttävät onnistuvan.

Syitä on neljä, ne ovat kaikki mekaanisia, ja alla oleva järjestys löytää ne nopeimmin.

Ensimmäiseksi: mitä validoinnissa oikeasti tapahtuu

Ennen kuin varmenteen myöntäjä voi myöntää varmenteen, sen on varmistettava, että hallitset nimeä. Yleisiä tapoja on kaksi, ja alustan käyttämä tapa vaikuttaa siihen, mikä voi mennä pieleen:

• HTTP-01 — CA pyytää osoitetta http://your-domain/.well-known/acme-challenge/<token> ja odottaa tiettyä merkkijonoa. Tämä edellyttää, että verkkotunnuksesi tavalliset HTTP-pyynnöt päätyvät alustalle.
• DNS-01 — CA etsii TXT-tietuetta. Tietueen on oltava olemassa ja CA:n resolverin nähtävissä, eikä kyseessä välttämättä ole sama resolver, jota itse kyselit.

Lähes aina validoinnin jumittumisen aiheuttaa jokin, joka on CA:n ja jommankumman näistä välissä.

Syy 1: haasteen edessä on proxy

Tämä on yleisin syy, kun verkkotunnus on CDN:n takana. Se on aidosti hämmentävää, koska proxy on yleensä juuri se asia, jota halusit käyttää.

Jos DNS-tietueesi on proxied-tilassa sen sijaan, että se osoittaisi suoraan alustalle, CA:n HTTP-01-pyyntö päättyy proxyyn. Proxy tarjoaa oman varmenteensa, soveltaa omia sääntöjään ja saattaa palauttaa uudelleenohjauksen, haastesivun tai 404-virheen — mikään näistä ei sisällä tokenia, jota CA odottaa.

Korjaa tilanne päästämällä haaste läpi:

• Poista proxyn käytöstä (vaihda tietue grey-cloud-tilaan), kunnes varmenne on myönnetty, ja ota se sitten uudelleen käyttöön.
• Tai rajaa /.well-known/acme-challenge/* kaikkien uudelleenohjaus- tai käyttöoikeussääntöjen ulkopuolelle.

Ongelma on siinä, että sekä "Always Use HTTPS" että "Under Attack" -tyyppiset suojaukset rikkovat HTTP-01:n, vaikka sivusto näyttää selaimessa toimivan täydellisesti.

Syy 2: väärä tietuetyyppi

Suurin osa jäljelle jäävistä tapauksista johtuu kahdesta virheestä:

A-tietue osoittaa vaihtuvaan osoitteeseen. Jos alusta antoi sinulle isäntänimen, käytä CNAME-tietuetta. Nykyisen IP-osoitteen kopioiminen A-tietueeseen toimii siihen asti, kunnes osoite vaihtuu alta.

CNAME vyöhykkeen juuritasolla. example.com ei voi standardin mukaan sisältää CNAME-tietuetta SOA- ja NS-tietueiden rinnalla. Jotkin palveluntarjoajat tarjoavat tämän kiertämiseen ALIAS-, ANAME- tai "CNAME flattening" -ominaisuuden, jotkin eivät. Jos omasi ei tarjoa sellaista, käytä aliverkkotunnusta — app.example.com — ja uudelleenohjaa juuritaso siihen.

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

Jos molemmat palauttavat tyhjän tuloksen, millään muulla tämän listan kohdalla ei ole vielä merkitystä.

Syy 3: propagointia ei mitata oikein

dig ilman argumentteja kysyy omaa resolveriasi, joka on saattanut tallentaa juuri luomasi vastauksen välimuistiin — tai vielä pahempaa, tallentaa välimuistiin aiemman NXDOMAIN-vastauksen ajalta ennen tietueen luomista. Pitkän TTL-arvon sisältävä negatiivinen välimuistimerkintä on hyvin yleinen syy siihen, että validointi epäonnistuu tunnin ajan ja onnistuu sen jälkeen ilman toimenpiteitä.

Kysy auktoritatiivisilta palvelimilta suoraan ja lisäksi julkiselta resolverilta, jotta näet, mitä CA todennäköisesti näkee:

# 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

Jos auktoritatiivinen vastaus on oikein mutta julkisten resolverien vastaukset vääriä, odotat TTL:n umpeutumista, eikä mitään ole korjattavana.

Syy 4: CAA estää myöntäjän

Tämä on harvinainen ongelma, joka ei näy tavallisissa DNS-tarkistuksissa ja toimii täysin äänettömästi, kun se ilmenee.

Verkkotunnuksesi CAA-tietue kertoo, mitkä varmenteen myöntäjät voivat myöntää sille varmenteita. Jos tietue on olemassa — usein peritty vanhasta määrityksestä tai lisätty tietoturvatarkistuksen suosituksesta — eikä siinä ole alustan käyttämää CA:ta, myöntäminen epäonnistuu. Ainoa paikka, jossa tämä näkyy, ovat CA:n lokit, joita et voi nähdä.

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

Tyhjä tulos tarkoittaa, ettei rajoituksia ole, mikä on hyvä. Jos saat tietueita, lisää niihin alustan käyttämä CA tai poista rajoitus.

Nopein tarkistusjärjestys

1. Suorita dig julkista resolveria vasten. Jos vastausta ei ole, tietue on väärä tai se ei ole vielä propagoinut — lopeta tähän.
2. Tarkista, onko tietue proxied-tilassa. Jos on, poista proxy käytöstä tai rajaa ACME-polku sen ulkopuolelle.
3. Tarkista CAA sekä juuritasolta että aliverkkotunnuksesta.
4. Harkitse vasta tämän jälkeen, että vika on alustassa.

Yhdeksänkymmentä prosenttia jumittuvista validoinneista päättyy vaiheeseen 1 tai 2.

Näin tämä toimii Dockupissa

Kaksi suunnitteluratkaisua poistaa suurimman osan arvailusta.

DNS-tietue luodaan puolestasi. Jos vyöhykkeesi on Cloudflaressa ja olet yhdistänyt tilin, verkkotunnuksen lisääminen kirjoittaa tietueen automaattisesti sen sijaan, että joutuisit kopioimaan arvon käsin:

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

Tämä poistaa kokonaan kirjoitus- ja tietuetyyppivirheiden luokan — alusta tietää, tarvitseeko se CNAME- vai A-tietueen, ja luo oikean tietueen.

Myönnetyt oikeudet koostuvat kahdesta luvasta. Zone:Read ja DNS:Edit, eikä mitään muuta. Dockup ei voi lukea muita vyöhykkeitäsi, muuttaa tiliasetuksia tai käsitellä mitään, mihin sille ei ole annettu oikeutta. DNS-automaation yhdistämisen ei pitäisi edellyttää koko tilin luovuttamista.

Vahvistuksen ja varmenteen tilan näkee verkkotunnuskohtaisesti yhden koontitilan sijaan, joten "DNS vahvistettu, mutta TLS odottaa" kertoo tilanteen sellaisena kuin se on — kyseessä on kaksi erillistä vaihetta, joista toinen on valmis.

Usein kysytyt kysymykset

Kuinka kauan varmenteen myöntämisen pitäisi kestää? Yleensä alle minuutin, kun DNS-resoluutio toimii oikein. Jos tila on odottanut yli noin 15 minuuttia, jokin estää myöntämisen sen sijaan, että prosessi olisi vain hidas.

Miksi verkkotunnukseni toimii selaimessa mutta validointi epäonnistuu? Koska selain seuraa uudelleenohjauksia ja käyttää HTTPS:ää, kun taas haaste ei tee kumpaakaan. Proxy, joka tarjoaa sivustosi täydellisesti, voi silti niellä tavallisen HTTP:n ACME-pyynnön.

Voinko käyttää CNAME-tietuetta juuritason verkkotunnuksessa? Et standardin mukaisessa DNS:ssä. Käytä palveluntarjoajan ominaisuutta, kuten ALIASia tai CNAME flatteningia, tai osoita juuritaso aliverkkotunnukseen uudelleenohjauksella.

Mikä CAA-tietue on, ja tarvitsenko sellaisen? Se rajoittaa, mitkä varmenteen myöntäjät voivat myöntää varmenteita verkkotunnuksellesi. Et tarvitse sellaista, mutta jos sinulla on CAA-tietue, josta alustan CA puuttuu, myöntäminen epäonnistuu äänettömästi.