Wenn AutoSSL kein Zertifikat erstellen oder erneuern kann, liegt das Problem normalerweise im DNS-Bereich der Domain, in den A/AAAA-Einträgen, in der CAA-Richtlinie, im .well-known-Validierungspfad, im Cloudflare-Proxy oder im cPanel-Domain-Besitz. Diese Anleitung wählt die richtige Überprüfung basierend auf der Fehlermeldung aus.
AutoSSL failed to secure the domain.
DNS DCV: SERVFAIL looking up A for example.com
Local HTTP DCV error: 403
The domain is unmanaged.
CAA record prevents certificate issuance.
cPanel AutoSSL scannt die Domänen der Konten und erstellt oder erneuert kostenlose DV-Zertifikate für geeignete Domänen. Wenn die Zertifizierungsstelle das Domain Name System (DNS) oder die Hypertext Transfer Protocol (HTTP)-Basierte Methode für die Domänensteuerung-Validierung nicht bestätigen kann, wird das Zertifikat nicht ausgestellt.
Während des DNS-DCV werden die A- oder AAAA-Einträge der Domäne, die Nameserver-Antwort und die CAA-Richtlinie überprüft. SERVFAIL, Timeout oder falsche IP-Validierung können dazu führen, dass es sofort fehlschlägt.
HTTP DCV erfordert einen externen Zugriff auf den speziellen .well-known-Validierungs-Pfad innerhalb des Domainnamens. 403, 404, unendliche Weiterleitungen, Anwendungsrouter oder WAF-Regel können die Validierungsdatei blockieren.
Cloudflare-Orangewolke kann in der Regel mit AutoSSL funktionieren; jedoch kann eine falsche Ursprungsregel, Worker, Immer HTTPS verwenden, Zugriffsrichtlinie oder AAAA-Eintrag die Überprüfung an ein anderes Ziel umleiten.
Wenn eine Domäne nicht korrekt als Addon, Alias oder Subdomain im cPanel-Konto definiert ist, kann AutoSSL sie als unmanaged sehen. Selbst wenn DNS korrekt ist, müssen die Kontobesitz und die Userdata-Einträge überprüft werden.
AutoSSL-Protokolle geben den Grund für den Fehler klar an. Bevor das Zertifikat erneut ausgeführt wird, beweisen Sie, dass DNS aus der Außenwelt korrekt reagiert und dass der HTTP-Validierungspfad von außen zugänglich ist.
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: AutoSSL konnte den Zertifikat-Erstellungs- oder -Erneuerungsprozess für die Domain nicht abschließen.
Mögliche Ursache: DNS/HTTP-DCV, CAA, Rate-Limit, Domain-Besitz oder Verbindungsproblem
Bedeutung: Autorisierter DNS-Server konnte keine gültige A-Antwort erzeugen.
Mögliche Ursache: Beschädigte Zone, DNSSEC-Fehlpassung, Nameserver-Zugriff oder Upstream-DNS-Problem.
Bedeutung: Das Zertifikatsvalidierungssystem hat den DNS-Antwort nicht rechtzeitig erhalten.
Mögliche Ursache: UDP/TCP 53 Blockierung, Nameserver geschlossen, Firewall oder Netzwerkprobleme.
Bedeutung: Der Zugriff auf die Verifizierungs-URL ist verboten.
Mögliche Ursache: ModSecurity, .htaccess-Deny, WAF, Cloudflare-Access oder Dateirechte.
Bedeutung: Die Verifizierungsdatei wurde nicht von der erwarteten URL ausgespielt.
Mögliche Ursache: Falsche DocumentRoot, Rewrite/Router, Proxy, Umleitung oder Domainzeiger auf einen anderen Server.
Bedeutung: Der CAA-Eintrag lässt die Zertifizierungsstelle, die von AutoSSL verwendet wird, nicht zu.
Mögliche Ursache: Erstens nur issue/issuewild-Einträge oder CAA SERVFAIL für verschiedene CAs.
Bedeutung: cPanel erken nicht als von dem zugehörigen Konto verwaltetes Domain erkennt.
Mögliche Ursache: Die Registrierung der Addon-Domain fehlt, die Userdata ist korrupt, die Domain gehört zu einem anderen Konto oder wurde entfernt.
Bedeutung: Beide HTTP- und DNS-Verifizierungsverfahren haben fehlgeschlagen.
Mögliche Ursache: Domainname verweist auf den falschen Server, DNS ist defekt oder Validierungspfad ist blockiert.
Bedeutung: Die Erneuerung wurde verzögert, weil das aktuelle Zertifikat für eine ausreichende Zeit gültig ist.
Mögliche Ursache: Normal AutoSSL-Verhalten oder Schutz eines von Benutzer hochgeladenen Zertifikats.
Bedeutung: Der Server stellt ein Zertifikat bereit, das nicht zum angeforderten Domänennamen gehört.
Mögliche Ursache: SNI/vhost-Ubereinstimmung, falsche IP, Proxy, altes Zertifikat oder Dienst-SSL.
Bedeutung: Der IPv6 unterstützte Authentifizierungsdomäne kann versuchen, auf einem anderen Ziel zu validieren.
Mögliche Ursache: Alter oder falscher AAAA-Eintrag; neuer Server wurde nicht mit IPv6 konfiguriert.
Bedeutung: Die Zertifizierungsstelle hat die Wiederholungs- oder Domänensatzgrenze überschritten.
Mögliche Ursache: Häufige fehlgeschlagene Versuche, mehrere identische Zertifikate oder ein falscher Testprozess.
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.
/usr/local/cpanel/bin/autossl_check --user=USERNAME
Startet den AutoSSL-Check für ein bestimmtes cPanel-Konto und erzeugt ein Ergebnis.
/usr/local/cpanel/bin/autossl_check --all
Scannen Sie alle aktiven AutoSSL-Benutzer; verwenden Sie mit Vorsicht auf beschäftigten Servern
ls -lt /var/cpanel/logs/autossl/ | head
find /var/cpanel/logs/autossl -type f -mtime -2 -print 2>/dev/null | tail -n 20
Finden Sie die neuesten AutoSSL-Einträge im Log
dig +short A ALANADI
dig +short AAAA ALANADI
dig +short NS ALANADI
dig +short CAA ALANADI
Zeigt schnell A-, IPv6-, Nameserver- und CAA-Einträge an.
for ns in $(dig +short NS ALANADI); do echo "### $ns"; dig @$ns ALANADI A +norecurse; done
Überspringt den Resolver-Cache und vergleicht die Antworten autoritativer Nameserver.
mkdir -p /home/USERNAME/public_html/.well-known/acme-challenge
echo eka-dcv-test > /home/USERNAME/public_html/.well-known/acme-challenge/eka-test.txt
curl -IL http://ALANADI/.well-known/acme-challenge/eka-test.txt
Es wird getestet, ob der Verifizierungs-Pfad 200 zurückgibt; löschen Sie die Testdatei, wenn fertig.
echo | openssl s_client -connect ALANADI:443 -servername ALANADI 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Zeigt die durch SNI angebotenen Zertifikatsdomänennamen und -daten an.
/usr/local/cpanel/bin/whmapi1 get_domain_info domain=ALANADI
grep -R "^documentroot:" /var/cpanel/userdata/USERNAME/ALANADI* 2>/dev/null
Überprüft, mit welchem Konto und DocumentRoot die Domain verknüpft ist.
Zuerst bestimmen Sie den Überprüfungsart in den Protokollen; danach überprüfen Sie DNS, HTTP-Pfad, CAA, Kontoinhaberschaft und den ausgestellten Zertifikat separat.
Allgemeines fehlgeschlagenes Nachrichten anstelle, den DNS-DCV, HTTP-DCV, CAA- oder Rate-Limit-Grund in der relevanten Domänenzeile aufzeichnen.
find /var/cpanel/logs/autossl -type f -mtime -2 -print 2>/dev/null | tailDer Domainname muss auf die korrekte IP dieses cPanel-Servers verweisen. Alter AAAA-Eintrag und getrennte Nameserver-Delegation werden insbesondere überprüft.
dig +short A ALANADI
dig +short AAAA ALANADI
dig +trace ALANADI NS | tail -n 30CAA sollte nur die zugelassenen Zertifizierungsstellen angeben. Wenn DNSSEC verwendet wird, muss der DS-Eintrag des Registrars mit der Zonen-Signatur kompatibel sein.
dig CAA ALANADI +dnssec
dig DNSKEY ALANADI +dnssecDas Testdokument sollte 200 zurückgeben. Wenn 403/404, werden die .htaccess, ModSecurity, Proxy, Anwendungsrouter und Cloudflare-Regeln angepasst.
curl -IL http://ALANADI/.well-known/acme-challenge/eka-test.txtDie Domain muss im richtigen cPanel-Konto und mit dem richtigen DocumentRoot registriert werden. Wenn notwendig, wird die Userdata unter Expertenkontrolle neu erstellt.
/usr/local/cpanel/bin/whmapi1 get_domain_info domain=ALANADINachdem der Grund behoben wurde, führen Sie AutoSSL nur für den relevanten Benutzer aus und überprüfen Sie mit openssl die SAN und die Ablaufdatum des neuen Zertifikats.
/usr/local/cpanel/bin/autossl_check --user=USERNAME
echo | openssl s_client -connect ALANADI:443 -servername ALANADI 2>/dev/null | openssl x509 -noout -dates -ext subjectAltNameA/AAAA-Einträge, Proxy-Status, Ursprungsregeln, Worker, Zugriff und Umleitungsregeln werden überprüft. Wenn ein vorübergehender DNS-Only-Test durchgeführt werden soll, sollten Sicherheit und Ursprungs-IP-Sichtbarkeit berücksichtigt werden.
dig +short A ALANADI
dig +short AAAA ALANADI
curl -IL http://ALANADI/.well-known/acme-challenge/eka-test.txtModSecurity-Audit-Log, .htaccess-Deny-Regeln und Cloudflare/WAF-Politik werden überprüft. Anstatt die gesamte Sicherheitsschicht zu deaktivieren, werden Ausnahmen für die Authentifizierung nur zugelassen.
grep -R "ALANADI" /usr/local/apache/logs/modsec_audit.log 2>/dev/null | tail -n 40Die HTTP→HTTPS- und www→non-www-Regeln können sich gegenseitig ausschließen. Der Pfad .well-known sollte aus dem Redirect-Schleifen ausgeschlossen werden.
curl -IL --max-redirs 10 http://ALANADI/.well-known/acme-challenge/eka-test.txtDie IPv6-Validierung kann auf den alten Server gehen. Wenn IPv6 nicht verwendet wird, wird AAAA entfernt; wenn verwendet wird, muss der gleiche vhost und die Validierungsroute auch auf IPv6 funktionieren.
curl -6IL http://ALANADI/.well-known/acme-challenge/eka-test.txt
curl -4IL http://ALANADI/.well-known/acme-challenge/eka-test.txtDer Web-Site-AutoSSL-Prozess für WHM/cPanel/Exim/Dovecot-Dienstzertifikate ist nicht derselbe. Der Hostname-DNS und die Verwaltung des Dienst-SSL-Zertifikats werden separat geprütet.
hostname -f
dig +short A $(hostname -f)
/usr/local/cpanel/bin/checkallsslcertsDie häufigsten Ursachen sind falsche A/AAAA-Einträge, DNS-SERVFAIL, HTTP-Authentifizierungs-Wege, die 403/404-Statuscodes liefern, CAA-Einschränkungen und Domainen, die nicht im cPanel verwaltet werden, sowie Rate-Limits.
DNS-DCV beweist die Domänenkontrolle über DNS-Einträge, während HTTP-DCV die Domänenkontrolle über den Zugriff auf eine spezielle Validierungsdatei am Web-Root beweist.
Nicht immer. Es kann jedoch ein falscher Proxy, Worker, Access, Redirect oder AAAA-Konfiguration den Validierungsanfragen einen anderen Ziel oder eine 403/404-Antwort zurückgeben
Finden Sie .htaccess, ModSecurity, WAF oder Zugriffspolitik, die den Pfad .well-known/acme-challenge Blockiert, und Wenden Sie Eine Sichere Ausnahme Nur für Diesen Validierungspfad An.
DNS-Eintrag, der angibt, welche Zertifizierungsstellen Zertifikate für den Domainnamen ausstellen dürfen. AutoSSL-Anbieter schlägt fehl, wenn nicht erlaubt.
Ja. Wenn der Domainname AAAA enthält, kann die IPv6-Zieladresse für die Verifizierung verwendet werden. Wenn AAAA unterschiedlich oder nicht zugänglich ist, kann die DCV fehlschlagen.
Für ein bestimmtes Konto wird der Befehl /usr/local/cpanel/bin/autossl_check --user=USERNAME verwendet. Die Fehlerursache muss zuerst korrigiert werden.
Der Proxy/CDN könnte ein altes Zertifikat bereitstellen, an die falsche IP angeschlossen werden oder der Web-Service könnte das neue Zertifikat noch nicht geladen haben. Mit SNI sollte mit openssl überprüft werden.
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.