SSL-Zertifikate: Ab 2016 Verwendung von SHA-2

[Frogman]

Da vor kurzem bei meiner DS ein neuer Domain-Name einzog, war auch mal wieder ein neues SSL-Zertifikat fällig. Zwangsläufig geriet ich dabei an einen Umstand, der insbesondere den Nutzern eigener SSL-Zertifikate in Kürze begegnen wird.

Obwohl der gebräuchliche Hash-Algorithmus SHA-1 bereits seit 10 Jahren als nicht mehr sicher angesehen wird, hat sich nicht allzu viel getan - bis heute wird er standardmäßig genutzt, wenn man einen CSR an eine Signaturstelle erzeugt.
Kürzlich einigte man sich jedoch (Link), dass in 2-3 Jahren dieser Algorithmus durch den bereits länger definierten SHA-2 ersetzt werden soll, der üblicherweise mit 256 Bit arbeitet. Sukzessive sollen Zertifikate, deren Ketten SHA-1 enthalten, als unsicher markiert und vermutlich in absehbarer Zeit als ungültig behandelt werden (Details findet man an geeigneter Stelle, bspw. auch hier von GlobalSign).

Wenn also jemand in der nächsten Zeit ein eigenes SSL-Zertifikat verwenden möchte und dazu einen CSR an die Root-CA seiner Wahl erstellt, sollte den Schalter -sha256 verwenden (Beispiel hier). Man muss dann zusätzlich darauf achten, dass auch die eventuell zu nutzenden Intermediate-Zertifikate der verwendeten Root-CA auf Basis von SHA-2 signiert sind. Das Root-Zertifikat selbst kann sowohl SHA-1 als auch SHA-2 anzeigen - da es der oberste Vertrauensanker und daher nur eigensigniert ist, enthält es keine weiteren Signaturen.

SSL-Zertifikate von StartSSL
Viele User nutzen hier ja auch gerne die kostenlosen einjährigen Class1-Zertifikate von StartSSL. Anbei finden sich für diese User, die aktuell bereits auf SHA-2 wechseln möchten, einige Dateien:

1. Im Ordner Root-Zertifikat die altbekannte 'ca.pem', die als Vertrauensanker für alle ausgestellten StartSSL-Zertifikate dient und eine Eigensignatur auf Basis von SHA-1 enthält.
2. Im Ordner Intermediate SHA-2 eine Datei 'sub.class1.server.sha2.ca.pem', d.h. das Intermediate für Class1-Zertifikate, welches für die signierten Serverzertifikaten auf Basis von SHA-2 verwendet wird. Dieses Intermediate ist mit dem bisherigen Intermediate 'sub.class1.client.ca.pem' auf Basis von SHA-1 quersigniert, so dass man damit auch weiterhin das Root-Zertifikat aus Punkt 1 verwenden kann.
3. Zusätzlich noch eine Datei 'chain_256.pem', welche man alternativ bei der Installation des StartSSL-Zertifikats in der DS an Stelle des Zwischenzertifikats aus Punkt 2 verwenden kann (d.h. man lädt neben Server-Key und Server-Zertifikat im dritten Feld dann diese Datei auf die DS). Damit liefert der Server zwar ein längeres Zertifikat aus (d.h. neben dem eigentlichen Serverzertifikat dann auch die Kette bestehend aus Intermediate-Zertifikat plus Root-Zertifikat), doch bei den typischen Nutzungen der DS spielt das keine Rolle. Damit hat man also neben einer Zertifikatskette auf Basis des lokal im Zertifkatsspeicher des Clients vorhandenen Root-Zertifikats von StartSSL auch eine zweite, sozusagen eigenbeglaubigte Kette.
   Der Vorteil der chain_256.pem ist, dass man damit die vom VPN-Server der DS exportierte 'ca.crt' direkt mit der OpenVPN-Konfiguration im OpenVPN-Client verwenden kann, ohne hier noch editieren zu müssen (Details hatte ich hier skizziert, sie gehen auf diesen älteren Thread zurück).

 

[Crash1601]

Guten Morgen,

ich habe mir gerade deinen Beitrag durchgelesen und mich gefragt, wie man denn eigentlich das Zertifikat auf den Ursprung zurücksetzen kann? Wenn ich nun selbst eines erstellt habe und doch wieder das originale von Synology haben möchte.

Kann man die Zertifikatseinstellungen auch einfach reseten?

 

[Frogman]

Du kannst Dir doch in der GUI auch wieder ein (selbstsigniertes) generisches Synology-Zertifikat erstellen lassen - ich sehe da jetzt nicht das Problem.

 

[Frogman]

...
SSL-Zertifikate von StartSSL
Viele User nutzen hier ja auch gerne die kostenlosen einjährigen Class1-Zertifikate von StartSSL. Anbei finden sich für diese User, die aktuell bereits auf SHA-2 wechseln möchten, einige Dateien:

1. ...
2. ...
3. Zusätzlich noch eine Datei 'chain_256.pem', welche man alternativ bei der Installation des StartSSL-Zertifikats in der DS an Stelle des Zwischenzertifikats aus Punkt 2 verwenden kann (d.h. man lädt neben Server-Key und Server-Zertifikat im dritten Feld dann diese Datei auf die DS). Damit liefert der Server zwar ein längeres Zertifikat aus (d.h. neben dem eigentlichen Serverzertifikat dann auch die Kette bestehend aus Intermediate-Zertifikat plus Root-Zertifikat), doch bei den typischen Nutzungen der DS spielt das keine Rolle. Damit hat man also neben einer Zertifikatskette auf Basis des lokal im Zertifkatsspeicher des Clients vorhandenen Root-Zertifikats von StartSSL auch eine zweite, sozusagen eigenbeglaubigte Kette.
   Der Vorteil der chain_256.pem ist, dass man damit die vom VPN-Server der DS exportierte 'ca.crt' direkt mit der OpenVPN-Konfiguration im OpenVPN-Client verwenden kann, ohne hier noch editieren zu müssen (Details hatte ich hier skizziert, sie gehen auf diesen älteren Thread zurück).
   

Zu diesem Thema einmal der Vollständigkeit halber eine kleine Aktualisierung:
dieser dritte Punkt ist inzwischen obsolet. Ich habe mit dem aktuellen VPN-Server einmal verschiedenste Konfigurationen durchgetestet - aktuell ist der Kunstgriff mit einem ergänzten Root-Zertifikat im Intermediate nicht mehr notwendig, man kann das in Punkt 2 erwähnte quersignierte Intermediate problemlos auch mit dem VPN-Server verwenden. Der VPN-Server generiert inzwischen korrekt aus den im DSM vorliegenden Zertifikaten zwei Zertifikatsdateien:

• ca.crt (das ist in der Regel das Intermediate, welches im DSM zusammen mit dem eigentlichen Serverzertifikat eingespielt wurde)
• ca_bundle.crt (hierin sind das Intermediate mit den relevanten Root-Zertifikaten zusammengefasst, im Falle des Intermediate aus Punkt 2 sind das die Root-Zertifikate mit Eigensignatur auf Basis von SHA-1 und mit Eigensignatur auf Basis von SHA-2)

Die Datei ca_bundle.crt wird dann in der Clientkonfiguration openvpn.ovpn des VPN-Servers referenziert.

EDIT:
Es gibt übrigens ein aktualisiertes SHA2-Intermediate (ebenfalls mit Quersignatur SHA-1/SHA-2) auf dem Server von StartSSL, nun mit einer Gültigkeit bis 2022.