Fehlerbehebung · 15.2
Fehlerbehebung: DNS-01
Bei DNS-01 erstellt TLSPilot beim DNS-Provider einen TXT-Record _acme-challenge.<name>, wartet auf die Propagation, lässt ihn von der CA validieren und löscht ihn wieder. Fehler des DNS-Providers erscheinen mit dem HTTP-Status und der Antwort des Providers, zum Beispiel Cloudflare create TXT failed: <status> <answer>.
| Symptom | Ursache | Lösung |
|---|---|---|
| Alle Provider | ||
| DNS-01 for <certificate> is incomplete: Provider and Credential are required. | Im Schritt Settings des Zertifikats ist kein DNS-Provider oder kein Credential ausgewählt. | Wählen Sie den DNS-Provider und das DNS-Credential, siehe Kapitel ACME-Zertifikat (AC). |
| Statusleiste DNS-01 waiting <n>s for propagation, danach Authorization invalid for <name> mit One validator did not see the TXT yet (NXDOMAIN). | Die CA validiert von mehreren Standorten aus, siehe Kapitel Multi-Perspective Validation; einer davon sah den TXT-Record noch nicht. | Klicken Sie erneut auf Force renew… oder erhöhen Sie in den Einstellungen auf dem Tab ACME providers den Wert DNS-01 propagation wait (seconds, 15-300) (Standard 60), zum Beispiel auf 90–120. |
| DNS-01: public NS of the domain must match the DNS provider; check TXT with nslookup 8.8.8.8. | Der TXT-Record wurde bei einem Provider erstellt, der für die Domain nicht autoritativ ist. | Prüfen Sie die öffentlichen Nameserver der Domain und den TXT-Record mit nslookup -type=TXT _acme-challenge.<name> 8.8.8.8. |
| Log: Public DoH poll did not yet see TXT <record> … Proceeding to Let’s Encrypt validation anyway | Nach der Wartezeit war der TXT-Record bei den öffentlichen Resolvern von Cloudflare und Google noch nicht sichtbar. Die Prüfung ist nur ein Hinweis; TLSPilot fährt mit der Validierung fort. | Kein Handlungsbedarf, wenn das Zertifikat ausgestellt wird. Schlägt die Validierung danach fehl, erhöhen Sie DNS-01 propagation wait (seconds, 15-300). |
| Die Validierung schlägt nur bei manchen Versuchen fehl, obwohl der TXT-Record beim DNS-Provider sichtbar ist | Noch nicht alle autoritativen Nameserver liefern den TXT-Record aus, zum Beispiel weil ein sekundärer Nameserver später aktualisiert wird. Jede Netzwerkperspektive der CA kann einen anderen Nameserver fragen, siehe Kapitel Multi-Perspective Validation. | Listen Sie die Nameserver mit dig NS <zone> +short auf und fragen Sie jeden einzeln ab: dig @<nameserver> TXT _acme-challenge.<name> +short. Erhöhen Sie DNS-01 propagation wait (seconds, 15-300), bis alle antworten. |
| Die Validierung schlägt fehl, obwohl der TXT-Record an manchen Standorten sichtbar ist | Geo-DNS oder Traffic Steering beim DNS-Provider antwortet je nach Standort der Abfrage unterschiedlich. | Nehmen Sie _acme-challenge-Namen von standortbasierten Regeln aus, damit jeder Standort denselben TXT-Record erhält. |
| Der TXT-Record ist auf dem Management-Host oder im internen Netz sichtbar, aber die Validierung schlägt fehl | Split DNS: Interne Resolver antworten aus einer internen Zone. Die CA sieht nur die öffentliche Zone. | Erstellen Sie den Record beim DNS-Provider der öffentlichen Zone und prüfen Sie ihn mit einem öffentlichen Resolver, zum Beispiel dig @8.8.8.8 TXT _acme-challenge.<name>. |
| <Provider> zone <zone> not found. | Das Konto hinter dem Credential verwaltet diese Zone nicht, oder der Zonenname ist falsch. | Prüfen Sie die Zone beim Provider und die Berechtigungen des API-Tokens bzw. -Schlüssels. |
| Provider mit API-Token (Cloudflare, Hetzner, DigitalOcean, Linode, deSEC, Hostinger) | ||
| <Provider> credential <name> not found, zum Beispiel DigitalOcean credential … not found (password=API token). | Das DNS-Credential existiert nicht oder hat kein Token als Secret. | Erstellen Sie das Credential im Credentials Manager mit dem API-Token als Secret. |
| Hetzner: Hetzner zone id was not found in the Cloud API. Select the zone again. | HTTP 404: Das Zertifikat speichert eine Zonen-ID der Hetzner DNS Console. | Wählen Sie die Zone im Zertifikat erneut. TLSPilot ermittelt die Zone über ihren Namen. |
| Hetzner: Hetzner Cloud API rejected the token (<status>). mit der Aufforderung, ein neues Hetzner Cloud API Token zu erstellen | HTTP 401 oder 403: Das Token ist kein Hetzner Cloud API Token oder nicht gültig. Tokens der Hetzner DNS Console funktionieren nicht. | Erstellen Sie in der Hetzner Console ein Hetzner Cloud API Token. Bis dahin verwenden Sie DNS Manual, siehe Kapitel Manuelle DNS-Validierung. |
| Hostinger: Hostinger rejected a zone overwrite (DNS:4008). TLSPilot never sends overwrite=true. | Der Provider hat die Änderung der Zone abgelehnt. | Prüfen Sie die Zone bei Hostinger und versuchen Sie es erneut. |
| Provider mit Schlüssel und Secret (Route 53, GoDaddy, Porkbun, OVH, Namecheap, ClouDNS) | ||
| Route 53: Route 53 ListResourceRecordSets was denied (<detail>). UPSERT writes only this TXT value. | Der IAM-Policy fehlt route53:ListResourceRecordSets. TLSPilot ersetzt dann das ganze TXT-Set unter dem Namen durch den Challenge-Wert, sodass andere Werte unter demselben Namen verloren gehen. | Erteilen Sie route53:ChangeResourceRecordSets, route53:ListHostedZones und route53:ListResourceRecordSets. |
| Route 53 credential … missing. UserName=Access Key Id, Secret=Secret Access Key. Analog für GoDaddy (API Key, API Secret) und Porkbun (API key, Secret key). | Das Credential enthält nicht beide Werte. | Speichern Sie den Schlüssel als Benutzernamen und das Secret als Secret des Credentials. |
| OVH: OVH UserName must be ApplicationKey:ApplicationSecret:ConsumerKey. | Das OVH-Credential hat das falsche Format. | Geben Sie Application Key, Application Secret und Consumer Key wie in der Meldung beschrieben ein. |
| Namecheap: The Namecheap API Client IP allow-list is mandatory. | Namecheap akzeptiert API-Aufrufe nur von erlaubten IP-Adressen. | Fügen Sie die öffentliche IP-Adresse des Management-Hosts unter Namecheap Profile → Tools → API Access hinzu. |
| ClouDNS: ClouDNS authentication failed. oder ClouDNS auth-id must be a number (API User ID) | Statt der numerischen auth-id wurde der Login-Benutzername verwendet. | Verwenden Sie die numerische auth-id als Benutzernamen und das auth-password als Secret (API & Resellers → API Users). |
| Cloud-DNS mit Service Principal oder Service Account (Azure DNS, Google Cloud DNS) | ||
| Azure credential … not found (UserName=appId, Password=client secret or PEM certificate). oder Azure DNS put TXT failed: <status> | Die App Registration fehlt oder darf die DNS-Zone nicht ändern. | Speichern Sie die appId als Benutzernamen und das Client Secret oder PEM-Zertifikat als Secret. Erteilen Sie der App Registration Schreibzugriff auf die DNS-Zone. |
| Google Cloud DNS credential secret must be a service-account JSON key (client_email + private_key). oder No Google Cloud DNS managed zone in project … matches … | Das Secret ist kein Service-Account-JSON-Schlüssel, oder das Projekt enthält keine passende Zone. | Speichern Sie den JSON-Schlüssel des Service Accounts als Secret und prüfen Sie das GCP-Projekt der Zone. |
| RFC 2136 und DNS Manual | ||
| BIND nsupdate not found. Install BIND tools or set Dns01.Settings nsupdatePath to the nsupdate executable. | RFC 2136 verwendet nsupdate aus den BIND-Tools, die nicht installiert sind. | Installieren Sie die BIND-Tools auf dem Management-Host oder setzen Sie den Pfad zu nsupdate. |
| RFC2136 credential … not found (UserName=TSIG key name, Password=secret). oder nsupdate failed (<code>) | Der TSIG-Schlüssel fehlt oder passt nicht zum Nameserver. | Speichern Sie den Namen des TSIG-Schlüssels als Benutzernamen und den Schlüssel als Secret, und prüfen Sie die Adresse des Nameservers. |
| DNS Manual: waiting for DNS TXT | Kein Fehler. Die Bestellung wartet, bis Sie den TXT-Record erstellt haben. | Erstellen Sie den angezeigten TXT-Record und fahren Sie fort, siehe Kapitel Manuelle DNS-Validierung. |
| DNS-01 Alias Mode | ||
| Die Bestellung startet nicht: DNS-01 Alias Mode: CNAME _acme-challenge.<name> is missing. It must point at <target>. Fresh CNAMEs can stay hidden for a few minutes because of negative caching. | Der CNAME-Record wurde in der Produktivzone nicht erstellt, oder ein Resolver speichert die negative Antwort aus der Zeit vor der Erstellung im Cache. | Erstellen Sie den CNAME-Record genau wie unter Alias domain aufgeführt, prüfen Sie ihn mit Check CNAMEs oder dig +short CNAME _acme-challenge.<name> und warten Sie einige Minuten, wenn er gerade erst erstellt wurde, siehe Kapitel DNS-01 Alias Mode einrichten. |
| Die Bestellung startet nicht: … CNAME _acme-challenge.<name> points at <other name>, expected <target>. | Der CNAME-Record zeigt auf einen anderen Namen, zum Beispiel ohne den Namen des Zertifikats, auf eine andere Alias-Domain oder mit einem Tippfehler. | Korrigieren Sie das Ziel auf _acme-challenge.<name>.<alias domain>, wie im Zertifikat aufgeführt, und prüfen Sie, ob Alias domain die Zone beim DNS-Provider ist. |
| Die Bestellung startet nicht: … CNAME _acme-challenge.<name> has a TXT record at the same name. Remove it before the order. oder … has more than one CNAME. Keep a single CNAME to <target>. | Unter demselben Namen existiert ein TXT-Record, zum Beispiel von einer früheren Validierung, oder ein zweiter CNAME-Record. Ein Name mit CNAME-Record darf keine weiteren Records haben. | Löschen Sie den TXT-Record oder den zusätzlichen CNAME-Record unter _acme-challenge.<name> in der Produktivzone, sodass nur der eine CNAME-Record übrig bleibt. |
| Warnung, die Bestellung startet trotzdem: … CNAME _acme-challenge.<name> could not check. No DNS-over-HTTPS resolver answered. | Weder cloudflare-dns.com noch dns.google haben geantwortet, zum Beispiel weil eine Firewall oder ein Proxy ausgehendes HTTPS vom Management-Host blockiert. Das bedeutet nicht, dass der CNAME-Record fehlt. | Erlauben Sie ausgehendes HTTPS (TCP 443) vom Management-Host zu cloudflare-dns.com und dns.google und klicken Sie dann auf Check CNAMEs. Schlägt die Validierung fehl, prüfen Sie die CNAME-Records mit dig. |
| Die CNAME-Records sind korrekt, aber die Validierung schlägt mit SERVFAIL oder einem DNSSEC-Fehler fehl | DNSSEC ist in der Alias-Zone oder in der Produktivzone eingeschaltet, und die Signaturkette über den CNAME- und den TXT-Record ist unterbrochen, zum Beispiel wegen eines fehlenden oder veralteten DS-Records. | Prüfen Sie die DNSSEC-Signatur beider Zonen, zum Beispiel mit einem DNSSEC-Analyzer, und korrigieren Sie den DS-Record beim Registrar oder schalten Sie DNSSEC in der Alias-Zone aus, siehe Kapitel DNS-01 Challenge Delegation (CNAME-Alias). |