Ich habe certbot-auto endlich auf der AWS EC2 Linux-Instanz installiert, die mir Probleme bereitet hat, und versuche, ein Wildcard-Zertifikat von Let’s Encrypt zu bekommen.
Mir wurde gesagt, ich solle einen TXT-Eintrag unter dem Namen (zum Schutz der Unschuldigen geändert) _acme-challenge.foo.bar.net mit einem bestimmten Wert erstellen.
Also gehe ich zur Konsolenseite von Route 53 und wähle die gehostete Zone von bar.net aus. Ich füge den Datensatz _acme-challenge.foo.bar.net mit dem angegebenen Wert hinzu, klicke auf „Datensatz speichern“ und warte ein paar Minuten. Dann wähle ich ihn aus und klicke auf „Datensatz testen“, und Route 53 denkt, er sei veröffentlicht.
Aber wenn ich certbot-auto anweise, fortzufahren, und Let's Encrypt nach dem Datensatz sucht, ist er nicht da. Und wenn ich ein nslookup -q=txt _acme-challenge.foo.bar.net mache, bekomme ich
Server kann _acme-challenge.foo.bar.net nicht finden
und für nslookup -q=txt foo.bar.net erhalte ich
Server kann foo.bar.net nicht finden
Und dennoch finde ich es, wenn ich einen regulären nslookup auf foo.bar.net durchführe.
Was läuft schief?
Antwort1
Ich habe die Ursache des Problems gefunden.
Beim Überprüfen der im NS-Eintrag aufgeführten Server fiel mir zufällig auf, dass der Name im TXT-Eintrag nicht derselbe war (Namen wurden immer noch geändert, um die Unschuldigen zu schützen).
_acme-challenge.foo.bar.net
Aber
_acme-challenge.foo.bar.net.bar.net
Mir war nicht aufgefallen, dass der Datensatz-Editor der Route 53-Konsole den Domänennamen der gehosteten Zone rechts neben das Feld zur Eingabe des Datensatznamens einfügt und ihn dann an Ihre Eingabe anhängt. Ich habe also den gesamten Datensatznamen eingegeben und dadurch „.bar.net“ zweimal dort eingefügt, einmal explizit und einmal implizit.
Um einen Satz zu prägen, der zuerst von einem gewissen fiktiven Ingenieur namens Montgomery Scott geäußert wurde:
Je mehr Sie über die Wasserleitungen nachdenken, desto leichter kann der Abfluss verstopfen.