Generierung eigener SSL-Zertifikate für die DS

[Benares]

Ich habe mich heute etwas mit dem o.g. Thema beschäftigt und möchte meine Erfahrungen damit gerne mal zur Diskussion stellen, bevor ich evtl. den Eintrag dazu im Wiki ergänze.

Das eigentliche Vorgehen ist im Wiki hier ja sehr gut beschrieben.

Die erste Hürde war, dass ich bei der Erstellung des Stammzertifikats der Default "Synology Station" als commonName nicht belassen habe. Damit hat der Zugriff über per https:/...:5001 dann überhaupt nicht mehr funktioniert. Keine Ahnung warum.

Im zweiten Anlauf hat es dann geklappt. Mich hat nur gestört, dass das Zertifikat nur beim Zugriff über einen bestimmten DynDNS-Namen funktioniert, nämlich den, den man bei der Erstellung des Server-Zertifikats als commonName eingegeben hat. Wenn man mehrere hat oder lokal über https arbeitet (z.B. https://DS212:5001) gibt es Fehler. Scheinbar geht man davon aus, dass jede "Domain" eigene Zertifikate benötigt. Das wollte ich aber nicht.

Bei Tante Google hab ich dafür eine Lösung gefunden:

Unter /usr/local/ssl legt man vor der Erstellung noch eine Datei (z.B. extfile.cnf) mit folgendem Inhalt an:

subjectAltName=DNS:<DnsName1>,DNS:<DnsName2>, ...

z.B.

subjectAltName=DNS:DS212,DNS:DS212.meinefirma.de,DNS:myhost.dydns.org,DNS:myhost.no-ip.com

Diese Datei gibt man bei der Erstellung der Zertifikate bei Schritt 3 mit dem Parameter -extfile jeweils mit,
also beim Stammzertifikat

openssl x509 -days 3650 -signkey ca.key -in ca.csr -req [COLOR="#FF0000"]-extfile extfile.cnf[/COLOR] -out ca.crt

und beim Server-Zertifikat

openssl x509 -days 3650 -CA ca.crt -CAkey ca.key -set_serial 01 -in server.csr -req [COLOR="#FF0000"]-extfile extfile.cnf[/COLOR] -out server.crt

Bei Schritt 2 der Erstellung des Server-Zertifikats verwendet man wie bisher einen der Namen (den am meisten verwendeten?) als commonName.

Beim IE muss man übrigens scheinbar das Zertifikat unter "Vertrauenswürde Stammzertifizierungstellen" speichern und nicht etwa unter "eigene Zertifikate", wie man meinen könnte.

Gruß Benares

 

[jahlives]

und unterstützt auch der Webserver diese "mehreren" Namen im Zert? afaik braucht es dazu SNI-Support. Hat den Synology in den Apache eingebaut?

 

[Benares]

und unterstützt auch der Webserver diese "mehreren" Namen im Zert? afaik braucht es dazu SNI-Support. Hat den Synology in den Apache eingebaut?

Das weiß ich nicht. Zumindest funktioniert bei mir der https-Zugriff nun über unterschiedliche DNS-Namen ohne die hässlichen Zertifikatsfehler.

Gruß Benares

 

[BAB-Hamburg]

hallo zusammen,

bin nicht der überprofi. das vorab.

aber ich habe es auch geschafft, mein eigenes zertifikat zu erstellen. mir ist jedoch wie benares aufgefallen, dass es nur ein zertifikat für eine domain gibt.

daher war ich froh, dass du die lösung hast. allerdings erhalte ich beim erstellen des stammzertifikats eine fehlermeldung, dass er die option -extfile.cnf nicht kennen würde. muss die -extfile.cnf nicht vielmehr im verzeichnis der openssl.cnf liegen, also /usr/syno/ssl/extfile.cnf und nicht in /usr/local/ssl/extfile.cnf?

die fehlermeldung lautet: WARNING: can't open config file: /usr/syno/ssl/openssl.cnf unknown option -extfile.cnf

und danach bekomme ich noch alle argumente für x509 aufgelistet

schöne grüße

 

[Benares]

Ich hab extfile.cnf unter /usr/local/ssl angelegt, dort, wo auch ca.config und server.config liegen.
Beachte die Schreibweise, die zusätzliche Optionen heisst "-extfile extfile.cnf", nicht nur "-extfile.cnf".

Gruß Benares

 

[BAB-Hamburg]

Jeep, das war's wohl. Hab ich wohl vergessen. Man sollte nachts nicht mehr so komplizierte Sachen machen.

 

[sinus65]

Bei Schritt 2 der Erstellung des Server-Zertifikats verwendet man wie bisher einen der Namen (den am meisten verwendeten?) als commonName.

Beim IE muss man übrigens scheinbar das Zertifikat unter "Vertrauenswürde Stammzertifizierungstellen" speichern und nicht etwa unter "eigene Zertifikate", wie man meinen könnte.

Gruß Benares

Ich verstehe nicht bei Schritt 2 welchen Name ich da eingeben muss und wo in der Zeile, kannst du mir da helfen?

Auszug aus der Wiki: 2. Erstellung des Key-Zertifikats:
openssl req -config ca.config -new -key ca.key -out ca.csr
bei mir kommt nämlich folgendes raus:
DiskStation> openssl req -config ca.config -new -key ca.key -out ca.csr
error on line -1 of ca.config
31670:error:02001002:system library:fopen:No such file or directory:bss_file.c:1      26:fopen('ca.config','rb')
31670:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:129:
31670:error:0E078072:configuration file routines:DEF_LOAD:no such file:conf_def.      c:197:

 

[Benares]

Vielleicht nicht explizit erwähnt, aber man muss sich im Verzeichnis /usr/local/ssl befinden, also

mkdir /usr/local/ssl
cd /usr/local/ssl
...

Hab's im Wiki ergänzt. Oder du hast die ca.config nicht oder falsch angelegt.

Wenn Schritt 2 funktioniert, werden Einstellungen abgefragt, u.a. ein commonName. Dort gibst du einen der Namen aus extfile.cnf (ohne DNS: davor) sozusagen als Hauptnamen ein, am Besten den DynDns-Namen. Die anderen Namen aus der extfile.cnf sind sowas wie Aliase.

Gruß Benares

 

[sinus65]

Ich habe alles noch mal neu gemacht und bin ins Verzeichnis /usr/local/ssl gewechselt und habe Schritt 2 erneut ausgeführt
Ergebnis:

DiskStation> openssl req -config ca.config -new -key ca.key -out ca.csrerror on line -1 of ca.config
18122:error:02001002:system library:fopen:No such file or directory:bss_file.c:126:fopen('ca.config','rb')
18122:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:129:
18122:error:0E078072:configuration file routines:DEF_LOAD:no such file:conf_def.c:197:

Die vi ca.config sieht bei mir so aus wie du es im Wiki hinterlegt hast:

[ req ]default_bits = 1024distinguished_name = req_DNstring_mask = nombstr[ req_DN ]countryName = "1. Staat (2 Buchstaben)"countryName_default = DEcountryName_min = 2countryName_max = 2stateOrProvinceName = "2. Bundesland "localityName = "3. Ort "0.organizationName = "4. Name der Organisation "organizationalUnitName = "5. Name der Organisationseinheit "commonName = "6. Common Name (Synology Station) "commonName_max = 64commonName_default = Synology StationemailAddress = "7. Email Adresse " emailAddress_max = 40

Ich habe sie mit und ohne den Inhalt der Ausführungszeichen abgelegt, also:

[ req ]
default_bits = 1024
distinguished_name = req_DN
string_mask = nombstr


[ req_DN ]
countryName = 
countryName_default = DE
countryName_min = 2
countryName_max = 2
stateOrProvinceName = 
localityName = 
0.organizationName = 
organizationalUnitName = 
commonName = 
commonName_max = 
commonName_default = 
emailAddress = 
emailAddress_max = 40

mit dem selben Ergebnis

Die Dateien habe ich mit nano erstellt

 

[Benares]

Das liegt vermutlich daran, dass die Datei ca.config nicht im Unix-Format vorliegt (nur LineFeed am Zeilenende)
Probier mal folgendes:

cd /usr/local/ssl
rm ca.config
vi ca.config

danach Taste i (insert), den Text aus dem Wiki per Cut&Paste einfügen, danach [ESC] (insert mode verlassen), dann ":wq" (write, quit). Danach muss dir "cat ca.config" den Inhalt wie im Wiki anzeigen.

Ebenso bei den beiden anderen Dateien, bevor du die Schritte 1-3 ausführst.

Gruß Benares

 

[sinus65]

Danke, es funktioniert, der Fehler lag an den Dateinamen, ich habe das vi davor gesetzt, was eigentlich der Editor sein sollte ;-) Dann habe ich hier im Forum eine Artikel gefunden wie man das alte Zertifikat löscht und das neue automatisch einbindet, was auch funktioniert hat Gruß Thomas

 

[Slingger]

Hallo Benares,

wir haben uns an die Anleitung gehalten und im Ergebnis jeweils ein Stamm- und Server-Zertifikat erhalten, welches die gewünschten alternativen DNS-Namen und IP-Adressen in der v3-Sektion beinhaltet. Danach haben wir das Stamm-Zertifikat auf unseren PCs in die Liste der vertrauenswürdigen Anbieter aufgenommen. Wenn wir jetzt auf unsere RS812+ über den im CommonName hinterlegten Namen zugreifen, ist alles schön! Wenn wir aber über einen der alternativen Namen oder IP darauf zugreifen, kommen wieder die Zertifikat-Fehler :-(
Wir nutzen DSM 4.1 mit dem von Synology zur Verfügung gestellten openssl und apache Versionen. Aus irgendeinem Grunde schienen die Browser die subjectAltName-Sektion komplett zu ignorieren. Kann es sein, dass das alles unter DSM 4.0 noch lief, aber unter DSM 4.1 nicht mehr?

Danke und Gruß,
Heiko

 

[Benares]

Hallo Heiko,

also bei mir funktioniert es, auch mit den AltNames, auch mit dem DSM 4.1, mit IE und Firefox probiert.
Schau dir mal das Zertifikat im Browser an. Da sieht man auch die AltNames. Im IE auch als "Vertrauenswürdige Stammzertifizierungsstelle" gespeichert?
Hast du evtl. noch alte Zertifikate installiert? Lösch die mal (im IE unter Extras, Internetoptionen, Inhalt, Zertifikate)

Gruß Benares

 

[JogibaerNr1]

Bei mir kommt jetzt nach erfolgreicher Generierung des Sicherheitszertifikates (Synology Wiki Anleitung benutzt und Zertifikat auf dem PC installiert) unter Chrome oder IE: "Das sicherheitszertifikat ist nicht vertrauenswürdig" Was habe ich falsch gemacht?

 

[jahlives]

es sollte in der Fehlermeldung auch stehen warum das Cert nichts als vertrauenswürdig angesehen wird. Oft weil dem Cert der CA-Auth nicht vertraut wird

 

[JogibaerNr1]

Sry vergessen, also ich habe "https://name_meines_NAS.synology.me/"
eingegeben.

Mit Chrome:

Sie haben versucht, auf /name_meines_NAS.synology.me zuzugreifen, der Server hat sich jedoch mit einem Zertifikat ausgewiesen, das von einer Entität ausgestellt wurde, der das Betriebssystem des Computers nicht vertraut. Dies bedeutet möglicherweise, dass der Server seine eigenen Sicherheitsinformationen erzeugt hat, auf die Google Chrome als Identitätsinformation nicht vertrauen kann, oder dass ein Hacker versucht, Ihre Kommunikation abzufangen.

Firefox:

 

[jahlives]

es steht doch da Dem Aussteller Cert wird nicht vertraut

 

[JogibaerNr1]

Ja aber ich habe es doch genau so wie im Wiki gemacht? Ich dachte das funktioniert dann. Worin liegt jetzt mein Fehler? Mir, also der Zertifizierungsstelle wird nicht vertraut. Also kann ich eine Selbstgenerierung vergessen weil die sowieso nicht akzeptiert wird?

 

[Benares]

Ach was, einfach "Ich kenne das Risiko" drücken. Als Privatanwender und für "umme" gibt es keine vertrauenswürdige Zertifikate.
Wenn du dir selbst nicht vertraust - lass es.

 

[casnoff]

Die Meldung verschwindet nur, wenn du ein Zertifkat einer anerkannten Zertifizierungsstelle verwendest. In der Regel musst du dafür immer bezahlen.

Ansonsten besteht noch die Möglichkeit ein Zertifikat von StartSSl http://www.startssl.com/?lang=de zu nutzen. Hier kann man kostenfrei ein solches erhalten, welches auch von einer Vielzahl von Browsern anerkannt wird.