...Standard Zertifikate könnten auch an sich unsicher sein, Dell hat ja erst neulich gezeigt, wie es geht
hier und
hier. Ebenso ist wohl auch der Standard-SSL Schlüssel eines Raspberry Pi Image immer der gleiche (finde grad leider keinen passenden Artikel dazu) weswegen man das SSL-Zertifikat erneuern sollte.
In dem Zusammenhang stimme ich Dir zu - aber alles, was im DSM zu finden ist, wird bei der Installation des DSM jungfräulich generiert.
Auch wenn es ein klein wenig OT sein mag, ein kurzer Schwenk dorthin, um das vielleicht wenigstens einmal im Forum zu beleuchten:
In den Installationsdateien findet sich ein Skript /usr/syno/etc/ssl/mkcert.sh - darin läuft die Erzeugung der gesamten Zertifikatsammlung einer DS. Zunächst wird ein CA-Key mit 1024 bit Schlüssellänge erzeugt, sozusagen der eigengenerierte Vertrauensanker "Synology":
Code:
echo "STEP1: Generating RSA private key for CA (1024 bit) [ca.key]"
if [ ".$randfiles" != . ]; then
[COLOR=#b22222]$openssl genrsa -rand $randfiles -out $sslkeydir/ca.key 1024 [/COLOR]
Im zweiten Schritt wird dann damit ein CSR für ein CA-Zertifikat erzeugt:
Code:
echo "STEP 2: Generating X.509 certificate signing request for CA [ca.csr]"
cat > /tmp/.mkcert.cfg <<EOT
[ req ]
default_bits = 1024
distinguished_name = req_DN
[ req_DN ]
...
EOT
[COLOR=#b22222] $openssl req -config /tmp/.mkcert.cfg \
-new -sha256 -key $sslkeydir/ca.key \
-out $sslcsrdir/ca.csr <<EOT[/COLOR]
TW
Taiwan
Taipei
Synology Inc.
Synology Inc. CA
product@synology.com
Im dritten Schritt erfolgt dann mit diesem CSR die Erstellung des CA-Zertifikats, welches mit dem in Schritt 1 erzeugten ca.key eigensigniert wird:
Code:
echo "STEP 3: Generating X.509 certificate for CA signed by itself [ca.crt]"
if [ ".$certversion" = .3 -o ".$certversion" = . ]; then
extfile="-extfile /tmp/.mkcert.cfg"
cat > /tmp/.mkcert.cfg <<EOT
extensions = x509v3
[ x509v3 ]
subjectAltName = email:copy
basicConstraints = CA:true,pathlen:0
nsComment = "mod_ssl generated custom CA certificate"
nsCertType = sslCA
EOT
fi
[COLOR=#b22222] $openssl x509 $extfile -days $days \
-signkey $sslkeydir/ca.key \
-in $sslcsrdir/ca.csr -req -sha256 \
-out $sslcrtdir/ca.crt [/COLOR]
Ok, damit ist eine eigene CA vorhanden, individuell auf jeder DS-Installation.
Jetzt geht's an das eigentliche Zertifikat, d.h. als erstes an den privaten Server-Key, der - wie ich oben ja schrieb - standardmäßig ebenfalls aus einem RSA-Schlüssel mit 1024 bit Länge besteht:
Code:
echo "STEP 4: Generating $algo private key for SERVER (1024 bit) [server.key]"
if [ ".$randfiles" != . ]; then
[COLOR=#b22222] $openssl genrsa -rand $randfiles -out $sslkeydir/server.key 1024 [/COLOR]
Im nächsten Schritt 5 wird dann - analog zu Schritt 2 - wiederum ein CSR erzeugt, dieses Mal für das eigentliche Serverzertifikat:
Code:
echo "STEP 5: Generating X.509 certificate signing request for SERVER [server.csr]"
cat > /tmp/.mkcert.cfg <<EOT
[ req ]
...
[COLOR=#b22222] $openssl req -config /tmp/.mkcert.cfg -new -sha256 \
-key $sslkeydir/server.key \
-out $sslcsrdir/server.csr <<EOT [/COLOR]
TW
Taiwan
Taipei
Synology Inc.
synology.com
product@synology.com
Im Schritt 6 wird - analog zu dem Schritt 3 - mit diesem CSR das Serverzertifikat selbst erzeugt und mit der zuvor erzeugten Synology-CA signiert:
Code:
echo "STEP 6: Generating X.509 certificate signed by own CA [server.crt]"
extfile=""
...
extensions = x509v3
[ x509v3 ]
...
[COLOR=#b22222] $openssl x509 $extfile \
-days $days \
-CAserial $MkcertSerial \
-CA $sslcrtdir/ca.crt \
-CAkey $sslkeydir/ca.key \
-in $sslcsrdir/server.csr -req -sha256 \
-out $sslcrtdir/server.crt [/COLOR]
Das war's dann auch schon - das individuelle Synology-signierte DS-Zertifikat, bestehend aus dem privaten Schlüssel
/usr/syno/etc/ssl/ssl.key/server.key und dem öffentlichen Serverzertifikat
/usr/syno/etc/ssl/ssl.crt/server.crt, ist fertig. Diese beiden Dateien werden für die verschlüsselte Kommunikation verwendet.
Danke für eure Hilfe.
