Jump to content
Froxlor Forum
  • 0
Leapfrog

letsencrypt: Token kann nicht verifiziert werden

Question

Im Zuge eines dist-upgrade auf Debian 10 Buster versuche ich jetzt erstmalig letsencrypt unter Froxlor (0.10.13-1) in Betrieb zu nehmen.
Für die Froxlor-GUI selbst hat das jetzt auch schon mit einigen Mühen geklappt.

Im zweiten Schritt soll nun aber auch die Customer Domain SSL mittels letsencrypt Zertifikat erhalten. Das scheitert bislang aber beharrlich.

Soweit ich das im debug erkennen kann, kann der Validierungs-Server von letsencrypt.org das erzeugte Token auf meinem Webserver nicht finden und somit auch nicht erfolgreich verifizieren. Das Zertifikat wird deshalb auch nicht erzeugt.

(anonymisiert)

php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug
	[...]
[Sat Feb  8 10:06:03 CET 2020] kunde.myserver.de:Verify error:Invalid response from http://kunde.myserver.de/.well-known/acme-challenge/pEqRmsnXbBJFyNuDRxOmol1sdzioPAMZ_FsUueBajH [X.X.X.X]:
[Sat Feb  8 10:06:03 CET 2020] Debug: get token url.
[Sat Feb  8 10:06:03 CET 2020] GET
[Sat Feb  8 10:06:03 CET 2020] url='http://kunde.myserver.de/.well-known/acme-challenge/pEqRmsnXbBJFyNuDRxOmol1sdzioPAMZ_FsUueBajH'
[Sat Feb  8 10:06:03 CET 2020] timeout=1
[Sat Feb  8 10:06:03 CET 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header  -g  --connect-timeout 1'
[Sat Feb  8 10:06:03 CET 2020] ret='0'
[Sat Feb  8 10:06:03 CET 2020] Debugging, skip removing: /var/www/froxlor/.well-known/acme-challenge/pEqRmsnXbBJFyNuDRxOmol1sdzioPAMZ_FsUueBajH
...
[error] kunde.myserver.de :: empty certificate file! Cannot create ssl-directives
...

Im Access log meines apache sehe ich auch den vergeblichen Versuch das Token zu finden:

kunde-kunde.myserver.de-access.log:
...
64.78.149.164 - - [08/Feb/2020:10:06:01 +0100] "GET /.well-known/acme-challenge/pEqRmsnXbBJFyNuDRxOmol1sdzioPAMZ_FsUueBajH HTTP/1.1" 404 454 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

Wie es für mich aussieht, passen da in der Tat auch die Pfade des Tokens nicht richtig zusammen. Das Token entsteht ursprünglich unter /var/www/froxlor/.well-known, aber dann versucht die Gegenstelle es unter http://kunde.myserver.de/.well-known bei mir zu verifizieren. Diese Adresse zeigt aber auf den DocumentRoot des Kunden /var/customers/webs/kunde/ und nicht /var/www/froxlor/.

Wer macht nun den Fehler? Sucht letsencrypt.org das Token an der falschen Stelle oder versäumt Froxlor das Token irgendwo unterhalb von /var/customers/webs/kunde/ zu platzieren?

Ich komme an dieser Stelle nicht mehr weiter :(

Grüsse

Share this post


Link to post
Share on other sites

5 answers to this question

Recommended Posts

  • 0

Für diesen Fall gibt es die acme.conf die in den Konfigurations-templates bei aktiviertem let's encrypt zur Erstellung angezeigt wird und einen alias bereitstellt, damit eben Anfragen auf .well-known/acme-challenge auf das eine Verzeichnis zeigen. Hast du diese Konfiguration durchgeführt?

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, d00p said:

Für diesen Fall gibt es die acme.conf die in den Konfigurations-templates bei aktiviertem let's encrypt zur Erstellung angezeigt wird und einen alias bereitstellt, damit eben Anfragen auf .well-known/acme-challenge auf das eine Verzeichnis zeigen. Hast du diese Konfiguration durchgeführt?

Bin mir nicht ganz sicher, was du meinst. Eine Konfiguration unter dem Reiter System->Konfiguration habe ich nach den Upgrades auf Debian 10 nicht durchgeführt. Dort habe ich den Hinweis ""Das System ist bereits konfiguriert".

"Konfigurations-templates"  sagt mir gerade auch nichts. Alles, was ich damit in Verbindung bringen könnte, sind folgende System SSL-Einstellungen bei mir:

Verzeichnis für Let's Encrypt challenges -> /var/www/froxlor

Pfad zu acme.conf -> /etc/apache2/conf-enabled/acme.conf

Jene acme.conf existiert auf meinem Server jedoch nicht, ich weiß auch nicht, wo die herkommen sollte.

Und jenes challenge-Verzeichnis wird bei dem Handshake bereits benutzt, wie ich in den Logs sehe.

Mir ist nicht klar,  was der Soll-Zustand ist, ob die Gegenstelle das Token unter /var/www/froxlor/.well-known/acme-challenge verifizieren soll (und wo das Token real ja auch liegt) oder unterhalb der Kunden-Domain /var/customers/webs/kunde/ .well-known/acme-challenge.

 

 

 

 

 

Share this post


Link to post
Share on other sites
  • 0

Wenn du SSL/Let's Encrypt aktivierst muss dein System natürlich auch entsprechend konfiguriert sein, damit das funktioniert. Gehe doch einfach noch mal durch die Konfiguration für den Webserver bzw. kontrolliere einfach ob du (default) die Datei /etc/apache2/conf-enabled/acme.conf hast und was drinsteht

17 minutes ago, Leapfrog said:

Mir ist nicht klar,  was der Soll-Zustand ist, ob die Gegenstelle das Token unter /var/www/froxlor/.well-known/acme-challenge verifizieren soll (und wo das Token real ja auch liegt) oder unterhalb der Kunden-Domain /var/customers/webs/kunde/ .well-known/acme-challenge.

Hab ich zwar schon erklärt, aber vielleicht war es nicht deutlich:

1) Ein Zertifikatsrequest legt intern in /var/www/froxlor/.well-known/acme-challenge eine Datei an

2) Von außen wird nun versucht auf [domain]/.well-known/acme-challenge/[datei] zuzugreifen

3) Bei einem korrekt konfigurierten System erkennt der Webserver, dass eine Anfrage auf .well-known/acme-challenge/ stattfindet und leitet diese mit einem sogenannten Alias real auf die datei im Ordner /var/www/froxlor/.well-known/acme-challenge

Share this post


Link to post
Share on other sites
  • 0

Halleluja d00p,

jetzt klappt auch die Zertifizierung der Kunden-Domain!!

Ursache war die fehlende acme.conf. Die tiefere Ursache für deren Fehlen wiederum war mein Missverständnis der Konfiguration-Page. Ich habe die immer umgangen, weil ich der Annahme war sie diene nur der Erstkonfiguration eines frischen Systems. Gleichzeitig war meine Befürchtung, sie würde mein System mit default-Konfigurationen überschreiben/löschen.

In diese bedrohliche Richtung hatte ich dann natürlich auch die Beschreibung des Handstarts interpretiert:
"Alternativ, führe den folgenden Befehl als root-Benutzer auf der Shell aus, um die Dienste automatisch zu konfigurieren."

Auf dein Anraten hatte ich es jetzt einfach mal gewagt und zu meiner Freude feszgestellt, daß dort nur fehlende Konfigurationshinweise (u.a. zur acme.conf) standen :)

Großartig, vielen Dank für deine Hilfestellung, d00p! Problem gelöst!

Grüsse

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...