Aus gegebenem Anlass habe ich mal zur Sicherheit das Zertifikat von Wesselonline neu erstellt. Da die Debian basierten Distributionen ja unter Umständen über einen Fehler in dem OpenSSL Paket angreifbar sind gab’s natürlich sehr zeitnah ein Update der betroffenen Programmpakete. Das Update allein nützt aber nichts, da ja die erstellten Zertifikate in der Regel noch in Benutzung sind und somit relativ leicht ausgehebelt werden können.
Recht vereinfacht lässt sich das so erklären: Bei der Erzeugung der Schlüssel werden mehrere zufällige Zahlen dazu benutzt, einen besonders einzigartigen Schlüssel zu erstellen, der durch die Nutzung von Unbekannten entsprechend sicher ist. Kennt man jedoch das Erstellungsverfahren und die Unbekannten, dann kann man einen erstellten Schlüsselcode berechnen. Die betroffenen OpenSSL Versionen haben leider einen solches Verhalten an den Tag gelegt. Als zufällige Zahlen haben die Pakete nur noch die Prozess-IDs mit einbezogen. Diese sind 15 bit groß und erlauben somit max. 32768 Prozesse oder verschiedene IDs auf einem unixartigen System (also auch Linux). Eine Zahl von 0 bis 32767 wurde also zur Schlüsselerstellung benutzt. Ergo braucht man max. 32768 (2^15) Versuche einen Schlüssel zu brechen. Und das ist durchaus machbar…
Also schnellstmöglich das Update einspielen:
apt-get update && apt-get upgrade -q -y
und anschließend neue Zertifikate erstellen. Die neuen Zertifikate kann man sehr schön zentral unter /etc/ssl/private/ ablegen. Das zentrale Ablegen der Schlüssel hat den Vorteil, dass mehrere verschiedene Dienste auf die Schlüssel zugreifen können ohne das man ihn in diverse Verzeichnisse linken oder gar kopieren müsste. Eine Änderung des Schlüssels würde also direkt nach dem Neustart der entsprechenden Dienste wie Postfix, Dovecot, Apache… etc. greifen.
Teil 1) Private Key anlegen:
openssl genrsa -out zertifikat.key 2048
legt einen RSA Schlüssel mit 2048 Bit Länge erstellen.
Teil 2) CSR erstellen:
openssl req -new -key zertifikat.key -out zertifikat.csr
legt einen CSR (Certificate Signing Request) an. zu erstellen. Der Common Name (CN) muss auf den FQDN des Server gesetzt werden, also den vollqualifizierten Namen (server.domain.org). Trägt man hier einen anderen Namen ein gibt es Probleme bei der Überprüfung des Zertifikats durch den Client (der aufgerufene Hostname passt dann nicht zu dem im Zertifikat hinterlegten Namen).
OpenSSL fragt beim Erstellen des CSR die folgenden Daten ab:
—–
Country Name (2 letter code) [DE]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:
Please enter the following ‚extra‘ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Teil 3) CERT erstellen:
openssl x509 -req -days 3800-in zertifikat.csr -out zertifikat.cert -signkey zertifikat.key
Wir erstellen ein x509 konformes Zertifikat in dem OpenSSL gesagt wird, dass es den bereits erstellten CSR einlesen soll, mit dem erstellten eigenen privaten Schlüssel (oder dem einer vorhandenen CA) unterschreiben soll und das Ergebnis in die Datei zertifikat.cert schreiben soll. Das ganze soll dann noch 3800 Tage (>10 Jahre) gültig sein.
Jetzt kann man die Dateien zertifikat.cert und zertifikat.key z.B. wie beschrieben nach /etc/ssl/private/ kopieren. Eventuell auch gleich ein
cat zertifikat.cert zertifikat.key > zertifikat.pem
absetzen.
Und nicht vergessen die entsprechenden Dienste neu zu starten – sonst werden die neuen Zertifikate nicht benutzt! Von dem Problem ist übrigens auch der SSH Server betroffen. Also auch hier die Schlüssel neu erstellen und verteilen. Bitte auch den Key des Servers neu erstellen!