Wenn das irgendwie Sinn machen soll, MUSS der Router sich ja das Zertifikat selbst besorgen (ACME-Protokoll, z.B. Let's Encrypt) oder es auch selbst ausstellen (self-signed, so macht es AVM ja im Moment, wenn es keinen MyFRITZ!-Account gibt) oder es tatsächlich "ab Werk" schon haben, dann aber auch wieder ein "individuelles" (mit einem eigenen, anderen unbekannten, privaten Key), wie das z.B. in der DOCSIS-Spezifikation geregelt ist (wo ein CM (Cable Modem) ja auch dem CMTS (Cable Modem Terminal System) des Providers das eigene Zertifikat präsentiert). Eine vierte Option ist das Verwenden eines Zertifikats (und eines Keys), den der Benutzer bereitgestellt hat - dann nimmt der Router halt auch dieses und die Verantwortung für alles weitere lastet auf dem Benutzer (gibt es im FRITZ!OS ja auch als Option). Nur bei Variante 3 gäbe es aber eine zeitliche Limitierung für das Zertifikat, bei allen anderen kann eine Aktualisierung erfolgen (1+2) oder der Benutzer ist verantwortlich (4).
Und bei einem Zertifikat (bzw. einem "Schlüsselpaar" - was immer noch blöd ist im Deutschen, denn das, was einen öffentlichen Schlüssel ausmacht, ist eine Teilmenge der Informationen in einem privaten) spricht auch nichts Absolutes gegen eine längere Gültigkeit (auch wenn's nicht unbedingt "best practice" ist und öffentliche PKI das per Policy i.d.R. ausschließen), solange die Schlüssellänge und Hash-Algorithmen immer noch den aktuellen Anforderungen entsprechen.
Die begrenzte Gültigkeit in öffentlicher PKI ist ja üblicherweise auch dafür gedacht, mit dem technischen Fortschritt mitzuhalten und nicht heute (praktisch wissentlich) schon Zertifikate für 2030 auszustellen, wo der Konsens, was als weiterhin sicher gilt, wohl auch ein anderer sein wird. Kryptologen befassen sich ja heute schon mit "post-quantum cryptography".
Aber eigentlich wird ja bei TLS nicht das (zertifizierte) Schlüsselpaar für die (Massen-)Verschlüsselung der übertragenen Daten verwendet (was dann tatsächlich zum Problem werden könnte, wenn es zuviele "Samples" gibt, die mit demselbem Key verschlüsselt wurden), sondern im Rahmen eines Schlüsselaustauschs werden zufällige Keys erzeugt und nur deren Austausch wird mit dem zertifizierten Schlüsselpaar gesichert.
Diese zufälligen Keys werden dann (wenn sie tatsächlich "langlebiger" sind, wie bei VPN-Verbindungen) auch nach einer gewissen Zeit oder nach einer damit verschlüsselten Datenmenge gewechselt - wobei ich gerade nicht beschwören will, wie das bei älteren TLS-Verbindungen läuft, die HTTP tunneln. Bei TLS 1.3 gibt es zumindest solche Updates in der Spezifikation:
https://tools.ietf.org/html/rfc8446#section-4.6.3 - iirc aber auch erst seit dieser Version.
Wenn der technische Fortschritt so ein Gerät irgendwann überrollt, ist das halt Schicksal ... wenn irgendwann alle Browser nur noch HTTP2 sprechen und HTTP 1.0 bzw. 1.1 nicht mehr unterstützen wollen, ist man bei HTTP (also auch ohne TLS) genauso erschossen.
Trotzdem ist "einfach TLS auch im LAN nutzen" schon ein spannendes und durchaus schwierig (für alle Gelegenheiten) umzusetzendes Themenfeld - auch/weil wenn es dort durchaus ein paar Tretminen gibt. Vielleicht schaffe ich es ja irgendwann auch mal, die Verwendung von TLS durch AVM etwas ausführlicher zu beschreiben ... denn da gibt es durchaus ein paar interessante Punkte, die es zu lösen galt und wo man auch darüber diskutieren kann, ob die von AVM gewählten Lösungen immer die besten sind (oder auch nur die praktikabelsten) und was das für Vor- und Nachteile hat.
Das geht schon damit los, wie man als Benutzer der TR-064-Schnittstelle auf Port 49443 eigentlich sicher sein kann, daß man auch tatsächlich mit der richtigen FRITZ!Box kommuniziert, wenn man sich - mit "basic auth", was bei Zugriff auf den Klartext der Kommunikation ja direkt Benutzernamen und Kennwort offenlegt - ihr gegenüber authentifizieren soll und was es da für Optionen gäbe. Spätestens dann, wenn ein TLS-Zugriff sowohl von der LAN- als auch von der WAN-Seite einer FRITZ!Box mit denselben (Client-)Einstellungen funktionieren soll, wird das sehr spannend (bis hin zum NAT-Hairpinning). Aber das ist tatsächlich ein weites Feld und eher ein Thema für einen anderen Thread ... zumal es AVM eigentlich auf allen Modellen gleich behandelt, auch wenn sich das mit der Firmware-Version ab und an mal ändert.
