AutoSSL hinter Cloudflare: Wenn die Domain-Validierung fehlschlägt

SSL 5 Min. Lesezeit

Auf unseren cPanel-Hosting-Paketen beantragt und erneuert AutoSSL für jede Domain ein kostenloses Let’s Encrypt-Zertifikat. Zur Beantragung ruft die Zertifizierungsstelle von außen eine Bestätigungsdatei aus dem Pfad „/.well-known/acme-challenge/“ der Domain ab. Befindet sich die Domain hinter dem Cloudflare-Proxy (orangefarbene Wolke), läuft auch diese Anfrage über Cloudflare und gelangt in einer standardmäßig konfigurierten Cloudflare-Zone problemlos zum Webhosting. Die Umleitung auf HTTPS stellt dabei kein Hindernis dar.

Sollten dennoch Probleme auftreten, wird die Anfrage fast immer von einer Cloudflare-Funktion abgefangen oder umgeleitet: eine Firewall-Regel (Challenge), der Bot Fight Mode, der „I’m Under Attack“-Modus, eine Umleitungsregel oder die Tatsache, dass Cloudflare den Webhost überhaupt nicht erreichen kann. Die Lösung besteht darin, den Überprüfungsweg innerhalb von Cloudflare unantastbar zu machen; es geht nicht darum, sich mit AutoSSL auseinanderzusetzen.

Warum hilft die DNS-basierte Überprüfung nicht?

Sollte die dateibasierte Überprüfung fehlschlagen, versucht AutoSSL eine DNS-basierte Überprüfung: Es fügt einen _acme-challenge-TXT-Eintrag in die DNS-Zone der Domain ein. Wenn jedoch die Nameserver der Domain auf Cloudflare verweisen, wird die cPanel-Zone nicht abgefragt, sodass der Eintrag in Cloudflare nicht angezeigt wird. Daher schlägt diese Ausweichmethode hinter Cloudflare stets fehl, und aus einem einmaligen Fehler wird so die Meldung „Das Zertifikat wurde seit Wochen nicht erneuert“.

1. Sehen Sie sich die Fehlermeldung von AutoSSL an

Öffnen Sie in der cPanel-Gruppe „Sicherheit“ den Bereich „SSL/TLS-Zertifikate“ und klicken Sie auf die Registerkarte „Status“. Bei Domains mit gelber oder roter Markierung gibt die Fehlermeldung an, was die Ausstellung verhindert hat.

SSL-Zertifikate, Registerkarte „Status“: AutoSSL-Zertifikate und die Schaltfläche „AutoSSL ausführen“

Sollte die Fehlermeldung darauf hinweisen, dass die Domain nicht auf unseren Server verweist, oder sollte ein anderer, nicht mit Cloudflare zusammenhängender Grund vorliegen, hilft Ihnen der Artikel zu AutoSSL-Fehlern weiter.

2. Finden Sie heraus, ob die Ablehnung von Cloudflare oder vom Webhosting-Anbieter stammt

Legen Sie eine Testdatei im Verzeichnis für die Überprüfung ab. Über das cPanel-Terminal (oder im Dateimanager, indem Sie im Dokumentenstammverzeichnis der Domain den Ordner „.well-known/acme-challenge“ anlegen):

mkdir -p ~/public_html/.well-known/acme-challenge
echo proba > ~/public_html/.well-known/acme-challenge/proba.txt

Rufen Sie die Seite anschließend von Ihrem eigenen Rechner aus auf – einmal über Cloudflare und einmal direkt vom Webhosting-Server (ersetzen Sie „203.0.113.10“ durch die IP-Adresse Ihres Webhosting-Servers; diese finden Sie auf der cPanel-Startseite im Feld „General Information“ in der Zeile „Shared IP Address“):

curl -si http://pelda.hu/.well-known/acme-challenge/proba.txt | head -12
curl -si --resolve pelda.hu:80:203.0.113.10 http://pelda.hu/.well-known/acme-challenge/proba.txt | head -12
  • Wenn die direkte Anfrage den Text „proba“ liefert, die über Cloudflare geleitete Anfrage jedoch einen 403-Fehler, eine Challenge-Seite oder den Eintrag „cf-mitigated: challenge“ im Antwort-Header enthält, ist Cloudflare der Blockierer.
  • Sollte die Datei auch bei direkter Abfrage nicht zurückgegeben werden, liegt der Fehler beim Webhosting-Anbieter, meist handelt es sich um eine Weiterleitung oder Sperrung in der Datei „.htaccess“. Mehr dazu erfahren Sie im Artikel „AutoSSL-Fehler“.

Wenn Sie fertig sind, löschen Sie bitte die Testdatei: rm ~/public_html/.well-known/acme-challenge/proba.txt.

3. Die Korrektur in Cloudflare

Ausnahme für den Prüfpfad in der Firewall. Erstellen Sie in Cloudflare auf der Seite „Security › WAF › Custom rules“ eine Regel: Legen Sie als Bedingung „URI Path starts with /.well-known/acme-challenge/“ und als Aktion „Skip“ fest und wählen Sie die Schutzmaßnahmen aus, die die Anfrage blockiert haben (z. B. die anderen benutzerdefinierten Regeln und die verwalteten Regeln). Die Regel sollte an den Anfang der Liste gesetzt werden. Dies ist eine dauerhafte Lösung und funktioniert in jedem Cloudflare-Paket.

Bot-Fight-Modus. Für den Schalter „Bot-Fight-Modus“ im kostenlosen Paket können keine Ausnahmen festgelegt werden, und es ist bekannt, dass er auch Überprüfungsanfragen blockieren kann. Sollte die Ausnahme keine Abhilfe schaffen, deaktivieren Sie den Modus bitte. Der Bot-Schutz der kostenpflichtigen Pakete (Super-Bot-Fight-Modus) lässt sich auf authentifizierte Roboter zuschneiden.

Weiterleitungs- und Umwandlungsregeln. Wenn eine Regel Anfragen unter /.well-known/ weiterleitet oder umschreibt (beispielsweise eine Regel „alle Anfragen an www“ auf einen anderen Server), geht die Validierungsdatei nicht an. Schließen Sie diesen Pfad aus der Regel aus. Eine einfache Weiterleitung von HTTP zu HTTPS stellt kein Problem dar.

Modus „I’m Under Attack“. Solange dieser Modus aktiviert ist, wird jedem Besucher – einschließlich der Zertifizierungsstelle – eine Überprüfungsseite angezeigt. Deaktivieren Sie diesen Modus oder wenden Sie die oben genannte Ausnahme an.

Cloudflare kann das Hosting nicht erreichen. Wenn die Website selbst einen 522- oder 523-Fehler ausgibt, schlägt die Überprüfung aus diesem Grund fehl; dies muss zunächst behoben werden.

Klicken Sie nach der Korrektur auf der Registerkarte „Status“ auf die Schaltfläche „Run AutoSSL“ und warten Sie, bis die Domain einen grünen Status anzeigt.

Vorübergehende Umleitung: graue Wolke

Auf der Cloudflare-DNS-Seite können Sie den Domain-Eintrag auf den Modus „DNS only“ (graue Wolke) umstellen, AutoSSL aktivieren und anschließend den Proxy wieder einschalten. Dies funktioniert zwar, ist jedoch mit manuellem Aufwand verbunden. Während der Zeit ohne Proxy ist die IP-Adresse des Webhosts öffentlich sichtbar, und bei der nächsten Verlängerung tritt derselbe Fehler erneut auf. Diese Vorgehensweise eignet sich dazu, festzustellen, ob Cloudflare die Ursache des Problems ist; als dauerhafte Lösung ist sie jedoch nicht geeignet.

Wildcard-Zertifikat und vollständig abgeschottete Zone

Ein Wildcard-Zertifikat (*.pelda.hu) kann nur mit DNS-Verifizierung ausgestellt werden, und wie oben gesehen, kann AutoSSL keine Einträge in Cloudflare vornehmen. Wenn Sie ein Wildcard-Zertifikat benötigen oder die Zone so stark abgeschirmt ist, dass eine Dateiverifizierung nicht möglich ist, bleiben Ihnen zwei Möglichkeiten:

  • Ein Cloudflare Origin CA-Zertifikat, das Sie auf Ihrem Webhosting-Server installieren. Es ist bis zu 15 Jahre gültig und unterliegt keiner Überprüfungsfrist, wird jedoch ausschließlich von Cloudflare akzeptiert: Wenn Sie den Proxy deaktivieren, melden die Browser einen Fehler. Mehr dazu erfahren Sie im Artikel „SSL hinter Cloudflare“.
  • DNS-Verifizierung über die Cloudflare-API mit einem ACME-Client, der den TXT-Eintrag in Cloudflare schreibt. Dies ist auf einem VPS oder einem eigenen Server üblich (mit Wildcard-DNS-Verifizierung von Let’s Encrypt).

Infografik: Die Modi „Flexible“, „Full“ und „Full (strict)“ von Cloudflare mit Verschlüsselung der beiden Verbindungsabschnitte

Was Sie nicht tun sollten

  • Stellen Sie den Cloudflare-SSL/TLS-Modus nicht auf „Flexible“ ein, damit „SSL funktioniert“. Dies kann zu einer Weiterleitungsschleife führen, und die Daten werden unverschlüsselt zwischen Cloudflare und dem Hosting-Anbieter übertragen. Der richtige Modus ist „Full (strict)“.
  • Schalten Sie nicht die gesamte Firewall aus, es reicht aus, eine Ausnahme für eine einzige Route zu erstellen.
  • Schließen Sie die Domain nicht aus AutoSSL aus, nur um die Warn-E-Mails zu unterbinden: Das Zertifikat läuft dennoch ab.
  • Bitte lassen Sie die Testdateien nicht im Ordner „public_html“ liegen.

Vorbeugung

Wenn Sie mehrere Domains hinter Cloudflare betreiben, fügen Sie die Ausnahme „/.well-known/acme-challenge/“ in die Grundeinstellungen jeder Zone ein. Überprüfen Sie vierteljährlich die Registerkarte „Status“ oder behalten Sie die Ablaufdaten der Zertifikate im Auge (so überprüfen Sie das Ablaufdatum), damit ein Fehler nicht als abgelaufenes Zertifikat, sondern als Fehlermeldung per E-Mail erkannt wird. Sollten Sie dabei auf Schwierigkeiten stoßen, wenden Sie sich bitte an unseren Support.

Zurück: SSL-Artikel (35)