Let's Encrypt Zertifikat auf der Fritzbox

War auch nur eine Alternative zum basteln auf der FB selbst. Sollte mit nem RasPI oder so auch gehen, oder ggf. auf einem Gerät von nem Freund.
 
Hallo zusammen!

Ich verwende jetzt letsencrypt.sh mit der dns-01 challenge. Vorteil: Ich muß im lokalen Netz keinen Webserver laufen haben.

Zur Automatisierung evtl. noch ein paar Anregungen. Hier ein kleines Powershell script zum Login und hochladen des Zertifikats: (getestet auf FritzOS 6.50 und Fritzbox 7490):

Herzlichen Dank dafür! Das hat mir sehr geholfen, dass Aktualisieren des Zertifikats auf meiner Fritzbox zu automatisieren. War bloss die falsche Sprache. :) Falls es jemanden helfen sollte, hier mein Port des Codes nach bash:

Code:
#!/bin/bash

# parameters
USERNAME="<may be empty>"
PASSWORD="<fritzbox/user password>"
CERTPATH="<location of privkey.pem and fullchain.pem>"
CERTPASSWORD="<may be empty>"
HOST=http://fritz.box

# make and secure a temporary file
TMP="$(mktemp -t XXXXXX)"
chmod 600 $TMP

# login to the box and get a valid SID
CHALLENGE=`wget -q -O - $HOST/login_sid.lua | sed -e 's/^.*<Challenge>//' -e 's/<\/Challenge>.*$//'`
HASH="`echo -n $CHALLENGE-$PASSWORD | iconv -f ASCII -t UTF16LE |md5sum|awk '{print $1}'`"
SID=`wget -q -O - "$HOST/login_sid.lua?sid=0000000000000000&username=$USERNAME&response=$CHALLENGE-$HASH"| sed -e 's/^.*<SID>//' -e 's/<\/SID>.*$//'`

# generate our upload request
BOUNDARY="---------------------------"`date +%Y%m%d%H%M%S`
printf -- "--$BOUNDARY\r\n" >> $TMP
printf "Content-Disposition: form-data; name=\"sid\"\r\n\r\n$SID\r\n" >> $TMP
printf -- "--$BOUNDARY\r\n" >> $TMP
printf "Content-Disposition: form-data; name=\"BoxCertPassword\"\r\n\r\n$CERTPASSWORD\r\n" >> $TMP
printf -- "--$BOUNDARY\r\n" >> $TMP
printf "Content-Disposition: form-data; name=\"BoxCertImportFile\"; filename=\"BoxCert.pem\"\r\n" >> $TMP
printf "Content-Type: application/octet-stream\r\n\r\n" >> $TMP
cat $CERTPATH/privkey.pem >> $TMP
cat $CERTPATH/fullchain.pem >> $TMP
printf "\r\n" >> $TMP
printf -- "--$BOUNDARY--" >> $TMP

# upload the certificate to the box
wget -q -O - $HOST/cgi-bin/firmwarecfg --header="Content-type: multipart/form-data boundary=$BOUNDARY" --post-file $TMP | grep SSL

# clean up
rm -f $TMP
 
Es gibt jetzt auch eine python client, der auch unter freetz auf der fritz!box läuft. Es ist der certbot client für letsencrypt, siehe auch ticket .
Dieses Freetz Packet packt den Certbot Client in ein crond job, der monatlich das Zertifikat erneuert.
AVM forwarding für port 443 muss eingerichtet weden und dann wird der standalone web server von certbot das zertifikat holen und verifizierien.

Man braucht auch noch die dazugehörigen Python Packete, welche folgendes Ticket zur Verfügung stellt.

Alles zusammen bekommt man auch von:
git clone ​​https://github.com/dirk-dhu/freetz.git freetz-devel

Mit folgendem Befehl kann ein Update bei Veränderungen gezogen werden:

git fetch; git reset —hard origin/master

Einen Patch kann man durch das Klicken auf den gewünschten Commit, welcher unter der URL:

​https://github.com/dirk-dhu/freetz/commits/master

zu finden ist, erstellen, dazu muss in der Adress-Zeile hinter dem SHA Wert .patch angehangen werden.
 
100 Dank germeier für den port nach Bash, das hat mir eine Menge arbeit erspart, ich nutzte diese Version des Script um via Raspi das Letsencrypt Cert auf die Fritzbox zu pushen. danke.
 
Hallo zusammen!

Ich verwende jetzt letsencrypt.sh mit der dns-01 challenge. Vorteil: Ich muß im lokalen Netz keinen Webserver laufen haben.

Ich bin ebenfalls Besitzer einer FritzBox 7490 und würde gerne ein Let's Encrypt-Zertifikat für meine DDNS (bei selfhost.de registriert) anlegen. Habe auch eine Synology NAS dahinter laufen, Port Forwarding für spezielle Synology-Dienste läuft aber über die FB auf die NAS. So wie ich das verstanden habe, ermöglicht obiger Code von germeier ein automatisiertes Updaten des Zertifikats auf der Fritzbox. Da ich aber bisher so gut wie noch nie mit bash gearbeitet habe, wäre für mich eine Schritt-für-Schritt-Anleitung sehr hilfreich.
Oder ist es vermutlich doch schlauer, ein port 80 forwarding (sollte das dann dauerhaft sein??) auf die NAS zu schalten, und die das Zertifikat-Handling übernehmen zu lassen? Könnte ich dann noch über den Browser von extern auf die Web-Oberfläche der FB zugreifen? Stehe hier gerade mit ein paar Fragezeichen da und würde mich über eine Anleitung "für dummies" freuen.

Danke schonmal! :)
 
Hallo zusammen!

Herzlichen Dank dafür! Das hat mir sehr geholfen, dass Aktualisieren des Zertifikats auf meiner Fritzbox zu automatisieren. War bloss die falsche Sprache. :) Falls es jemanden helfen sollte, hier mein Port des Codes nach bash:

Hallo germeier,
Ich krieg das leider nicht hin. Bei mir läuft eine Fritzbox 7590, auf dem Raspberry Pi verwende ich das Script von https://github.com/srvrco/getssl um ein aktuelles Zertifikat in Nginx auf dem Pi zu installieren. Irgendwie klappte der Client von Letsencrypt bei mir nicht. An das genaue Warum kann ich mich leider nicht erinnern. Als Resultat habe ich dann 2 Files für Nginx (copy&paste aus der default.conf):

Code:
ssl_certificate /etc/ssl/box.mydomain.de.chain.crt;
ssl_certificate_key /etc/ssl/box.mydomain.de.key;

Insofern habe ich folgendes in deinem Script angepasst:
Code:
cat $CERTPATH/box.mydomain.de.key >> $TMP
cat $CERTPATH/box.mydomain.de.chain.crt >> $TMP

Das Script läuft ohne Fehlermeldung durch. In der Fritzbox bleibt es aber bei der Meldung: Die FRITZ!Box verwendet ein Zertifikat, das sie selbst erstellt hat.

Lasse ich mir mit echo in deinem Script die Variablen ausgeben, bekomme ich für $SID immer "0000000000000000", alle anderen Variablen sind für mich zumindest plausibel immer mit zufälligen Zeichen befüllt. Keine Ahnung ob es bereits bei der Variable für SID scheitert und 0000000000000000 normal ist.

Vielleicht habe ich das Ding auch nur falsch verstanden, wie auch immer, es wird nichts hochgeladen bzw. die Box nimmt das Ding nicht an. Mangels Fehlermeldung sehe ich da leider nix weiter...

Update 1:
Ich hab mal das erstellte Zertifikat nicht bereinigen lassen, sondern es manuell importiert. Das klappt soweit. Ich nehme also an, das der Login nicht klappt. Vielleicht gibts da Unterschiede auf der 7590 zur 7490?

Update 2: Hab das Problem gefunden. Das Passwort war falsch. Blöde Sonderzeichen...
Ich werde das Script ein wenig anpassen und prüfen ob als SID die 0000000000000000 zurückkommt. Wenn ja, verschicke ich eine Mail an root und breche mit "exit 1" ab. Für's Erste reicht es aber.

Vielen Dank für das Script.
 
Zuletzt bearbeitet:
Hallo!
Gibt es hier jemanden der mir dabei helfen kann einen Webserver (lighttp) auf der Fritzbox 7362SL mit freetz-ng mit einem Let's Encrypt Zertifikat zu konfigurieren?

Ich hatte mich für das acme.sh-Verfahren entschieden weil das schon als Freetz-package angeboten wird. Die Anforderung eines Zertifikates hat auch geklappt aber
nun weiß ich leider nicht wo was in welches Verzeichnis einzutragen ist.

Die Anleitungen im Internet gehen im allg. von einer Installation für apache aus und die für lighttp haben wohl auch eine andere Version als Basis. Die Konfigurationsdatei
lighttpd.conf kann wohl nur vor dem komplieren editiert werden, sehr umständlich für trial-and-error Vorgehensweise...

Für jede Hilfe dankbar verbleibend

# baerenbisch
 
Probier mal /tmp/flash/lighttpd/crt.pem und ca.pem
Aber grundsätzlich solltest du im Konfigurationsfrontend das Zertifikat einspielen können.
 
Zuletzt bearbeitet:
Also ich habe nun "dehydrated" installiert aber beim aufrufen mit "rc.dehydrated init" kommt immer wieder
eine Fehlermeldung, nämlich:

Was mache ich da noch falsch?


Code:
running dehydrated ...
# INFO: Using main config file /etc/dehydrated/config
Processing www.mydomain.de
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for www.mydomain.de
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for www.mydomain.de authorization...
 + Cleaning challenge tokens...
 + Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: ["type"]      "http-01"
["status"]      "invalid"
["error","type"]        "urn:ietf:params:acme:error:unauthorized"
["error","detail"]      "Invalid response from http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc [77.13.154.186]: \"\u003c?xml version=\\\"1.0\\\" encoding=\\\"iso-8859-1\\\"?\u003e\\n\u003c!DOCTYPE html PUBLIC \\\"-//W3C//DTD XHTML 1.0 Transitional//EN\\\"\\n         \\\"http://www.\""
["error","status"]      403
["error"]       {"type":"urn:ietf:params:acme:error:unauthorized","detail":"Invalid response from http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc [77.13.154.186]: \"\u003c?xml version=\\\"1.0\\\" encoding=\\\"iso-8859-1\\\"?\u003e\\n\u003c!DOCTYPE html PUBLIC \\\"-//W3C//DTD XHTML 1.0 Transitional//EN\\\"\\n         \\\"http://www.\"","status":403}
["url"] "https://acme-v02.api.letsencrypt.org/acme/chall-v3/13060478464/JOngRw"
["token"]       "h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc"
["validationRecord",0,"url"]    "http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc"
["validationRecord",0,"hostname"]       "www.mydomain.de"
["validationRecord",0,"port"]   "80"
["validationRecord",0,"addressesResolved",0]    "77.13.154.186"
["validationRecord",0,"addressesResolved",1]    "2003:e0:a3bf:29a:c225:6ff:fea6:166d"
["validationRecord",0,"addressesResolved"]      ["77.13.154.186","2003:e0:a3bf:29a:c225:6ff:fea6:166d"]
["validationRecord",0,"addressUsed"]    "2003:e0:a3bf:29a:c225:6ff:fea6:166d"
["validationRecord",0]  {"url":"http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc","hostname":"www.mydomain.de","port":"80","addressesResolved":["77.13.154.186","2003:e0:a3bf:29a:c225:6ff:fea6:166d"],"addressUsed":"2003:e0:a3bf:29a:c225:6ff:fea6:166d"}
["validationRecord",1,"url"]    "http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc"
["validationRecord",1,"hostname"]       "www.mydomain.de"
["validationRecord",1,"port"]   "80"
["validationRecord",1,"addressesResolved",0]    "77.13.154.186"
["validationRecord",1,"addressesResolved",1]    "2003:e0:a3bf:29a:c225:6ff:fea6:166d"
["validationRecord",1,"addressesResolved"]      ["77.13.154.186","2003:e0:a3bf:29a:c225:6ff:fea6:166d"]
["validationRecord",1,"addressUsed"]    "77.13.154.186"
["validationRecord",1]  {"url":"http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc","hostname":"www.mydomain.de","port":"80","addressesResolved":["77.13.154.186","2003:e0:a3bf:29a:c225:6ff:fea6:166d"],"addressUsed":"77.13.154.186"}
["validationRecord"]    [{"url":"http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc","hostname":"www.mydomain.de","port":"80","addressesResolved":["77.13.154.186","2003:e0:a3bf:29a:c225:6ff:fea6:166d"],"addressUsed":"2003:e0:a3bf:29a:c225:6ff:fea6:166d"},{"url":"http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc","hostname":"www.mydomain.de","port":"80","addressesResolved":["77.13.154.186","2003:e0:a3bf:29a:c225:6ff:fea6:166d"],"addressUsed":"77.13.154.186"}]
["validated"]   "2021-05-12T16:12:58Z")
done.
 
Sehr schön ... so sieht man zwar (immerhin) das Ergebnis, aber muß hinsichtlich des Aufrufs und der Vorbereitungshandlungen weiter raten.

Aber wenn ich wirklich raten sollte und in der Ausgabe den HTTP-Fehler 403 sehe, würde ich als erstes darauf tippen, daß da das Verzeichnis, was intern als WELLKNOWN verwendet werden soll (https://github.com/dehydrated-io/dehydrated/blob/master/docs/wellknown.md) nicht in der Konfiguration des HTTP-Servers eingetragen wurde. Das ist aber - angesichts der Infos oben hoffentlich verzeihlich - auch nur geraten von mir.
 
Ohne dehydrated zu kennen, aber anhand des logs hat letsencrypt unter http://www.mydomain.de/.well-known/acme-challenge/h_XmpMoWwrhoMCduYPMoU3LqkahnU_SKenWOplJOBcc was anderes vorgefunden als erwartet.
Ja, da steht nämlich: GAR NICHTS.

Habe alles (für mich) erdenkliche gecheckt. Schreibrechte, Besitzer, der Server ist von außen über 80 und 443 erreichbar. Im Netz gibt es viele Fundstellen zu dieser Fehlermeldung ...
Ich frage mich auch worin der Sinn dieses packages besteht wenn explizit gefordert wird den Server unter Port 80 und 443 erreichen zu können was die Fritzbox ja nur unter gröbsten
Verrenkungen ermöglicht. (Portweiterleitungen auf alternative Ports werden von acme/dehydrated konsequent abgelehnt)
 
Peter hats eh schon geschrieben: Ohne Config vom Webserver und Dehydrated wird dir niemand helfen können.
wenn explizit gefordert wird den Server unter Port 80 und 443 erreichen zu können
DNS-Challenge fordert das nicht und spart "gröbste Verrenkungen"
Portweiterleitungen auf alternative Ports werden von acme/dehydrated konsequent abgelehnt
Das sieht das ACME Protokoll bei der HTTP-01 challenge so vor.

Oben hast du geschrieben, dass die Zertifikatsanforderung mit acme.sh geklappt hat. Warum nimmst du dann dehydrated? Die Zertifikate kommen dann auch nicht zu in lighttpd.
 
DNS-Challenge fordert das nicht und spart "gröbste Verrenkungen"
DNS-Challenge vs. feste Ports auf der FritzBox?
Meinen wir hier etwas unterschiedliches?


dehydrated.conf:


Code:
#!/bin/bash

BASEDIR=/tmp/flash/dehydrated
PRIVATE_KEY=/tmp/flash/dehydrated/private_key.pem

WELLKNOWN=/var/media/ftp/uStor01/webseiten/mydomain/.well-known/acme-challenge/
KEYSIZE=2048
[email protected]
#
RENEW_DAYS="25"
 
Das sagt aber auch noch nichts über die Konfiguration des Webservers aus ... dieser wird von dehydrated NICHT automatisch konfiguriert (aber die entsprechende Anleitung habe ich ja oben schon einmal verlinkt).
 
Ich wollte ergänzen

Code:
server.modules += ("alias")
alias.url += (
 "/.well-known/acme-challenge/" => "/var/www/dehydrated/",
)


Leider gelang es mir nicht die lighttpd.conf zu editieren.
Änderungen werden nicht übernommen ...


Hier die lighttpd.conf:


Code:
server.modules += ( "mod_access" )
index-file.names = ( "index.cgi", "index.html", "index.htm", "default.htm", "index.php", "index.rb" )
mimetype.assign = (
".pdf" => "application/pdf",
".sig" => "application/pgp-signature",
".spl" => "application/futuresplash",
".class" => "application/octet-stream",
".ps" => "application/postscript",
".torrent" => "application/x-bittorrent",
".dvi" => "application/x-dvi",
".gz" => "application/x-gzip",
".pac" => "application/x-ns-proxy-autoconfig",
".swf" => "application/x-shockwave-flash",
".tar.gz" => "application/x-tgz",
".tgz" => "application/x-tgz",
".tar" => "application/x-tar",
".zip" => "application/zip",
".mp3" => "audio/mpeg",
".m3u" => "audio/x-mpegurl",
".wma" => "audio/x-ms-wma",
".wax" => "audio/x-ms-wax",
".ogg" => "application/ogg",
".wav" => "audio/x-wav",
".gif" => "image/gif",
".jar" => "application/x-java-archive",
".jpg" => "image/jpeg",
".jpeg" => "image/jpeg",
".png" => "image/png",
".xbm" => "image/x-xbitmap",
".xpm" => "image/x-xpixmap",
".xwd" => "image/x-xwindowdump",
".css" => "text/css",
".html" => "text/html",
".htm" => "text/html",
".js" => "text/javascript",
".asc" => "text/plain",
".c" => "text/plain",
".cpp" => "text/plain",
".log" => "text/plain",
".conf" => "text/plain",
".text" => "text/plain",
".txt" => "text/plain",
".dtd" => "text/xml",
".xml" => "text/xml",
".mpeg" => "video/mpeg",
".mpg" => "video/mpeg",
".mov" => "video/quicktime",
".qt" => "video/quicktime",
".avi" => "video/x-msvideo",
".asf" => "video/x-ms-asf",
".asx" => "video/x-ms-asf",
".wmv" => "video/x-ms-wmv",
".bz2" => "application/x-bzip",
".tbz" => "application/x-bzip-compressed-tar",
".tar.bz2" => "application/x-bzip-compressed-tar",
"" => "application/octet-stream",
)
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi", ".rb", ".cgi" )
server.port = 80
server.pid-file = "/var/run/lighttpd.pid"
server.username = "wwwrun"
server.groupname = "wwwrun"
connection.kbytes-per-second = 0
server.kbytes-per-second = 0
server.chroot = "/var/media/ftp/uStor01/webseiten/mydomain/"
dir-listing.activate = "disable"
dir-listing.encoding = "utf-8"
server.modules += ( "mod_openssl" )
$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.pemfile = "/tmp/flash/lighttpd/crt.pem"
#ssl.use-compression = "disable"
}
server.document-root = "/websites"
 
Ich habe den Verdacht, Du hast da einen riesigen Denkfehler in Deinem Ansatz - vielleicht kommt einem das aber auch nur so merkwürdig vor, weil Du zwei Probleme (in zwei verschiedenen Threads) gleichzeitig lösen willst.

Wie funktioniert das mit dem Let's Encrypt-Zertifikat und dehydrated?

Das Shell-Skript dehydrated kümmert sich ausschließlich darum, die notwendigen Dateien zum richtigen Zeitpunkt in einem Verzeichnis zu erzeugen, das ohnehin schon von einem HTTP-Server für Clients (auf der WAN-Seite einer FRITZ!Box, wenn wir schon von einer solchen reden) bereitgestellt wird.

BEVOR also dehydrated IRGENDETWAS ausrichten kann, muß man dafür sorgen, daß bei einem Zugriff aus dem Internet auf die aktuelle IP-Adresse (der Box) am Port 80 auch eine Datei http://<mein_domain_name>/.well-known/acme-challenge/index.html OHNE jede Angabe von Credentials (Benutzername und/oder Kennwort) einwandfrei gelesen werden kann, wobei man diese Datei index.html im passenden Verzeichnis selbst erzeugen muß. Erst dann, wenn das problemlos funktioniert, hat der LE-Server überhaupt die Chance, die von dehydrated an derselben Stelle erzeugten Daten zur Kontrolle der "Herrschaft" über die angegebene Domain auch abzurufen - das alles muß also schon funktionieren, BEVOR man dehydrated überhaupt aufruft.

Daher kann auch Dein Vorhaben mit der Ergänzung oben nicht funktionieren ... aber es wäre bei korrekter Konfiguration des HTTP-Servers vermutlich auch gar nicht erforderlich, noch den Alias-Namen in die Konfiguration einzubauen, wenn tatsächlich das Basisverzeichnis für "document root" des HTTP-Servers stimmt und /var/media/ftp/uStor01/webseiten/mydomain wäre (wie es wohl als chroot-Jail angedacht ist nach der Konfiguration).

Nur paßt das wieder so gar nicht zur Angabe von server.document-root am Ende der lighttpd-Konfiguration, wenn da ein /websites steht ... denn danach wäre das "Wurzelverzeichnis" für den HTTP-Content ja das Unterverzeichnis /websites unterhalb des Root-Verzeichnisses /var/media/ftp/uStor01/webseiten/mydomain - also letztlich das Verzeichnis /var/media/ftp/uStor01/webseiten/mydomain/websites. ALLES das, was dann über diesen Server ausgeliefert werden könnte und nicht über einen anderen Alias von anderer Stelle käme, stünde unterhalb dieses Verzeichnisses ... bei dehydrated wäre dann also auch /var/media/ftp/uStor01/webseiten/mydomain/websites/.well-known/acme-challenge als Verzeichnis für die Response-Daten anzugeben.

Da wäre dann die Vergabe eines Alias-Namens (und dann stimmt die dehydrated-Konfiguration auch nicht mehr) wohl doch die schlauere Lösung ... zumal die Challenge-/Response-Daten einer ACME-Validierung ohnehin nur temporären Charakter haben (ein "replay" wäre hier auch tödlich) und daher auch nur an einer temporären Stelle gespeichert werden sollten. Da paßt dann /var/www/something auch im FRITZ!OS, weil /var eben beschreibbar ist.

Aber selbst dann, wenn das aus dem LAN alles funktioniert und sich die erwähnte index.html (oder was auch sonst da verwendet wird) problemlos abrufen läßt, gilt das ja noch lange nicht für die WAN-Seite einer FRITZ!Box ... dazu braucht es dann schon noch eine Portfreigabe für TCP-Port 80 (und andere akzeptiert das ACME-Protokoll nicht) auf der WAN-Seite, wobei ich mir ohnehin (basierend auf dem anderen Thread) die Frage stelle, ob diese FRITZ!Box überhaupt direkt am Internet hängt oder ob sie als IP-Client irgendwo in einem LAN steckt und es für das Ausstellen eines LE-Zertifikats ohnehin noch die Portfreigabe von Port 80 an der externen IPv4-Adresse auf die interne IP-Adresse dieser FRITZ!Box bräuchte ... zumal man dann bei einer solchen Portfreigabe ja auch noch externe und interne Portnummer unterschiedlich wählen könnte (weil das der ACME-Server gar nicht bemerkt).

Irgendwie wird das - sobald man beide Threads miteinander verknüpft - schon sehr schräg und man merkt immer mehr, wieviele Informationen da am Ende tatsächlich fehlen. Denn auch eine Freigabe von Port 80 extern auf die eigene interne IPv4-Adresse, ist bei einer FRITZ!Box eben nur mit der Änderung der ar7.cfg möglich (oder anderer Dateien) ... und das dann eben auch nicht "on the fly" und nur mal für die Zeit, wo ein LE-Zertifikat erzeugt werden soll. Spätestens wenn dazu noch ein Neustart des dsld erforderlich sein sollte und der bei PPPoE mit der Vergabe einer neuen externen Adresse einhergeht, wird es schnell komplizierter, als mancher es wahrhaben will.
 
Nun hat es doch noch geklappt. Es waren tatsächlich die Pfade. Die GUI zur lighttp Konfiguration setzt an den Pfad für die Websites immer noch sein eigenes "/websites" dran.
Und dann noch eine Datei namens "index.html" in das Verzeichnis ".../mydomain/.well-known/acme-challenge". Dieses Verzeichnis verschwindet dann nach erfolgreicher
Zertifizierung von alleine.
Letztlich noch "cntmgr -s" und "rc.lighttpd start" in die "rc.custom". Hier habe ich zwischen die beiden Aufrufe noch ein "sleep 10" gesetzt weil das stoppen des cntmgr eine
gewisse Zeit in Anspruch nimmt und der lighttpd dann zu früh startet und die Ausführung wegen besetzter Ports 80 und 443 verweigert.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.