Speicherort für die selbst erstellten Zertifikate
Die Daten stehen in den Dateien
/var/flash/websrv_ssl_cert.pem und
/var/flash/websrv_ssl_key.pem. Das Zertifikat wird dabei unverschlüsselt gespeichert, der dazugehörige private Schlüssel hingegen wird beim Speichern mit einem nur für diese eine Box gültigen Kennwort (letztlich nur ein MD5-Hash über die
maca-Angabe) verschlüsselt (siehe
https://github.com/PeterPawn/decoder/blob/master/scripts/privatekeypassword und der zugehörige Thread hier im Board).
Afaik hat sich da auch nichts geändert - sofern man ein eigenes Zertifikat hochlädt, wird (a) der Key passend (neu) verschlüsselt und (b) das automatische Generieren eigener Zertifikate (was ansonsten bei allen Änderungen, die Auswirkungen auf die DynDNS-Konfiguration hätten (inkl. MyFRITZ!), ebenfalls neu generiert würde) wird eingestellt.
Praktisch alles, was ich im Laufe der Jahre dazu geschrieben habe in diesem Board, sollte sich durch die Suche nach den o.g. Dateinamen finden lassen. Ersetzt man die verwendeten Dateien "von Hand", muß man - neben dem Verschlüsseln des Keys - auch noch dafür sorgen, daß die AVM-Dienste, welche die bisherigen Dateien verwenden, neu gestartet werden.
Verwendet man die AVM-Funktionen zum Upload (über
cgi-bin/firmwarecfg als
POST-Request mit Angabe von
sid,
BoxCertImportFile und - falls Verschlüsselung für den hochzuladenden Key verwendet wurde -
BoxCertPassword), muß man sich darum keine eigenen Gedanken machen.
Je nach Modell benötigt man beim Zugriff auf die Dateien in
/var/flash spezielle Vorkehrungen, die hier auch häufig genug thematisiert wurden (einfach selbst danach suchen).
EDIT: Das von AVM generierte LE-Zertifikat steht in anderen Dateien (
/var/flash/letsencrypt_*) und ist NICHT mit dem erwähnten Hash über die
maca-Angabe verschlüsselt, sondern anders (was ich bisher noch nicht beschrieben bzw. (nach-)implementiert habe). Der eigentliche Witz bei der AVM-Implementierung ist es, daß das dort verwendete
letsencrypt-Binary durchaus in der Lage wäre, auch andere Domain-Namen als den MyFRITZ!-Namen der jeweiligen Box zu verwenden:
Rich (BBCode):
# letsencrypt -?
usage: letsencrypt [options]
options:
-? - print this help
-v - verbose. (NOTSET)
-p - use production api (server) of letsencrypt.org. (NOTSET)
-a STRING - file with letsencrypt.org account info (may not exist). ("/var/tmp/letsencrypt.account")
-d STRING - domain dame (subject) for certificate. (NULL)
-r - renew cert instead of initial generate. (NOTSET)
-c STRING - certificate PEM file. (NULL)
-k STRING - private key PEM file. (NULL)
-D STRING - switch debug logs on. (FUNC)
letsencrypt
#
Allerdings hat AVM da wieder den gezielten, eigenen Aufruf dieses Binarys dadurch verhindert, daß darin getestet wird, ob der "Vaterprozess" der
ctlmgr ist und sofern das nicht der Fall ist (was man ggf. auch wieder "türken" könnte, aber der Aufwand erscheint recht hoch), macht das Binary nur Unsinn (u.a. werden falsche Kennwörter für die Verschlüsselung erzeugt).
Wenn ich die Wahl hätte, würde ich immer auf das
letsencrypt-Binary von AVM verzichten (u.a. auch deshalb, weil man dafür ja ein MyFRITZ!-Konto verwenden muß) und stattdessen mein selbstgeneriertes Zertifikat (das muß ja auch nicht von LE oder einem anderen ACME-basierten Service sein) verwenden. Ob über den Upload per
firmwarecfg oder über den direkten Austausch der o.g. Dateien, ist dann nur noch Geschmackssache.
gist.github.com
