Openssl Problem

Goblin2605

Neuer User
Mitglied seit
30 Jun 2016
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Habe folgendes probelm
wenn ich versuche openssl req -new -key ssl.key -out ssl.csr einzugeben bekomme ich folgende meldung
WARNING: can't open config file: /mod/etc/ssl/openssl.cnf
Unable to load config info from /mod/etc/ssl/openssl.cnf

Weiß jemand wie ich diesen fehler beheben kann bzw. diese config file erstellen kann.
 
Mal eine ganz andere Frage (weil der korrekte Aufbau der Datei zu kompliziert ist für das Forum) ... warum willst Du überhaupt einen neuen CSR (von Hand) generieren?

Willst Du tatsächlich ein Zertifikat von einer CA signieren lassen? Wenn ja, kannst Du den Key auch auf jedem anderen System erstellen lassen (inkl. CSR, wofür man ja nun einige zusätzliche Angaben braucht (was wird da eigentlich zertifiziert) und genau die stehen dann in der cnf-Datei, deshalb ist das auch kein Zweizeiler bei der Antwort) und am Ende alles in die Box importieren.

Aber das FRITZ!OS erstellt selbst einen RSA-Key mit 2048 Bit, wenn es noch keinen hat und man könnte auch gleich den verwenden und einen passenden CSR erzeugen ... auch hier braucht man natürlich wieder die cnf-Dateien mit den Angaben zum Zertifikat.

Wenn man das noch nicht gemacht hat, ist es tatsächlich einfacher, es erst einmal mit einer GUI-basierten Lösung zu probieren - da ist die Eingabe der notwendigen Daten leichter.

Wenn ich die Frage falsch verstanden habe und es weniger um den Inhalt der Datei als vielmehr um deren Speicherort ging, das kann man auch mit der Option "-config" beim Aufruf festlegen, wo die Datei gesucht werden soll.

Wenn Du am Ende ohnehin bei einem "self-signed"-Zertifikat landen solltest/willst, dann kannst Du auch gleich das aus der Box nehmen, das wird wenigstens sofort auf die DynDNS-Namen der Box ausgestellt (also den ersten DynDNS-Account und ggf. den MyFRITZ!-Namen) und auch (solange es ein selbsterstelltes ist und kein vom Benutzer importiertes) bei der Änderung eines relevanten Wertes (das geht von der IP-Adresse bis zum FRITZ!Box-Namen und jedem DynDNS-Konto) neu erstellt.

Zusammengefaßt ... wenn Du nicht weißt, was in die cnf-Datei gehört, dann solltest Du lieber auf einem anderen Weg das Zertifikat (oder auch nur den CSR dafür) zu generieren. Ich weiß im Moment einfach nicht so richtig, wofür Du den CSR brauchen solltest, wenn ich an die Beschreibung des Einsatzfalles aus dem anderen Thread denke.

Wenn Du wirklich ein "offizielles" Zertifikat für die Box haben willst, würde ich es eher extern generieren und später in die Box importieren.

Wenn Du nur für irgendeinen Dienst ein Zertifikat und den passenden privaten Schlüssel in der Box brauchst, nimm einfach gleich den Schlüssel des FRITZ!OS (die 2048 Bit des automatisch generierten reichen auch, aber niemand hindert Dich am Import eines Keys mit 4096 Bit - nur RSA muß es im Moment im FRITZ!OS m.W. sein). Der wird vom FRITZ!OS selbst verschlüsselt gespeichert, für das Auslesen der Passphrase für die Verschlüsselung gibt es aber ein Paket in Freetz.

Um auch der eigentlichen Frage nicht auszuweichen ... ich hänge mal ein Bash-Script an, mit dem ich bei meiner eigenen (self-signed) CA die Erneuerung abgelaufener Zertifikate betreibe - da werden die Angaben zum "Inhaber" aus dem alten Zertifikat ausgelesen und in den Request übernommen, im Anschluß dann der generierte CSR signiert. Man kann sich zumindest in "create_request" ansehen, was da in so eine cnf-Datei für die Generierung des CSR gehören würde - aber auch das ist nur ein möglicher Weg, kein Dogma.
 
Ja du hast natürlich recht ich könnte einfach die CSR auf meinem PC oder generien was ich warscheinlich dann auch tun werde, denn das ganze siht doch etwas kompliziert aus, das ganze wird für pyload benötigt für denn https login auf dem webinterface.
 
Warum nimmst Du denn da nicht einfach das FRITZ!Box-Zertifikat ... dann braucht man sich wenigstens nicht mit mehreren Identitäten herumschlagen.
 
das ist auch eine gute idde, in welchen verzeichnis liegen diese denn auf der Box
 
Der Key liegt in /var/flash/websrv_ssl_key.pem, das Zertifikat in /var/flash/websrv_ssl_cert.pem und die Passphrase für den privaten Schlüssel kann man mit "privatekeypassword" (gibt ein Paket in Freetz dafür) ermitteln.

Ich weiß nicht, wie das Zertifikat in pyload angegeben werden muß, notfalls muß man mit openssl etwas umformen vom Quellformat (PEM-Dateien, Key + Cert getrennt) zu dem, was man braucht.

Aber das steht irgendwo bestimmt auch schon alles ... ich helfe ja gerne, aber es sollte nicht in ein Frage-Antwort-Spiel "Wie geht das?" ausarten - manche Information findet man auch durch die eigene Suche. ;-)
 
Dann paßt es ja.
 
Ne da gebe ich dir recht Frage antwort spiel ist etwas blöde, naja gut ich denke mal mit dem rest werde ich dann selbst zurecht kommen, wie ich das ganze umgewandelt bekomme, das Netz ist ja groß genug :)
Ich Danke dir für deine Hilfe
 
Zuletzt bearbeitet:
Für den Fall, daß pyLoad unbedingt einen unverschlüsselten Key braucht, kann man den auch "on the fly" entschlüsseln ... wie das z.B. als Eingabe für "dropbearkeyconvert" aussehen könnte (da kann natürlich auch pyLoad stehen), habe ich hier mal exemplarisch gezeigt.
 
also ich hatte es noch nie versucht mit einen verschlüsselten key aber ich vermute mal das es unverschlüsselt sein muss.
openssl genrsa 2048 > ssl.key
openssl req -new -key ssl.key -out ssl.csr
openssl req -days 36500 -x509 -key ssl.key -in ssl.csr > ssl.crt

Also das schreibt pyload für die generierung
 
Ja, das liegt daran, daß pyLoad beim Einrichten des SSL-Kontexts (irgendwo in der WSGI-Implementierung in modules/lib) gar keine Möglichkeit vorsieht, ein Kennwort für den privaten Schlüssel ein- oder anzugeben.

Nun könnte man ja auf die Idee kommen, den Schlüssel einfach als "unencrypted copy" für den Start von pyLoad zu speichern (hoffentlich nur irgendwo im tmpfs, die Leute kommen ja auf die merkwürdigsten Ideen), aber selbst das muß eigentlich nicht sein, wenn man anstelle der Schlüsseldatei einen FIFO (kann man auch mit "mknod <dateiname> p" einrichten, wenn es kein mkfifo geben sollte) benutzt, in den einerseits mit openssl (natürlich bei jedem Start von pyLoad) der unverschlüsselte Key geschrieben wird und aus dem dann - quasi "auf der anderen Seite" - der Python-Code ihn lesen kann. Da dort ja nicht von stdin gelesen wird, ist das Verwenden von Pipes im Shell-Code außen herum ja nicht möglich.

Die saubere Lösung wäre das Hinzufügen einer Callback-Funktion zum Webserver-Code von pyLoad (set_passwd_cb heißt die Methode für den SSL-Kontext in pyopenssl), die dann beim Lesen des verschlüsselten Keys das Kennwort direkt bereitstellt ... sind - grob geschätzt - 10 Zeilen Python, die man ändern müßte (EDIT: und als Änderungsvorschlag im Upstream einreichen könnte, wenn man es ähnlich wie Apache2 mit dem PassphraseDialog-Parameter macht).

- - - Aktualisiert - - -

Wobei auch pyLoad wieder ein Paradebeispiel dafür ist, daß man die Verwender der OpenSSL-Libraries auch mal zu ihrem Glück zwingen muß ... wenn da im Prinzip auch eine SSLv2- oder SSLv3-Verbindung möglich wäre, dann kann nur die bereitgestellte Library das noch irgendwie verhindern. Da gehört heutzutage eben TLSv1_2_METHOD hin und gut ist's ... wenn jemand unbedingt einen uralten Browser zur Verwaltung benutzen will, muß er eben auch eine uralte pyLoad-Version benutzen oder selbst Hand anlegen.

Dann kann man auch gleich noch die Unterstützung für verschlüsselte "private keys" hinzufügen, denn das ist nichts weiter als eine zusätzliche Callback-Funktion in diesem Cherry-irgendwas-Server, die ein externes Programm aufruft, dessen stdout dann die zu verwendende Passphrase liefert beim Aufruf. Solche Passphrase-Callbacks hat heutzutage jede halbwegs ernst zu nehmende Software, die mit verschlüsselten Daten umgehen muß oder will - die einfach von vorneherein unverschlüsselt zu speichern, nur weil man ein paar wenige Zeilen sparen will, ist einfach nicht mehr zeitgemäß.
 
Zuletzt bearbeitet:
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.