Az egyéni domain SSL-ellenőrzése beragadt

Létrehoztad a rekordot. A dig megjeleníti. A platform még mindig függőben lévőként jelzi, és ez már egy órája így van. A beragadt egyéni domain-ellenőrzés éppen azért különösen frusztráló, mert minden saját magad által futtatható ellenőrzés sikeresnek tűnik.

Négy oka lehet, és mindegyik mechanikus jellegű. Az alábbi sorrendben haladva találhatod meg leggyorsabban a problémát.

Először: mit végez valójában az ellenőrzés?

Mielőtt egy tanúsítványkiadó szervezet kiad egy tanúsítványt, meg kell győződnie arról, hogy te rendelkezel a domainnév felett. Ennek két gyakori módja van, és az, hogy a platformod melyiket használja, meghatározza, mi okozhat hibát:

• HTTP-01 — a CA lekéri a http://your-domain/.well-known/acme-challenge/<token> címet, és egy meghatározott karakterláncot vár. Ehhez a domainre érkező normál HTTP-kéréseknek el kell jutniuk a platformhoz.
• DNS-01 — a CA egy TXT-rekordot keres. Ehhez a rekordnak léteznie kell, és láthatónak kell lennie a CA resolvere számára, amely nem feltétlenül az, amelyet te lekérdeztél.

A beragadt ellenőrzések szinte mindegyikénél valami a CA és e két feltétel egyike közé ékelődik.

1. ok: proxy működik a challenge előtt

Ez a leggyakoribb ok, amikor a domain CDN mögött található. Azért is zavaró, mert a proxy általában éppen az, amit használni szerettél volna.

Ha a DNS-rekordod proxyn keresztül működik, és nem közvetlenül a platformra mutat, a CA HTTP-01 kérése a proxynál végződik. A proxy a saját tanúsítványát szolgálja ki, a saját szabályait alkalmazza, és átirányítást, challenge-oldalt vagy 404-es választ adhat vissza — ezek egyike sem tartalmazza a CA által várt tokent.

A megoldás az, hogy átengeded a challenge-et:

• Kapcsold ki a proxyt (állítsd a rekordot szürke felhőre), amíg a tanúsítvány ki nem kerül, majd kapcsold vissza.
• Vagy zárd ki a /.well-known/acme-challenge/* útvonalat az átirányítási és hozzáférési szabályok alól.

A probléma forrása gyakran az, hogy az „Always Use HTTPS” és az „Under Attack” jellegű védelmek egyaránt megszakítják a HTTP-01 folyamatot, miközben a böngésződből nézve az oldal tökéletesen működik.

2. ok: nem megfelelő rekordtípus

A fennmaradó esetek nagy részét két hiba okozza:

Olyan címre mutató A rekord, amely változhat. Ha a platform egy hostname-et adott meg, használj CNAME-et. Az aktuális IP-cím A rekordba másolása egészen addig működik, amíg a cím meg nem változik alattad.

CNAME a zóna apexén. Az example.com szabványosan nem tartalmazhat CNAME-et az SOA- és NS-rekordjai mellett. Egyes szolgáltatók ALIAS, ANAME vagy „CNAME flattening” funkciót kínálnak ennek megkerülésére, mások nem. Ha a szolgáltatódnál ez nem érhető el, használj aldomaint — például app.example.com —, és irányítsd át rá az apexet.

# Amit a világ ténylegesen lát, nem azt, amit a vezérlőpult mutat
dig +short app.example.com CNAME
dig +short app.example.com A

Ha mindkét parancs üres eredményt ad, a lista többi pontjával még nem érdemes foglalkozni.

3. ok: nem azt méred, hogy lezajlott-e a propagáció

A dig argumentumok nélkül a te resolveredet kérdezi le, amely lehet, hogy a most létrehozott választ tárolta gyorsítótárban — vagy még rosszabb esetben a rekord létrehozása előtti NXDOMAIN-választ. A hosszú TTL-lel rendelkező negatív gyorsítótár-bejegyzés gyakori oka annak, hogy az ellenőrzés egy órán át sikertelen, majd beavatkozás nélkül sikeressé válik.

Kérdezd le közvetlenül az autoritatív szervereket, valamint egy nyilvános resolvert is, hogy lásd, mit fog valószínűleg érzékelni a CA:

# A zóna saját nameservereinek lekérdezése
dig +short app.example.com @$(dig +short NS example.com | head -1)

# A hálózatodon kívüli resolver lekérdezése
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8

Ha az autoritatív válasz helyes, a nyilvános resolverek viszont még hibás választ adnak, akkor a TTL lejártára vársz, és nincs mit kijavítani.

4. ok: a CAA elutasítja a tanúsítványkiadót

Ez ritka, a szokásos DNS-ellenőrzések során láthatatlan, és teljesen csendben okoz hibát.

A domaineden található CAA-rekord felsorolja, mely tanúsítványkiadó szervezetek adhatnak ki rá tanúsítványt. Ha van ilyen rekordod — gyakran egy régi beállításból örökölve vagy egy biztonsági ellenőrzés javaslatára létrehozva —, és nem tartalmazza a platformod által használt CA-t, a kiadás meghiúsul. Erről az egyetlen jelzés a CA naplóiban jelenik meg, amelyekhez nem férsz hozzá.

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

Az üres kimenet azt jelenti, hogy nincs korlátozás, ami megfelelő. Ha rekordokat kapsz vissza, add hozzá a platformod által használt CA-t, vagy távolítsd el a korlátozást.

A sorrend, amellyel a leggyorsabban megtalálod a hibát

1. Kérdezd le a rekordot egy nyilvános resolverrel a dig segítségével. Ha nincs válasz, a rekord hibás, vagy még nem propagálódott — itt állj meg.
2. Ellenőrizd, hogy a rekord proxyn keresztül működik-e. Ha igen, kapcsold ki a proxyt, vagy zárd ki az ACME-útvonalat.
3. Ellenőrizd a CAA-t az apexen és az aldomainen is.
4. Csak ezután vizsgáld meg annak lehetőségét, hogy a platform hibázik.

A beragadt ellenőrzések kilencven százaléka az 1. vagy a 2. lépésnél megoldódik.

Így működik ez a Dockupban

Két tervezési döntés kiküszöböli a találgatás nagy részét.

A DNS-rekordot a rendszer hozza létre. Ha a zónád Cloudflare-en található, és csatlakoztattad a fiókot, egy domain hozzáadásakor a rekord automatikusan létrejön, nem neked kell kézzel bemásolnod az értéket:

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

Ezzel kiküszöbölhető a gépelési hibákból és a helytelen rekordtípusból eredő problémák teljes köre — a platform tudja, hogy CNAME-re vagy A rekordra van-e szükség, és a megfelelőt hozza létre.

A hozzáférés két engedélyből áll. Zone:Read és DNS:Edit, semmi másból. A Dockup nem tudja olvasni a többi zónádat, nem módosíthatja a fiókbeállításokat, és nem férhet hozzá semmihez, amihez nem adtál engedélyt. A DNS-automatizálás csatlakoztatásához nem kell átadnod egy teljes fiók hozzáférését.

Az ellenőrzés és a tanúsítvány állapota domainenként látható, nem egyetlen összesített állapotként. Így a „DNS ellenőrizve, TLS függőben” pontosan azt jelenti, amit kell — két külön lépésről van szó, amelyek közül az egyik már befejeződött.

Gyakran ismételt kérdések

Mennyi ideig tart általában a tanúsítvány kiállítása? A DNS helyes feloldása után általában kevesebb mint egy percig. Ha körülbelül tizenöt percnél tovább van függőben, valami blokkolja a folyamatot, nem csupán lassú.

Miért működik a domainem a böngészőben, miközben az ellenőrzés sikertelen? Mert a böngésződ követi az átirányításokat és HTTPS-t használ, a challenge viszont egyikre sem képes. Egy proxy tökéletesen kiszolgálhatja az oldaladat, miközben elnyeli a sima HTTP-s ACME-kérést.

Használhatok CNAME-et a gyökérdomainemen? A szabványos DNS-ben nem. Használj olyan szolgáltatói funkciót, mint az ALIAS vagy a CNAME flattening, vagy irányítsd az apexet egy aldomainre átirányítással.

Mi az a CAA-rekord, és szükségem van rá? Azt korlátozza, hogy mely tanúsítványkiadó szervezetek adhatnak ki tanúsítványt a domainedre. Nincs rá szükséged, de ha van olyan rekordod, amely nem tartalmazza a platformod CA-ját, a tanúsítvány kiállítása csendben meghiúsul.