DSM 7.0 Selbsterstellte Zertifikate erneuern DSM7

[DeepNAS]

Wäre das erlaubt, wäre ein Zertifikat für z.B. 192.168.1.10 auf jedem System dieses Planeten mit selber IP zertifiziert und Du könntest jedes System durch Änderung seiner IP zu einem vertrauenswürdigen Client erklären.

Ganz so einfach ist es zum Glück nicht.
Dein beliebiges System müsste schon den passenden privaten Key haben, der zu dem Request passt, den du (oder jede andere CA) "unterschrieben" hast.


Ehrlich gesagt weiß ich nicht, ob das laut Standard zulässig ist, aber in meinem Fall funktioniert eigentlich genau das.
Ich habe mir eine eigene CA erstellt und in Win 10 in den Zweig "vertrauenswürdiger Stammzertifizierungsstellen" importiert.
Damit habe ich dann ein entsprechendes selbst erstelltes Zertifikat für das NAS "unterschrieben" welches einfach auf den im NAS konfigurierten Namen (unter Systemsteuerung->Netzwerk->Servername) als "Common Name" und zusätzlich die lokale IP des NAS als "Subject Alternative Name" enthält.
Damit kann ich dann z.B. mit Chrome ohne die "nicht sicher Meldungen" auf das NAS zugreifen.
Allerdings geht das halt nur, weil Chrome in dem Fall die Liste der vertrauenswürdigen Anbieter des Betriebssystems auswertet. Wenn die benutze App (wie anscheinend die Photo App) das nicht macht und selbst keinen entsprechenden Zertifikatstore führt (wie z.B. Firefox), dann wird das nicht klappen - wobei das dann wahrscheinlich auch mit Lets Encrypt nicht funktionieren kann? Woher soll die App denn wissen, ob das Zertifikat gültig ist, wenn es keine entsprechende Liste führt/ausliest, welche die "erlaubten" CA's enthält....
Aber kann ich nix zu sagen, nutze die App nicht.







Wikipedia sagt IP-Adressen sind als SAN zulässig:
https://en.wikipedia.org/wiki/Subject_Alternative_Name
https://www.openssl.org/docs/manmaster/man5/x509v3_config.html#Subject-Alternative-Name

 

[roterteufel81]

Damit verbiegst Du den Standard. Es ist so zum Glück nicht offiziell zulässig und auch nicht vorgesehen. Sonst könnte man mit der Methode bei relevanten Dingen mächtig Schmu betreiben, den man ja jetzt schon durch die verkürzte Lebensdauer von zertifizierten Zertifikaten versucht einzudämmen.

Im Prinzip trickst Du ja nur rum, um für Dich ein geschlossenes Schloss-Symbol zu erzeugen.

Später mit TLS 1.3 only wird diese Methode, denke ich, auch nicht mehr gehen.

Und gut, dass Synology Photos sowas nicht frisst.

 

[the other]

Moinsen,
kommt ja generell auch immer aufs individuelle setting an:
machst du alles nur im Heimnetz und maximal per VPN, dann spricht imho gar nix gegen ein eigenes signiertes Zertifikat mit eigener CA. Geht das aber eben auch über extern, und nicht nur mit VPN, dann sollte es schon was "offizielleres" sein, denn viele Anwendung streiken bei selbstsignierten Zertifikaten direkt bzw. nehmen es eben (zum Glück) nicht an.
Ob es jetzt sinnig ist, dass bei ausschließlich internem Traffic https genutzt wird ist dann wieder eine andere Diskussion...ich mach das hier so, mit eigenen Zertifikaten und das läuft auch. Ist aber auch eher so die Bastelecke...

 

[Benares]

Damit verbiegst Du den Standard

Wieso? Der "Standard" sieht auch IP-Adressen vor.
Ob das Sinn macht und auch im Sinne des Erfinders ist, ist eine andere Frage. Aber da ist man ja auch schon mit selbstsignierten Zertifikaten neben der Spur.

 

[DeepNAS]

Es ist so zum Glück nicht offiziell zulässig und auch nicht vorgesehen. Sonst könnte man mit der Methode bei relevanten Dingen mächtig Schmu betreiben,

Doch, es ist wohl offiziell so zulässig, dachte ich im ersten Moment auch nicht aber steht ja offiziel so drin - ansonsten würde es Chrome wohl auch nicht einfach so "fressen".

Was soll man denn deiner Meinung nach für mächtigen Schmu betreiben können?


Grundsätzlich verstehe ich nicht, warum dem selbst erstelltem und signierten Zertifikat eine schlechtere Sicherheit/Vertraulichkeit oder Authentifizierung unterstellt wird? Auch wenn man eine extern aufgelöste Domain benutzt.
Die relevanten Nachteile sind, dass es halt umständlich ist, zusätzliche Arbeit macht (insbesondere bei vielen verschiedenen Nutzern), es zu kompliziert für den 0815 Nutzer ist, und bei manchen Anwendungsfällen halt nicht funktioniert, da manche Anwendung so zugenagelt ist, das die entsprechende Konfig nicht akzeptiert wird - was eigentlich ein Unding ist....

Aber weder die Sicherheit der Verschlüsselung, bzw. Integrität der übertragenen Daten noch die Authentifizierung der Gegenseite ist schlechter als bei den sog. "offiziellen" Zertifikaten - im Gegenteil.

Verschlüsselung und Integretät der Daten ist in beiden Fällen gleich gut/schlecht. Das hängt nur von den verwendeten Verschlüsselungsverfahren ab.
Die Authentifizierung ist unterm Strich sogar besser. Bei den "offiziellen" Zertifikaten muss ich als Nutzer darauf vertrauen, dass eine dritte Partei mir bescheinigt, dass der Server zu dem ich mich verbinden will auch tatsächlich der ist, der er behauptet zu sein. Warum sollte ich das tun? Habt ihr mal in die Zertifikatsstores geschaut was da alles für Stellen als "vertrauenswürdig" bezeichnet werden? Das reicht von diversen kommerziellen Firmen aus aller Welt über staatliche / halbstaatliche Stellen aus durchaus dubiosen Staaten. Zusätzlich besteht auch immer das Risiko, dass so eine Firma selbst gehackt wird und dann gefälschte Zertifikate in Umlauf kommen - was auch schon mehrfach passiert ist.
https://www.privacy-handbuch.de/handbuch_21f.htm
https://www.golem.de/news/sicherheitsluecke-digicert-und-lineage-os-server-gehackt-2005-148236.html

Bescheinige ich mir mit meiner eigenen "CA" selbst, dass das Serverzertifikat das richtige ist, dann kann ich mir zu 100% sicher sein, das meine Verbindung zum Server nicht von dritten abgefangen wird. Aber wie gesagt, das Handling ist halt sehr aufwendig. Aus diesem und da ich ja auch verschlüsselte Verbindungen zu fremden Servern herstellen möchte gibt es diese Zertifizierungsstellen.
Ansonsten müsste ich, wenn ich eine verschlüsselte Verbindung zu Servern die nicht unter meiner Kontrolle sind (z.B. die Bankwebsite) irgendwie anders überprüfen ob das jetzt ein Betrüger ist oder die richtige Webseite. Ginge auch (z.B. könnte mir meine Bank den Hash ihres Zertifikats per Brief schicken), aber das ist halt 0,0 Praxistauglich. daher vertraut mein Betriebssystem/Browser irgendwelchen Stellen die behaupten die Ausstellung der Zertifikate entsprechend zu prüfen...

Später mit TLS 1.3 only wird diese Methode, denke ich, auch nicht mehr gehen.

es ist schon eine TLS 1.3 Verbindung

 

[whocares]

Da kann anscheinend einer keine Kritik vertragen. Das ändert aber nichts daran, dass IPv6 nicht das Problem ist.

Du verstehst meine Argumentationskette offensichtlich nicht. Einfach mal den Link in meinem vorherigen Beitrag folgen, lesen und vor allem verstehen. Um die IPv6-Geschichte geht's hier im Thema nur am Rande, also bleibe bitte beim Thema (zu dem Du leider immer noch nichts sinnvolles beitragen konntest). Nochmal deutlich: Es ist für mich witzlos, mein Netz von außen zugänglich zu machen, um ein Zertifikat zu bekommen, nur damit ich lokal Videos per Photos streamen kann und der Browser keine Warnungen mehr zeigt. Kosten und Nutzen stehen in keinem sinnvollen Verhältnis. Die Erreichbarkeit von außen bei der Deutschen Glasfaser ist zudem komplexer, als mit einer Standard-öffentlichen IPv4-Adresse (siehe mehrfach erwähnten Link). Das ist das was ich sagte, ohne anfangs auf Details einzugehen. Alles andere zu dem Thema ist nur Deine Meinung, die mich 1. nicht interessiert und 2. bisher nicht konstruktives beigetragen hat. Nun zurück zum Thema bitte.
Edit: Hier noch eine gute Beschreibung der speziellen IPv4-Adressen, für die, die es interessiert.

 

[Benares]

Grundsätzlich verstehe ich nicht, warum dem selbst erstelltem und signierten Zertifikat eine schlechtere Sicherheit/Vertraulichkeit oder Authentifizierung unterstellt wird?

Ist auch nicht so, die sind genauso sicher.
Nur würde ich gerne unterscheiden wollen, ob man solche Zertifikate für private Zwecke (verschlüsselte Backups, VPN-Strecken ...) einsetzt, wo man sich nicht nicht ständig um die Zertifikatserneuerung kümmern will/kann, sondern eher Sicherheit/Langzeitstabilität in Vordergrund steht, oder für Client-Zugriffe.
Für Client-Zugriffe ist sicherlich ein "normales" Zertifikat besser geeignet.

 

[roterteufel81]

Ob es jetzt sinnig ist, dass bei ausschließlich internem Traffic https genutzt wird ist dann wieder eine andere Diskussion...

Da hat man an der Stelle, bei der es gewünscht war, keine Wahl mehr.

Videos abspielen in Synology Photos über https funktioniert ausschließlich mit offiziell abgesegnetem Zertifikat und das geht an dieser Stelle auch nunmal nur via DynDNS. Fotos anschauen geht auch mit selbst signiert, da frisst die App auch Bastel-Zertifikate.

Wo das herrührt mit den Videos über https weiß ich nicht.

 

[synfor]

Du verstehst meine Argumentationskette offensichtlich nicht. Einfach mal den Link in meinem vorherigen Beitrag folgen, lesen und vor allem verstehen.

Da steht nichts drin, was deine Aussage "Davon abgesehen ist es, Deutsche Glasfaser sei Dank, wegen der öffentlichen ipv6 Adresse, recht umständlich, per Internet auf das Heimnetzwerk zuzugreifen." deckt (Hervorhebung von mir). Das sehe übrigens nicht nur ich so. Außerdem gibt es beispielsweise Internetzugänge bei der Telekom mit Dual Stack (ebenfalls mit öffentlichen IPv6-Adressen) bei denen es deine Probleme nicht gibt. Das Problem gibt es also gar nicht "wegen der öffentlichen ipv6 Adresse".

Es ist für mich witzlos, mein Netz von außen zugänglich zu machen, um ein Zertifikat zu bekommen, nur damit ich lokal Videos per Photos streamen kann und der Browser keine Warnungen mehr zeigt. Kosten und Nutzen stehen in keinem sinnvollen Verhältnis.

Es gibt alternative Wege um bei Lets Encrypt zu einem Zertifikat zu kommen. Nur bei einem dieser Wege muss dein System zum Zeitpunkt der Erstellung oder der Verlängerung von außen erreichbar sein.

Die Erreichbarkeit von außen bei der Deutschen Glasfaser ist zudem komplexer, als mit einer Standard-öffentlichen IPv4-Adresse (siehe mehrfach erwähnten Link). Das ist das was ich sagte, ohne anfangs auf Details einzugehen.

Nein, das war eben nicht was du sagtest, sondern das, was du meintest. Das was du sagtest, habe ich weiter oben zitiert.

 

[whocares]

Siehst du, ist doch gar nicht so schwer, etwas konstruktives zum Thema beizutragen. Viel angenehmer als deine erste Methode, die aus einer Beleidigung und sonst nichts bestand. ;-)

 

[synfor]

Welche Beleidigung?

 

[whocares]

Ich fange jetzt hier nicht an, mit dir darüber zu diskutieren. Generell werde ich dir hier keine Antworten mehr geben, die nichts zum eigentlichen Thema beitragen, ich denke, es ist alles gesagt. Gibt schon genau Off Topic in diesem Beitrag.

 

[synfor]

Toll, anderen Vorwürfe machen, die aber nicht belegen wollen. Das passt zu dem Eindruck, den ich von dir hier gewonnen habe.

 

[ErichBV228]

Hier meine Erfahrungen zu diesem Thema.
Vorbemerkungen:

1. Meine beiden (privat betriebenen) NAS laufen rein intern in meinem Heimnetz. Sämtliche Zugriffe aus dem Internet laufen über mein ebenfalls privat betriebenes Wireguard-VPN. Damit dürfte klar sein, dass die Zertifikate von LE "außen vor" sind, denn ich möchte ja keinen direkten Zugriff aus dem Internet. Trotzdem, schon weil moderne Browser einfach TLS verlangen, betreibe ich auch intern alle Verbindungen verschlüsselt.
2. Ich habe meine letzten 15 Arbeitsjahre vor der Pensionierung in leitender Tätigkeit in einem großen TrustCenter verbracht, und auch als Pensionär betreibe ich weiterhin eine privat betriebene CA und generiere für Interessenten jedes Jahr mehrere 100 Zertifikate für S/MIME und TLS.

Als ich meine DS220+ auf DSM 7 aktualisiert hatte, hatte ich auf einmal das Problem, dass ich nicht mehr deren GUI erreichte. Dummerweise war die Umleitung von http auf https aktiviert. Zum Glück konnte ich das Problem per ssh lösen. Näheres dazu steht in einem gesonderten Thread.

Ich habe also zuerst (nachdem ich wieder das GUI erreichte) sofort vor dem Import der neuen Zertifikate die Umleitung auf https deaktiviert => Empfehlung!
Dann habe ich mit dem von mir genutzten tollen Programm "XCA" ein reines TLS-Serverzeritifikat (ohne kritische Einschränkungen) generiert. (Ich nutze Templates für S/MIME-, Server-, VPN- und sonstige Zertifikate.)
Dieses Zertifikat wurde selbstverständlich mit meinem üblichen vorhandenen und 20 Jahre geltenden CA-Zertifikat signiert, welches auch als vertrauenswürdiger Herausgeber in allen meinen Gerätschaften und denen meiner "Kunden" importiert ist.

Nun habe ich im .pem-Format exportiert:
- cert.pem (also das eigentliche Server-Zertifikat)
- key.pem (den private-key des Servers, selbstvertändlich ohne Transport-Verschlüsselung)

Hier meine Erfahrungen zu diesem Thema.
Vorbemerkungen:

1. Meine beiden (privat betriebenen) NAS laufen rein intern in meinem Heimnetz. Sämtliche Zugriffe aus dem Internet laufen über mein ebenfalls privat betriebenes Wireguard-VPN. Damit dürfte klar sein, dass die Zertifikate von LE "außen vor" sind, denn ich möchte ja keinen direkten Zugriff aus dem Internet. Trotzdem, schon weil moderne Browser einfach TLS verlangen, betreibe ich auch intern alle Verbindungen verschlüsselt.
2. Ich habe meine letzten 15 Arbeitsjahre vor der Pensionierung in leitender Tätigkeit in einem großen TrustCenter verbracht, und auch als Pensionär betreibe ich weiterhin eine privat betriebene CA und generiere für Interessenten jedes Jahr mehrere 100 Zertifikate für S/MIME und TLS.

Als ich meine DS220+ auf DSM 7 aktualisiert hatte, hatte ich auf einmal das Problem, dass ich nicht mehr deren GUI erreichte. Dummerweise war die Umleitung von http auf https aktiviert. Zum Glück konnte ich das Problem per ssh lösen. Näheres dazu steht in einem gesonderten Thread.

Ich habe also zuerst (nachdem ich wieder das GUI erreichte) sofort vor dem Import der neuen Zertifikate die Umleitung auf https deaktiviert => Empfehlung!
Dann habe ich mit dem von mir genutzten tollen Programm "XCA" ein reines TLS-Serverzeritifikat (ohne kritische Einschränkungen) generiert. (Ich nutze Templates für S/MIME-, Server-, VPN- und sonstige Zertifikate.)
Dieses Zertifikat wurde selbstverständlich mit meinem üblichen vorhandenen und 20 Jahre geltenden CA-Zertifikat signiert, welches auch als vertrauenswürdiger Herausgeber in allen meinen Gerätschaften und denen meiner "Kunden" importiert ist.

Nun habe ich im .pem-Format exportiert:
- cert.pem (also das eigentliche Server-Zertifikat)
- key.pem (den private-key des Servers, selbstvertändlich ohne Transport-Verschlüsselung)
- zwischencert.pem (was nichts anderes als das _öffentliche_ Zertifikat meiner CA ist)
Diese 3 Dateien per GUI importiert, einen reboot gemacht und alles lief wieder per https. Nach einigen Tests dann wieder die Umleitung mit dem Zwang von https aktiviert.
Eigentlich genau so, wie ich das schon alle Jahre vorher gemacht habe.

Selbstverständlich kann man das auch in Handarbeit auf der Konsole mit keygen und den entsprechenden Parametern machen, aber per XCA geht es eben (zumal ich ja sehr viel damit mache) viel einfacher. Und ich bestehe auch (so wie ich das ja viele Jahre gewohnt war!) auf die Signatur durch ein eigenes CA-Zertifikat. Schon damit mein Browser und die anderen Geräte dauerhaft "zufrieden" sind. Ausnahmeregelungen und das Generieren eines cert als CA-Zertifikat widerstreben mir.

Viel Erfolg!
MfG Peter

Diese 3 Dateien per GUI importiert, einen reboot gemacht und alles lief wieder per https. Nach einigen Tests dann wieder die Umleitung mit dem Zwang von https aktiviert.- zwischencert.pem (was nichts anderes als das _öffentliche_ Zertifikat meiner CA ist)
Eigentlich genau so, wie ich das schon alle Jahre vorher gemacht habe.

Selbstverständlich kann man das auch in Handarbeit auf der Konsole mit keygen und den entsprechenden Parametern machen, aber per XCA geht es eben (zumal ich ja sehr viel damit mache) viel einfacher. Und ich bestehe auch (so wie ich das ja viele Jahre gewohnt war!) auf die Signatur durch ein eigenes CA-Zertifikat. Schon damit mein Browser und die anderen Geräte dauerhaft "zufrieden" sind. Ausnahmeregelungen und das Generieren eines cert als CA-Zertifikat widerstreben mir.

Viel Erfolg!
MfG Peter

Hallo Peter,
ich habe heute bei Godaddy ein Zertifikat über eine csr Anforderung aus DSM7.0 in meiner Diskstation erzeugt.
Hier stand es müssen alles pem Dateien sein.
Ich hatte damit Erfolg siehe Screenshoot.

Wie bisher server.key und das Zertifikat(Sicherheitszertifikat).crt und die bundle.crt (zwischenzertifikat eingefügt)

Es sind keine PEM Dateiendungen notwendig.

Dein Hinweis die http auf https zu deaktivieren war goldrichtig.

Beim einfügen dieser Dateien passiert erstmal gar nichts, erst wenn man mit der Maus den Hintergrund anklickt,
ist das Neue Zertifikat aktiv.

Danke für die Hinweise.

Ich habe noch eine gute Seite mit dem man die crs crt Dateien und den Key prüfen kann.
https://goto-ssl.de/

Die Konvertierungstools sind Klasse, die Internetseiten kurz und knapp gehalten.

Grüße Erich

 

[Favi]

Hallo,

Videos abspielen in Synology Photos über https funktioniert ausschließlich mit offiziell abgesegnetem Zertifikat und das geht an dieser Stelle auch nunmal nur via DynDNS.

Gerade habe ich mir mit einem selbstsignierten Zertifikat das Gegenteil bewiesen, die Verbindung erscheint sogar unter vertrauenswürdigen Verbindungen in der Photos-App. In iOS 15.5, hast Du auch in den Einstellungen die erhöhte Vertrauenswürdigkeit extra eingeschaltet?

Viele Grüße
Favi

 

[roterteufel81]

Also bei mir akzeptiert Synology Photos nicht das Synology Zertifikat, dass bis 2038 gültig ist. Auch selbst signierte Zertifikate wurden bei mir nicht akzeptiert (vielleicht hat sich da was geändert?), aber auch die haben ja mittlerweile ein kürzeres Ablaufdatum und nicht mehr z.B. 10 Jahre möglich. Dann nehme ich doch lieber automatisiert Let's Encrypt, wo ich mich um nichts kümmern muss. Einziger Wehrmutstropfen ist halt, wenn man Googles 2FA nutzt, dann muss man nach jedem Zertifikatswechsel den 6-stelligen Code eingeben und das merkt man nur, wenn man die App aktiv öffnet. Öffnet man die App kaum, nutzt aber die Backupfunktion, läuft das Backup halt irgendwann einfach nicht mehr, bis man die App einmal öffnet und den 2FA bestätigt.

 

[Favi]

Also bei mir akzeptiert Synology Photos nicht das Synology Zertifikat, dass bis 2038 gültig ist. Auch selbst signierte Zertifikate wurden bei mir nicht akzeptiert (vielleicht hat sich da was geändert?), aber auch die haben ja mittlerweile ein kürzeres Ablaufdatum und nicht mehr z.B. 10 Jahre möglich.

Ich habe auch mein CA-Zertifikat in der Laufzeit auf ein Jahr begrenzt, vielleicht ist das der Unterschied? Als Apple die Restriktionen für iOS damals erhöht hat, habe ich die Anforderungen so gelesen, dass die maximale Laufzeit von Zertifikaten ein Jahr sein darf, damit man alle Funktionen damit nutzen kann. Vielleicht habe ich das auch falsch verstanden und nur das Server-Zertifikat muss so kurz gültig sein.

Meine Interpretation führt natürlich zu erhöhtem Aufwand durch Erneuerung des CA-Zertifikats jedes Jahr. Für mich ist das in Ordnung.

 

[roterteufel81]

Mehr als 1 Jahr geht auch nicht mehr (genauer 13 Monate oder auch 397 Tage). Das ist aber nicht nur die Idee von Apple gewesen , sondern die Zertifikats-Communities haben diesen Standard verabschiedet. Apple hat es als erster kommuniziert. https://www.globalsign.com/de-de/blog/ssl-tls-zertifikate-gelten-nun-maximal-ein-jahr

Ist seit September letzten Jahres in Kraft und umgesetzt.

Für mich wäre eine händische Erneuerung jedes Jahr leider nicht in Ordnung, da ich sonst durch Firmen tanzen muss, die auf automatismen angewiesen sind.

 

[Ghost108]

OK. Dann gibt es die Option in der GUI des DSM 7 nicht mehr… Dachte evtl. liegts nur an der VM Version.

Immerhin hat gerade das testweise importieren beliebiger Zertifikate noch funktioniert.


Wenn du ein Zertifikat erneuern willst, ist das im Grunde auch der gleiche Vorgang wie das neu erstellen – außer das man nicht die ganzen Werte für Namen und DNS Namen etc. neu eingeben muss.

Habs gerade probiert. Wenn man bei einem Zertifikat in DSM auf erneuern klickt, bekommt man einen Download mit einer ZIP-Datei, welche einen neuen privaten Key (*.key) und den Zertifikatrequest (*.csr) enthält. Diese würde man dann zu einer kommerziellen Zertifizierungsstelle schicken und bekäme dann von denen das Zertifikat zurück – oder man erzeugt sich das Zertifikat halt selbst - was dann aber aufgrund der nicht in den Betriebssystemen vorhandener „ist schon so in Ordnung“ root Zertifikate als „nicht vertrauenswürdig“ abgestempelt wird. Will man das vermeiden, muss man wie in dem Post zuvor von Peter beschrieben ein entsprechendes Root Zertifikat im Betriebssytem und/oder den benutzen Browsern/Software hinterlegen.


Die grundsätzliche Vorgehensweise ist wie folgt (wenn du aus DSM heraus erneuerst überspringst du die ersten beiden Schritte – das hat DSM quasi schon erledigt):

Vorab braucht man Openssl. https://www.openssl.org/source/
In Linuxen ist das meist schon installiert, oder kann über die Paketverwaltung nachinstalliert werden. Für Windows gibt es aber auch einen fertig kompilierten Installer (https://slproweb.com/products/Win32OpenSSL.html)

1. privaten Schlüssel erstellen (Beispiel für 4096 Bit langen RSA-Key):
   openssl genrsa -out test_key.pem 4096
   
   
2. Certificate Signing Request für den Key erstellen:
   openssl req -new -key test_key.pem -out test_request.pem
   
   
3. selbst signiertes Zertifikat erstellen (Beispiel für 365 Tage Gültigkeit):
   openssl x509 -req -days 365 -in test_request.pem -signkey test_key.pem -out test_cert.pem

Die Dateiendungen können statt .pem auch anders lauten wie z.B. bei den von DSM erstellten .key / .csr oder was auch immer - das sind alles im Grunde Textdateien.
Die Gültigkeitsdauer würde ich ehrlich gesagt richtig lang machen. Mir fällt eigentlich kein vernünftiger Grund ein, bei einem selbstsignierten Zertifikat eine regelmäßige Erneuerung einzubauen. Da du ja selbst dafür „gerade stehst“ und es in deiner eigenen Kontrolle liegt, kannst du bei Bedarf jederzeit das Zertifikat löschen/erneuern, wenn du der Meinung bist es wurde irgendwie kompromittiert o.ä.

Moin!

ich habe es genau so gemacht und habe meine 3 Dateien erhalten.
Diese wollte ich nun wie folgt importieren:



Erhalte aber dann folgende Fehlermeldung:



Was mache ich falsch?

 

[Ghost108]

hat sich erledigt. habe das Zwischenzertifikat einfach rausgelassen, da optional -> schon gehts.