-
-
Save wikrie/f1d5747a714e0a34d0582981f7cb4cfb to your computer and use it in GitHub Desktop.
| #!/bin/bash | |
| ## this little Gist is for Copy the Letsencrypt Cert from an Linux machine (e.g. Raspberry PI or Synology NAS) | |
| ## to the router (Fritzbox). | |
| ## It is usefull to be able to speak to the Router over DDNS without any Cert issue in the Browser. | |
| ## thanks to https://gist.github.com/mahowi for the perfect Idea | |
| ## put it in /etc/letsencrypt/renewal-hooks/post so it gets run after every renewal. | |
| ## since Fritz OS 7.25 it is needed to select a Username, from a security point of view | |
| ## it is always a good idea to have a non default user name. And as normaly a Fritz Box | |
| ## is connected to the Internet, the prefered method should be WITH Username. | |
| # parameters | |
| USERNAME="needed since Fritz OS 7.25" | |
| PASSWORD="fritzbox-password" | |
| CERTPATH="path to cert eg /etc/letsencrypt/live/domain.tld/" | |
| CERTPASSWORD="cert password if needed" | |
| 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 |
Hey Eldiabolo21,
ich hab auch die 7530 (zwar neueres OS) und das Skript funktioniert aktuell (auch aus verschiedenen Netzen).
Wie sieht es denn mit den Berechtigungen des cert-user's aus?
Ich sehe hier bei mir in der Box, dass Benutzern auch die Berechtigung für das Lesen und Ändern von Einstellungen gegeben werden kann (bei nur einem User kann dies nicht deaktiviert werden -> Admin).
Prüfe das mal bitte.
Dann könntest du nochmal Testweise einen neuen Benutzer / Passwort anlegen bzw. vergeben.
Vielleicht auch nochmal das Skript prüfen ob du dort aus Versehen (zu viel) Änderungen vorgenommen hast.
Hey, auch vielen Dank auch fuer deine Antwort, leider keine Erfolg.
Berechtigung zum Einstellungen aendern waren gesetzt. Neuen Nutzer angelegt, gleiches Problem. Passwort fuer den aktuellen Cert-user habe ich auch schon x-mal geaendert.
Was ich aber rausgefunden habe, dass wenn ich im Scipt wirklich das falsche Passwort angebe, kommt noch eine ganz andere Meldung vom Script...
Habe zum Testen mal die Einstellung "Zugang aus dem Internet erlaubt" eingeschaltet, aber auch keine Besserung.
Noch mehr Ideen?
Edit:
Ich werde bekloppt.... Ich habe beide Sites mit Wireguard verbunden. Also einmal 192.168.8.0/24 was Probleme macht und 192.168.16.0/24, wo es problemlos geht. Beide Sites koennen einander erreichen.
Ich habe gerade das Script einfach auf den Host in 192.168.16.0/24 kopiert, so wie es auf dem anderen host war, und es geht o.OOOOO
Das laesst mich irgendwie zu dem Schluss kommen, dass eins der Pakete borken ist... Allerdings sind beide Hosts Ubuntu 20.04.5... Ich vergleiche mal Paketversionen...
Edit 2:
the mystery has been solved!!! It was the f****ng certificate. I created a cert with a docker compose command from here: https://stackoverflow.com/a/66638930
Unfortunately that did something super weird with the created certs (I assume it's the --rsa-key-size 4096) and they can't be imported into the Fritzbox. I actually reached that conclusion when I compared the TMP-files the script creates. The private key on the non working machine was much shorter. I don't know what exactly went wrong, it still seemed like a valid cert, but didn't work for the Fritzbox. I ran certbox directly on the host, w/o any further key size args and imported the cert with success.... URGH, glad this is over...
Hey, auch vielen Dank auch fuer deine Antwort, leider keine Erfolg. Berechtigung zum Einstellungen aendern waren gesetzt. Neuen Nutzer angelegt, gleiches Problem. Passwort fuer den aktuellen Cert-user habe ich auch schon x-mal geaendert.
Was ich aber rausgefunden habe, dass wenn ich im Scipt wirklich das falsche Passwort angebe, kommt noch eine ganz andere Meldung vom Script...
Habe zum Testen mal die Einstellung "Zugang aus dem Internet erlaubt" eingeschaltet, aber auch keine Besserung.
Noch mehr Ideen?
Edit: Ich werde bekloppt.... Ich habe beide Sites mit Wireguard verbunden. Also einmal 192.168.8.0/24 was Probleme macht und 192.168.16.0/24, wo es problemlos geht. Beide Sites koennen einander erreichen.
Ich habe gerade das Script einfach auf den Host in 192.168.16.0/24 kopiert, so wie es auf dem anderen host war, und es geht o.OOOOO Das laesst mich irgendwie zu dem Schluss kommen, dass eins der Pakete borken ist... Allerdings sind beide Hosts Ubuntu 20.04.5... Ich vergleiche mal Paketversionen...
Edit 2: the mystery has been solved!!! It was the f****ng certificate. I created a cert with a docker compose command from here: https://stackoverflow.com/a/66638930
Unfortunately that did something super weird with the created certs (I assume it's the
--rsa-key-size 4096) and they can't be imported into the Fritzbox. I actually reached that conclusion when I compared the TMP-files the script creates. The private key on the non working machine was much shorter. I don't know what exactly went wrong, it still seemed like a valid cert, but didn't work for the Fritzbox. I ran certbox directly on the host, w/o any further key size args and imported the cert with success.... URGH, glad this is over...
Great you managed to make it work.
I use acme.sh to automatically issue / renew a wildcard certificate (single domain certificates are even easier to setup) and automatically install them from my VPS onto my fritzbox via wireguard. If you are interested you can check it out here: https://gion.io/blog/automatic-renewal-of-wildcard-certificates/
Anyhow, I am glad you found the error and made it work.
Have a great weekend!
This sentence comes to my mind:
Security breaking down our nerves (2023)
I had the same problem and it was because the certificate's private key was an ecdsa key.
Changing key_type to rsa in /etc/letsencrypt/renewal/xxx.conf and renewing the certificate (certbot renew --force-renewal) generated a certificate with a rsa private key which could be imported again.
Since recently, I was using this script to update the certificate on both, a Fritz!Box and a Fritz!Repeater 1200 AX.
The certificate option is not exposed in the UI on repeaters, but worked via this script just fine.
The repeater is now on 7.57 and it stopped working.
The returning page indicates a problem:
`
Das Update ist fehlgeschlagen:
Invalid variable name.
`Anyone experiencing the same problem?
@mbo77 maybe you want to give fritzbox_upload_certificate a try. it was recently updated for 7.57.
Looks nice and clean, but I suspect the problem is on the repeater side.
POSTing to the URL still gives the same message on the returing page:
Das Update ist fehlgeschlagen:
Invalid variable name.
Works fine with 7530AX on 7.57.
I suspect the repeater triggers the wrong function internally:
FRITZ!Repeater Update
Das Update ist fehlgeschlagen:
Invalid variable name.
Wiederholen Sie das Update oder starten Sie den FRITZ!Repeater neu.
This looks to me some message related to updating the firmware itself.
As the server-side binary is called "firmwarecfg", I suspect it was initially deployed for updating the firmware and later was extended to handle certificates as well. So maybe they messed it up internally on the repeater.
I will open a support case with AVM.
@mbo77 unfortunately i don't have access to a Fritz!Repeater 1200 AX. i ran the fritzbox_upload_certificate sucessfully with a FRITZ!WLAN Repeater DVB-C. it's not possible to upload a certificate via the ui but the /cgi-bin/firmwarecfg url works well with at least 7.01.
let us know what AVM says. 😄
No luck..
Die Funktion für den Import der Zertifikate war für unsere Repeater nie geplant und über die Benutzeroberfläche auch nicht möglich.
Durch aktuelle FRITZ!OS-Änderungen im Unterbau ist es nun bei Repeatern auch komplett entfernt worden.
Gerne gebe ich Ihr Anliegen aber als Verbesserungsvorschlag an unsere Produktentwicklung weiter.
@mbo77 What a pity. But thanks for sharing the answer. At least I'll list the Fritz!Repeater 1200 AX with 7.57 as unsupported. Unfortunately there is no easy way to get the product name and the OS version from a fritzbox to check it.
Hello,
I want to share my experience.
The script worked well. At a certain point it looks not working properly: no error prompted and no certificate imported.
After troubleshooting it I've discovered the issue was related to letsencrypt that changed from rsa to ecdsa. I replaced in the letsencrypt configuration file as below
#key_type = ecdsa
key_type = rsa
And now is working well back.
hope my experience will help you.
(tested with fritz7590 and 7530ax both version 7.57)
Hi,
this worked for me for years. now my boxtogo app say something like verification chain error ... after some testing i see the box don't have the cert anymore and don't get it with the script ...
maybe its the same like xraver say - but ... how to change? i use letsencrypt in a docker.
thx ;)
In my installation (standard debian) there is a file in /etc/letsencrypt/renewal with the name of your domain.
Inside there is a key: key_type. you have to change it as described above and request new certificate.
Hi Folks,
I do not maintain this script anymore as I use a complete solution for all of my Cert Issues.
https://github.com/NginxProxyManager/nginx-proxy-manager
so there you can also add and create a Cert for the FritzBox and all your services. So no need to create this and transfer it anymore.
hi xraver,
i found this file and changed it, but i'm not able to certbot renew --force-renewal ... it say something will use port 80 (what the nginx proxy is) -.-
@draddy82 With my Script you do not create any Cert it just upload the existing Letsencrypt Cert to a AVM FirtBox.
see the first 2 Lines in my Script Description
this little Gist is for Copy the Letsencrypt Cert from an Linux machine (e.g. Raspberry PI or Synology NAS)
to the router (Fritzbox).
yeah is ok wikrie
problem seems to be that the actual cert is not rsa ... but the fritzbox only accept rsa.
Nice! Thank you for this little script!
Hey, danke fuer die schnelle Antwort.
Server der das Script ausfuehrt und Fritzbox sind beide in 192.168.8.0/24. Passwort fuer den dedizierten cert-user der Fritzbox besteht das Passwort nur Zahlen, Gross- und Kleinbuchstaben. Daran kanns auch nicht liegen.
Sonst noch ne Idee?
Gruss!