Let's Encrypt Zertifikat auf der Fritzbox

Peter8Dev

Neuer User
Mitglied seit
12 Dez 2015
Beiträge
6
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

erstmal kurz zur Info, für die "Let's Encrypt" zum ersten mal hören. (https://letsencrypt.org/) Ein Projekt das es ermöglicht ein vertrauenswürdiges, kostenloses Zertifikat zu erstellen für seine eigenen Server. Sprich endlich per https und DynDNS auf die Fritzbox zuzugreifen und keine Ausnahmeregel die man bestätigen muss.

Das Projekt ist mittlerweile in der Open Beta und ich finde immer noch keine Ergebnisse zu "Let's Encrypt" und Freetz/Fritzbox. Auch der AVM-Support klang so, als würden sie das zum ersten mal hören. Aus meiner Sicht wäre ein Mehrwert für die Fritzbox.

Nun aber mal konkret zu meinen Fragen/Anregungen:
Gibt es denn generell Interesse für vertrauenswürdige Zertifikate um das aktuell in der Fritzbox vorhandene selbstsignierte Zertifikat zu ersetzten? Gibt es schon Informationen/Sammlungen/Ideen zu Fritzbox und diesem Projekt die ich einfach nicht finden konnte?

Aktuell habe ich es geschafft mit viel geduld und viel lesen/suchen ein funktionierendes Zertifikat über Let's Encrpyt für meine Fritzbox zu erstellen. Das ganze ist aber noch weit von einer praktikablen und automatisierten Lösung entfernt. (Aber eine Automatisierung ist dringen notwendig, da die Zertifikate gewollt nur für 3 Monate gelten und es ggf. in naher Zukunft noch kürzer gültig sind).

Ich kann gerne mal ein kleines HowTo schreiben wie ich es aktuell zum laufen bringe. (Falls das für jemanden nützlich sein sollte)

Fragen/Ideen/Anregungen/Lösungen/Untersützung wären super. Ich glaube in dem Projekt steckt viel potential und eine Fritzbox Unterstüzung könnte vielen Helfen.

Grüße Peter

PS: Tut mir leid für die etwas wenig konkreten Informatione/Fragen, aber ich habe einfach noch nichts gefunden und bin noch ganz am Anfang. Und falls das Thema im allgemeinen Fritzbox-Forum besser aufgehoben ist, bitte gerne verschieben, ich denke aber das es noch eher eine Modifikation für Experten ist.
 
Ich kann gerne mal ein kleines HowTo schreiben wie ich es aktuell zum laufen bringe. (Falls das für jemanden nützlich sein sollte)
In etwa so?
1. Cert am Rechner erstellen
2. CSR einsenden
3. Cert auf FB laden

Das sollte man autmatisieren können.
 
Da hat der TO sicherlich eher an eine automatisierte Lösung gedacht, die gar nicht erst einen "Rechner" benötigt und komplett in der FRITZ!Box selbst abläuft.

Aber ich glaube kaum, daß AVM da vor dem tatsächlichen Release des Dienstes (ist ja nur eine public beta zur Zeit) etwas in der Richtung unternehmen würde und auch dann noch liefe das mit einiger Wahrscheinlichkeit auf eine eigene Implementierung in C hinaus (mit entsprechendem Aufwand), da die von Let's Encrypt selbst angebotenen Module zur automatischen Verifikation des "Antragstellers" wohl in Python vorliegen und AVM kaum ein Python-Environment in der FRITZ!Box einrichten wird.
 
Man kann das am Rechner auch ohne Python machen, wenn man die API selbst bedient, da sollte auf der FB auch funktionieren.
 
Was heißt denn "wenn man die API selbst bedient"?

Kannst Du das mal etwas genauer erklären?

Wenn Du damit meinen solltest, daß man das ACME-Protokoll auch in anderen Sprachen implementieren könnte, dann ist das ja eigentlich genau das, was ich beschrieben habe.

Ich kenne zwar die Möglichkeiten der Plugins "Standalone" (startet einen eigenen Webserver nur für die Verifikation), "Manual" (erfordert zusätzliche Arbeiten durch den Benutzer, die zwar anders sind als bei anderen "certificate for free"-Diensten, aber am Schluß wäre das ja der in #3 beschriebene Weg) und "Webroot" (kopiert die erforderlichen Dateien in ein Unterverzeichnis eines bereits existierenden Webservers, der die dann ausliefern soll) ... aber keines davon kommt ohne Python aus. Also noch einmal die Eingangsfrage ... was heißt "selbst bedient"? Die Verifikation besteht ja darin, daß einer "Aufforderung" der CA für die Bereitsstellung bestimmter Ressourcen unter dem zu zertifizierenden Domain-Namen nachgekommen wird und das will man sicherlich nicht alle drei Monate (oder ggf. sogar noch öfter, wenn die derzeit verwendeten 90 Tage nicht die finale Entscheidung gewesen sein sollten) erneut von Hand ausführen.

Ich gehe nach wie vor davon aus, daß auch dem TO eher eine Lösung vorschweben würde, die zumindest das Renewal selbst vornimmt (dann kann auch gleich der initiale Request auf diesem Weg erfolgen, das ist prinzipiell kein Unterschied bis auf das Anlegen eines Accounts) - so steht es jedenfalls nach meiner Lesart in #1 - und genau das erfordert aber eben dann (mit dem ISRG-Client) eine Python-Installation auf der FRITZ!Box oder eben eine eigene Implementierung des ACME-Protokolls in einer unterstützten Sprache auf der FRITZ!Box. Das wären derzeit Lua und Shell als Interpreter-Sprachen und eben alles, was in C (mit der uClibc als Runtime-Library) programmiert ist oder was statisch gelinkt wird. Da das ACME-Protokoll ja auf einer (automatisierten) Abfrage des Webservers unter der zu zertifizierenden Adresse basiert, mit der die Identität des Servers abgesichert werden soll (zumindest die zu diesem Zeitpunkt vorhandene "Herrschaft" über diesen Server) und dafür normalerweise nur die Ports 80 und 443 verwendet werden, muß man da also zumindest statischen Content von der richtigen Adresse (die, wohin der Servername im Zertifikat zeigt) und dem richtigen Port "servieren", wenn man den Prozess durchläuft. Jeder "new-authz"-Aufruf antwortet mit entsprechenden "Aufgaben", die der Server-Admin zu erfüllen hat, damit externe Abfragen die richtigen Ergebnisse liefern.

Wenn parallel AVM darauf angesprochen wurde (siehe #1), dann steht man dort genauso vor dieser Entscheidung. Die wird vermutlich eher nicht in Richtung Python auf einer FRITZ!Box gehen, weil das spätestens bei den NOR-Boxen absehbar zu erheblichen Platzproblemen führt. Also braucht es eine ACME-Implementierung mit wenig Platzbedarf (das dürfte in C am kleinsten werden) und meines Wissens gibt es so etwas bisher noch nicht (zumindest nicht als OpenSource) ... aber ich lasse mich gerne über entsprechende Quellen aufklären, dann kriege ich das auch auf einer Box automatisiert.
 
Zuletzt bearbeitet:
Ja, ich meinte das ACME-Protokoll, ich wusste nicht dass das ein eigenes Protokoll ist.
Ich habe schon eine Implementation in JavaScript gesehen, daher wird es wohl auch welche in C geben.
 
thtomate12 schrieb:
Ja, ich meinte das ACME-Protokoll
Ich hatte auch aus Versehen den alten Draft verlinkt, der korrekte (aktuelle) ist unter https://tools.ietf.org/html/draft-ietf-acme-acme-01 zu finden.

daher wird es wohl auch welche in C geben.
Meines Wissens gibt es bisher die ISRG-Implementierung in Python, eine in Ruby on Rails und einen recht kompletten C#-Client - neben der JS-Implementierung, die eigentlich auch nichts weiter als ein "endlicher Automat" ist, der die einzelnen auszuführenden Schritte dem Benutzer anzeigt und die eigentliche Arbeit trotzdem ihm überläßt. Die JS-Implementierung und auch die C#-Version greifen obendrein noch auf OpenSSL als Kommandozeilenversion zurück, um einige kryptographische Operationen auszuführen, die Python-Version auf pyOpenSSL als Module und damit m.W. auf die OpenSSL-Libraries - bei der Ruby-Version habe ich keine Ahnung, was die noch an "Rahmenbedingungen" braucht.

Aber am Ende ist die JS-Version (die kannte ich tatsächlich auch schon seit Mitte November und der Ankündigung der "public beta" durch "Let's Encrypt" und nicht erst seitdem ein in IT-Kreisen bekannter Blogger dahin verlinkte und dann heise.de darüber berichtete) eben nichts anderes als das "manual"-Plugin der Python-Version, es ist nur die "Ablaufsteuerung" für den Benutzer ... die dann bei ihm wirklich kein Python verlangt, aber immer noch die Möglichkeit, statische Inhalte auf dem Webserver "auf Kommando" bereitzustellen unter einem Pfad - ".well-known/acme-challenge" - auf den ein normaler User keinen Zugriff haben sollte - damit nicht eine beliebige "Webpräsenz" auf einem "shared server" (nach dem Schema "www.server.tld/usercontent") sich ein Zertifikat für den gesamten Server beschaffen kann.

Der eigentliche Vorteil der automatisierten Abläufe ist es ja, daß der Benutzer eben nicht irgendwelche komplizierten Kommandos in ein Terminal kopieren oder aus einer Anleitung abtippen muß. Wenn man den Aufwand bei der manuellen Vorgehensweise mit ACME-Protokoll mit dem Aufwand bei anderen Methoden (z.B. StartSSL mit E-Mail-Verifikation über eine administrative E-Mail-Adresse) vergleicht, schneidet nach meiner Meinung das ACME-Protokoll sogar schlechter ab ... es kann eben seinen entscheidenden Vorteil - die Automatisierung - nicht ausspielen.

Man kann also sicherlich mit ein wenig Aufwand auch "manuell" ein "let's encrypt"-Zertifikat für eine FRITZ!Box generieren (indem man für die Dauer der Verifikation die eingehenden Ports für HTTP/HTTPS auf einen anderen Server forwarded (z.B. die "standalone"-Version des letsencrypt-Clients) oder die Inhalte tatsächlich in die FRITZ!Box bringt, was aber gar nicht so einfach ist angesichts des benötigten Pfades für einen solchen Request und ohne Shell-Zugriff ohnehin nichts wird) ... aber der Aufwand dafür steht angesichts der Gültigkeitsdauer erst einmal in keinem Verhältnis zum Nutzen. Da ist dann tatsächlich ein (lokal generierter, alles andere ist Quatsch) CSR für StartSSL fast einfacher zu erledigen mit der richtigen Anleitung, wobei der m.W. wieder keine SANs-Entities erlaubt.

Wenn das mit "Let's Encrypt" dem Beta-Stadium entwachsen ist, kann man sich sicherlich auch Gedanken darüber machen, wie man so etwas in die FRITZ!Box bekommt ... und zwar so, daß es automatisch funktioniert. Das setzt dann aber eine "konzertierte Aktion" verschiedener Komponenten voraus, z.B. muß dann eben zum Zeitpunkt der Validierung jede im Zertifikat angegebene DynDNS-Adresse auch tatsächlich aktuell sein, damit so ein Request funktionieren kann.

Einen reinen C-Client sehe ich jedenfalls im Moment noch nicht als OpenSource-Software irgendwo im Internet ... ich habe bisher nichts gefunden. Das ist ähnlich wie bei einer WebDAV-Server-Implementierung in "purem" C oder meinetwegen noch C++ ... alles was es jenseits des Apache-Moduls gibt, ist in irgendeiner (Interpreter-)Hochsprache geschrieben, die zusätzlichen Aufwand auf der Box verlangt.

Am Ende sollte so etwas für den Benutzer eben so einfach sein, daß er nur noch einen Haken setzt bei "Let's Encrypt-Zertifikat verwenden" und die FRITZ!Box dann anhand der konfigurierten DynDNS-Namen ein Zertifikat automatisch erstellen läßt.

Aber da lauert dann auch schon die nächste Falle ... wenn man so ein externes Zertifikat verwendet, kann man den internen Zugriff über HTTPS praktisch vergessen. In den self-signed-Zertifikaten der FRITZ!Boxen sind eben nicht nur die externen Namen enthalten, sondern auch noch weitere "subject alternative names":
Code:
DNS Name=<primary DynDNS name>
DNS Name=<myfritz name>
DNS Name=fritz.box
DNS Name=www.fritz.box
DNS Name=myfritz.box
DNS Name=www.myfritz.box
DNS Name=<FRITZ!Box name>
DNS Name=fritz.nas
DNS Name=www.fritz.nas
Außer den ersten beiden Einträgen wird man wohl keinen der aufgeführten Namen von einer externen CA "genehmigt" bekommen. Wenn man also intern auch HTTPS verwenden will und dabei nicht über den externen DynDNS-Namen (oder den MyFRITZ!-Namen) zugreifen will, ist so ein "richtiges Zertifikat" auch nicht das Gelbe vom Ei.

Unter diesem Aspekt ist dann wieder ein ordentliches "self-signed"-Zertifikat (ggf. von der eigenen CA und nicht von der Box selbst ausgestellt, wenn man mehrere Boxen verwaltet und anstatt der ganzen Box-Zertifikate dann nur das eigene CA-Zertifikat "pinnen" muß) sogar die bessere Wahl ... einen Tod muß man eben sterben.

Meine (sehr persönliche) Einschätzung: Unter Umständen ist "Let's Encrypt" auch in einer FRITZ!Box eine gute Idee, allerdings wäre es dann vermutlich sogar schlauer von AVM, zwei unterschiedliche Zertifikate (ein "offizielles" für extern und ein "self-signed" für intern) zu verwenden und per SNI das richtige auszuwählen. Aber auch die SNI-Unterstützung ist m.W. noch nicht vorhanden, müßte also - neben dem Automatismus für ACME - ebenfalls noch implementiert werden.

Sehe ich in nächster Zukunft eher verschwommen, aber lassen wir uns überraschen ... vielleicht kriegt es AVM im Zuge einer solchen Änderung ja auch hin, den externen DynDNS-Namen und den MyFRITZ!-Namen bei internen Abfragen auf die LAN-Adresse der FRITZ!Box aufzulösen. Das hat zwar auch Nachteile (beim NAT-Hairpinning für "forwarded ports" auf LAN-Clients), aber auch verschiedene Vorteile bei Redirections vom HTTP- auf den HTTPS-Port - dann löst eben "fritz.box" immer noch auf die interne IP-Adresse beim HTTP-Zugriff auf und dort gibt es zwar ein Redirect auf den "offiziellen" DynDNS-Namen, aber der löst ebenfalls auf die interne Adresse auf ... zumindest solange gar keine externe Verbindung besteht, das wäre nämlich dann der Punkt, wo so ein TLS-Zugriff auf den externen Namen nicht mehr funktionieren würde, weil gar kein "NAT hairpinning" stattfinden kann, solange erstens das externe Interface keine Adresse hat und zweitens diese Adresse nicht im DynDNS aktualisiert wurde, so daß DNS-Abfragen auch auf die aktuelle externe IP-Adresse auflösen.

Das "keine Verbindung"- oder "DynDNS nicht aktuell"-Problem ist ja ein weiterer Pferdefuß bei der internen Verwendung der offiziellen DynDNS-Namen zum Zugriff auf die Box selbst (und natürlich auch auf jeden Client mit "forwarded ports"). Während man das bei einem beliebigen LAN-Client aber noch verschmerzen mag, wird es bei der Konfiguration der FRITZ!Box dann schon wieder kritisch, wenn die als Antwort beim HTTP-Zugriff unabhängig von ihrem aktuellen Zustand immer auf TLS unter dem externen DynDNS-Namen verweist und dieser Zugriff aber gar nicht funktionieren kann, weil schon der externe Name mangels externem DNS-Server (mangels Internetverbindung) nicht aufgelöst werden kann. Das ist zwar sicherlich nicht der "Normalfall", aber auch den muß man eben berücksichtigen, wenn man so etwas plant - da bietet sich dann eben wieder die Verwendung eines "internen" Zertifikats für die IP-Adresse und ein Redirect auf diese Adresse an, solange keine Internet-Verbindung besteht oder man läßt dann den HTTPS-Zugriff gleich weg, was wieder Auswirkungen auf die Sicherheit haben kann (session hijacking).

Wenn dann irgendwann auf Port 80 bei FRITZ!Boxen nur noch ein Redirector auf eine TLS-Verbindung antwortet und der Server mit HSTS modernen Browsern beim ersten Kontakt automatisch die künftige Verwendung von TLS nahelegt, dann klappt es auch mit dem automatischen internen HTTPS-Zugriff und ein Kriterium für vier "Pluspunkte" für sichere Router nach dem BSI-Entwurf (Punkt 3.4.3, S. 22) ist damit erfüllt.

Allerdings sollte dann auch noch die (parallele, aber möglichst auch abschaltbare, falls man einen anderen Server dort laufen lassen will) Verwendung des Standard-HTTPS-Ports 443 aus dem internen Netz möglich sein ... bisher nimmt AVM wohl denselben Port wie für einen externen Zugriff, damit die Konfigurationen irgendwelcher FRITZ!Apps auch dann noch gültig sind, wenn sich die Geräte im LAN befinden und nicht über das Internet zugreifen (was natürlich denselben Beschränkungen unterliegt, wenn die Box gar nicht erst ins Internet kommt - ich kenne nicht genug von den Android-Apps um sagen zu können, ob dabei dann ein automatischer Fallback auf die per UPnP im LAN lokalisierte Box erfolgen würde, meine MyFRITZ!-App für iOS schaut dann recht dumm aus der Wäsche und braucht ein "internes Konto"). Allerdings sollte es ja kein Problem sein, da noch einen zusätzlichen Listener auf Port 443 aufzusetzen - es gibt ja ohnehin schon mehrere Sockets im "listen()"-Mode, da macht ein weiterer den Kohl nicht fett.

Aber so ein TLS-Zertifikat hat eben viele "Konsequenzen", die alle bedacht sein wollen ... das war zwar bisher bei der Verwendung eines "offiziellen" eigenen Zertifikats auch so, aber da wußte der Benutzer dann in aller Regel auch einiges über Zertifikate an sich und genau das soll ja bei ACME nicht mehr erforderlich sein - mit entsprechenden Auswirkungen an anderen Stellen (wie ich vielleicht zeigen konnte).

Ob man jetzt den internen HTTPS-Zugriff für notwendig hält oder nicht (immerhin bin ich ja offenbar nicht alleine dieser Meinung, wenn der BSI-Entwurf dafür auch vier Extra-Punkte vergibt), ist vielleicht Geschmackssache ... wenn aber eine "Let's Encrypt"-Unterstützung das auf alle Zeiten verhindern würde, würde ich für das Auslassen von ACME-Unterstützung plädieren. Einfach schon deshalb, weil ein "certificate pinning" ohnehin in modernen Browsern um sich greifen wird (eigentlich macht es der Mainstream ja schon, daß man solche "Sicherheitsausnahmen" permanent speichern kann) und auch auf Serverseite gibt es mit HPKP ja inzwischen eine Lösung für das Pinnen einer CA oder sogar eines Zertifikats - da kann man (zumindest ich) mit einer einmaligen Browser-Warnung bei einer (erwarteten) Änderung des Zertifikats besser leben als mit einem dauerhaft abhörbaren Zugriff auf das GUI der Box. Allerdings verwende ich ohnehin für die FRITZ!Boxen Zertifikate meiner eigenen CA, die dann auch die notwendigen internen Namen und sogar noch die IP-Adresse der FRITZ!Box als "subject alternative names" enthalten ... das vermeidet natürlich die angesprochenen Probleme mit "intern vs. extern" ebenfalls.
 
Zuletzt bearbeitet:
Ich finde einen SSL-Zwang schlimm, weil man manchmal auch mal nur HTTP z. B. zum Debugging will. Mal ein Beispiel aus der Consumer-Router-Branche: Die Router eines magentafarbenes Provider haben das, dummerweise ist, bis auf bei der neusten Generation, das Zertifikat abgelaufen, d. h. man muss einen alten Browser vorhalten oder IE verwenden...
 
Meinetwegen für solche Zwecke dann eine "spezielle Einstellung" in der Box, die ein Redirect ausnahmsweise verhindert (obwohl man in der Regel so etwas ja auch mit den Developer-Tools eines Browsers debuggen kann - jedenfalls in den meisten Fällen - und dann stört TLS gar nicht) ... aber eben nur auf besonderen Wunsch und ansonsten die Kunden/Benutzer zu einer sicheren Umgebung "zwingen". Letzten Endes ist das ja auch der Grundgedanke hinter "Let's Encrypt" ... alles oder zumindest das meiste verschlüsselt abwickeln, dann ist es erstens nicht zu belauschen und erhöht zweitens den Anteil des verschlüsselten Verkehrs, wenn jemand "auf Vorrat" mitschneidet (letzteres ist sicherlich im LAN nur der Fall, wenn man sich einen unerwünschten Lauscher eingefangen hat). Mit dem Einzug von HTTP/2 in die Browser wird wohl das unverschlüsselte HTTP generell weiter abnehmen, denn obwohl der Standard ja auch unverschlüsseltes HTTP/2 erlaubt, haben die Browser-Hersteller ja wohl ein Erfordernis von TLS für HTTP/2 verkündet: https://www.mnot.net/blog/2015/06/15/http2_implementation_status
 
Erstmal Danke für die sehr lehrreichen Antworten.

@SF1975: Die Anleitung ist für mich leider nicht praktikable, da hier eine eigene Domain vorrausgesetzt wird.

Ich kann hier heraushören, dass ich lieber nicht auf eine "offizielle" Lösung von AVM in naher Zukunft hoffen sollte. Ihr habt auch meine Vermutung bestätigt, das eine portierung des ACME-Protokols auf die Fritzbox recht aufwendig sein wird, mit den aktuell zu findenden Quellen.

1. Cert am Rechner erstellen
2. CSR einsenden
3. Cert auf FB laden

Das sollte man autmatisieren können.

Im Moment klingt das für mich als die vielversprechenste und machbarste Lösung. Ich nutze aktuell den C# Port und habe damit ein Zertifikat erstellt. Das hosten der ACME-Challange Datei, das Freigeben des Ports in der Fritzbox und das laden des Zertifikats auf die Fritzbox waren noch manuell. Wenn ich diese Schritte nun noch automatisieren könnte wäre ich fürs erste glücklich. (Ein Häckchen in der Fritzbox wäre natürlich ein Traum ;-))
Einen minimal HTTP-Server in C# habe ich schon. Ich habe gelesen, dass die Portweiterleitung per TR-064 konfiguriert werden kann. Also fehlt nur noch das hochladen des Zertifikats, da konnte ich erstmal nichts finden. Könnt ihr mir da einen kleinen Hinweis geben oder muss ich da doch mehr in die Box eingreifen?
 
Könnt ihr mir da einen kleinen Hinweis geben oder muss ich da doch mehr in die Box eingreifen?
Wenn Du damit so etwas wie eine Implementierung der IInstaller-Klasse auf dem Python-Client meinen solltest (also eine Möglichkeit des automatischen Uploads des fertigen Zertifikats), dann geht das über das "firmwarecfg"-Binary des FRITZ!OS, das per CGI aufgerufen wird. Da kann man also einfach einen passenden "wget"-Request o.ä. basteln, man muß sich nur einmal die notwendigen Formularfelder anhand eines browserbasierten Uploads ansehen. Das Upload-Formular findet sich unter "FRITZ!Box-Dienste" bei "Internet/Freigaben". Das Format der zu sendenden Datei ist dokumentiert, im Prinzip der "private key" gefolgt von allen Zertifikaten der Chain bis hoch zur CA und das alles in PEM-Kodierung.

Eigene DH-Parameter (zur Vermeidung von "LogJam") kann man zwar direkt in der Box angeben als weiteren "Anhang" hinter dem Zertifikat (/var/flash/websrv_ssl_cert.pem) und sie werden dann auch tatsächlich verwendet, aber beim Import über firmwarecfg funktioniert das leider nicht, da dabei die Datei in ihre Bestandteile zerlegt wird. Die muß man also (wenn man es für notwendig erachtet) anschließend erst irgendwie per Skript an das Zertifikat anhängen ... das macht bei mir ein Start-Skript, das einfach nur in der Zertifikat-Datei die Zeichenkette "-----BEGIN DH PARAMETERS-----" sucht und wenn es sie nicht findet, kopiert es die inline vorliegende dhparam-Datei (sind nur 8 Zeilen) hinter das Zertifikat im Flash und hinter die Kopie in /var/tmp und startet den ctlmgr einfach noch einmal neu, damit die geänderte Datei wirksam wird.

Also noch mal zusammengefaßt: Für reinen Zertifikat-Upload braucht es nur einen passenden HTTP-Request (geht natürlich auch mit PowerShell, wenn Deine C#-Version ohnehin auf PS basieren sollte), für den Austausch von DH-Parametern muß man etwas mehr in die Eingeweide der Box abtauchen.
 
Na dann werde ich mich wohl am Wochenende mal hinsetzten müssen und mir etwas zusammen basteln. Vielen Danke für die Hinweise und Anregungen.
 
Per PN wurde ich gebeten, mal meine aktuellen Ergebnisse zu zeigen, da dieser nicht weiter kommt, aber irgendwie kann ich ihm keine Nachricht schicken (seine Einstellungen erlauben es nicht). Wie auch immer, evtl. ist es für den ein oder anderen Hilfreich und ich werde wohl diesen Lösungsweg nicht weiter verfolgen, da sich ein anderer Weg wohl doch sinnvoller für mich scheint. (Aber mit mehr Änderungen an der Box, dazu evtl. später mehr)

Also hier der Versuch eines Leitfadens (Das ist garantiert kein How-To da zuviel offen ist)
Vorraussetzungen:
- Windows Rechner der vom Internet aus über Port 80 erreichbar ist
- WebServer auf dem Rechner (z.B. einfache .net implementierung http://www.codeproject.com/Articles/742260/Simple-Web-Server-in-csharp)
- Powershell 32bit
- Sourcen von https://github.com/ebekker/ACMESharp

Ausführung:
Der Anleitung auf https://github.com/ebekker/ACMESharp/wiki/Example-Usage folgend bis zum Schritt "Edit-ACMEProviderConfig". Ab hier verwendet man statt "s3HttpProvider" den "manualHttpProvider". Beim Schritt "Complete-ACMEChallenge" gibt es als Output die Anweisung die erstelle Datei auf den WebServer zu laden. Das macht man z.B. mit dem oben beschriebenen einfachen WebServer. Und fährt dann fort wodurch man zu einem generierten Zertifikat kommt.
Dieses muss dann noch mit Private Key und Zwischenzertifikat in eine Datei zusammengeführt werden:
Rauskommen sollte eine einzelne ".pem"-Datei die man dann in der Fritzbox hochlädt. Der Inhalt ist der aneinandergehängte Inhalt der folgenden Dateien:
- Private Key (cert1-key.pem)
- Erstelltes Zertifikat (cert1-crt.pem)
- Zertifikat von LetsEncrypt CA (Get-ACMEIssuerCertificate -ExportCertificatePEM "filename")

Diese Datei kann dann in der Fritzbox hochgeladen werden und hat bei mir dann auch funktioniert.

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):
Code:
[COLOR=#008000]#Parameters[/COLOR]
$password = "<FritzBox Passwort>"
$BoxCertPassword = "<Passwort des Zertifikats(falls vorhanden)>"
$BoxCertFile = "<Pfad zur PEM-Datei>"

[COLOR=#008000]#get the challenge value of "login_sid.lua" [/COLOR]
$loginRequest = Invoke-WebRequest -Uri http://fritz.box/login_sid.lua
$loginXML = Select-Xml -Content $loginRequest.Content -XPath /SessionInfo/Challenge
$challange = $loginXML.Node.InnerText

[COLOR=#008000]#generate the login response[/COLOR]
$md5 = new-object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider
$utf16le = new-object -TypeName System.Text.UnicodeEncoding
$hash = $md5.ComputeHash($utf16le.GetBytes($challange + "-" + $password))
$hashstring = ""
$hash | foreach { $hashstring = $hashstring + $_.ToString("x2") }
$challangeResponse = "http://fritz.box/login_sid.lua?sid=0000000000000000&username=&response=$challange-$hashstring"

[COLOR=#008000]#send the login response and get the SessionID (SID)[/COLOR]
$loginRequest = Invoke-WebRequest -Uri $challangeResponse
$loginXML = Select-Xml -Content $loginRequest.Content -XPath /SessionInfo/SID
$SID = $loginXML.Node.InnerText

[COLOR=#008000]#generate the certificate upload request[/COLOR]
$boundary = Get-Date -Format "yyyyMMddHHmmss"
$boundary = "---------------------------" + $boundary
$CertFileContent = Get-Content -Path $BoxCertFile
$LF = "`r`n"
$certRequest = "--$boundary$LF" + "Content-Disposition: form-data; name=`"sid`"$LF$LF$SID$LF" +
               "--$boundary$LF" + "Content-Disposition: form-data; name=`"BoxCertPassword`"$LF$LF$BoxCertPassword$LF" +
               "--$boundary$LF" + "Content-Disposition: form-data; name=`"BoxCertImportFile`"; filename=`"BoxCert.pem`"$LF" + 
               "Content-Type: application/octet-stream$LF$LF$CertFileContent$LF" +
               "--$boundary--"
[COLOR=#008000]#send the upload request[/COLOR]
$certResponse = Invoke-WebRequest -Uri http://fritz.box/cgi-bin/firmwarecfg -Method Post -ContentType "multipart/form-data; boundary=$boundary" -Body $certRequest

Für mich aktuell neue Lösung:
Da ich meine Box wohl doch mehr anpassen werde als bisher gedacht, hat sich ergeben, dass ich nun auch python benutzen kann und damit läuft die Erstellung des Zertifikats auf der Box selbst.
Ich habe jetzt auf der Box einen zweiten Webserver, openssl und python. Zum erstellen benutze ich dann das Script aus https://github.com/diafygi/acme-tiny/ das sehr überschaubar und verständlich ist.
Bis das aber stabil und automatisiert läuft, wird es wohl noch etwas dauern, aber ein Zertifikat konnte ich schonmal erfolgreich erstellen. Das heißt, es ist ansich möglich.

Ich hoffe ich konnte damit jemandem helfen und bin natürlich gerne weiterhin bereit falls konkretere Fragen da sind. (Auch wenn ich alles andere als ein Experte in diesem Thema bin, nur ein einfacher Bastler)
 
Ich habe jetzt auf der Box einen zweiten Webserver, openssl und python.

Erstmal vielen Dank für deine Antwort, ist vermutlich eh sinnvoller, wenn du sie öffentlich postest. So hat jeder was davon.
Mich würde noch interessieren: Wird der angesprochene Webserver auf der Fritzbox erst per Custom Firmware (Freetz o.ä.) möglich oder ist das auch schon nativ irgendwie realisierbar?
 
Ohne Modifikation (das muss nicht freetz sein) bekommst Du den Webserver nicht gestartet und den Port in der Firewall nicht freigegeben.
 
Einen solchen temporären HTTP-Server für die externe Abfrage beim Erstellen eines Zertifikats kann man bereits mit einer passenden Busybox aufsetzen, da dort eigentlich nur statische Inhalte bereitzustellen sind. Dafür muß man die Firmware nicht einmal dauerhaft modifizieren, geschweige denn ein anderes Image verwenden.

Zweiter Punkt auf der Box ist halt das (temporäre) Einrichten einer passenden Weiterleitung vom richtigen externen Port, das geht ebenfalls nur mit Shell-Zugriff auf der FRITZ!Box, wenn man so etwas nicht permanent hinstellen will (was eine zusätzliche Schwachstelle wäre und das sollte man tunlichst vermeiden) - schon auf dem Windows-PC, wenn man den beim Erstellen des Zertifikates benutzt hat (s.o.), was ja auch passende Portweiterleitungen in der FRITZ!Box erfordert haben dürfte (steht ja praktisch im Text).

Allerdings geht da bei der 06.50 für die 7490 tatsächlich recht einfach ... sogar mit automatischem "Ableben" so einer Weiterleitung.

Auch für einen etwas aufwändigeren HTTP-Server auf der Box braucht man nicht unbedingt Freetz, wobei es wieder auf das Modell der Box ankommt - bei einem NOR-Modell kann man auch gleich Freetz nehmen.
 
Bitte ergänze: Das sollte kein Dauerzustand sein!
Wie gesagt, ich werde wohl diesen Lösungsweg nicht weiterverfolgen. Das ganze war der derzeitige Ist-Zustand. Und da war noch viel händisch zu tun, wie z.B. das temporäre freischalten des Port 80. Aber soweit ich das weiß, ist das automatisiert möglich. (TR-064 oder UPNP, bitte korrigieren falls das nicht stimmt)

Was mich an der Idee gereizt hat, war das dafür überhaupt keine Modifikation an der Firmware nötig wäre.

@yellowbear: Die nativen möglichkeiten der Box sind leider nicht wirklich dafür geeignet. Nicht nur der Webserver, den man vermutlich (leicht) anpassen könnte, aber auch das verfügbare "openssl" hat bei mir die Keys nicht entsprechend generieren können. (Meldung: "Segmentation Fault").

Ich entdecke grade weitere portierungen des Clients und werde mich mal umhören und natürlich berichten sobald ich was automatisiertes habe, aber das wird wohl noch dauern.
Falls jemand für den Moment nur ein Zertifikat braucht, das einmal erstellt und dann evtl. alle 3 Monate mal händisch aktualisiert wird, ist eine Linux VM die einfachste Möglichkeit.
 
Zuletzt bearbeitet:
Falls wer nen Syno NAS hat könnte ggf. auch damit nen Zertifikat erstellen lassen, es exportieren und in der FB importieren.

Dieses könnte man manuell machen, oder sollte auch mit nem Kopierbefehl gehen vom NAS auf FB via Telnet/SSH.

Würde Freetz ersparen und ganzen zusätzlichen Pakete.

ds1.JPG ds2.JPG

Beim Export die 3 Certs zusammen kopieren in eine, siehe auch Anleitung hier http://www.ip-phone-forum.de/showthread.php?t=284908
 
Zuletzt bearbeitet von einem Moderator:

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,690
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
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.