[Info] FRITZ!Box 7490 Labor-Firmware 153.06.83-46493 Labor vom 12.09.2017

F

Feuer-Fritz

Guest
Es gibt eine neue Labor speziell zu diesen Themen:

Experimentelles zu Netzwerk für FRITZ!Box 7490
Dieses FRITZ! Labor enthält zum Ausprobieren zwei experimentelle Funktionen im Alfa/Beta-Status, die sich mit den beiden Themen Browserzertifikaten (SSL-Zertifikaten des Anbieters Let's Encrypt) und potentieller Erkennungen von Schadsoftware im Heimnetz beschäftigen. Achtung: Diese Version beruht auf dem Releasestand 6.83 und beinhaltet KEINE neuen Funktionen des WLAN Mesh-Labors (Version 6.90/6.88). Dieses FRITZ!Labor mit der Version 6.83 wird in dieser Ausprägung nicht weiter fortgeführt werden. Wir empfehlen die Version nur dann einzuspielen, wenn an den beiden Themen besonderes Interesse besteht

Letzte Aktualisierung: 12.09.2017



Besonderheiten:
 
Mh, die zweite Neuerung (Erkennung der Kontaktaufnahmen von Schadsoftware) hat Potential. Virenscanner binden so was bereits in Browser ein, aber wenn das zügig vonstatten geht und die Box das nebenher schafft ...
 
Aber was soll sowas in der alten Firmware (wenn in der neuen so viel geändert ist... ) ?
 
Feldversuch wie die Resonanz ist oder wie laut gemeckert wird weil ein Loch im Virenscanner ist...:confused:
 
Als Ersatz für einen Virenscanner würde ich das nicht sehen - aber als durchaus sinnvolle Ergänzung.
 
Ich finde die Funktion, so wie hier beschrieben: https://avm.de/fritz-labor/fritzbox-7490/uebersicht/
FRITZ!Box versucht zu erkennen, ob Heimnetzgeräte mit einem derzeit für die Kontrolle von Schadsoftware bekannten Server im Internet Kontakt herstellen wollen. Solche Versuche werden in einem Ereignis protokolliert (System / Ereignisse) und auf der Übersichtsseite ein entsprechender Hinweis ausgegeben. Die Info-LED am Gerät leuchtet rot. Bei aktivem Push Service wird außerdem eine Information per Mail versendet.
sogar sinnvoller als irgend ein Antivren Snakeoil Programm.

Und MyFRITZ! mit SSL-Zertifikaten von Let's Encrypt finde ich einfach nur großartig!
Leider kann ich nicht mit rumspielen, da ich nicht zuhause bin :-(
 
Ich habe mir eine Hand hinter den Rücken gebunden ... ich will mich nicht noch weiter verzetteln, auch wenn das LE-Zertifikat ja schon lange auf der "Wunschliste" steht und auch AVM die Reservierung für die Namen schon lange vorgenommen hatte.

Wobei mich schon interessieren würde, ob AVM da einen eigenen ACME-Client in C oder Lua geschrieben hat oder einen in Shell-Code (inzwischen gibt es mehrere) angepaßt hat an die FRITZ!Box oder ob man die C-Implementierung genommen hat, die es seit Mai 2016 gibt (wobei die m.W. LibreSSL als SSL-Stack will in der portablen Version).

Ich glaube jedenfalls nicht daran, daß man sich einen der Clients in einer "Hochsprache" gegriffen hat (das Original war in Python, wenn ich mich richtig erinnere) und dem die passende Runtime-Umgebung spendiert hat ... wobei das sicherlich auch mal etwas wäre, wenn es Python, Perl oder Ruby auf der Box gäbe. Auch der Client in JS sollte (beim bisher bekannten Funktionsumfang auf dem "Server" in der Box) kaum möglich sein ... oder AVM hat einen JS-Interpreter/-Compiler auf die Box gebracht. Ist schon nicht unspannend, aber ich habe mir erst einmal das Image gesichert und verkneife es mir sogar, das überhaupt auspacken zu lassen.

Aber auch sonst gibt es beim LE-Zertifikat noch viele spannende Fragen zu beantworten ... u.a. die, wo AVM am Ende die Informationen zum "Konto" (/acme/new-account) wohl speichert, denn es gibt zwar schon länger die zwei erwähnten Nodes im TFFS (für den privaten Schlüssel und das Zertifikat), aber es gab zumindest bisher keine zusätzliche Konfigurationsdatei und wenn die nicht auch noch neu "erfunden" wurde, dann muß das ja in irgendeiner anderen stehen, denn für das (hoffentlich automatische) Erneuern braucht es ja dann nicht nur CSR und Schlüssel, sondern auch den richtigen Account (wenn ich mich richtig erinnere).

================================================

Das mit der Erkennung von Schadsoftware ist auch nicht ganz so einfach ... wenn das nicht nur plakativ, sondern auch ausreichend wirksam sein soll. Was kann man denn vom Prinzip her nur machen?

Man kann z.B. irgendwo eine Liste bekannter C&C-Server-Adressen verwalten (wer macht das, wie aktuell ist die, wer trägt die Verantwortung für Aktualisierungen) und bei Kontaktaufnahme dahin halt seine Annahmen treffen und Warnungen erzeugen.

Das wird bei Schadsoftware, die einfach IRC in öffentlichen Channels (also gänzlich unverschleiert, aber in der Hoffnung, "im Rauschen" unterzugehen) oder gleich "hidden services" (also "vollverschleiert") für die Kommunikation nutzt, wieder nicht wirklich funktionieren ... und die Schadsoftware lernt ja auch dazu und direkte Verbindungen zu einem C&C-Server sind bei weitem nicht mehr so häufig wie früher - die Malware-Programmierer wollen ja auch nicht, daß jeder AV-Hersteller problemlos mit einem einzigen eingesammelten Sample sofort die Adressen ihrer C&C-Server identifizieren und in der Folge Verbindungen dorthin blockieren kann. Da wird verschleiert (auch über P2P), was das Zeug hält und wenn C&C-Verbindungen über Onion-Routing gehen, steht der Router eigentlich auch dumm da ... es sei denn, alle TOR-(Entry-)Nodes stehen auch gleich noch auf der Liste der "bösen Adressen" und das will ich mal nicht hoffen.

So richtig hilft das halt nur dann (angesichts dessen, was der Router da noch mitbekommen kann in einer Ende-zu-Ende-Verschlüsselung und die verwendet da fast jeder inzwischen), wenn eine Adresse im Netz tatsächlich als (reiner) C&C-Server bekannt ist ... und damit kommt man automatisch wieder zu der Frage zurück, wer diese Liste dann verwaltet und damit ggf. auch die Macht hat, darüber zu entscheiden, was die Box klaglos akzeptiert bei einer ausgehenden Verbindung oder wo sie Alarm schlägt.

Solange sie dann (aktuell soll das ja so sein) die Verbindung auch noch aufbaut, ist das vielleicht auch noch in Ordnung (wobei die meisten Kunden sicherlich auch erst einmal verunsichert sind), aber wenn das dann irgendwann auf automatisches Blockieren hinausläuft, dann hat man - als derjenige, der die Liste "wartet" - auch gleich wieder so etwas wie ein Zensur-Werkzeug an der Hand (wobei Zensur ja eigentlich den Zensor und die Genehmigungspflicht beinhaltet, hier ginge es dann mehr um das Unterdrücken unerwünschter Präsenzen).

Ich sehe also durchaus auch einen denkbaren Nutzen ... aber ich bin mir gar nicht so sicher, ob ich einen solchen Service (solange der nicht wahnsinnig transparent arbeitet) wirklich auf meinem Router haben wollte. Wenn der am Ende die Schadsoftware, die ihre Verbindungen zum C&C-Server besser tarnt, gar nicht erkennen kann und ich mir aber parallel eine unbekannte Quelle für irgendwelche "blacklists" einhandele (irgendwo dort dürfte die Lösung ja dann andocken, auch wenn zur Zeit nicht blockiert werden soll nach der Beschreibung bei AVM), dann sollte man das ggf. noch einmal hinterfragen ... auch die eigene Begeisterung.

Klar, wenn das als Blockieren von Schadsoftware deklariert wird, will das schon mal jeder haben ... wer wäre nicht gerne sicherer? Aber dann muß AVM m.E. auch die genauen Abläufe sehr klar offenlegen ... daß es wahrscheinlich früher oder später auch bei AVM mal in die Richtung gehen könnte, hatte ich schon im Gefühl (und habe das auch hier irgendwo mal geschrieben), als Symantec mit seiner "Norton Core Router"-Idee auflief.

Ich muß ganz ehrlich sagen, daß ich anstelle dieser "Warnung" über mögliche Aktivitäten von Schadsoftware viel lieber eine Möglichkeit hätte, einem Netzwerk-Client schon in der Netzwerk-Übersicht auf Knopfdruck das Recht für den Internet-Zugriff zu entziehen (ihn also direkt in das Profil "Gesperrt" zu verschieben - gibt es zwar inzwischen bei den Details, versteht aber der "normale Kunde" ohne ausreichende Erklärung gar nicht, wie ich selbst feststellen durfte bei mehreren "Einweisungen") und optimal wäre es, wenn man für so einen Client (damit der seine Updates noch kriegt oder ähnliches) einen "Lernmodus" einschalten könnte, in dem die Box die Ziele ausgehender Verbindungen protokolliert und sie einem nach dem Ende dieses Lernvorgangs noch einmal als Liste anbietet.

Da löscht man dann all die Ziele, die für Updates unwichtig sind, aus dieser Liste und im Anschluß darf so ein Gerät dann nur noch externe Verbindungen zu den verbliebenen Adressen (meinetwegen auch Namen, wobei das wieder DNS-Spoofing/-Hijacking möglich macht - andererseits gibt es auch für Updates CDNs und da ist dann eine einzelne Adresse auch Quatsch, wie mancher bei eigenen Sperrversuchen über die Blacklist schon merken durfte) aufbauen ... so eine Art "Whitelist", aber für einzelne Clients getrennt.

Kombiniert man das dann noch mit einer "Datenbank", in der die wichtigsten Hersteller mit ihren Geräten und Update-URLs vertreten sind und man kann dem Benutzer damit auch noch beim Löschen aus der Liste so weit assistieren, daß man ihm "Hinweise" für die bekanntermaßen unschädlichen Update-URLs anbietet (entweder man versucht den LAN-Client gleich selbst durch "fingerprinting" zu identifizieren oder man bietet eine Liste über Hersteller->Typ->Produkt-Zuordnungen an) oder - auf Wunsch - gleich die Liste passend zurechtstutzt, dann kann das auch der durchschnittliche Kunde wieder benutzen. Das wird sicherlich nicht für jedes exotische Gerät klappen, aber die wichtigsten NAS-Hersteller und -Modelle oder IP-Kameras (oder was auch immer) kriegt man relativ schnell zusammen und es ist ja auch keine Schande, wenn man mal sagen muß: "Kenne ich nicht, mußt Du selbst erkunden oder im Netz nach anderen Erfahrungen damit suchen." - das soll ja nur eine "Hilfe" sein und kein komplett automatischer Assistent, der einem das Denken auch noch abnimmt.

Damit beugt man (zumindest bei den wirklich "unsicheren Kandidaten") nicht nur der Kontaktaufnahme mit bekannten C&C-Servern vor, man kann als Benutzer auch steuern (ich weiß, daß das schon heute geht, aber kaum ohne wenigstens den Bachelor in Netzwerktechnik gemacht zu haben (in irgendeinem MINT-Studiengang) und dabei ist das FRITZ!OS schon deutlich mehr "user friendly" als andere Geräte), wie weit diese Geräte dann "nach Hause telefonieren", was gerade bei IoT-Gadgets auch in der Zukunft immer mehr zum Thema werden wird. Ein Dash-Button muß eben irgendwie Kontakt mit den AWS-Servern aufnehmen können, aber kaum mit irgendeinem obskuren Server irgendwo in Panama oder auf den Seychellen.

Meinetwegen kann man das dann tatsächlich noch mit einer Liste von "verdächtigen Adressen" kombinieren ... aber das wäre dann eben mehr die zweite Verteidigungslinie an dieser Stelle bzw. für die Geräte geeignet (PCs, Tablets, Smartphones), bei denen man die sinnvollen Zieladressen nicht wirklich wirksam einschränken kann.
 
Zuletzt bearbeitet:
Wer eine Infrastruktur zur Selektion von Internetinhalten einrichtet (und die Gefahr, daß aus einer Warnung am Ende eine automatische Blockade wird, weil das so schön bequem ist und der Kunde doch ansonsten nur unnötig verwirrt sein könnte, kann man sich bei so mancher AV-Lösung für Windows schon heute ansehen - da kriegt man dann auch harmlose Programme wie "netcat" (für Windows) nur mit Kopfständen wieder aus irgendeiner Quarantäne), der schafft damit auch eine Möglichkeit des Mißbrauchs dieser Infrastruktur für Zwecke, für die sie gar nicht gedacht war - man kann vielleicht bei der Wahrscheinlichkeit für einen solchen Mißbrauch noch geteilter Meinung sein.

Die Beispiele aus dem "normalen Leben" sind schon zahlreich ... von den immer wieder auftauchenden Begehrlichkeiten bei den Daten der Maut-Brücken auf den Autobahnen bis zu Bestands- und Verkehrsdaten von TK-Kunden. Die "Aufstände" in der Zivilgesellschaft, wenn es um die Einrichtung von DNS-Sperren u.ä. ging, hatten ja auch ihre Gründe ... und das waren eben nicht die, daß die Gegner solcher Sperren die dort liegenden Angebote nun so gut fanden, sondern daß sie das dort vorhandene Mißbrauchspotenzial (auch für künftige Regierungen u.ä.) sahen.

Wie schwer wäre es wohl für einen "Angreifer", mit irgendeiner absolut dämlichen Malware, die man nur weit und schnell genug verbreiten muß (die muß ja nicht mal wirklich etwas bewirken oder Systeme auch erfolgreich infizieren, sondern sich nur gut genug "untersuchen" lassen), einfach auf einem für mehrere Internetauftritte genutzten Host einen weiteren als "vorgeblichen" C&C-Server zu diskreditieren?

Oder gar mit irgendeiner dort gemieteten (oder gekaperten) Wordpress-Instanz auf einem vServer (die genauso mit Blödsinn antwortet, wie die Malware sinnlose Requests dorthin erzeugt ... solange das nur irgendwie den Eindruck von - richtig guter - Verschlüsselung erweckt) genau den Verkehr erzeugt, der diesen Server als C&C-Instanz "verdächtig" macht und ihn damit auf so einer Sperrliste landen läßt?

Wenn dann auf so einem Server irgendwelche "unerwünschten Inhalte" mit einer solchen Aktion (vom Listenverwalter, Politik oder auch Kriminellen als "Erpressung", weil das bei Automatismen halt auch zum "Wegsperren" der Kunden führen kann) unterdrückt werden können, dann konnte das am Ende natürlich niemand ahnen, daß so etwas auch machbar wäre.

Wenn ich als Kunde am Ende nicht mehr selbst entscheiden kann, was ich wo im Internet suchen und finden kann (warum warnen eigentlich so viele Leute vor dem gewaltigen Einfluß von Google auf die "Weltsicht" der Leute, brauchen die auch alle Alu-Hüte oder ist an "Filterblasen" vielleicht doch etwas dran?) oder auch nur, wenn das der "Masse der Leute" auf diesem Weg vorenthalten bzw. so weit erschwert wird, daß sie entsprechende Inhalte gar nicht mehr konsumieren können/wollen, dann stellt sich irgendwann tatsächlich wieder die Frage, wie "realistisch" das Abbild der Welt im Netz noch ist ... da ist mir jede Infrastruktur mit entsprechendem Mißbrauchspotential direkt suspekt, weil man am Ende auch nie sicher weiß, in wessen Hände die mal gelangen könnte (siehe Türkei, Ungarn, Polen, Großbritannien), wenn es politische Veränderungen gibt.

Das gilt aber genauso auch für die Privatwirtschaft ... genau deshalb habe ich zuerst auch die Frage aufgeworfen, wer da am Ende die Einschätzung "gute Seite" oder "böse Seite" treffen wird. Solange das nicht in einer einzelnen Hand liegt, sinkt mit jeder unabhängig agierenden Stimme auch das Mißbrauchspotential wieder. Wenn das von einem einzelnen AV-Hersteller kommt (wie es bei den AV-Suites heute gang und gäbe ist, der "Norton Core Router" wird sicherlich auch nicht die Software von Avast verwenden), dann bin ich nun mal doppelt skeptisch.

Es ist ja nun auch nicht so, daß jeder AV-Forscher als Erstes mal die Adressen der C&C-Server veröffentlicht, die von der von ihm gerade untersuchten Malware kontaktiert/verwendet werden ... das würde die Betreiber dort ja ebenfalls warnen und solche Aktionen, daß da C&C-Server "von den Guten" übernommen werden, um das komplette Botnet aus dem Verkehr zu ziehen, gleich mal verhindern. Solche Adressen dürften damit auch schon mal - sicherlich nachvollziehbar - nicht zu den "gesperrten" gehören - da sind wir dann bei der Aktualität der Listen.

Was nutzt es bei einem Ausbruch wie "Wannacry", wenn die Adresse der Server dort (und die Ransomware kontaktiert den ja zumindest mit der Info, daß/welchen Rechner sie gerade verschlüsselt hat) nach 4 Wochen in der Sperrliste landen und wie lange bleiben sie da dann eigentlich stehen? Hat dann der nächste Mieter eines Servers bei irgendeinem Hoster halt auch mal Pech, weil er eine IP zugeteilt bekommt, auf der vor einem oder zwei Jahren mal ein solcher C&C-Server lief und nun alle möglichen alten und nie aktualisierten Listen diese Adresse enthalten? [EDIT]Das geht heute schon manchem Kunden beim Mieten eines Servers so, wenn er dabei eine IP "erbt", die zuvor von irgendeinem Spammer genutzt wurde und nun in diversen "blacklists" steht - da kannst Du dann erst einmal für das "Austragen" aus solchen Listen einen Heidenaufwand treiben.[/EDIT]

Diese ganzen Punkte meine ich, wenn ich von "Transparenz" bei so einer Lösung spreche. Nur wenn man weiß, wie das genau abläuft, kann man die Vor- und Nachteile (hier auch die potentiellen) gegeneinander abwägen und eine vernünftige Entscheidung treffen, ob man so ein Angebot annehmen will oder nicht. Daß bei solcher Transparenz dann auch "die Bösen" erfahren, wie sie sich noch besser tarnen können, liegt nun mal in der Natur der Sache. Eine wirklich gute Lösung braucht aber keine "Geheimhaltung", sondern sie widersteht der Kritik dadurch, daß sie selbst keine (eklatanten) Schwächen aufweist. Das ist in etwa dasselbe, wie bei "PC-Wahl" ... wie man erst kürzlich nachlesen konnte.
 
Zuletzt bearbeitet:
Vielleicht meint avm garnicht dem Virus Scanner, vielleicht so eine Art frimware Schutz gegen fremd frimware wie zb freetz
 
Hat denn das Zeug jetzt mal jemand installiert?
Gibt es Screenshots?
 
FRITZ!Box versucht zu erkennen, ob Heimnetzgeräte mit einem derzeit für die Kontrolle von Schadsoftware bekannten Server im Internet Kontakt herstellen wollen. Solche Versuche werden in einem Ereignis protokolliert (System / Ereignisse) und auf der Übersichtsseite ein entsprechender Hinweis ausgegeben. Die Info-LED am Gerät leuchtet rot. Bei aktivem Push Service wird außerdem eine Information per Mail versendet.

Das bedeutet einfach: wenn mein Edge-Browser (oder IE) seinen SmartScreen-Filter nutzt, um einen Abgleich der aktuell aufgerufenen Webseite mit der MS-Datennbank (="einem derzeit für die Kontrolle von Schadsoftware bekannten Server im Internet") zu machen, dann leuchtet die Info-LED rot und in der Netzwerkübersicht bekommt mein PC ein entsprechendes Flag und dann erhalte ich auch noch eine Email.

Kann mir jemand nochmal die Sinnhaftigkeit einer solchen Implementierung erklären?
Denn mit mehr Sicherheit hat es nichts zu tun!
 
:)

Diese Interpretation ist auch nicht schlecht ... ist das jetzt schon "getestete Erkenntnis" oder nur Interpretation der Formulierung?

So richtig funktionieren würde so etwas aber tatsächlich auch wieder nicht (zumindest nicht mit der notwendigen Selektivität), weil der Router nur die Kontaktaufnahme, aber nicht den Inhalt und das Ergebnis der Abfrage sieht, denn das sollte auch vom MS Edge mit TLS übermittelt werden. Vielleicht sollte AVM ja "nachbessern" und - wenn Deine Beschreibung stimmt - aus dem "von" ein "auf" machen, dann ist das deutlicher. Andere Änderungen ("Steuerung" statt "Kontrolle") sind auch wieder nicht eindeutig genug ... greift man wieder zur allseits beliebten Analogie mit Autos (oder Schiffen, da gibt es wenigstens auch einen KontrollSteuermann), heißt es ja auch noch lange nicht, daß jemand mit der Hand am Steuer auch tatsächlich die Kontrolle hat. :D
 
Wenn mit "Kontrolle von Schadsoftware" Server gemeint sind, die mit der Schadsoftware kommunizieren (Kontrollserver, Downloadserver), so ist eine Liste solcher dann bereits zu alt, wenn du den nächsten Eintrag hinzufügst. :)
 
Das bedeutet einfach: wenn mein Edge-Browser (oder IE) seinen SmartScreen-Filter nutzt, um einen Abgleich der aktuell aufgerufenen Webseite mit der MS-Datennbank (="einem derzeit für die Kontrolle von Schadsoftware bekannten Server im Internet")
Wenn du so deine gesamte Surf-History bei Microsoft "ablagerst", ist dir ohnehin nicht mehr so richtig zu helfen. ;-)

Ansonsten funktioniert das gut mit dem Zertifikat von Let's Encrypt, falls man den myfritz-DynDNS-Service von AVM nutzen will. Jetzt wäre der nächste logische Schritt, das auch für eigene Zertifikate von Let's Encrypt zu öffnen. Aber da ist sicher der Bedarf nicht groß genug, da die allermeisten Fritzbox-User ja kostenfreie DDNS-Dienste benutzen und nicht eigene DynDNS-SubDomains.

Zumindest hat AVM hier einen Schritt in die richtige Richtung getan und natürlich auch was für die Kundenbindung.
 
Heißt das jetzt, AVM läßt das LE-Zertifikat nur für die myfritz.net-Adresse ausstellen oder hattest Du nur keinen weiteren DynDNS-Eintrag konfiguriert? Ich habe das "eigene LE-Zertifikat" als "außerhalb der Box erzeugt" verstanden.

EDIT:
Wobei es ohnehin sinnvoller wäre (keine Ahnung, ob das hier schon geändert wurde), wenn die Box da für die Auswahl eines Zertifikats den SNI-Header auswerten würde und man mehrere Zertifikate hinterlegen könnte (geht ja notfalls auch in einer Datei, muß dann halt beim Laden zerlegt werden).

Dann kann man neben dem LE-Zertifikat oder einem eigenen für externen Zugriff auch aus dem LAN beim HTTPS-Zugriff (anhand von "fritz.box", was von extern garantiert nicht kommen sollte) weiterhin ein selbstgeneriertes verwenden und könnte dann auch problemlos von innen per HTTPS zugreifen (und zwar ohne Redirections).

Hier wäre ggf. sogar so etwas wie eine lokale CA denkbar (wirklich nur einmal generiert, z.B. beim Finalisieren bei der Herstellung), damit eher der vertraut werden kann anstatt ein einzelnes Zertifikat zu pinnen, was sich bei einer FRITZ!Box ja unter diversen Bedingungen ändert, wenn es das selbstsignierte ist.

Bei internem, direktem HTTPS-Aufruf (mit nur einem LE-Zertifikat, das man ja nie für "fritz.box" erhalten wird) nutzen reine Redirections ja auch nichts so richtig, weil der HTTP-Fehlercode für die Umleitung erst in der TLS-Verbindung übermittelt werden kann (außer man ruft "http://fritz.box" auf, da kann natürlich dann auf eine HTTPS-URL verwiesen werden) und bereits diese würde ja von einem Browser als "unsicher" angesehen, wenn das Zertifikat nicht zur URL paßt.
 
Zuletzt bearbeitet:
Doch, ich hatte einen weiteren DynDNS-Eintrag konfiguriert und AVM ließ sich in meinem bei LE offensichtlich nur für die myfritz.net-Domain ein Zertifikat ausstellen. Das hatte ich wegen der Platzierung auf der MyFRITZ!-Konto-Seite auch nicht anders erwartet.

"außerhalb der Box erzeugte" Zertifikate lassen sich schon länger installieren, mir gefiel nur der brutal einfache Weg und würde das gern für individuelle LE-Zertifikate nutzen wollen.
 
Danke für die Konkretisierung ... weil AVM da tatsächlich zwei verschiedene Speicherorte für die Zertifikate verwendet (das selbst-signierte bzw. vom Benutzer hochgeladene Zertifikat landet in "websrv_ssl_{key,cert}.pem" und für die LE-Zertifikate gibt es neue TFFS-Nodes (203 + 204) mit den Namen "letsencrypt_{key,cert}.pem"), hatte ich das mit dem "eigenen LE-Zertifikat" dann trotzdem so verstanden, daß Du ein eigenes LE-Zertifikat anstelle des von der Box generierten auch an diesen zweiten Speicherort hochladen wolltest (vom Sinn der Sache jetzt mal abgesehen, weil die Box ohne Kenntnis des passenden Accounts das ja gar nicht selbst wieder erneuern könnte).

Wie sieht es denn dann jetzt beim Zugriff aus? Wenn man (von extern) auf die Box unter dem myfritz.net-Namen zugreift, wird sicherlich das LE-Zertifikat verwendet - das wäre zumindest logisch. Greift man jetzt mit einem anderen Namen zu (und die Box wertet den SNI-Header tatsächlich aus), könnte da ja tatsächlich auch das andere Zertifikat präsentiert werden. Gibt es da einen Unterschied?

Sorry, wenn ich so blöd frage, anstatt das einfach selbst zu testen ... ich bin zwar neugierig, will aber nicht noch eine weitere Baustelle bei mir aufmachen.
 
Eine gute Nachricht: Als ich nochmal beim Urzustand anfing, d.h. beim selbstausgestellten FRITZ!Box-Zertifikat, dann ein MyFritz/LE-Zertifikat erstellen ließ und dann mein benutzereigenes Zertifikat für meine zusätzliche DynDNS-SubDomain installiert habe, funktionieren seitdem tatsächlich beide HTTPS-Adressen!

Beim Deaktivieren von "MyFRITZ! für diese FRITZ!Box aktiv" erscheint dann übrigens - jeden Zweifel zerstreuend - "Das Zertifikat wird nicht benutzt, da Let’s Encrypt oder MyFRITZ! nicht aktiv.". Freundlicherweise lässt sich das MyFRITZ!-Konto auch gleich wieder reaktivieren.
 
Wenn LE Unterstützung käme, das wäre geil ....
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
245,826
Beiträge
2,240,723
Mitglieder
373,092
Neuestes Mitglied
mueschol
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.