Hi,
Many times I already experienced that if I request SSL cert for a new domain but accidentally tries validate it before the TXT record is configured properly, the DNS servers of Let's Encrypt does not validate if again and it caches that either TXT value does not exist or it has wrong (previously configured) value.
The DNS server owns my domain configured 1 hour TTL, but even after 1 hour, the DNS servers of Let's Encrypt still cannot validate the domain because either the value is wrong or record does not exist. However, when I request the record on my computer, it is already valid and active.
According to screenshot here, the validation happened on 06:47 UTC (08:47 in CEST), and you can see my time is already 10:46 (almost two hours more), but the validation still did not moved forward. The window on the bottom of screenshot shows that with nslookup I already request the right value.
Any idea from anyone how this DNS validation can be speed up?
Thanks!
Gabor
1 Like
Kedves Gábor,
Mielött a domain nĂ©v Ă©rvĂ©nyesĂtĂ©s elkezdõdne a Letsencrypt szerveren, meg kell gyõzõdni, hogy a domain nĂ©v összes hivatalos nĂ©vszerverĂ©n már megtörtĂ©nt a TXT bejegyzĂ©s naprahozása.
Nem csak ilyen általános segĂtsĂ©get tudnánk nyĂşjtani, ha a formula kitöltĂ©sre kerĂĽlt volna.
Ăśdv:
Attila
5 Likes
Kedves Attila,
Köszönöm a választ!
A formulát azĂ©rt nem töltöttem ki, mert a domain, ahol jelenleg a hibát tapasztaltam egyelĹ‘re nem hozzáfĂ©rhetĹ‘ szabadon, Ăgy annak kiĂrására nincs lehetĹ‘sĂ©g.
Elvileg, mivel a TTL 1 óra, emiatt a domain hivatalos összes névszerverén 1 órán belül le kell, hogy frissüljön a TXT rekord, viszont hogy lehet az, hogy validáció időpontja nem frissül a let's encrypt challenge URL-jében (screenshot felső kép)? Nekem az lenne a normális, hogy ahányszor lekérem, az az időpont automatikusan mindig frissül, mert a lekérés időpontjában nézi meg a DNS bejegyzést. Ehelyett azt látom, hogy gyakorlatilag sok órával korábbi.
Üdv: Gábor
Ha a névszerverek jól müködnek, a rekord naprahozása másodpercen belül meg kell hogy történjen az összes hivatalos névszerveren. Ez az idõtartam nem keverendõ össze a TTL hosszával, ami csak a tárolás maximális hosszát jelenti. Itt ez nem játszik szerepet, a Letsencrypt DNS szervere amúgy is maximálja ezt az értéket egy percre.
Azt javaslom, hogy egy tetszõleges adattal legyen leellenõrizve, milyen gyorsan frissĂĽlnek a hivatalos nĂ©vszerverek. EgyĂ©bkĂ©nt akár lehet más beállĂtási problĂ©ma is velĂĽk.
Javaslom a https://letsdebug.net/ használatát, sok problĂ©mát kiderĂthet.
4 Likes
Köszönöm!
A baj az, hogy ahogy nĂ©zem, a letsdebug csak HTTP(S) validáciĂłt csinál, Ă©s nem csinál DNS validáciĂłt. Mivel jelenleg nem HTTP validáciĂłt használok, hanem DNS alapĂşt, Ăgy ez nem igazán használhatĂł.
Habár, itt is fura az üzenet. Azt mondja, hogy nincs A rekord bejegyezve. De ha DNS-be lekérem, akkor van A rekord:
Van egy pull-down menü kiválasztani a DNS-01 validációt, a jobb oldalon.
3 Likes
Oké. Nem látok
Viszont, ennek ez az eredménye:
Ehelyett a validáció még mindig hibás.
Ez már elég jó. Ezek után le kellene ellenõrizni, hogy milyen gyorsan frissül egy bejegyzés a hivatalos névszerverek között.
3 Likes
A TXT rekord reggel 8.30 körĂĽl lett beĂrva. AzĂłta ezeknek már rĂ©g le kellett szinkronizálni.
A másik érdekesség, hogy a téma nyitó hozzászólásában levő képen levő URL a prod környezetre utal. Ez is érdekes, amikor a verbose-re megyek a validációnál:
Az eredeti TXT bejegyzés már érvénytelen, azt ki is lehet törölni. A letsencrypt szerver minden egyes próbálkozáskor új, az elõzõtõl különbözõ TXT bejegyzést kér.
3 Likes
Az elsĹ‘ DNS bejegyzĂ©s felĂĽl lett Ărva. Az már nincs benne a DNS-ben.
És az Ăşjabb TXT bejegyzĂ©s már minden egyes hivatalos nĂ©vszerveren elĂ©rhetõ? Csak akkor Ă©rdemes a Letsencrypt Ă©rvĂ©nyesĂtĂ©sre tovább lĂ©pni.
3 Likes
Akkor keletkezik hiba, amikor még a helyes DNS rekord előtt véletlenül validálásra kerül a domain. Ez esetben onnantól többet már nem képes validálni a letsencrypt. Ez egy elég nagy hibának tűnik.
Ha létrehozok egy új igényt, megcsinálom a DNS TXT rekord bejegyzést, és validálok, akkor rendben van.
Igen, az Ă©rvĂ©nyesĂtĂ©si kisĂ©rlet vagy sikerĂĽl, vagy nem. Ha nem sikerĂĽl, akkor Ăşj rekordra van szĂĽksĂ©g az Ăşjabb Ă©rvĂ©nyesĂtĂ©si kisĂ©rlethez. Ez nem igazán hiba, csupán elvárás a nĂ©vszerverektõl, hogy az Ă©rvĂ©nyesĂtĂ©si kisĂ©rlet elött már mindegyiken ott legyen a kĂvánt rekord.
3 Likes
Ahh Ă©rtem. SzĂłval az by design, hogy ha az elsĹ‘ Ă©rvĂ©nyesĂtĂ©s sikertelen, akkor utána már nem is kell vele prĂłbálkozni.
Köszönöm. Ez megmagyarázza a dolgokat.
1 Like
The ACME protocol does allow for retrying challenges, but Let's Encrypt doesn't implement that.
https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md says:
Boulder does not implement the ability to retry challenges
It would take a somewhat significant amount of redesign of the database schema to support retrying, unfortunately.
3 Likes
Thanks for your answer!
Yeah. That is a big problem, I guess.
1 Like
system
Closed
April 28, 2023, 4:36am
18
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.