Türkei (Türkisch)
Germany (German)
Worldwide (English)
DNS-ÜberprüfungA-, AAAA-, TXT- und CAA-Einträge
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Plesk SSL! und Let’s Encrypt-Vorgänge überprüfen die Domänensteuerung mithilfe der ACME-Validierung. Falsche A/A AAAA-Einträge, fehlende _acme-challenge TXT, externe DNS, CAA-Begrenzungen, Port 80-Blockierung oder ausstehende Wildcard-Vorgänge können die Erteilung und automatische Neuerstellung des Zertifikats verhindern.
Domain validation failed
Incorrect TXT record found at _acme-challenge.example.com
DNS problem: NXDOMAIN looking up TXT
DNS problem: SERVFAIL looking up TXT
Invalid response from http://example.com/.well-known/acme-challenge/Die Zertifizierungsstelle überprüft, dass du die Domain mit HTTP-01 oder DNS-01-Validierung verwendest. Während HTTP-Pfade in normalen Zertifikaten verfügbar sind, erfordern Wildcard-Zertifikate in der Regel die _acme-challenge-TXT-Eintrag.
Bei der HTTP-01-Verifizierung sollte die A/AAAA-Eintrag des Domains auf den Plesk-Server richtig ausgerichtet sein und das Challenge-File sollte über Port 80 über das Internet zugänglich sein.
Bei der DNS-01-Validierung muss der neue TXT-Wert, der von Plesk angezeigt wird, auf dem autorisierten Nameserver veröffentlicht werden. Wenn der alte TXT-Wert bleibt, kann ein Fehler bei der falschen TXT-Zeichenfolge auftreten.
Wenn DNS von einem anderen Anbieter verwaltet wird, Plesk reicht das Hinzufügen eines Eintrags zur lokalen DNS-Zone allein nicht aus. Der Eintrag muss im tatsächlichen autorisierten DNS-Panel eingetragen werden.
Wenn auch ein Zertifikat erworben wurde, kann der Benutzer das alte Zertifikat trotzdem anzeigen, wenn es nicht dem Web-, Mail-, Webmail- oder Panelservice zugewiesen wurde.
Wildcard-TXT-Wert kann sich mit jeder Erneuerung ändern. Wenn der externe DNS-Anbieter nicht automatisch mit Plesk integriert ist, kann die automatische Erneuerung eine manuelle TXT-Update erfordern.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: ACME-Server sah einen anderen Wert anstelle des erwarteten TXT.
Mögliche Ursache: Altes TXT-Eintrag, falsche DNS-Panel oder unvollständige Bereitstellung.
Bedeutung: _acme-challenge-Name konnte auf DNS nicht gefunden werden.
Mögliche Ursache: Das TXT-Eintrag wurde nicht hinzugefügt oder in das falsche Host-Feld eingegeben.
Bedeutung: Autorisierter DNS-Server konnte keine gültige Antwort erzeugen.
Mögliche Ursache: DNSSEC-Korruption, Nameserver-Probleme oder DNS-Dienstfehler
Bedeutung: Die HTTP-Challenge-URL hat den erwarteten Token nicht zurückgegeben.
Mögliche Ursache: Falsche A/AAAA-Regel, Port 80-Block, Umleitung, Proxy- oder Anwendungsroutine.
Bedeutung: Der CAA-Eintrag lässt Let's Encrypt nicht zu, Zertifikate auszustellen.
Mögliche Ursache: Falsche oder einschränkende issue/issuewild-Eintrag.
Bedeutung: Let’s Encrypt hat eine große Anzahl an fehlgeschlagenen Versuchen in kurzer Zeit erkannt.
Mögliche Ursache: Zertifikanforderungen wurden vor der Behebung des Problems wiederholt gesendet.
Bedeutung: Die automatische Erneuerungsaufgabe für das aktuelle Zertifikat wurde nicht abgeschlossen.
Mögliche Ursache: DNS-Änderung, externer DNS, Aufgabenfehler oder Änderung des Domainscope.
Bedeutung: Das neue Zertifikat wurde nicht der richtigen Dienst zugewiesen oder der Proxy-Cache dient einem alten Zertifikat.
Mögliche Ursache: Domain-Hosting-Einstellung, Mail-/Panel-Zertifikat oder CDN-Edge-Zertifikat.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
dig +short A example.com
dig +short AAAA example.com
dig +trace example.com | tail -n 30Zeigt, auf welchen Server der Domainname und der IPv6-Eintrag verweisen.
dig +short NS example.com
dig SOA example.com +noall +answerBestimmt, welcher DNS-Anbieter die Änderung vornehmen sollte.
dig TXT _acme-challenge.example.com +noall +answerListet die TXT-Werte auf, die im externen Welt sichtbar sind.
curl -vI http://example.com/.well-known/acme-challenge/eka-testPort 80 zeigt externen Zugriff auf die Redirect- und Challenge-Pfad an.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltNameZeigt die von dem Server tatsächlich bereitgestellten Zertifikatnamen und -daten an.
grep -Ei 'letsencrypt|acme|certificate|sslIt' /var/log/plesk/panel.log | tail -n 120Plesk-Panel-Zertifikatsvorgänge zeigen Fehlerdetails.
plesk repair web example.comDomain-Web-Konfiguration und SSL-Zuweisungen-Check auf der Plesk-Seite
Geben Sie den Zertifikattyp an, überprüfen Sie den autorisierten DNS, testen Sie den Challenge-Pfad und stellen Sie nur dann erneut einen Antrag, wenn das Problem behoben wurde.
Wildcard-Zertifikate erfordern eine DNS-01-TXT-Verifizierung. Wenn ein normales Zertifikat über HTTP-01 erhalten werden kann, ist der Prozess anders.
NS-Einträge sollten im DNS-Panel außerhalb von Plesk eingerichtet werden, wenn der Plesk-Server nicht angezeigt wird.
dig +short NS example.comFalsche IPv6-Eintrag, kann alten TXT- oder restriktiven CAA-Zertifikatsprozess brechen.
Port 80 und der .well-known-Pfad sollten nicht durch einen Proxy, Redirect oder Sicherheitsregel blockiert werden.
curl -v http://example.com/.well-known/acme-challenge/eka-testSenden keine Continue/Reload- oder neue Anfrage ohne Anzeige in allen autorisierten Resolvern senden.
Die Zertifikatszuweisungen für die Website, Webmail, Mail und Panel können getrennt sein. Prüken Sie den öffentlichen Endpunkt mit openssl.
Während der HTTP-Challenge werden Umleitungen und WAF-Regeln überprüft. Die Origin A/AAAA-Eintragung muss korrekt sein; für Wildcard ist ein echter DNS-TXT-Eintrag erforderlich.
DNS Plesk außerhalb und API-Integration kann eine manuelle Aktualisierung des neuen TXT-Werts erfordern.
Mail-Server- und Webmail-Zertifikatszuweisungen werden auch im Abschnitt Tools & Settings überprüft.
Let’s Encrypt kann über IPv6 den falschen Ursprung erreichen. Verwendete AAAA-Einträge müssen entfernt oder auf die richtige IP ausgerichtet werden.
Mit dem Registrar DS-Eintrag wird die Schlüsselübereinstimmung mit dem DNS-Anbieter überprüft; ein Zertifikat wird vor der Auflösung des gebrochenen Zertifikatschlüssels nicht angefordert.
Die DNS- oder Challenge-Bedingungen können nach der ersten Einrichtung geändert worden sein. Ein häufiger Grund ist, dass der Wildcard-TXT-Wert in der externen DNS nicht automatisch aktualisiert werden kann.
Let’s Encrypt sieht stattdessen einen anderen oder alten TXT-Wert anstatt des erwarteten neuen Tokens.
Da es nicht möglich ist, alle unter dem Wildcard-Umfang liegenden Subdomänen einzeln über HTTP zu verifizieren, wird die Domänenprüfung mit der DNS-01-Methode nachgewiesen.
Nein. Cloudflare-Edge-Zertifikat ist zwischen Cloudflare und Besucher; Ursprungszertifikat des Plesk-Servers sollte auch verwaltet werden.
Ja. Wenn der Domainname auf einen falschen Server mit IPv6 weist, kann die Verifizierung vom entsprechenden Endpunkt aus fehlschlagen.
Das neue Zertifikat wurde möglicherweise nicht der relevanten Domain oder Dienst zugewiesen oder der CDN/Proxy zeigt sein eigenes Zertifikat an.
Nicht erforderlich; wenn jedoch vorhanden, können nur erlaubte Zertifizierungsstellen Zertifikate ausstellen. Falsche CAA-Verfahren verhindern die Ausstellung.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.