X.509 Server Zertifikate

Einleitung

Nachdem wir im vorherigen Schritt unsere eigene Root-CA erstellt haben, können wir diese nun nutzen, um eigene Zertifikate für Server oder Clients auszustellen. Der Ablauf ist dabei immer gleich:

• Schlüssel und Zertifikatsanfrage (CSR) für den gewünschten Server oder Client erstellen

• CSR mit unserer Root-CA signieren

• Signiertes Zertifikat auf dem Zielsystem einrichten

So entsteht eine Vertrauenskette: Das ausgestellte Zertifikat wird von unserer Root-CA bestätigt – und jedes Gerät, das unserer Root-CA vertraut, akzeptiert auch dieses neue Zertifikat.

Vorbereitung

Server Schlüssel erstellen

Wir erstellen wieder einen privaten Schlüssel, dieses Mal für den Server:

entweder einen RSA Schlüssel:

openssl genrsa -out myServer.key 2048

oder einen modernen EC Schlüssel:

openssl ecparam -genkey -name prime256v1 -out myServer.key

CSR erstellen

Ein CSR (Certificate Signing Request) ist eine Datei, die alle wichtigen Informationen für ein Zertifikat enthält , z. B. den öffentlichen Schlüssel, den Common Name (Domainname) und optionale Angaben wie Organisation oder Standort. Sie wird mit dem privaten Schlüssel erzeugt und anschließend an eine Zertifizierungsstelle (in unserem Fall unsere eigene Root-CA) geschickt, um daraus ein signiertes Zertifikat zu erstellen.

Damit unser Zertifikat später von den Clients (z.B. Webbrowser) akzeptiert wird, brauchen wir noch die SAN-Extension.

Wir erstellen eine Konfig, die wir für das Erstellen des CSR verwenden.

nano myServer.conf

# =================================
# OpenSSL Server CSR Configuration
# =================================

[ req ]
default_md          = sha256       # Default message digest
distinguished_name  = req_dn       # Default DN template
string_mask         = utf8only     # UTF-8 encoding
prompt              = no           # Non-interactive mode
req_extensions      = req_ext_SAN  # SAN Extension

[ req_dn ]
C                         = DE
# ST                        = Rheinland Pfalz
# L                         = Mainz
O                         = Meine fiktive Organisation
OU                        = Web
CN                        = Some Service

# Das gleiche, nur mit langen Key-Namen
# [ req_dn ]
# countryName               = DE
# stateOrProvinceName       = Rheinland Pfalz
# localityName              = Mainz
# organizationName          = Meine fiktive Organisation
# organizationalUnitName    = Web
# commonName                = Some Service

[ req_ext_SAN ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = myServer.test
IP.1 = 192.168.1.1

Mit dieser Konfig können wir nun den CSR erstellen:

openssl req -new -config myServer.conf -key myServer.key -out myServer.csr

Jetzt haben wir drei neue Dateien:

root@debian-vm:~/certs# ls -l
insgesamt 24
-rw-r--r-- 1 root root 1184 12. Aug 14:56 myCA.conf
-rw-r--r-- 1 root root  737 12. Aug 14:57 myCA.crt
-rw------- 1 root root  302 12. Aug 14:55 myCA.key
-rw-r--r-- 1 root root 1051 15. Aug 11:18 myServer.conf
-rw-r--r-- 1 root root  513 15. Aug 11:20 myServer.csr
-rw------- 1 root root  302 15. Aug 11:17 myServer.key

Wir können unseren Server CSR überprüfen:

openssl req -in myServer.csr -noout -text

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C = DE, O = Meine fiktive Organisation, OU = Web, CN = Some Service
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:dd:ef:80:20:8d:05:ee:6b:3e:f2:a9:d3:60:cb:
                    6a:86:0b:02:04:7b:61:65:0d:ce:8f:fc:b2:a3:e0:
                    ff:37:5b:89:dd:50:89:3c:e7:9f:95:80:90:9e:03:
                    2d:c6:8c:9f:7f:50:81:3c:11:f6:2b:47:c9:9c:19:
                    2c:d6:c0:5d:63
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        Attributes:
            Requested Extensions:
                X509v3 Subject Alternative Name:
                    DNS:myServer.test, IP Address:192.168.1.1
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:45:02:21:00:e9:f5:b3:51:ad:c0:6b:7e:33:96:ab:a3:a6:
        42:5c:bc:f9:f7:7b:59:89:01:1b:e1:6e:85:af:ec:6a:28:dc:
        5c:02:20:25:81:d7:5c:f0:f1:0d:fa:00:99:b2:43:c5:9d:62:
        c6:a0:60:8d:08:07:3a:fb:5b:07:4e:db:bb:ba:f6:4b:ee

CSR signieren

Mit dem erstellten CSR (Certificate Signing Request) würden wir normalerweise zu einer öffentlichen Zertifizierungsstelle (z.B. Let's Encrypt) gehen, um ein signiertes Zertifikat zu erhalten. In unserem Fall nutzen wir jedoch unsere eigene Root-CA, um den CSR zu signieren und so ein vertrauenswürdiges Zertifikat für unseren Server oder Client auszustellen.

Wir erstellen eine Konfig-Datei für den Signier-Vorgang mit folgendem Inhalt:

nano ca-sign.conf

# =================================
# OpenSSL CA Signing Configuration
# =================================

[ req ]
default_md          = sha256     # Default message digest
string_mask         = utf8only   # UTF-8 encoding
prompt              = no         # Non-interactive mode
x509_extensions     = v3_x509    # when req -x509 is in use

[ v3_x509 ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

Nun können wir den CSR mit unserem Root-CA Key signieren, wir übernehmen dabei die Extensions aus dem CSR:

openssl req -x509 -config ca-sign.conf -CA myCA.crt -CAkey myCA.key -copy_extensions copy -days 825 -in myServer.csr -out myServer.crt

Wir haben jetzt 8 Dateien:

root@debian-vm:~/certs# ls -l
insgesamt 32
-rw-r--r-- 1 root root  529 15. Aug 11:22 ca-sign.conf
-rw-r--r-- 1 root root 1184 12. Aug 14:56 myCA.conf
-rw-r--r-- 1 root root  737 12. Aug 14:57 myCA.crt
-rw------- 1 root root  302 12. Aug 14:55 myCA.key
-rw-r--r-- 1 root root 1051 15. Aug 11:18 myServer.conf
-rw-r--r-- 1 root root  818 15. Aug 11:25 myServer.crt
-rw-r--r-- 1 root root  513 15. Aug 11:20 myServer.csr
-rw------- 1 root root  302 15. Aug 11:17 myServer.key

• myCA.*

  Siehe Eigene X.509 Root-CA erstellen (selbstsigniert)

• ca-sign.conf

  Wird verwendet, um während des Signierens weitere Extensions an das Zertifikat zu hängen.

• myServer.conf

  Die Konfiguration für einen CSR, gedacht für einen Webserver oder eine andere Anwendung.

• myServer.csr

  Der fertige CSR, der an eine CA geschickt werden kann, um dort ein Zertifikat zu erstellen.

• myServer.key

  Der private key für den Webserver

• myServer.crt

  Das CA-signierte Zertifikat für den Webserver

Wir prüfen nun das Server Zertifikat:

openssl x509 -in myServer.crt -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            11:9f:ae:ea:b5:9a:ed:05:51:df:5e:30:de:13:ac:a1:c8:ac:5d:4a
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = DE, O = Meine fiktive Organisation, CN = My Root CA
        Validity
            Not Before: Aug 15 08:15:52 2025 GMT
            Not After : Nov 18 08:15:52 2027 GMT
        Subject: C = DE, O = Meine fiktive Organisation, OU = Web, CN = Some Service
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:dd:ef:80:20:8d:05:ee:6b:3e:f2:a9:d3:60:cb:
                    6a:86:0b:02:04:7b:61:65:0d:ce:8f:fc:b2:a3:e0:
                    ff:37:5b:89:dd:50:89:3c:e7:9f:95:80:90:9e:03:
                    2d:c6:8c:9f:7f:50:81:3c:11:f6:2b:47:c9:9c:19:
                    2c:d6:c0:5d:63
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:myServer.test, IP Address:192.168.1.1
            X509v3 Subject Key Identifier:
                A5:A9:CD:A1:99:A9:EB:C2:BB:4C:C3:F3:BD:C8:48:52:B8:EC:D8:42
            X509v3 Authority Key Identifier:
                59:0D:28:CB:78:4A:42:33:E5:09:1B:6F:7C:9E:2D:2B:27:A1:B7:69
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:46:02:21:00:c2:c1:7c:d8:e9:9f:fb:c2:af:ab:c7:93:2b:
        4b:a7:50:61:cf:4d:a1:2a:c1:d8:29:d5:c8:2d:3e:a6:04:76:
        01:02:21:00:bf:74:38:99:c1:56:b7:f0:9f:2c:59:bf:ee:98:
        f2:87:3b:c8:b6:0a:bf:ad:d3:1e:a7:5d:4c:9a:00:8f:e3:6b

Wie zu erkennen ist, sind Issuer und Subjekt nicht mehr die gleiche Entität. Das Server Zertifikat wurde von unserer Root-CA signiert.

Server Zertifikat einsetzen

Die beiden Dateien

• myServer.crt
• myServer.key

können wir jetzt verwenden, um die Kommunikation eines Servers (z.B. nginx oder mosquitto) über TLS abzusichern.

Beispielhafte Konfiguration:

Nginx (Webserver)

server {
        server_name myServer.test;
        listen 443 ssl;
        ssl_certificate /etc/nginx/ssl/myServer.crt;
        ssl_certificate_key /etc/nginx/ssl/myServer.key;
        ...
}

Mosquitto (MQTT Broker)

listener 8883
certfile /etc/mosquitto/certs/myServer.crt
keyfile /etc/mosquitto/certs/myServer.key
...

Zusammenfassung

• Wir haben eine eigene Root-CA erstellt, damit eigene Server- und Client-Zertifikate signiert werden können.

• Die ausgestellten Zertifikate sind vertrauenswürdig für alle Systeme, auf denen unsere Root-CA installiert ist.

• Private Schlüssel sollten in der Praxis immer auf dem Zielsystem erzeugt werden – nur so bleibt die Sicherheit gewährleistet.

• Mit der eigenen CA lassen sich Test-Umgebungen, interne Dienste oder private Netzwerke zuverlässig absichern, ohne externe Zertifikate zu nutzen.

Tipp: Der Root-CA-Schlüssel sollte immer besonders sicher aufbewahrt werden - wer Zugriff darauf hat, kann Zertifikate ausstellen, die von allen vertrauenswürdigen Systemen akzeptiert werden.

Siehe:

• https://docs.openssl.org/master/man1/openssl-req/
• https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/