KMIP Server for Synology DSM - erneuern von abgelaufenen Keys und Zertifikat

[Annika Hansen]

Ich bin grade dabei, meine DS1522+ nochmal neu aufzusetzen, diesmal mit Volumeverschlüsselung - die Möglichkeit dazu hatte ich beim ersten Setup leider übersehen. In einem anderen Thread (klick mich) bin ich über den möglichen Einsatz eines KMIP-Servers als Encryption Key Vault gestolpert.

Also habe ich den KMIP Server for Synology DSM mal auf meinem Raspberry Pi 4 installiert, was auch absolut unproblematisch und easy-going war. In der Konfiguration gibt man u.a. die Gültigkeitsdauer des Zertifikats und der Keys an. Die Default-Werte sind

# RSA key size and lifetime configuration
CA_KEY_SIZE=2048 # (bits, 2048 or 4096 is recommended)
CA_LIFETIME=3560 # (days)
CLIENT_KEY_SIZE=2048 # (bits, 2048 or 4096 is recommended)
CLIENT_CERT_LIFETIME=1095 # (days)
SERVER_KEY_SIZE=2048 # (bits, 2048 or 4096 is recommended)
SERVER_CERT_LIFETIME=1095 # (days)

Folgendes ist mir nicht so ganz klar, vielleicht kann mir ja jemand auf die Sprünge helfen:

• Sollten die Lifetime des Zertifikat und der Keys nicht besser identisch sein?
• Was passiert wenn ich nach Tag 1095 die Diskstation reboote? Dann sind die Schlüssel ja ungültig - komme ich dann überhaupt noch an das Volume dran (vermutlich nur noch durch manuelle Eingabe des Passworts, das ich bei der Erstellung des Volumes als ordentlicher Admin zuvor in einem Password Safe gespeichert habe)?
• Wie sieht dieser Eingabe-Dialog für eine manuelle Entschlüsselung aus bzw. wann "poppt der beim Reboot hoch"?
• Wie und wo erstelle ich dann neue Keys und Zertifikate? Reicht es aus diese mit "openssl req -x509 -newkey... bla bla" zu erstellen und dann auf dem KMIP-Server unter /certs zu hinterlegen und anschliessend im DSM Web Interface zu importieren?

Ich mache mir lieber jetzt die Gedanken, um eine mögliche Panikattacke in 3 Jahren zu vermeiden.

 

[Annika Hansen]

Ich habe eine Lösung gefunden, wie ich die Keys/Zertifikate für den KMIP-Server auf meinem Raspberry erneuern kann. Es gibt mit Sicherheit elegantere Methoden, aber diese hier funktioniert und reicht für mich vollkommen aus.

Step 1:
Kopieren des Shellscripts init.sh aus dem git-Repo kmip-server-dsm und ablegen auf dem Raspberry.

Step 2:
Anpassen des Skripts init.sh durch hinzufügen des Inhalts des Skripts config.sh aus dem gleichen Repo. Bei mir sieht das wie folgt aus:

Spoiler: create-certs.sh (modifiziert)

#!/bin/sh

# --- Beginn: Übernahme der settings aus config.sh

# RSA key size and lifetime configuration
CA_KEY_SIZE=2048 # (bits, 2048 or 4096 is recommended)
CA_LIFETIME=3560 # (days)
CLIENT_KEY_SIZE=2048 # (bits, 2048 or 4096 is recommended)
CLIENT_CERT_LIFETIME=1095 # (days)
SERVER_KEY_SIZE=2048 # (bits, 2048 or 4096 is recommended)
SERVER_CERT_LIFETIME=1095 # (days)

# If you have local DNS in your environment, syntax is following:
# SSL_SERVER_NAME=DNS:<fully qualified hostname of this KMIP server>
# SSL_CLIENT_NAME=DNS:<fully qualified hostname of Synology NAS>
#
# Otherwise, you can configure static IP addresses:
# SSL_SERVER_NAME=IP:<IP address of this KMIP server>
# SSL_CLIENT_NAME=IP:<IP address of Synology NAS>

# Common names for CA, server and client certificates
SSL_COMMON_NAME_CA="Private KMIP CA"
SSL_COMMON_NAME_SERVER="Private KMIP Server"
SSL_COMMON_NAME_CLIENT="Private KMIP Client"

# Country name for CA, server and client certificates. Set to two letter
# country code, for example US or DE
SSL_COUNTRY_NAME="DE"

# State or province name for CA, server and client certificates
SSL_STATE_OR_PROVINCE="Berlin"

# Locality (city/town) name for CA, server and client certificates
SSL_LOCALITY="Berlin"

# Organization name for CA, server and client certificates
SSL_ORGANIZATION="Private SAN"

# Organizational unit name for CA, server and client certificates
SSL_ORGANIZATIONAL_UNIT="PKI"

# --- Ende: Übernahme der settings aus config.sh

mkdir -p ./certs

# Erzeugen der neuen Keys mit openssl (v3.1.1 INSIDE docker)

if [ ! -f ./certs/ca.key ]; then
    echo "=== Generating private CA RSA key"
    openssl genrsa -out ./certs/ca.key $CA_KEY_SIZE
fi

if [ ! -f ./certs/ca.crt ]; then
    echo "=== Generating private CA certificate"
    openssl req -nodes -x509 -days $CA_LIFETIME \
        -key ./certs/ca.key \
        -out ./certs/ca.crt \
        -subj "/C=$SSL_COUNTRY_NAME/ST=$SSL_STATE_OR_PROVINCE/L=$SSL_LOCALITY/O=$SSL_ORGANIZATION/OU=$SSL_ORGANIZATIONAL_UNIT/CN=$SSL_COMMON_NAME_CA"
fi

if [ ! -f ./certs/server.key ]; then
    echo "=== Generating server RSA key"
    openssl genrsa -out ./certs/server.key $SERVER_KEY_SIZE
fi

if [ ! -f ./certs/server.crt ]; then
    echo "=== Generating server certificate"
    openssl req -key ./certs/server.key -new \
        -out ./certs/server.csr \
        -subj "/C=$SSL_COUNTRY_NAME/ST=$SSL_STATE_OR_PROVINCE/L=$SSL_LOCALITY/O=$SSL_ORGANIZATION/OU=$SSL_ORGANIZATIONAL_UNIT/CN=$SSL_COMMON_NAME_SERVER" \
        -addext "subjectAltName = $SSL_SERVER_NAME" \
        -addext "extendedKeyUsage = serverAuth, clientAuth"
    openssl x509 -req -CA ./certs/ca.crt \
        -CAkey ./certs/ca.key \
        -in ./certs/server.csr \
        -out ./certs/server.crt \
        -days $SERVER_CERT_LIFETIME -CAcreateserial -copy_extensions copy
fi

if [ ! -f ./certs/client.key ]; then
    echo "=== Generating client RSA key"
    openssl genrsa -out ./certs/client.key $CLIENT_KEY_SIZE
fi

if [ ! -f ./certs/client.crt ]; then
    echo "=== Generating client certificate"
    openssl req -key ./certs/client.key -new \
        -out ./certs/client.csr \
        -subj "/C=$SSL_COUNTRY_NAME/ST=$SSL_STATE_OR_PROVINCE/L=$SSL_LOCALITY/O=$SSL_ORGANIZATION/OU=$SSL_ORGANIZATIONAL_UNIT/CN=$SSL_COMMON_NAME_CLIENT" \
        -addext "subjectAltName = $SSL_CLIENT_NAME" \
        -addext "extendedKeyUsage = serverAuth, clientAuth"
    openssl x509 -req -CA ./certs/ca.crt \
        -CAkey ./certs/ca.key \
        -in ./certs/client.csr \
        -out ./certs/client.crt \
        -days $CLIENT_CERT_LIFETIME -CAcreateserial -copy_extensions copy
fi

ls -l ./certs

Dabei die beiden Variablen SSL_COMMON_NAME_SERVER und SSL_COMMON_NAME_CLIENT so setzen, dass sie zu dem eigenen Setup passen. Speichern des modifizierten Skripts unter einem sprechenden Namen, z.B. "create-certs.sh".

Step 3:
Jetzt kopieren wir das Skript in das Verzeichnis /tmp in den docker-Container:

docker cp ./create-certs.sh <CONTAINER ID>:/tmp/create-certs.sh
Successfully copied 6.14kB to <CONTAINER ID>:/tmp/create-certs.sh

Step 4:
und starten im Anschluß eine Shell im docker-Container:

docker exec -it <CONTAINER ID> /bin/sh

Im docker-Container wechseln wir jetzt in das Verzeichnis /tmp und machen das Skript ausführbar:

/ # cd /tmp
/tmp # chmod 700 create-certs.sh

Step 5:
Nun können wir das Skript ausführen und erzeugen damit neue Keys/Zertifikate:

Spoiler: Erzeugen der neuen Keys/Zertifikate

/tmp # ./create-certs.sh
=== Generating private CA RSA key
=== Generating private CA certificate
=== Generating server RSA key
=== Generating server certificate
Certificate request self-signature ok
subject=C = DE, ST = Berlin, L = Berlin, O = Private SAN, OU = PKI, CN = Private KMIP Server
=== Generating client RSA key
=== Generating client certificate
Certificate request self-signature ok
subject=C = DE, ST = Berlin, L = Berlin, O = Private SAN, OU = PKI, CN = Private KMIP Client
total 36
-rw-r--r--    1 root     root          1354 Apr 18 16:42 ca.crt
-rw-------    1 root     root          1704 Apr 18 16:42 ca.key
-rw-r--r--    1 root     root            41 Apr 18 16:42 ca.srl
-rw-r--r--    1 root     root          1403 Apr 18 16:42 client.crt
-rw-r--r--    1 root     root          1106 Apr 18 16:42 client.csr
-rw-------    1 root     root          1708 Apr 18 16:42 client.key
-rw-r--r--    1 root     root          1403 Apr 18 16:42 server.crt
-rw-r--r--    1 root     root          1106 Apr 18 16:42 server.csr
-rw-------    1 root     root          1704 Apr 18 16:42 server.key

Die neuen Keys/Zertifikate werden im Verzeichnis /tmp/certs im docker-Container erzeugt und abgelegt.

Step 5:
Jetzt verlassen wir den docker-Container und es geht auf dem Host weiter. Das Verzeichnis mit den eben erzeugten neuen Keys/Zertifikaten wird jetzt auf den Host (Raspberry) nach /tmp kopiert.

Spoiler: Kopieren der neuen Keys/Zertifikate auf den Host

[pi@raspi1:/] $cd /tmp
[pi@raspi1:/tmp] $ docker exec <CONTAINER ID> /bin/sh -c 'cd /tmp; tar -cf - certs/' | tar -xvf -
certs/
certs/server.csr
certs/ca.srl
certs/server.key
certs/ca.crt
certs/client.key
certs/client.crt
certs/server.crt
certs/ca.key
certs/client.csr
[pi@raspi1:/tmp] $

Step 6:
Austausch der Keys/Zertifikate im docker-Verzeichnis auf dem Raspberry:

Spoiler: Austausch der Keys/Zertifikate

Stop und remove des docker-Containers

[pi@raspi1:/tmp] $ cd /srv/docker/kmip-server-dsm
[pi@raspi1:/srv/docker/kmip-server-dsm] $ docker compose down

Sichern des Verzeichnis mit den alten Keys/Zertifikaten:

[pi@raspi1:/srv/docker/kmip-server-dsm] $ mv certs certs.bak

Kopieren des Verzeichnis mit den "neuen" Keys/Zertifikaten von /tmp in das docker-Verzeichnis:

[pi@raspi1:/srv/docker/kmip-server-dsm] $ mv /tmp/certs .

Ändern von Besitzer und Gruppe für das neue certs-Verzeichnis:

[pi@raspi1:/srv/docker/kmip-server-dsm] $ sudo chown -R root:root certs

Step 7:
Nun kann der docker-Container wieder neu erzeugt und gestartet werden und verwendet ab sofort die neuen Keys/Zertifikate:

[pi@raspi1:/srv/docker/kmip-server-dsm] $ docker compose up -d

Last but not least können jetzt die neuen Keys/Zertifikate im DSM importiert werden, eine Anleitung hierfür erspare ich mir.

Hinweis: Den Umweg über den docker-Container habe ich gewählt, da für die Erstellung der Keys OpenSSL 3.1.1 benötigt wird, auf meinem Raspberry unter bullseye aber nur OpenSSL 1.1.1w installiert ist, und mir der Aufwand für die Installation von OpenSSL 3.1.1 nicht gerechtfertigt erschien. Und wie bereits eingangs erwähnt: es gibt mit Sicherheit elegantere Methoden, aber diese hier funktioniert und reicht für mich vollkommen aus.