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.
( Wo hab icke denn die Parameter her ? )