[Frage] WLAN Repeater 1750E modifizieren

Du hast absolut recht ... mein Fehler bei der Auswahl der korrekten Version.

Ich bin ein Verzeichnis "zu hoch" gewesen (weil ich die Quellen für den Repeater nicht in meinen "normalen" Arbeitsverzeichnissen habe, da ich keinen besitze, mußte ich die erst auspacken, als das mit diesem Thread und dem Aufbau der Image-Datei losging):
Code:
vidar:/tmp/squashfs-root $ grep VERSION etc/version
export FIRMWARE_VERSION=${CONFIG_VERSION_MAJOR}.06.06
export FIRMWARE_SUBVERSION=""
export CVC_FIRMWARE_VERSION=073008002010
   echo $FIRMWARE_VERSION
                        echo $FIRMWARE_VERSION
                        echo $FIRMWARE_SUBVERSION
                        echo $CVC_FIRMWARE_VERSION
vidar:/tmp $ cd ..
vidar:/tmp $ grep VERSION var/tmp/squashfs-root/etc/version
export FIRMWARE_VERSION=${CONFIG_VERSION_MAJOR}.07.01
export FIRMWARE_SUBVERSION=""
   echo $FIRMWARE_VERSION
                        echo $FIRMWARE_VERSION
                        echo $FIRMWARE_SUBVERSION
vidar:/tmp $
Damit habe ich natürlich einen vollkommen anderen Stand verglichen (bzw. mit "grep cert" darin gesucht) und noch dazu von einem vollkommen anderen Gerät, der da zum falschen Zeitpunkt am richtigen Ort herumlag:
Code:
vidar:/tmp # grep PRODUKT_NAME squashfs-root/etc/init.d/rc.conf
export CONFIG_PRODUKT_NAME="FRITZ!Box 6360 Cable"
export CONFIG_PRODUKT_NAME="FRITZ!Box 6360 Cable (kdg)"
export CONFIG_PRODUKT_NAME="FRITZ!Box 6360 Cable (kbw)"
export CONFIG_PRODUKT_NAME="FRITZ!Box 6360 Cable (um)"
Dann bin ich nur noch verblüfft, warum die FTP-Einstellungen von AVM nicht einfach in eine Abfrage der NAS-Fähigkeiten eingebettet wurden und trotzdem eine andere Datei verwendet wird. Die "Idee" dahinter werde ich vermutlich auch nie wirklich verstehen ...
 
@hermann72pb: welche Reiter gibt es bei Dir unter "Internet/Freigaben"? Wird Dir "Fritz!Box-Dienste" angezeigt? Wenn nicht versuche mal die URL selbst zu basteln, müsste sowas sein:
Code:
http://fritz.box/?sid=CURRENT_SESSION_ID&lp=remoteHttps
CURRENT_SESSION_ID ist der Platzhalter, der durch die eigentliche SESSION_ID zu ersetzten wäre
 
Diese Lua-Datei hatte ich mir schon gestern direkt an der Box angeschaut und mir über ctlmgrctl die Parameter mir "r" auf beiden Boxen ausgelesen. Mich hat auch gewundert, wie er13 schon festgestellt hat, dass dort fast alle mir als relevant erscheinenden Optionen bei einer 7390 mit importierten Zertifikaten und bei der 1750 gleich gesetzt waren. Aber weiter bin ich mit meinen Versuchen doch nicht gekommen.
Jetzt ein Paar Fragen an euch, weil ihr mir wieder etwas zu schnell seid:
1. @PeterPawn Wie soll ich denn mit "firmwarecfg" quasi "zufuss" die Zertifikate manuell importieren? Kennst du da die nötigen Befehle? Wo kann man sie sich abgucken? Im welchen Lua-Script. Und geht es denn überhaupt über Konsole? Denn irgendwie hast du was von http und Co. beim Import gesprochen. Oder habe ich da was missverstanden.
2. Du sprichst was von den Keys, die mit Passwörter verschlüsselt werden usw. Ist es denn wirklich so? Ich dachte, beim Import werden die Zertifikate einfach rüberkopiert, höchstens irgendwie zusammengesetzt mit cat, auch die Keys. Ich hatte es nicht geprüft, kann aber noch machen, meiner Meinung nach kann ich aber die Key und Cert Datei von einer anderen Box nehmen und bei der 1750 einfach so verwenden. Wenn ich da falsch liege, bitte korrigieren.
3. Ihr spricht was davon, https-Seite bei 1750 einfach mal kurz freischalten. Wie mache ich das denn? Ich weiß nicht, ob 1750 überhaupt so leicht das darstellen kann. Denn https ist bei 7390 und Co unter DSL- und Internet-Einstellungen. Zwar hat der 1750 was ähnliches für LAN (und am LAN betreibe ich meinen 1750 ja auch), die Seite sieht aber völlig anders als bei den Routern. Ich befürchte, dass man dafür wahrscheinlich die Hälfte von DSL- und Co.-Parametern setzen muss, damit die Seite überhaupt da dargestellt werden kann.

Aber ansonsten und generell hatte ich auch gestaunt, als dort beim Repeater so viele Sachen von den Routern drin in der Firmware sind, obwohl sie bei einem Repeater nie benötigt werden...

MfG

Edit: @er13: soweit war ich schon mal auch und mir diese lp-URLs bei meiner 7390 abgeschaut. Nein, die "Internet"-Seite gibt es beim Repeater gar nicht und der Aufruf von diesen allen lps führt dazu, dass der Repeater seine Startseite zeigt. Wird anscheinend irgendwo abgefangen und er kennt remoteHttps nicht...
 

Anhänge

  • 1750_Heimnetz_Zugang.png
    1750_Heimnetz_Zugang.png
    84.8 KB · Aufrufe: 25
  • 1750_Uebersicht.png
    1750_Uebersicht.png
    80.6 KB · Aufrufe: 23
1. Nimm Dir einen modernen Browser (z.B. Firefox) und rufe da mit F12 die Developer-Funktionen (Register "Network") auf, bevor Du bei einer "richtigen" FRITZ!Box das Zertifikat per Upload ersetzt. Danach schaust Du in den Developer-Funktionen nach und findest einen Aufruf von "/cgi-bin/firmwarecfg" für den Upload, dessen Parameter und Ergebnis man sich rechts genauer ansehen kann.

Da es für diesen Aufruf einen POST-Request braucht und dieser auch noch ein spezielles Format haben muß (das "multipart/form-data" hatte ich ja schon erwähnt), muß man schon etwas Intelligenteres wie "curl" nehmen, um den zusammenzubauen, obwohl es auch "on the hard way" geht, wie ich es hier: https://github.com/PeterPawn/YourFritz/blob/master/scriptlib/multipart_form mal in Shell-Code gemacht hatte. Aber "curl" ist einfacher ... und wie der Aufruf jetzt konkret aussieht, müßte ich selbst erst nachschauen - ich will Dir nicht die Entdeckerfreude verderben.

Wie das mit "curl" prinzipiell geht, ist mehrfach im Internet beschrieben ... weil "curl" eines der wenigen Programme ist, die das von der Kommandozeile aus können. Die richtige Reihenfolge der Parameter kriegst Du - wie gesagt - aus dem Request im Browser abgelesen.

2. Ich bin mir ganz, ganz, ganz sicher, daß der private Schlüssel in der "websrv_ssl_key.pem" mit dem boxspezifischen Kennwort (wie sich das zusammensetzt, kannst Du in meinem Thread zum Entschlüsseln der Werte aus AVM-Dateien nachlesen) verschlüsselt ist ... ich wußte nur nicht aus dem Kopf, womit das erfolgt (weil sich das auch geändert hat in einer der letzten Versionen - es wurde von 3DES auf AES umgestellt). Schaut man in so eine Datei hinein:
Code:
# cat /var/flash/websrv_ssl_key.pem
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,D8C1F84F164F0C00597FEB29BE8B9156

FBaxOLWA7TllQRkjksauOYBiVANAeylPbD4ZSjThi//9ddJ1BXJFBtdWfpjdHHDu
[...]
YEH1ojQ1/EUnwoPhlutXHsymgR78lRPGfbKYOzMD8wqx45aycT5zJ3cNgXTuZ70g
-----END RSA PRIVATE KEY-----
#
, sieht man ja auch sofort, daß der Key mit AES-128 verschlüsselt ist (mit CBC als Chaining und dem Wert hinter dem Komma als IV).

Du brauchst also nur das Kennwort Deiner Box ermitteln (wie gesagt, man kann das auch ohne die Box machen, wenn man die notwendigen "Merkmale" der Box kennt - alles im "decoder"-Thread beschrieben) und dann den privaten Key mit diesem Kennwort und AES-128 verschlüsseln, bevor Du ihn in den TFFS-Node (also in die "websrv_ssl_key.pem") kopierst.

Wenn Du Dich überzeugen willst, daß der Key tatsächlich verschlüsselt ist (und Dir die gezeigten "Kopfzeilen" nicht dafür reichen), dann kannst Du (sofern die Kommandos auf der Box existieren - das "privatekeypassword" müßtest Du dann mitbauen lassen im Freetz und "openssl" natürlich genauso) das auch einfach selbst prüfen:
Code:
openssl rsa -in /var/flash/websrv_ssl_key.pem -text -noout -passin pass:$(privatekeypassword)
Wenn das einen (sinnvollen) Text mit den Koeffizienten ausspuckt, stimmte schon mal die Ausgabe von "privatekeypassword" (die hier ja direkt an "openssl" weitergegeben wurde).

3. Möglicherweise wird der gesamte Internet-Teil auch schon in der "menu_data.lua" (wenn die nicht auch "speziell" ist für die Repeater) ausgeblendet, wenn es sich um einen Repeater handelt ... ich würde das Thema aber auch weit nach hinten schieben und vor dem Punkt, wo man sich Gedanken macht, wie man den Import "user-tauglich" bekommt, erst einmal klären, ob es überhaupt funktioniert und das setzt dann frühestens beim "firmwarecfg" an (ich persönlich würde als Erstes glatt noch das Kopieren nach Verschlüsseln machen und erst danach den CGI-Weg testen). Funktioniert der Import darüber nicht, braucht man sich um die Lua-Seiten auch nicht mehr kümmern. Erst wenn das geht, macht es wieder Sinn, nach deren "Freischaltung" zu forschen.
 
@hermann72pb:

Ich kann zwar den Gedankengang von Peter nachvollziehen, würde aber eher den etwas umgekehrten Weg gehen. Bevor ich mich mit "multipart/form-data", curl und Co. auseinander setze, würde ich es eher versuchen, die entsprechenden Einträge im AVM-WebIF freizuschalten, damit eben AVM-WebIF sich mit dem Erstellen der relevantem Requests im richtigen Format beschäftigt.

remoteHttps scheint in menu_data.lua einfach weggepatcht zu sein. Mit dem folgenden Patch müsste sich die URL aus #43 händisch aufrufen lassen (wenn es dann geht, kann man sich Gedanken machen, wie man es im AVM-WebIF direkt einblendet/auswählbar macht)

[Die Version für die Original-Firmware, i.e. "no freetz"-Modus]
Code:
--- usr/www/avm/menus/menu_data.lua
+++ usr/www/avm/menus/menu_data.lua
@@ -176,6 +176,11 @@
 ["lua"] = forLuaOnly and "home/home.lua",
 ["help"] = (forLuaOnly and "hilfe_status") or true
 } or nil,
+["remoteHttps"] = config.REMOTE_HTTPS and {
+["show"] = true,
+["lua"] = "internet/remote_https.lua",
+["help"] = (forLuaOnly and "hilfe_internet_remote_https") or true
+} or nil,
 ["meshSet"] = {
 ["show"] = true,
 ["js"] = "wlan/mesh_settings.js",
--- usr/www/avme/menus/menu_data.lua
+++ usr/www/avme/menus/menu_data.lua
@@ -176,6 +176,11 @@
 ["lua"] = forLuaOnly and "home/home.lua",
 ["help"] = (forLuaOnly and "hilfe_status") or true
 } or nil,
+["remoteHttps"] = config.REMOTE_HTTPS and {
+["show"] = true,
+["lua"] = "internet/remote_https.lua",
+["help"] = (forLuaOnly and "hilfe_internet_remote_https") or true
+} or nil,
 ["meshSet"] = {
 ["show"] = true,
 ["js"] = "wlan/mesh_settings.js",

[Die Version für die gefreetze Firmware]
Code:
--- usr/www/all/menus/menu_data.lua
+++ usr/www/all/menus/menu_data.lua
@@ -176,6 +176,11 @@
 ["lua"] = forLuaOnly and "home/home.lua",
 ["help"] = (forLuaOnly and "hilfe_status") or true
 } or nil,
+["remoteHttps"] = config.REMOTE_HTTPS and {
+["show"] = true,
+["lua"] = "internet/remote_https.lua",
+["help"] = (forLuaOnly and "hilfe_internet_remote_https") or true
+} or nil,
 ["meshSet"] = {
 ["show"] = true,
 ["js"] = "wlan/mesh_settings.js",

Die einfachte Möglichkeit, den Patch im Freetz-Modus anzuwenden, wäre es diesen unter einem beliebigen Namen unter patches/devices/07_0X/1750/ abzulegen.
 
@er13: Danke! Hat geklappt. Ich habe mit dem zweiten Patch eine neue Firmware generiert. Danach erscheint tatsächlich unter Internet->Freigaben die besagte Seite, die auch Import der Zertifikate ermöglicht. Nebeneffekt: Man kann jetzt wahrscheinlich auch Port 443 verstellen, wenn man das denn möchte...
Mit dem Importieren der Zertifikate hat es auch geklappt.
Nun hole ich etwas heraus, was ich mit dem ganzen bezwecken will und motiviere etwas, warum die Informationen von @PeterPawn für mich auch Goldwert sind und ich auf der Front auf jeden Fall weiter machen würde.
Bei Letsencrypt gelten die Zertifikate bekannterweise nur drei Monate. Danach sollte man sie erneuern und man bestrebt natürlich dies irgendwie zu automatisieren. Wie Peter hier irgendwo schon mal geschrieben hat, basieren die Standard-Skripte zum Generieren der Zertifikate auf Perl und sind aus diesem Grund kaum für eine Fritzbox geeignet. Es macht aus meiner Sicht auch keinen Sinn von wegen einmal in drei Monaten Zertifikate aktualisieren das komplette Perl-Gewerk auf der Box "scharf zu halten". Und dazu gibt es bereits im Netz eine Lösung, die so aufgebaut ist, dass der certbot (das entsprechende Perl-Tool) z.B. auf einem RaspberryPi läuft, die Zertifikate holt und dann anschließend eine weitere Anwendung sich auf einer unmodifizierten FritzBox anmeldet und die Zertifikate per Import auf die Box "pusht". Ich habe es selbst nicht ausprobiert, sollte aber wohl funktionieren. Das wäre die Lösung, wenn man kein FREETZ auf der Box hat. Die Lösung würde aber auch mit dem "leicht verändertem" 1750E nun auch funktionieren, wenn die besagte Import-Seite freigeschaltet ist.
Wenn man FREETZ (oder von mir aus modfs oder was auch immer) auf der Box hat, kann man noch etwas weiter gehen und entweder das Generieren der Zertifikate direkt auf der Box mit einem shell-basierten-Skript machen (bitte nach "dehydrated" im Netz suchen, ist eine shell-Alternative für certbot) oder die Zertifikate wenigstens (wenn schon nicht selbst generieren) nicht von extern "pushen", sondern per ssh/ftp/rsync von einem weiteren Server (RaspberryPi oder was draußen im Internet) holen. Und hier kommen die Ideen von @PeterPawn zum tragen: Die Zertifikate sollte man irgendwie rein per Shell importieren. Entweder man nutzt die Importwerkzeuge von AVM auf der Box selbst, aber per Shell, nicht per WebCGI, oder man verrät das Passwort der Box dem äußeren Server und der äußere Server generiert dann KEY+CERT in dem entsprechenden Format, sodass man sie auf der Box nur ins Flash schreibt und ctlmgr neu startet (Minimalaufwand auf der Box).
Das sind so grob die Gedanken in die Richtung. Von daher würde ich gerne noch den steinigen Weg von @PeterPawn versuchen zu gehen. Multipart stört mich nicht so. Das hatte ich schon mal vor ein Paar Jahren auch per Shell programmiert, wahrscheinlich ähnlich wie @PeterPawn. Es ging damals um das Vorbereiten der Anhänge für sendmail und zwar wirklich im Rohformat. Von daher, machbar ist es, aber natürlich etwas zeitaufwendiger.
@er13: Die beiden Patches kann man von mir aus erstmal so ins FREETZ übernehmen. Vielleicht noch wählbar machen, dass man sie auch abwählen kann. Funktionieren tut es bei mir.
Nochmal vielen Dank an euch beide! Ich melde mich, wenn ich was zur Shell-Lösung herausfinde oder Fragen habe.

EDIT:
Der Menüeintrag ist übrigens da (s. Bild). Ich musste nicht mit irgendwelchen urls die Seite erzwingen. Man kann sich schön durch die Menüstruktur durchklicken. Sieht zwar mit dem "Internet" etwas blöd bei einem Repeater aus, aber wenn es hilft...

MfG
 

Anhänge

  • 1750_HTTPS.png
    1750_HTTPS.png
    120.5 KB · Aufrufe: 41
Zuletzt bearbeitet:
Thema "Let's Encrypt"-Zertifikate für DynDNS-Adressen und nicht nur für die myfritz.net basierten

(vielleicht wäre das in einem eigenen Thread sogar besser aufgehoben als "Anstoß" zu einer Diskussion, wie man's am besten macht)

Das hatte ich in Shell (und zwar für die "ash", mit "openssl" für die Crypto-Operationen) auch mal in Angriff genommen (mit der Idee, das als "modfs"-Paket anzubieten - noch bevor sich die AVM-Implementierung materialisierte), aber dann kam AVM damit um die Ecke (zumindest mit erkennbaren Plänen, denn lange war ja auch nicht klar, daß damit bei AVM nur die myfritz.net-Adressen funktionieren würden - zuerst war ja fast 1 Jahr lang nur die "Reservierung" der Dateinamen im TFFS zu sehen) und dann kam auch noch die Abschaltung von TLS-SNI-01 als Validierung dazu - und jetzt gibt es inzwischen genug fertige Implementierungen auch in "pure shell".

Ich würde hier aber tatsächlich eher über Wildcard-Zertifikate nachdenken (geht seit dem Frühjahr ja auch und mit "acme.sh" existiert auch eine Shell-Version dafür, die außer "openssl" nichts weiter braucht) ... das kann man dann auf mehreren Geräten im LAN verwenden (und nicht jedes braucht ein eigenes), außerdem ist das beim "Pinnen" etwas angenehmer, wenn es weniger sind.

[ Selbst für "stunnel" auf dem Edge-Router kann man es dann nehmen, wenn man damit TLS-Verbindungen "nach außen" legt für Clients, die das ansonsten nur ohne Verschlüsselung könnten ... ich habe da auch noch ein offenes Problem mit eher preiswerten IP-Kameras, die ein Kunde unbedingt in seine Loxone-App einbinden will und die dafür vom Loxone-Server zwar über WebSockets angesprochen werden, wo das Ganze aber unverschlüsselt erfolgt und man Benutzernamen und Kennwort problemlos mitlesen kann zwischen Loxone-(Cloud-)Server und der IPCam. Da kommt dann ein "stunnel" davor und so ein Wildcard-Zertifikat verursacht dann auch beim "stunnel" kein "CN mismatch", wenn man damit mehrere Kameras absichert (in verschiedenen Tunneln naturlich). ]

Solange die zu sichernden Clients alle hinter der FRITZ!Box als Gateway sitzen, ist das ja sogar die "logische Struktur", wenn man das nur auf der Box selbst macht und das Wildcard-Zertifikat dann an die nachfolgenden Geräte verteilt. Ich vermute einfach mal, daß auch bei AVM die Reise irgendwann dahin gehen wird ... schließlich kann der Master so ein Zertifikat wunderbar an die Slaves verteilen, weil er bereits einen geschützten Kanal zu diesen hat.

Berücksichtigt man dann noch die Art und Weise, wie AVM schon heute die MyFRITZ!-Freigaben (auch und gerade für IPv6) einrichtet und teilt die Annahme, daß auch AVM irgendwann mal bei (zwingendem) TLS auf der LAN-Seite ankommen wird, drängt sich das (meiner Meinung nach jedenfalls) förmlich auf, so etwas mit einem Wildcard-Zertifikat für die MyFRITZ!-Adresse der Box und "darunter" liegende Geräte zu lösen (bis hin zur Download-Möglichkeit oder einem Hook, damit man das auch auf NAS und Co. installieren kann und über Erneuerungen benachrichtigt wird), anstatt auf allen potentiellen Geräten im LAN (und ich rede jetzt nur von den AVM-Geräten mit GUI, die auch noch im Mesh verwaltet werden können und trotzdem ihre eigene GUI mitbringen) immer wieder ein eigenes Zertifikat zu verlängern.

Das würde ja dann auch noch zu höchst unterschiedlichen Zeitpunkten für die einzelnen Geräte erfolgen, weil die wohl alle zu anderen Zeiten ablaufen würden ... irgendwie ein "Alptraum" und solange immer noch ein Edge-Router mit MyFRITZ!-Account der "Eingang" ins LAN von der Internet-Seite ist (und das dürfte in AVM's Interesse sein, daß eine FRITZ!Box diese Rolle übernimmt), bietet sich so ein Wildcard-Zertifikat in meinen Augen eben geradezu an.

Ob ich die Verteilung im Mesh mache oder das (mit i.d.R. ziemlich doofen Clients) von jedem (AVM-)Gerät im LAN selbst machen lasse, nimmt sich (zumindest im SOHO-Rahmen und nach meiner Ansicht) erst mal auch im Hinblick auf Sicherheit nicht so richtig etwas (wenn ich etwas übersehe, diskutiere ich gerne darüber) ... außer daß man damit auch noch die tatsächlich vorhandene Infrastruktur vor einem interessierten Angreifer verstecken kann.

Denn wenn der erst mal die LE-Zertifikate für eine bestimmte MyFRITZ!-Domain zusammensuchen kann und damit eine Liste aller (oder zumindest vieler) Geräte im LAN erhält, kann er sich viel genauer überlegen, welches der Geräte im LAN er aufs Korn nimmt - mit einem Wildcard-Zertifikat fehlt ihm die Information über jedes einzelne Gerät in der (öffentlich einseh- und durchsuchbaren) Transparency-Liste (z.B. über https://crt.sh/?a=1).

Daß man mit der AVM-Implementierung nur wenig anfangen kann, ist vermutlich unstrittig (die reicht dann vielleicht für den Durchschnittsnutzer und auch als solcher würde ich mir das sehr lange überlegen, wie weit ich mich AVM auch beim "Betrieb" meiner FRITZ!Box ausliefere) ... die Beschränkung auf die MyFRITZ!-Adresse dürfte auch "Strategie" sein.

Wenn man jetzt ein Freetz-Paket damit bastelt (wie gesagt, das "acme.sh" oben sollte eine extrem gute Ausgangsbasis sein - war auch mal bei heise.de (bzw. in irgendeiner der Publikationen von dort) beschrieben, iirc), würde ich das gleich unter einem "Client-Server-Paradigma" machen, wobei dann der "Server" das Wildcard-Zertifikat holt, verwaltet (also auch erneuert) und es (über einen gesicherten Download (User/Password), mit verschlüsseltem PrivateKey - am besten gleich als PKCS#12-Datei) im LAN zum Download anbietet, von wo man es dann entweder automatisiert beziehen kann oder auch von Hand auf weiteren Geräten installieren kann.

Das automatisierte Abholen vom Server (zumindest für Geräte mit Freetz, um NAS und Co. muß man sich dann eben mit eigenen Skripten auf diesen Geräten kümmern) erledigt dann der "Client-Teil" dieses Paketes, wenn die Erneuerung fällig sein könnte. Der kann dann auch mal "intensiver pollen", wenn es in die Nähe des Datums der Verlängerung kommt bzw. er kann ja auch das vorhandene mit den vom Server abgleichen und bei Änderungen ersetzen.

Das erspart auch das Lavieren mit Portfreigaben (für die Zertifizierung und die Erneuerung) zu den einzelnen Clients ... im "normalen Betrieb" kann ich denen irgendwelche krummen Port-Nummern geben, aber für die Validierung müssen die eben ganz genau auf Port 80 (bei HTTP-01-Validierung) reagieren und das muß man von einem LAN-Client dem Edge-Router dann auch erst mal erfolgreich verklickern und dabei noch hoffen, daß kein anderer Client gerade dasselbe versucht, weil auch sein eigenes Zertifikat gerade erneuert werden muß.
 
@PeterPawn:
1. Eigenes Thread für LetsEncrypt. Ja, macht Sinn, werde ich erstellen, allerdings etwas später. Lass uns mal hier einige Details zu Ende "durchkauen", die sonst den anderen Thread unnötig aufblasen würden. Wie ich schon gesagt hatte, werde ich meine Versuche mit shell und Co. starten und komme sicher noch auf euch mit meinen Fragen zu, wenn ich irgendwas nicht verstehe, oder wenn was nicht klappt.
2. LetsEncrypt gefällt mir persönlich nicht so gut von der Idee her, wie die Amis es wieder schön für sich und bei sich gemacht haben. Wer weiß, wer da alles beim Erstellen der Zertifikate mithört. Ist aber ein anderes Thema. Müssen wir hier nicht diskutieren. Tatsache ist, dass es derzeit die einzig bezahlbare Option, die Zertfikiate in Browsern und Co. "grün" zu bekommen. Die aus meiner (und nicht nur aus meiner) Sicht bessere Option wäre die eigens erstellten CAs zu akzeptieren. Die Tendenz bei Android- und anderen Geräten geht aber eher dahin, dass solche CAs als "böse" eingestuft werden. Darum bin ich bei LetsEncrypt nicht aus Überzeugung, sondern rein pragmatisch. Und genau aus diesem Grund würde ich die Variante mit eigens erstellten Zertifikaten (nicht selbst signiert, sondern mit einer eigenen CA) nicht ganz begraben. Soll heißen: LetsEncrypt mittels Skripte usw, ja, aber auch die Möglichkeit belassen, eigene Zertifikate nach klassischer Manier einzuspielen.
3. WildCards. Ja, habe ich auch. Darum habe ich "dehydrated" oben angesprochen. Ich betreibe einen STRATO-Virtual-Server mit einigen Domains drauf. Da läuft auch PowerDNS (als BIND-Nachfolger) und ich stelle letzte Zeit alle Domains darauf um, dass ich meine eigenen Namenserver stelle. STRATO hatte sich bis vor 2-3 Monaten dagegen sehr stark gewehrt. Nun erlauben sie es auch, allerdings sind die meisten von meinen Domains von denen bereits zu einem Provider weggezogen, der die Einstellung von eigenen NS erlaubt. Warum eigene NS? Weil ich seit Jahren auf dem Server meinen eigenen DynDNS betreibe. Um dies zu ermöglichen, brauchst du schon deine eigenen Namenserver, sonst funktioniert es nicht. Mein privater DynDNS-Service basiert auf einer alten bekannten PHP-Umsetzung, die ich allerdings etwas modifiziert habe. Meine FritzBoxen kriegen ihre Adressen nicht von MyFritz, sondern von meinem privaten DynDNS-Dienst. Und genau darüber bin ich auf LetsEncrypt gekommen, um die Zertifikate für meine FritzBoxen für den Zugriff von Außen zu bekommen. Das hatte ich mit "dehydrated" und Wildcards erfolgreich vor einem Monat auf dem Strato-Server umgesetzt. Für WildCards braucht "dehydrated" einen funktionierenden Namenserver (in dem Falle PowerDNS). Dafür gab es angepasste fertige Skripte, die ich installiert habe und die auf dem Strato-Server zunächst WildCards generieren. Ob wir sowas auf einer dynamischen Adresse und auf einer FritzBox je zum Laufen bekommen, mag ich sehr stark zu bezweifeln. Denn die Restriktionen seitens LetsEncrypt Richtung Wildcards sind schon enorm. Ob man den komplizierten Weg gehen will, den ich persönlich mit meinem Strato-Server gehe, mag ich auch stark zu bezweifeln: wird sicherlich nicht jeder tun. Das Use Case für die Mehrheit unter uns hier wird irgendwo dazwischen liegen. Aber diese Punkte sollten wir wirklich nicht hier diskutieren, sondern im speziellen LetsEncrypt-Thread. Ich wollte hier nur meine Sichtweise dazu äußern und meinen aktuellen Erfahrungs- und Kenntnisstand hier darstellen.

Von daher, lass uns mal hier erstmal bei meinem 1750E bleiben (wird mein Versuchskaninchen dann sein) und darauf (oder alternativ noch auf meinen 7390 und 7490) deine Ideen zur Zertifikatserzeugung bzw. Import via Shell üben.

MfG
 
Zuletzt bearbeitet:
Die ACME2-Spezifikation ist ja noch nicht so alt und wer seine eigene Root-CA betreibt, wird irgendwann auch mal bei einem solchen Paket landen, denn das Ausstellen aller Zertifikate "von Hand", ist ganz schön nervig ... das hatte ich selbst auch als Orgie alle zwei Jahre, weil alle meine Services (von OCSP bis zum Mail-Server) mit Zertifikaten von dieser CA arbeiten und wehe, deren Laufzeit (also die der Zertifikate) näherte sich dem Ende. Mehr als zwei Jahre sollte man (nachgeordnete) Zertifikate auch nicht laufen lassen, weil sich die verwendeten Algorithmen dann doch schneller "abnutzen", als man so manches Mal denkt.

Ob man mit einem ACME-Client also dann die eigene Root-CA benutzt oder den Lets Encrypt-Service, ist gleichgültig - das ist ohnehin "parametrierbar" bei so ziemlich jedem fertigen Client, den ich nun wieder kenne und vermutlich auch bei "dehydrated" - den ich dann nicht weiter verfolgt habe (auch wenn ich das Logo von früher kenne), weil mir "acme.sh" mehr zusagt.

Wenn ich etwas von Client-Server-Modell schreibe, meine ich dabei auch keinen DynDNS-Server auf einer FRITZ!Box (das bringt ja nur etwas, wenn die Box eine statische Adresse hat), sondern nur eine einzige Instanz, die beim ACME-Server das Wildcard-Zertifikat verwaltet und bei der sich dann die (LAN-)Clients "bedienen".

Wie schon mal festgestellt, kriegt man ansonsten bei HTTP-01-Authentifizierung für ACME-Clients hinter dem Edge-Router Probleme, weil man die Portweiterleitung des Edge-Routers dann für die Validierung passend einrichten müßte und das spätestens bei zwei gleichzeitig aktiven ACME-Clients mit Ansage gegen die Wand fährt ... mal vollkommen außer Acht gelassen, daß beim PCP eben auch die Vergabe des "korrekten" externen Ports nicht mehr garantiert ist, das ACME-Protokoll aber (meines Wissens, wobei ich die letzten Versionen - seit meinen eigenen Versuchen vor langer Zeit - nicht mehr richtig gelesen habe) keine Konfiguration dieses Ports zuläßt und auf Port 80 beharrt (zurecht, sonst ist das bei vServern hinter einer gemeinsamen Adresse wieder angreifbar).

Die wenigsten Benutzer werden für die Validierung DNS-01 verwenden können ... ganz einfach deshalb, weil man dafür schon den eigenen Name-Server braucht, denn welcher (NS-)Provider läßt den Kunden schon irgendwelchen Unfug (für die Validierung) automatisiert und ausreichend geschwind in den DNS-Datenbestand eintragen (mal abgesehen von allem anderen, wie der Notwendigkeit, den SOA zu aktualisieren und die Zone ggf. noch an Secondaries zu verteilen nach dem Eintragen der Validierungsdaten).

Bleibt man also bei HTTP-01, muß man sich auch überlegen, was man macht (immer unter der Annahme, man will das tatsächlich (voll-)automatisieren), wenn man eben nicht nur einen WLAN-Repeater hat, der sein Zertifikat erzeugen/erneuern will, sondern mehrere - die genaue Anzahl spielt gar keine Rolle, weil man sich schon bei zweien mit dem Problem der gleichzeitigen Arbeit auseinandersetzen muß, wenn das "reliable" sein soll.

Die Frage, wie man das so erzeugte Zertifikat (und den Key) dann in den einzelnen Geräten "installiert", betrifft ja eher den "Client-Teil" in meinem "Modell" ... das habe ich aber schon seit sehr langer Zeit so praktiziert, sogar schon, bevor es von AVM die Möglichkeit gab, das eigene Zertifikat "offiziell" zu installieren (was ja zunächst auch mal "undokumentiert" daherkam: https://www.ip-phone-forum.de/threa...-domäne-bzw-die-fritz-box-fernwartung.270401/ von AVM).

Ich kann Dir nur versichern, daß es eben nach dem Speichern des privaten Keys (mit dem richtigen Kennwort verschlüsselt) und des eigenen Zertifikats (mit der von Dir bereits bemerkten Kommentarzeile) in den beiden TFFS-Nodes (deren Namen AVM als "websrv_ssl_{cert,key}.pem" "definiert" hat) und dem Neustart des "ctlmgr" (der dazu am besten nicht läuft beim Speichern, ebenso sollte man alle Kopien des Zertifikats im "tmpfs" (also unterhalb von "/var") entsorgen, damit er die neu erstellen muß) eigentlich keine Probleme (bei mir zumindest) gibt ... wenn man ohnehin irgendein "automatsches" Paket erstellen will und in diesem nicht das Zertifikat (und den Key natürlich) "von außen" auf die Clients im LAN pushen will, dann gibt es ja keinen Grund, überhaupt das Verhalten von "firmwarecfg" auf einem Repeater zu untersuchen. Dann braucht man halt auf dem Gerät (als "Client") die entsprechende Software, die das Zertifikat entgegennimmt und installiert ... ein Shell-Skript reicht, wenn man die beiden (weiter oben gezeigten) Programme auf dem Gerät hat (openssl + privatekeypassword).

Wenn allerdings "firmwarecfg" tatsächlich auch auf einem (komplett unmodifizierten) Repeater benutzbar ist und das Zertifikat korrekt installiert (das GUI ist da "standardmäßig" ja nicht zugänglich, wie inzwischen klargestellt wurde), dann macht es vielleicht sogar wieder Sinn, wenn man ein "Let's Encrypt"-Paket in Freetz (für die DynDNS-Adressen und nicht nur für die MyFRITZ!-Adresse) nur auf dem Edge-Router laufen läßt und diesem Paket "beibringt", wie es ein Zertifikat nach dem Erneuern auf welche Clients im LAN verteilen muß ... denn da muß das natürlich am Ende landen, weil TLS Ende zu Ende verschlüsselt.

Geht man das so an, kann man auch - wenn man alle Datenschutzbedenken hinsichtlich der "Offenlegung" der internen Hosts durch zuviele "Einzelzertifikate" über Bord wirft - für jeden (auswählbaren) Client im LAN (bei dem das Sinn macht) ein eigenes Zertifikat (mit dem Namen des Clients im FRITZ!OS-GUI z.B.) generieren lassen und das Ergebnis dorthin "pushen" ... dann braucht man vielleicht Alternativen bei der "Installation" auf dem jeweiligen Client (am besten als "Plugin" und erweiterbar bei neuen Wegen), aber keinen eigenen ACME-Client auf jedem in Frage kommenden Gerät.

Das wäre dann der LE-Proxy auf dem Edge-Router, der aber auch die Verwaltung (samt Refresh) übernehmen müßte und wo sich die "Stellvertreter-Funktion" dann mehr auf die Validierung bezieht, während der Rest (Verwaltung, Erneuern, Account) schon eher ein (ausgewachsener) Server (also eher ein "ACME-Daemon") wäre, denn so etwas will (sofern es wirklich skalierbar und dabei trotzdem noch sicher sein soll) auch erst mal organisiert sein (inkl. Backup/Restore und was da noch alles dazugehört).
 
@GokuSS4: Wenn wir es alle so machen würden, gäbe es hier weder "Modifikationen"-Thread noch FREETZ. Ich bin von der Natur her kein Käufer/Verkäufer und kann deswegen auch die "Erbsenzähler" unter uns nur schwer leiden, wobei sich damit nachweislich deutlich schneller (gewinnoptimiert) Geld machen lässt.
1750E sieht schon schick aus und "redet" besser mit dem Rest der FritzBoxen bei mir zuhause. Zudem hatte ich den auch nicht neu gekauft, sondern von jemanden veräußert bekommen. Und ich würde gerne noch 2-3 im Hause installieren. Denn von der Einrichtung her, von der Form, auch von der Reichweite bin ich mit den Dingen voll zufrieden. Ich kenne keinen OpenWRT-Router, der mir gleichzeitig WLAN + GastWLAN als Repeater "verlängern" kann, ohne, dass ich dafür was extra einrichten muss. Selbst die FritzBoxen als Repeater (z.B. meine 7390) können das nicht.
@PeterPawn: OK, ich habe es verstanden.
 
Ich bin der Überzeugung, daß bei der Frage der Validierung von Wildcard-Zertifikaten über HTTP-01 das letzte Wort noch nicht gesprochen ist - auch wenn LE halt im Moment der einzige Anbieter von öffentlichen ACME-basierten Zertifikaten ist, soweit ich weiß.

Ich kenne nur den Entwurf bei der IETF, der eindeutig aussagt:
It is up to the server's local policy to decide which names are acceptable in a certificate, given the authorizations that the server associates with the client's account key. A server MAY consider a client authorized for a wildcard domain if it is authorized for the underlying domain name (without the "*" label).
Angesichts der Schwierigkeiten für die Benutzer, bei dynamischem DNS die Kontrolle über den DNS-Server zu erhalten und angesichts der Tatsache, daß Einzelzertifikate eben genau die innere Struktur des Netzwerks "offenlegen" würden und ihrerseits jedweden Versuch der "Verschleierung" ad absurdum führen (wenn sie in der Transparency-Liste landen), kann ich mir einfach nicht vorstellen, daß die Entscheidung von LE, für Wildcard-Zertifikate zwingend DNS-01 vorzuschreiben, auf längere Sicht oder gar für alle Zeit Bestand haben wird ... das ist ja alles "im Fluß" und die Verfügbarkeit der Wildcard-Zertifikate gerade mal 9 Monate gegeben.

[ EDIT: PS/OT: Bei Schlund+Partner habe ich auch nur die Secondaries ... der Primary ist schon seit Menschengedenken (praktisch seitdem ich meine erste eigene Domain registriert habe) immer mein eigener gewesen, auch wenn der (so wie die Domain auch) immer mal wieder umgezogen wurde (und über irgendein "Mitglied" muß man seine Domains halt verwalten). Meine zweite Domain (nach der für den Nachnamen) war "winnt.de" (habe ich immer noch - aus Gewohnheit und Sentimentalität) ... nun kannst Du ja mal zurückrechnen, wann ich die wohl registriert haben könnte (das kostete damals noch richtig Geld). ]
 
Zuletzt bearbeitet:
@cuma: Hinweis auf Quellcode war hier eigentlich @er13 adressiert, damit er es im Trunk einpflegen kann und weil es hier oder irgendwo in einem der Ursprungsthreads darum ging, dass es keine Quellen dazu gibt. Daraufhin hatte ich AVM "nett" gefragt und nun haben wir die Quellen. Dass ich die Quellen nicht brauche, solange ich ohne "replace kernel" leben kann, ist mir klar. Auch klar ist mir, dass alleine mit den Quellen da noch nicht alles getan ist und eine Menge der Anpassung an den Patches und Co erforderlich ist.
Bei den anderen Repeatern, Smarthome-Dingens usw. hat sich hier keiner so richtig gemeldet, der sie unbedingt in FREETZ haben wollte. Der Weg ist jetzt aufgezeigt und du bist herzlich eingeladen, deine eigenen Erfahrungen dazu beizutragen und sie in Form von Patches oder wie auch immer und wo auch immer zu posten (wie @PeterPawn schon hier kürzlich sehr ausführlich vorgeschlagen hat).
Bzgl. Wildcards. Ich persönlich würde es mit Wildcards machen, allerdings würde ich diese nicht auf der Box generieren, wie bereits oben erwähnt. Und wie bereits oben erwähnt, geht es mir hier in diesem Thread primär darum, die Zertifikate für AVM-Interface zu importieren. Aber auch hier gilt: Poste deine Lösung/Anleitung irgendwo im weiten Netz und lass uns daran teil haben. Du kannst auch gerne den von @PeterPawn vorgeschlagenen Thread zur allgemeinen Diskussion über LetsEncrypt & Co. anlegen und dort die Diskussion anfangen bzw. fortführen. Bis ich (wenn überhaupt) dazu komme, vergehen die Wochen...

MfG
 
Ich habe mir heute etwas Zeit genommmen, um mich auf der Box umzusehen. Viel Zeit war es leider nicht, aber immer hin konnte ich für mich einiges besser nahvollziehen und die Sachen verinnerlichen, die @PeterPawn oben angesprochen hat. Und natürlich habe ich noch weitere Fragen, die nun weiter im Text folgen.
1. Ich habe mir intensiv die Datei remote_https.lua angeschaut und mir da einige Befehle (z.B.
Code:
cmtable.add_var( ctlmgr_save, "remoteman:settings/user_cert_delete" , "1" )
abgeschaut. Die Idee dabei war, diese Befehle mit ctlmgr_ctl aus der Shell auszuführen. Und tatsächlich
Code:
root@FWR1:/var/mod/root# ctlmgr_ctl r remoteman settings/user_cert_present
1
root@FWR1:/var/mod/root# ctlmgr_ctl r remoteman settings/user_cert_delete

root@FWR1:/var/mod/root# ctlmgr_ctl l remoteman settings
root@FWR1:/var/mod/root# ctlmgr_ctl r remoteman settings/cert_sha1_fingerprint
XX:2F:YY:BF:37:ZZ:AB:XX:63:YY:81:ZZ:4C:XX:5A:YY:BB:ZZ:36:XX
root@FWR1:/var/mod/root# ctlmgr_ctl r remoteman settings/configured_port_changed
0
man kann sie wenigstens lesen, wen man weiß, was man liest. Vermutlich wird auch schreiben a-la
Code:
ctlmgr_ctl w remoteman settings/user_cert_delete 1
Und hier kommt meine erste Frage: Ist denn "ctlmgr_ctl w" ein echtes permanentes Schreiben oder wird es lediglich irgendwo im Cache abgelegt und man muss es zusätzlich mit irgendeinem weiteren supergeheimen Befehl es abspeichern?
Ich treibe die Untersuchungen in die Richtung, um nachher nicht alles per WebIF über irgendwelche komische wrapper und curl zu ändern, sondern direkt in der AVM-Datenbank. Oder ist meine Idee falsch und ich soll es vergessen?
Übrigens, ctlmgr_ctl ist heutzutage deutlich gesprächiger und spuckt da schon mal viele Beispiele, wenn man ihn falsch bedient:
Code:
usage: ctlmgr_ctl [options] <r [ui-module key]+> | <w [ui-module key value]+> | <u [ui-module]*> | <del [ui-module command]+
options:
  -?                 - print this help
  -s STRING          - string: SID to use. (NULL)
  -v                 - bool: echo variable name, not only value. (NOTSET)
  -d CHAR            - use character instead of TAB for field delimiter. ()
  -D STRING          - switch debug logs on. (FUNC)
(r: read), then list of tuples describing each value to be read (at least one)
(w: write), then list of triples describing each value to be read (at least one)
(u: dump), then list of ui-modules. If empty, will provide list of available ui-modules
(del), then command string, which node should be deleted
(l: list), list variable
examples:
1) ctlmgr_ctl w wlan settings/STA_enabled 1
2) ctlmgr_ctl r wlan settings/STA_enabled
3) ctlmgr_ctl u wlan
4) ctlmgr_ctl del landevice landevice:command/landevice0
5) ctlmgr_ctl l landevice "settings/landevice/list(UID,allow_pcp_and_upnp,igd_fw_cnt_pcp,igd_fw_cnt_upnp)"
Kannte ich von früher nicht. Man musste sich diese Informationen mühsam irgendwo zusammenerraten oder zusammensuchen.
2. Nach der lua-Betrachtung bin ich nun weiter gegangen. Wie @PeterPawn zurecht oben angemerkt hat, führt keinen Weg an /cgi-bin/firmwarecfg vorbei, wenn man Zertifikate mit AVM-eigenen Mitteln importieren will. Und an der Stelle komme ich leider nicht weiter:
1. Nimm Dir einen modernen Browser (z.B. Firefox) und rufe da mit F12 die Developer-Funktionen (Register "Network") auf, bevor Du bei einer "richtigen" FRITZ!Box das Zertifikat per Upload ersetzt. Danach schaust Du in den Developer-Funktionen nach und findest einen Aufruf von "/cgi-bin/firmwarecfg" für den Upload, dessen Parameter und Ergebnis man sich rechts genauer ansehen kann.
Naja, "rechts" habe ich noch halbwegs gefunden, obwohl bei meinem deutschen FF 63.0.3 (WIN x64) die Default-Einstellung eigentlich "unten" war, aber Register "Network" finde ich da beim besten Willen nicht. Es gibt irgedwelche "Netzwerkanalysen" mit Tortendiagrammen. Daraus kann ich aber die Aufrufparameter für firmwarecfg nicht ersehen. Kann jemand vielleicht ein Bild posten oder etwas detaillierter erklären, wo ich nach dem Drücken von F12 dieses "Network" in FF finden kann?
Ich probiere es gleich auf meinem MINT-Rechner. Da sieht der FF sowieso wiederum anders aus. Ich kannte diese F12-Funktion von FF bis jetzt nicht. Quellcode: ja, aber nicht F12.

3. Den alternativen Weg über openssl und privatekeypassword habe ich nun auch verstanden, muss allerdings auf meine Boxen zunächst ein Image mit entsprechenden Tools bringen (der Repeater 1750 hat derzeit nicht mal openssl drauf). Den Weg würde ich auch gerne ausprobieren. Vor allem um zu testen, wie die Boxen darauf reagieren, wenn man die beiden pem-Dateien unter /var/flash einfach tauscht. Vernünftigerweise sollte man natürlich ctlmgr dafür stoppen und anschließend wieder starten.

Ich werde hier portionsweise über meine Fortschritte berichten, wenn ich was Neues herausfinde.

MfG
 
Auf diesem Bild sollte man eigentlich alles Relevante sehen können ... angefangen vom richtigen "Menüpunkt" in der oberen Leiste ("Network") über die Liste der Requests (links) bis zu den Details eines Requests (rechts, aber erst, wenn links einer ausgewählt wurde):
developer tools - network traffic - request details.png
Ich hatte hier allerdings gerade keine passende Datei im PEM-Format zur Hand und habe daher mein CA-Zertifikat hochgeladen ... aber der anschließende Fehler hat keinen Einfluß auf den Aufbau des Request.

Man sollte den aber in jedem Falle noch mal selbst ausführen ... ich weiß z.B. im Moment nicht genau, ob der "firmwarecfg" mit dem "Content-Type"-Header etwas anfangen kann oder nicht bzw. ob er den nicht sogar braucht. Ich müßte es selbst erst wieder probieren, weil ich natürlich schon lange nur noch mit "selbstgebauten" Dateien im Flash arbeite.

Einer der Gründe dafür war die Feststellung, daß die AVM-Implementierung im "ctlmgr" tatsächlich in der Lage ist, für die DH-Initialisierung in der "websrv_ssl_cert.pem" enthaltene Parameter auszuwerten (das ist ja bei vielen "Programmierbeispielen" so gezeigt und da wurde wohl jemand davon inspiriert ... das gab es beim Seeden eines PRNG ja auch schon im AVM-(Object-)Code zu sehen), wenn die als Zusatz:
Code:
-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEAjzRRUlot2d6dFTozxmkVhcyko5ghp2kBjFCAGjc2pfqWrNYbFQJr
WZTV9/zw2rBLnkr46OXuIxk7FxuPdfiug4FQWW0CkAmsCGGwKrOvxwI9PDPRszPj
g2NTNiABaeqGCIuG+HnBD25cUgTFfZTxy9FrGTi6nDBG2XgWVPqRArnvxdhv0MJL
6PAQwyPx6X6Fu0YyeXYNRNQeyMDgMiiQQrml3hkB9jeKTOQmAHCeY12XVCzGu5q3
xxxxxxxxxxxxxxxxxxxxxxxxxxxhKFo+hJhjvHIzvGPVs2SoQothn0PBApjBXR7
FQ81cmuYXh/bCl9YEfSLEr83/6zxaDHD1wIBBQ==
-----END DH PARAMETERS-----
in der Zertifikat-Datei enthalten sind.

Nun erwartet "firmwarecfg" zwar alle notwendigen Bestandteile für die Verschlüsselung (privater Key, ggf. auch bereits verschlüsselt, das Kennwort zum Entschlüsseln steht dann in den Parametern aus dem Formular und das Zertifikat im PEM-Format) in einer gemeinsamen Datei, diese wird aber intern offenbar noch zerlegt und so wird ein darin enthaltener DH-Abschnitt wieder entfernt und nicht gespeichert - gibt aber auch keinen echten Fehler, solange die "Begrenzer" stimmen.

Wer sich nicht mehr an ein damit im Zusammenhang stehendes Problem erinnern kann, sollte mal nach "Logjam" suchen ... da basiert der Angriff auf schwachen DH-Parametern und die FRITZ!Box verwendet in ihrer Standardkonfiguration (zumindest damals, aber auch heute wüßte ich nicht, wann sie sich die Zeit für die Generierung nehmen würde) erstens ständig dieselben (offenbar fest einkompilierten) Werte und zweitens waren die damals alles andere als ausreichend, weil nur 512-Bit-basiert. Die Folgen (und die Voraussetzungen) für Logjam kann man heutzutage z.B. bei heise.de noch nachlesen - was AVM jetzt verwendet, habe ich schon lange nicht mehr geprüft. Allerdings sollte jeder Online-SSL-Test heutzutage ja auch auf Logjam checken und ich habe schon länger keine Klagen mehr gehört, aber eigene Primzahlen (die sich von denen der anderen FRITZ!Box-Besitzer unterscheiden, denn ich glaube - wie geschrieben - nicht daran, daß die auf der Box generiert werden, weil das doch ein heftiger Aufwand ist und schon auf einem ausgewachsenen PC seine Zeit braucht, wie jeder mit einem mutigen:
Code:
vidar:~ $ openssl dhparam -5 -outform pem -text
Generating DH parameters, 2048 bit long safe prime, generator 5
This is going to take a long time
...................................................+..................................+..........................................................................................................................................................................................................................+............................+................................................................+...............................+................................................................................................................+.................................................+.....................................................+............................+................................................................................................................................................................+...................+............................................................+.............+......................................................................................................+...................................................................................................................+.....................+............................................................................................................................+.......................................................................................................................................................+............................................................................................................................................................+.............................................................................................................................................................+....................................................................................................................................................................................+.............+.....................................................+.............................................................................................................................................................+...................................................................................................................+.........................................+...........................................................................+......................+...................................................................................................................+.......................................................................................................................................................................................................................................................................................................+.......................................+.................+........................................................................................................................................+..................................................................................+....................+....................................................................................................................................................+......................................................+.....................................................................................................................++*++*
    DH Parameters: (2048 bit)
        prime:
            00:8f:34:51:52:5a:2d:d9:de:9d:15:3a:33:c6:69:
            15:85:cc:a4:a3:98:21:a7:69:01:8c:50:80:1a:37:
            36:a5:fa:96:ac:d6:1b:15:02:6b:59:94:d5:f7:fc:
            f0:da:b0:4b:9e:4a:f8:e8:e5:ee:23:19:3b:17:1b:
            8f:75:f8:ae:83:81:50:59:6d:02:90:09:ac:08:61:
            b0:2a:b3:af:c7:02:3d:3c:33:d1:b3:33:e3:83:63:
            53:36:20:01:69:ea:86:08:8b:86:f8:79:c1:0f:6e:
            5c:52:04:c5:7d:94:f1:cb:d1:6b:19:38:ba:9c:30:
            46:d9:78:16:54:fa:91:02:b9:ef:c5:d8:6f:d0:c2:
            4b:e8:f0:10:c3:23:f1:e9:7e:85:bb:46:32:79:76:
            0d:44:d4:1e:c8:c0:e0:32:28:90:42:b9:a5:de:19:
            01:f6:37:8a:4c:e4:26:00:70:9e:63:5d:97:54:2c:
            c6:bb:9a:b7:8a:0b:72:bf:d1:07:5d:08:66:0f:7b:
            9d:ab:1a:09:63:ad:28:ee:ba:fc:84:a1:68:fa:12:
            61:8e:f1:c8:ce:f1:8f:56:cd:92:a1:0a:2d:86:7d:
            0f:04:0a:63:05:74:7b:15:0f:35:72:6b:98:5e:1f:
            db:0a:5f:58:11:f4:8b:12:bf:37:ff:ac:f1:68:31:
            c3:d7
        generator: 5 (0x5)
-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEAjzRRUlot2d6dFTozxmkVhcyko5ghp2kBjFCAGjc2pfqWrNYbFQJr
WZTV9/zw2rBLnkr46OXuIxk7FxuPdfiug4FQWW0CkAmsCGGwKrOvxwI9PDPRszPj
g2NTNiABaeqGCIuG+HnBD25cUgTFfZTxy9FrGTi6nDBG2XgWVPqRArnvxdhv0MJL
6PAQwyPx6X6Fu0YyeXYNRNQeyMDgMiiQQrml3hkB9jeKTOQmAHCeY12XVCzGu5q3
igtyv9EHXQhmD3udqxoJY60o7rr8hKFo+hJhjvHIzvGPVs2SoQothn0PBApjBXR7
FQ81cmuYXh/bCl9YEfSLEr83/6zxaDHD1wIBBQ==
-----END DH PARAMETERS-----
vidar:~ $
selbst feststellen kann), können ja eigentlich auch nicht wirklich schaden.

Um also eigene "DH PARAMETERS" dem Zertifikat hinzufügen zu können (damals habe ich auch geprüft, daß diese tatsächlich verwendet werden und Logjam damit erledigt war - irgendwo gibt es hier bestimmt noch den alten Beitrag, den man mit "dhparam" o.ä. auch finden können sollte), mußte ich das ohnehin selbst speichern und konnte "firmwarecfg" nicht bemühen - daher auch die absolute Unkenntnis, ob AVM da geändert hat und wenn ja, was und wann genau.

Also alles einfach noch einmal selbst überprüfen ... beim Request an "firmwarecfg" kommt es auf die Reihenfolge an, weil inzwischen wohl schon die SID direkt geprüft wird, damit da niemand aus Spaß den "firmwarecfg" einfach mal so in einem Request länger "festhalten" kann (z.B. durch unvollständig gesendete Requests, die keine Authentifizierung brauchen), denn das ist wohl immer noch ein "singleton", also ein Programm, von dem nur eine einzige Instanz parallel laufen kann (zumindest war er mal einer - wodurch der DoS-Angriff auf ihn erst möglich wurde).

PS/EDIT: Um auch das noch mal festzuhalten ... man muß im FF erst die DevTools starten und auf "Network" stellen, bevor man den Request startet ... ansonsten wird da nichts aufgezeichnet.

PPS: Weil ich auch das noch vergessen hatte ... ja, "ctlmgr_ctl w ..." ist ein "echtes Schreiben" (wenn auch manchmal etwas "lazy" wg. des Cachens) - nur bringt das hier m.E. nicht so richtig etwas, weil das einzige beschreibbare "Datum" wohl der Befehl zum Löschen des benutzereigenen Zertifikats ist. Der dann - iirc - auch gleich noch das Generieren eines neuen, internen Keys anschiebt, weil der TLS-Support ja sowohl einen Key als auch ein Zertifikat braucht und das LE-Zertifikat alleine hier wohl nicht reicht, denn es zertifiziert ja auch nur die MyFRITZ!-Adresse und wird nur bei dieser im SNI-Header auch hervorgeholt.

Aber das kann man ja "abfangen" und sich so die Abläufe und die Reihenfolge verdeutlichen ... AVM verwendet für das Generieren zwei spezielle Binaries, eines für das Generieren eines Keys (genrsa) und eines zum Signieren (req). Wenn man diese beiden (in /bin) mit eigenen Dateien "überlädt" (per bind-Mount und das können ja auch Shell-Files mit SheBang sein), dann kann man genau sehen, in welcher Abfolge die aufgerufen werden (und wie), wenn man das in eine entsprechende (gemeinsame) Log-Datei schreibt, bevor man die originalen Programme aufruft (von anderer Stelle, wo man sie zuvor gesichert hat).

Ich sehe also nicht, was der "ctlmgr_ctl" hier beim Verwenden eigener Dateien bringen sollte ... er kann zwar Werte abfragen, die das Vorhandensein eines eigenen Zertifikats betreffen, aber die einzige "Wirkmöglichkeit", die er hat, ist m.W. das Löschen des Benutzerzertifikats, womit dann ein neues generiert wird, samt Key. Der Upload geht immer über den "firmwarecfg" und es wäre denkbar, daß der intern den "ctlmgr" noch irgendwie davon in Kenntnis setzt (über eine IPC-Message), daß es jetzt einen neuen Key und ein neues Zertifikat gibt ... aber das kann man auch über ein "strace" ermitteln, wer da am Ende die Daten in die "websrv_ssl_{cert,key}.pem" schreibt. Startet man dann noch den "ctlmgr" mal mit Protokollierung, sieht man vielleicht sogar die IPC-Messages, die da zwischen "firmwarecfg" und dem "ctlmgr" vermutlich ausgetauscht werden.
 
Zuletzt bearbeitet:
@PeterPawn: Danke für die Aufklärungen. Mit dem FF DevTools versuche ich klar zu kommen. Es sieht wirklich bei meinem Win10 FF anders aus, als z.B. bei LinuxMint oder bei dem, was du beschreibst. Ich werde mich da aber durchkämpfen, weil ich jetzt zumindest weiß, wonach ich suche. Ich kannte diese sniffer-Funktion von FF bis jetzt nicht...
Bzgl. ctlmgr_ctl war eher eine allgemeine Frage von mir, weil ich damit noch mehr machen will. Du hast mich aber mit deiner ausführlichen Erklärung damit auf eine Idee gebracht, ob es vielleicht sogar nicht besser wäre, genau diese Aufrufe von genrsa und req generell abzufangen und anstelle selbst signierte Zertifikate von der Box generieren zu lassen ihr unsere eigene (z.B. die von Letsencrypt) "runterzuschieben". Ist aber nur eine der vielen möglichen Ausführungen. Ich kannte die beiden Binaries nicht, darum danke für den Hinweis. Ich dachte eher, dass firmwarecfg spezielle Libraries dafür nutzt und dass man da ohne strace kaum weiter kommt. Wenn es aber Binaries sind, die man "übermounten" kann und per Shell die Aufrufe verfolgen kann, ist es schon nicht so ganz kompliziert.
Bzgl. firmwarecfg an sich. Eigentlich würde man (in meiner Vorstellung) aus der Shell heraus mit dem "reden", das Ding ist aber an sich eine CGI. Und wie du richtig anmerkst, braucht es schon seine "Sonderbehandlung" mit Multipart, SessionID usw. Die Geschichte wird dadurch beliebig kompliziert... Darum will ich nicht direkt mit firmwarecfg aus Shell "reden".
Warum ich nach AVM-Tools schaue? Deine jetzige Lösung würde OpenSSL und privatekeypassword voraussetzen. Eigentlich hat AVM schon ähnliche Werkzeuge am Board. Darum versuche ich (soweit es geht und soweit ich es hinbekomme) zunächst mal die "Hintergrund-Tools" von firmwarecfg ausfindig zu machen und ggf. mitnutzen.
Deine eigene Lösung muss ich natürlich erstmal für mich auch nachbauen und verinnerlichen. OpenSSL und privatekeypassword habe ich schon mal in meine beiden Boxen mitaufgenommen, um in die Richtung "spielen" zu können. Wird aber nur mir persönlich was bringen. Ansonsten spielt es in der Kategorie "das Rad neu erfinden", da du es schon nachweislich am Laufen hast.

MfG
 
Übrigens, ctlmgr_ctl ist heutzutage deutlich gesprächiger und spuckt da schon mal viele Beispiele, wenn man ihn falsch bedient:
Und damit wären auch hübsche formatierte Ausgaben möglich.
Crashkurs:
Code:
ctlmgr_ctl l landevice "settings/landevice/list(name,ip,mac,active,online)"
:rolleyes: ( Wo hab icke denn die Parameter her ? )
Ganz einfach...
Code:
ctlmgr_ctl u landevice
:rolleyes: ( Woher hab icke das "landevice" ? )
Code:
ctlmgr_ctl u
 
Aber das kann man ja "abfangen" und sich so die Abläufe und die Reihenfolge verdeutlichen ... AVM verwendet für das Generieren zwei spezielle Binaries, eines für das Generieren eines Keys (genrsa) und eines zum Signieren (req). Wenn man diese beiden (in /bin) mit eigenen Dateien "überlädt" (per bind-Mount und das können ja auch Shell-Files mit SheBang sein), dann kann man genau sehen, in welcher Abfolge die aufgerufen werden (und wie), wenn man das in eine entsprechende (gemeinsame) Log-Datei schreibt, bevor man die originalen Programme aufruft (von anderer Stelle, wo man sie zuvor gesichert hat).
Ich habe nun "/bin/openssl_genrsa" und "/bin/openssl_req" als wrapper mit dem Logger ausgestatet. Hier ist die Reihenfolge und die Commandos beim Generieren von eigensignierten Zertifikaten:
Code:
openssl_genrsa -aes128 -passout pass:*GEHEIM* 2048
Antwort über STDOUT
Code:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,XXXYYYZZZXXXYYYZZZ

XXXYYYZZZ
*KEY-INHALT*
XXXYYYZZZ
-----END RSA PRIVATE KEY-----
Der Inhalt wird dann von frimwarecfg vermutlich unter /var/flash/websrv_ssl_key.pem abgelegt. Danach erfolgt
Code:
openssl_req -config /var/tmp/openssl.cnf -new -x509 -key /var/flash/websrv_ssl_key.pem -out /var/tmp/websrv_ssl_cert.pem -days 6974 -sha256
Wobei die von firmwarecfg kurz angelegte und wieder gelöschte /var/tmp/openssl.cnf wie folgt aussieht:
Code:
[ req ]
prompt = no
default_bits = 2048
distinguished_name  = req_distinguished_name
x509_extensions = v3_ca

input_password = '*GEHEIM*'
string_mask = nombstr

[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true
subjectAltName=DNS:home.meine.tld,DNS:fritz.box,DNS:www.fritz.box,DNS:myfritz.box,DNS:www.myfritz.box,DNS:FB1,DNS:fritz.nas,DNS:www.fritz.nas
[ req_distinguished_name ]
CN = home.meine.tld
Beim Import eigener Zertifikate (in meinem Falle letsencrypt wildcard, KEY ohne Passwort) nutzt firmwarecfg offensichtlich die beiden openssl-Binaries nicht. Die Frage für mich ist hier: Warum? Irgendwie wird doch /var/flash/websrv_ssl_key.pem generiert? Hier bitte ich um die Aufklärung von einem von euch, der sich mit dem openssl-Zeug gut auskennt.
Folgende Erkenntnisse, Ideen und Gedanken meinerseits, was man daraus machen kann:
1. Man kann sich schon mittels eines solchen Wrappers an die beiden Datein "anhängen", die Abfragen abfangen, etwas abändern / umlenken, was auch immer. Die firmwarecfg würde denken, es generiere eigensignierte Zertifikate, man würde dagegen der Box eigene Zertifikate "unterschieben".
2. Man kann mit /var/tmp/openssl.cnf "rumspielen" und dort eigene Konfiguration platzieren. Die ganz einfache Geschichte wäre es, die Einträge unter "subjectAltName" durch eigene Namen zu ersetzen bzw. zu ergänzen. Somit hätte man zwar eigensignierte Zertifikate, aber nicht nur für myfritz-Domänen, sondern auch für eigens ausgedachte Namen.
3. Auf "privatekeypassword" wird man vermutlich nicht verzichten können, wenn man die beiden Binaries ohne firmwarecfg aufrufen will. Denn das Passwort wird schon von firmwarecfg an die beiden Dateien gestellt.
4. Das Ablegen vom Passwort im Klartext in /var/tmp/openssl.cnf ist nicht die feine Art von AVM, wie man mit Passwörter umgeht, selbst wenn die Datei nur kurz vorhanden ist und danach gelöscht wird...
5. Beide Binaries gibt es wahrscheinlich im "großen" /usr/bin/openssl als Aufrufoption, oder verstehe ich es falsch? Soll heißen, man kann auch alternativ über die normale openssl gehen, wenn man sie am Board hat. Vielleicht sogar beide Binaries durch wrapper mit der Umlenkung zu /usr/bin/openssl im solchen Fall ersetzen.

Diese "wrapperei" hat mich darauf gebracht, einen wrapper für AVM-eigene letsencrypt-Binary zu machen, um sich dort "umzuschauen". Denn, wenn man dort die ganzen myfritz-Domänen durch eigene ersetzen könnte, könnte man evtl. auf eine etwas "billigere" Art zumindest die auf myfritz-eingeschränkte AVM-Lösung auch auf andere Domänen ausweiten. Werde ich wahrscheinlich auch irgendwann mal angehen...

Die offene Frage bleibt aber für mich vorerst: Wie werden eigene Zertifikate importiert, wenn der Weg an beiden binaries vorbei geht?

MfG
 
Beim Import kann "firmwarecfg" ja keinen eigenen Key generieren, denn der korrekte (private) Schlüssel ist Bestandteil der zu importierenden Daten. Diese bestehen ja aus Key + Zertifikat, der Aufbau ist inzwischen auch bei AVM beschrieben. Und nur mit dem Import hat "firmwarecfg" überhaupt etwas zu tun ... der Aufruf der beiden anderen Binaries erfolgt über den "ctlmgr" bzw. beim CSR-Generieren auch noch von "letsencrypt" aus, wobei das Generieren des RSA-Keys für das LE-Zertifikat wohl direkt irgendwo erfolgt und nicht über einen Aufruf von "openssl_genrsa".

Das CGI-Binary kommt nur beim Upload (und Parsen der übertragenen Daten) überhaupt zum Einsatz ... damit interessiert es dort auch nicht, wen oder was Du durch einen Wrapper gekapselt hast. Die Datei wird geladen, in ihre Bestandteile zerlegt, der private Key (wenn er verschlüsselt hochgeladen wurde) entschlüsselt und mit dem Box-Key wieder verschlüsselt, bevor beide Dateien im TFFS gespeichert werden ... fertig.

Mehr passiert beim Import praktisch nicht ... höchstens noch die Benachrichtigung an den "ctlmgr", daß es ein neues Zertifikat gibt, damit der das auch lädt und verwendet - denn er ist ja (in Personal-Union) auch noch der TLS-Server für das GUI und der Austausch eines Zertifikats durch Upload erfolgt von "firmwarecfg" aus ... was zwar vom "ctlmgr" in seiner Funktion als HTTP-Server auch aufgerufen wurde, aber da hat der "ctlmgr" zunächst mal gar keinen Schimmer, was der Benutzer konkret von "firmwarecfg" will, denn das hat ja viele Funktionen.

Wenn ich mich richtig erinnere, gingen alle Schreiboperationen beim Import nach "/var/flash/websrv_ssl_{cert,key}.pem" von "firmwarecfg" aus (ggf. aus einer Lib, die von dort aus verwendet wurde, aber immer im Kontext des Prozesses für "firmwarecfg").

Der "ctlmgr" befaßt sich mit der OpenSSL-Geschichte nur dann, wenn er beim Start keine passenden Daten hat (u.a. auch dann, wenn er den Key nicht mit dem Box-Kennwort entschlüsseln kann, dann generiert er sich einen neuen) oder wenn ihm vom GUI mitgeteilt wird, daß der Benutzer den vorhandenen Key (egal, ob das ein hochgeladener oder ein selbstgenerierter war) löschen möchte (das hast Du ja schon gefunden). Ansonsten muß er nur noch wissen, welche Zertifikate mit welchen Keys ihm für TLS-Verbindungen zur Verfügung stehen ... das hat aber mit der "Verwaltung" (Generieren, Kopieren, usw.) nur noch am Rande zu tun.

-----------------------------------------------------------------------------------------------------------------

An das Generieren des LE-Zertifikats würde ich mich nicht versuchen anzuhängen ... zumindest nicht, ohne zuvor mal zu prüfen, ob der "ctlmgr" das passende Zertifikat anhand des SNI-Headers in einem TLS-Request auf der Basis des tatsächlichen CN (bzw. SAN) im LE-Zertifikats auswählt oder generell anhand der Tatsache, daß es eine Adresse in der Domain "myfritz.net" ist (und möglichst noch der eigene Name) und ansonsten darauf vertraut, daß es schon irgendwie passen wird, weil er natürlich nicht mit ungewöhnlichen Inhalten im Zertifikat rechnet.

Ist nur der Domain-Name für ihn entscheidend (ich weiß es nicht wirklich, das mußt Du selbst prüfen), kannst Du soviele SAN-Einträge haben, wie Du willst - es würde nichts bringen, weil er für alles, was seiner Ansicht nach nicht mit dem LE-Zertifikat erfüllt werden kann, dann das andere nimmt und auch da wohl erst noch testet, ob die Domain paßt ... denn ansonsten könnte man mit einem HTTPS-Request für die IP-Adresse (also ohne SNI-Header, weil der Request keinen Hostnamen hat) ja auch wieder umgehend die MyFRITZ!-Adresse der FRITZ!Box ermitteln, denn die stünde ja in dem Zertifikat, was die Box bei einem Request ohne SNI-Header präsentiert, wenn es kein zweites Zertifikat gäbe.

Da (in diesem zweiten (Nicht-LE-)Zertifikat) steht dann nun aber (wenn man kein eigenes installiert hat) auch wieder nur die (ohnehin schon bekannte) IP-Adresse der FRITZ!Box (in v4 und v6, wenn sie beide hat) und die internen Domain-Namen. Insofern "verrät" das selbstgenerierte Zertifikat der FRITZ!Box ggf. noch die Zuordnungen von IPv4- und IPv6-Adresse für den Anschluß ... wenn man ohnehin mit A- und AAAA-Record auf die eigene Box verweist, ist das aber auch eine läßliche Sünde (mal abgesehen davon, daß wieder mal die DSL-MAC in der IPv6-Adresse steht und damit das Tracking auch wieder mal erleichtert wird).

Hier würde ich mir irgendwie noch wünschen, daß die IPv6-Adresse nur in einem eigenen Zertifikat für IPv6-Zugriffe auftaucht ... wenn AVM schon Zertifikate mit Adressen anstelle von Domain-Namen ausstellen will. Denn einen Gewinn an Sicherheit, daß man tatsächlich mit der richtigen Box "redet", gibt es über die IP-Adresse natürlich auch nicht ... und solange ein Browser das Zertifikat nicht anhand des öffentlichen Schlüssels "pinnen" kann, ist die Bekanntgabe der "Adresszuordnung" irgendwie nur "niederträchtiger Geheimnisverrat" durch die Box.

Das ist zwar für irgendwelche Apps auch ganz nett (weil das API der Mobilgeräte auch schon mal das Pinnen mit dem PublicKey erlaubt: https://developer.android.com/training/articles/security-config), aber der Wechsel des Zertifikats mit jedem Wechsel der IP-Adresse ist natürlich auch Gift für jeden (PC-)Browser, der seinerseits nun ein "certificate pinning" vornehmen will - damit ist man schon fast gezwungen, ein eigenes Zertifikat zu verwenden.

Solange man jetzt den dort enthaltenen Domain-Namen nicht in die "rebind exceptions" einträgt, gibt es wohl den HTTP-Error beim Versuch der Verbindung ... ich kenne zwar die Zusammenhänge auch nicht wirklich, könnte mir das aber auch als Sicherheitsmaßnahme vorstellen, damit die Box eben nicht bei jedem HTTPS-Request an die eigene IP-Adresse sofort die Domain-Namen verrät, unter denen ein Angreifer (der nichts weiter machen kann, als einen TLS-Handshake zu versuchen - den aber anonym und durch "Abgrasen" ganzer AS, auch wenn der "versteckte Port" das etwas verlangsamt) sie auch später wiederfinden könnte (die Portnummer hat er dann ja i.d.R. bereits gefunden). Vielleicht hat es ja auch ganz andere Gründe ... und ich rede mir das bloß schön als "Feature", mit dem AVM die Sicherheit der Box weiter verbessern will.

Wenn meine Vermutung aber stimmt, dann deutet die Notwendigkeit des zusätzlichen Eintrags in die "rebind exceptions" ja eher darauf hin, daß AVM hier wohl mit einer Liste von Domain-Namen arbeitet und nicht wirklich mit dem Inhalt des Zertifikats (also dem CN bzw. SAN in diesem) ... daher würde ich das (um mal wieder zum AVM-LE-Zertifikat zurückzufinden) dann auch beim LE-Zertifikat eher analog erwarten und nicht wirklich auf der Basis des Inhalts dieses Zertifikats. Wäre das aber so, ist es vollkommen egal, was Du im LE-Zertifikat noch für Namen hast ... das würde nur dann von der Box "vorgezeigt", wenn der Request auch an die MyFRITZ!-Adresse geht. Daher mein Ratschlag, das erst gründlich zu testen, bevor man sich da einklinken will.
 
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.