Lets Encrypt für Keyhelp Panel, SSL Fehler? [GELÖST]

[Systemweb]

Aufgesetzt wurde ein frisches System mit Debian 8.9 und Keyhelp 17.1

Der einzige angelegte Webbenutzer nutzt ein eigenes, signiertes Zertifikat. Keyhelp sollte ein LetsEncrypt erhalten. Es lag also vorerst noch kein signiertes Zertifikat bereits vor, das nur hätte verlängert werden müssen, sondern musste neu erstellt werden
.
Da bei Aufruf des ".well-known" Aliases jedoch konsequent eine Umleitung auf SSL erfolgte, konnte LetsEntrypt die Token-Prüfung nicht abschließen. Der Token wird ja bekanntlich generell immer per http geprüft, autom. Weiterleitungen auf https führen zum Abbruch und damit zum Fehler bei der Überprüfung.
Dies ist auch der Grund, warum Verlängerungen dieser Zertifikate bei vielen Kunden nicht funktionieren: Sie nutzen ein LetsEncrypt-Zertifikat und haben in Ihrem Keyhelp-Account für diese Domain die autom. Weiterleitung http://-->https:// aktiviert. Diese Kunden sollten aber stattdessen eine .htaccess Variante im www-Ordner ablegen, die das gleiche bewirkt. Auf diese Weise kann der alias "/.well-known/" weiter per http aufgerufen werden.

Das Auskommentieren der Weiterleitungen auf https in der keyhelp.conf des Apachen und anschließendem Apache-Restart brachte nicht die Lösung (evtl. Caching seitens LetsEncrypt, so dass immernoch auf https geleitet wurde?).

Einzige Lösung war, vom alten Server, der den gleichen Hostnamen bzw. Keyhelp-Domain hatte, die dort noch vorhandenen Dateien des LetsEncrypt Zertifikates zu holen und auf dem neuen Server in /etc/ssl/keyhelp/letsencrypt/keyhelp/ zu kopieren. Im Übrigen war die IP Änderung vor mehr als 48 Stunden erfolgt, dürfte damit auch längst bei LetsEncrypt bekannt sein.

Die Zertifikatsprüfung in Keyhelp zeigte nun keine Token-Erros mehr, da das Zertifikat bereits vorhanden und noch einige Zeit gültig ist.
Allerdings wurde nun trotz bereits gesetzter Einstellung für die Serverdienste, dass statt des default Keyhelp Zertifikates für alle Dienste das LetsEncrypt verwendet werden soll, nicht übernommen. Sicher hat Keyhelp dies aus gutem Grund nicht übernommen: Es bestand ja vorher auf Grund der Token-Fehler überhaupt kein entspr. Zertifikat auf dem Server, Apache hätte beim Start mit einer Fehlermeldung abgebrochen.

Also zuletzt für alle Dienste noch einmal auf "default" gesetzt, gewartet bis der Cron durchlief, dann wieder auf LetsEncrypt zurück und nun ist endlich alles wie es sein soll.

Um künftig solche Probleme zu vermeiden nun meine Frage:
Ist es möglich, den ".well-known" Alias generell auf http umzuleiten?
Falls nicht, kann man zumindest den Kunden im Panel bei Verwendung eines LetsEncrypt in den Domaineinstellungen das Setzen der Weiterleitung http://--->https:// autom. sperren?

[Alexander]

Da bei Aufruf des ".well-known" Aliases jedoch konsequent eine Umleitung auf SSL erfolgte, konnte LetsEntrypt die Token-Prüfung nicht abschließen. Der Token wird ja bekanntlich generell immer per http geprüft, autom. Weiterleitungen auf https führen zum Abbruch und damit zum Fehler bei der Überprüfung.

Das Problem kann ich leider nicht reproduzieren. Selbst mit Zwangsweiterleitungen wird das Zertifikat ordnungsgemäß aktualisiert (gerade noch einmal getestet). Außerdem Benutzen viele Kunden / wir selbst die Zwangsweiterleitung und diese Problembeschreibung trat bislang noch nicht auf - in jedem Fall ungewöhnlich.

Könnte Sie einmal Auszüge des Logs hinzufügen, wo nachdem ein Lets Encrypt Update fehlgeschlagen ist? Bzw. Wie lautet die Fehlermeldung in den Logs?

Wurden nach der KeyHelp Installation eigene Servereinstellungen vorgenommen?

[Systemweb]

Hier ein Auszug aus den Logs:

[28-Jul-2017 12:36:02] INFO --> check domain "XXXXXX.net'
[28-Jul-2017 12:36:02] INFO --> certificate file does not exist
[28-Jul-2017 12:36:02] DEBUG --> renew cert
[28-Jul-2017 12:36:02] DEBUG --> Using certificate authority "https://acme-v01.api.letsencrypt.org".
[28-Jul-2017 12:36:02] DEBUG --> Account already registered. Continue.
[28-Jul-2017 12:36:02] DEBUG --> Start certificate generation process for domains.
[28-Jul-2017 12:36:02] DEBUG --> Request callenge for "XXXXXX.net".
[28-Jul-2017 12:36:02] DEBUG --> Sending signed request to "/acme/new-authz".
[28-Jul-2017 12:36:03] DEBUG --> Got challenge token for "XXXXXX.net".
[28-Jul-2017 12:36:03] DEBUG --> Token stored at "/home/keyhelp/www/.well-known/acme-challenge/pou_WEBcRgi8u3DjKREJTUtdC4GfW-5_65OF0ssN7cU".
[28-Jul-2017 12:36:03] DEBUG --> Token should be available at "http:/XXXXXX.net/.well-known/acme-challenge/pou_WEBcRgi8u3DjKREJTUtdC4GfW-5_65OF0ssN7cU".
[28-Jul-2017 12:37:03] ERROR --> a lets encrypt error occurred: Self check is unable to access token uri "http://XXXXXX.net/.well-known/acme-chal ... 5OF0ssN7cU"
[28-Jul-2017 12:37:03] DEBUG --> finished
[28-Jul-2017 12:37:03] DEBUG --> send notification to: info@XXXXXX.eu
[28-Jul-2017 12:37:03] DEBUG --> email sent

Der Token war bei manueller Überprüfung der URL http://XXXXXX.net/.well-known/acme-chal ... 5OF0ssN7cU erreichbar, wurde jedoch wie bereits erwähnt autom. auf https weitergeleitet.
So weit ich bisher informiert war, stellt LetsEncrypt keine Zertifikate aus, wenn irgend eine Domain-Umleitung erkannt wird. Ob zwischenzeitlich an diesem Verfahren etwas geändert wurde ist mir nicht bekannt.
Dieses Problem kannte ich bereits von Froxlor, dass ich ebenfalls zur Zeit noch als Panel einsetze.
Keyhelp wurde ohne Modifikationen auf einem frisch aufgesetzten Debian minimal System ohne Fehler installiert. Auf dem Server wurden keinerlei manuelle Anpassungen vorgenommen.

[Alexander]

Sie haben die "manuelle" Prüfung, ob die Datei existiert, in Ihrem Browser vorgenommen?
Versuchen Sie einmal von der Konsole ihres Servers aus die gewünschte Datei zu erreichen. Das würde dem "self-check" entsprechen.
Hier sollten Sie nun eine Fehlermeldung erhalten, warum dies nicht möglich ist.

[Systemweb]

Auch bei Aufruf der URL via Konsole wird aktuell der gesetzten Weiterleitung auf https gefolgt. Allerdings liegt ja nun durch das manuelle Kopieren des alten Zertifikates eine verifizierte Verbindung vor.
Kann es sein, dass die generelle Weiterieitung auf https für den Keyhelp-Host nur dann Probleme macht, wenn noch kein gültiges, verifiziertes Zertifikat vorhanden ist? Eine Verlängerung vor Ablauf sollte eigentlich funktionieren.
So weit ich mich inzwischen belesen habe müssen die Token entgegen meiner bisherigen Annahme nicht nur per http, sondern dürfen auch per https erreichbar sein. Wenn aber https, dann wird wahrscheinlich ein signiertes Zert. erwartet.

Bei einer frischen Installation wird das Standard-Zertifikat für das Keyhelp-Panel installiert. Da dieses Zertifikat nicht validiert ist bekommt man beim Erstaufruf der KH Panel-URL im Browser auch eine entspr. Warnung und muss eine Ausnahme hinzufügen.

Stelle ich das zu verwendende Zertifikat wieder auf default zurück, ist ein Aufruf des Tokens per Konsole (wget) nicht mehr möglich.
Die Fehlermeldung gibt, den Hinweis, den Parameter "--no-check-certificate" hinzuzufügen.
Lösche ich nun das bereits vorhandene LetsEncrypt Zertifikat für das Panel wieder und schubse den SSL Cronjob an, weigert sich LE erneut, ein Zert. auszustellen: "Self check is unable to access token uri"

Bei bisherigen Installationen v14 und v17.0 kam es in der Vergangenheit nicht zu diesem Problem. Nur bei der kürzlichen Installation der v17.1 weigerte sich LetsEncrypt permanent, auch 2 Tage nach dem IP-Switch ein Zertifikat auszustellen.

Ich denke, hier liegt ein generelles Problem vor, wenn unsignierte Zertifikate vorliegen. In KH Panel wird stets die sichere Verbindung erzwungen.
Kunden haben da weniger Probleme: Sie haben in der Regel noch kein SSL konfiguriert, die Domain ist also bei Anforderung eines LE noch per http erreichbar und somit auch der Token. Bei Verlängerung eines bereits existierendem signierten Zertifikates gibt es kein Problem.

Problematisch wäre nur, wenn der Kunde mit einem selbstsignierten/abgelaufenem Zert. ein LE erwerben will und wie beim KH Panel es selbst auch so eingestellt hat, dass alles von http generell auf https weitergeleitet wird.

[Tobi]

Bei einer frischen Installation wird das Standard-Zertifikat für das Keyhelp-Panel installiert. Da dieses Zertifikat nicht validiert ist bekommt man beim Erstaufruf der KH Panel-URL im Browser auch eine entspr. Warnung und muss eine Ausnahme hinzufügen.

Eigentlich muss man nur ca. 5 Minuten warten. Nach erfolgreicher Installation beantragt KeyHelp selbst das passende Lets Encrypt Zertifikat.
Aber dieser Vorgang läuft erst NACH der Installation.

Eine Zwangsweiterleitung einer Domain auf https macht natürlich nur dann Sinn wenn die Domain auch wirklich ein valides Zertifikat verwendet. Also die Weiterleitung ausschalten und erst dann das Zertifikat anfordern. Folgeverlängerungen können dann problemlos auch per https erfolgen.

[Systemweb]

Danke Tobi dass du versuchst zu helfen. Es geht hier aber hauptsächlich um das LE für Keyhelp, nicht für einen Kunden. Die Zwangsweiterleitung von http auf https kann man für die KH Domain über das Panel nicht deaktivieren.

Nach frischer Installation hat KH ein default Zertifikat eingebunden das nicht validiert ist.
Die nicht änderbare Voreinstellung, dass KH nur per https erreichbar ist vererbt sich auch auf den Alias ".well-known".

Ich kann es mir jedenfalls nicht erklären, warum es mit bisherigen Installationen von KH funktionierte und mit der aktuellen 17.1 nicht mehr. Evtl. war in den Vorgänger-Versionen der alias noch per http ohne Zwangsweiterleitung auf https erreichbar?
Verlängerungen sind ja nicht das Problem, sondern die Erstausstellung des LE. Bei validiertem SSL ist der Zugriff auf den Token möglich, bei nicht-validem SSL nicht (außer wenn ma n dies explizit zulässt).

Kunden betrifft dieses Problem eigentlich nur, wenn sie diese Weiterleitung ebenfalls aktiviert haben und ein nicht-validiertes bzw. abgelaufenes Zertifikat aktiv haben.

[Systemweb]

Ich hätte wohl wie von Alexander empfohlen die Konsole des Dedi benutzen sollen, statt von externem Terminal die URL abzurufen.

Es stellte sich soeben heraus, dass in der hosts Datei ein Tippfehler in der IP war.
IP korrigiert, über Konsole des Servers ist der Token nun abrufbar.

Ich denke das Prob ist damit gelöst. Danke für eure Mühen.

[Tobi]

Nach frischer Installation hat KH ein default Zertifikat eingebunden das nicht validiert ist.

Richtig, das ist das selbstsignierte Stamm-Zertifikat deines Servers.

Es geht hier aber hauptsächlich um das LE für Keyhelp

Aber wie ich oben bereits schrieb, warte einfach 5 Minuten und rufe dann erst den Hostnamen auf. Bis dahin sollte deine frische Installation selbstständig das passende Let's Encrypt Zertifikat für deine Panel-URL eingebunden haben.

[Systemweb]

Bisher lief das genau so wie du beschrieben hast, Tobi.

Wenn man aber in der Datei /etc/hosts einen Tippfehler in der IP des Hostnamens einbaut kann dieser lokal natürlich nicht aufgelöst werden und es gibt weder nach 5 Minuten noch nach 5 Tagen ein LE Zertifikat

Auf diese Idee muss man erstmal kommen, stattdessen habe ich verzweifelt irgendwelche sinnvollen Erklärungen dafür gesucht, warum es sonst immer funktioniert hatte und ausgerechnet diesmal nicht...