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:
openssl genrsa -out myServer.key 2048
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.
openssl req -new -nodes -key myServer.key -out myServer.csr
Uns werden jetzt wieder Fragen zu den Distinguished Name Feldern gefragt, bis auf Common Name können wir auch hier fast alles leer lassen.
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DarkMatterBytes
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:DarkMatterBytes Server Certificate
Email Address []:.
Jetzt haben wir zwei neue Dateien:
root@debian-vm:~/certs# ls -l
insgesamt 16
-rw-r--r-- 1 root root 1257 12. Aug 14:57 myCA.crt
-rw------- 1 root root 1704 12. Aug 14:56 myCA.key
-rw-r--r-- 1 root root 976 15. Aug 09:13 myServer.csr
-rw------- 1 root root 1704 15. Aug 09:12 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 = DarkMatterBytes, CN = DarkMatterBytes Server Certificate
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a8:7c:69:bd:8b:96:47:d6:83:29:05:af:bc:b7:
5c:11:ee:12:88:b7:f7:d7:04:93:e5:c5:47:90:5c:
99:a1:06:f0:0f:31:7c:c2:98:a7:08:df:19:b3:70:
3b:7c:62:23:70:df:83:6c:7e:dc:c3:32:37:e5:ef:
87:aa:b3:0b:b5:2c:fa:0f:dc:56:9f:ef:17:a6:11:
10:8d:14:7f:3a:c1:dd:9b:ed:5c:d4:56:ba:96:35:
7b:fe:ea:c0:ed:dc:4c:a8:b9:1d:27:25:ff:ae:46:
59:91:a9:70:da:38:5f:1d:75:e7:a2:bb:bb:92:e5:
26:1a:dd:20:b4:80:58:e7:d3:54:9b:a2:07:ff:93:
4b:d3:04:2b:b1:15:22:57:b6:cf:70:6a:04:a9:72:
52:82:7b:8d:c7:15:c3:4a:f8:91:4f:0d:01:7d:2e:
26:b1:9c:cd:c1:3d:2f:b7:03:69:dc:5b:aa:73:f6:
40:f3:77:a8:f1:37:b4:86:28:87:78:c6:eb:a6:f7:
c0:e9:79:f7:de:9f:fe:7f:71:e9:85:87:36:02:bf:
cf:4e:03:65:67:ad:df:57:ae:0d:15:5a:d3:09:5e:
6b:ec:3a:90:d2:64:1d:99:aa:2c:1b:a4:f6:1f:46:
a8:5a:75:e5:62:72:cf:1c:46:e6:77:d4:b3:c0:27:
05:31
Exponent: 65537 (0x10001)
Attributes:
(none)
Requested Extensions:
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
0f:e8:32:3e:3a:42:2e:6e:a5:ba:6e:3f:be:55:30:d4:95:7d:
09:df:85:30:13:f5:84:33:e6:36:11:e5:6a:de:3d:af:a0:58:
c6:ab:f3:d4:ec:08:f8:db:53:43:e2:27:d3:8f:4d:67:e8:2a:
28:4e:df:81:3f:e6:f3:44:59:63:0a:1f:1c:b4:2c:57:33:ee:
1c:c5:42:d7:a1:3a:ff:ed:28:2c:8f:7e:24:58:c9:2e:76:ff:
6f:19:17:b5:d2:26:ac:85:df:57:2c:8c:1d:54:13:7f:ee:32:
6b:fe:eb:a8:ad:07:24:80:6c:b3:9b:74:3f:4c:65:9d:db:48:
fd:03:c7:d0:a8:a4:06:32:d4:33:51:8f:b3:f1:63:aa:04:59:
0a:9c:d7:df:17:06:07:c2:63:87:8f:e5:d4:a6:b9:40:85:c3:
80:1a:e4:79:ce:c6:c4:09:84:ea:83:ad:fc:6f:9b:e7:c0:07:
33:92:7d:53:65:d4:42:11:78:c4:f3:ea:7f:a1:1c:cd:34:a6:
7c:f7:ce:03:b9:2e:35:74:ed:31:ce:e1:09:e1:f4:62:54:f3:
39:d4:f0:66:fc:e2:d4:e4:96:fa:dd:b5:3a:32:87:e0:fc:32:
bb:a6:da:0e:c3:15:00:4e:8e:9e:06:f2:0a:3d:00:cf:ef:36:
20:af:fc:0f
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.
Damit unser Zertifikat später von den Clients (z.B. Webbrowser) akzeptiert wird, brauchen wir noch die SAN-Extension.
Beispiel: Ein Zertifikat für example.com kann über SAN auch www.example.com oder shop.example.com abdecken. Ohne SAN gilt ein Zertifikat normalerweise nur für den Hauptnamen (Common Name, CN).
Ein SAN kann dabei auch eine IP-Adresse sein.
Früher reichte es, nur den Common Name (CN) anzugeben. Heute verlangen die meisten Zertifizierungsstellen (CAs) für SSL/TLS-Zertifikate, dass SANs im CSR enthalten sind, selbst wenn es nur ein einziger Name ist.
Wir erstellen eine extensions-Datei mit folgendem Inhalt:
nano myServer.ext
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = myServer.test # Wenn unser Server unter einer Domain erreichbar ist
IP.1 = 172.31.32.118 # Wenn unser Server unter einer IP erreichbar ist
Nun können wir den CSR mit unserem Root-CA Key signieren:
openssl x509 -req -in myServer.csr -CA myCA.crt -CAkey myCA.key -out myServer.crt -days 825 -sha256 -extfile myServer.ext
Wir prüfen nun das Server Zertifikat:
openssl x509 -in myServer.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
38:7d:fe:55:8c:b3:e0:38:d1:cd:2b:1c:25:c0:96:35:94:54:e4:50
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = DE, O = DarkMatterBytes, CN = DarkMatterBytes 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 = DarkMatterBytes, CN = DarkMatterBytes Server Certificate
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a8:7c:69:bd:8b:96:47:d6:83:29:05:af:bc:b7:
5c:11:ee:12:88:b7:f7:d7:04:93:e5:c5:47:90:5c:
99:a1:06:f0:0f:31:7c:c2:98:a7:08:df:19:b3:70:
3b:7c:62:23:70:df:83:6c:7e:dc:c3:32:37:e5:ef:
87:aa:b3:0b:b5:2c:fa:0f:dc:56:9f:ef:17:a6:11:
10:8d:14:7f:3a:c1:dd:9b:ed:5c:d4:56:ba:96:35:
7b:fe:ea:c0:ed:dc:4c:a8:b9:1d:27:25:ff:ae:46:
59:91:a9:70:da:38:5f:1d:75:e7:a2:bb:bb:92:e5:
26:1a:dd:20:b4:80:58:e7:d3:54:9b:a2:07:ff:93:
4b:d3:04:2b:b1:15:22:57:b6:cf:70:6a:04:a9:72:
52:82:7b:8d:c7:15:c3:4a:f8:91:4f:0d:01:7d:2e:
26:b1:9c:cd:c1:3d:2f:b7:03:69:dc:5b:aa:73:f6:
40:f3:77:a8:f1:37:b4:86:28:87:78:c6:eb:a6:f7:
c0:e9:79:f7:de:9f:fe:7f:71:e9:85:87:36:02:bf:
cf:4e:03:65:67:ad:df:57:ae:0d:15:5a:d3:09:5e:
6b:ec:3a:90:d2:64:1d:99:aa:2c:1b:a4:f6:1f:46:
a8:5a:75:e5:62:72:cf:1c:46:e6:77:d4:b3:c0:27:
05:31
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
44:F5:4B:2D:53:61:84:6F:67:63:1F:FE:7D:BC:4F:1C:31:82:B7:C5
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
X509v3 Subject Alternative Name:
DNS:myServer.test, IP Address:172.31.32.118
X509v3 Subject Key Identifier:
98:A3:7E:56:07:6D:44:26:E1:FD:7D:4C:C4:4F:67:E5:C7:3D:49:3F
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
b7:3f:82:86:d5:2e:e3:46:a5:9c:c6:0d:6c:37:fc:3b:7e:53:
1f:2c:cc:35:2e:bc:95:be:b6:aa:74:ac:ba:cf:74:df:ff:58:
b7:a3:1b:d4:3f:1a:1d:4a:c0:46:59:ec:48:a0:61:9c:15:09:
d4:29:84:b7:f7:6f:be:c5:25:c9:bc:af:3e:45:df:ad:1c:6e:
fd:94:fe:9e:43:e9:4d:ac:3f:3f:70:a2:af:cf:ff:6d:55:e4:
75:d2:2d:c4:a0:2d:34:a4:e7:41:46:9c:91:32:f8:bf:cf:0e:
46:fb:a0:a9:23:9a:34:6a:eb:f7:1a:f3:0f:e0:21:be:ec:7c:
b1:62:00:f4:8c:54:f0:d8:f3:c8:bc:16:ff:69:04:63:df:26:
10:86:55:a4:0b:fe:d9:e1:0e:1a:7a:d2:93:1c:8c:6d:37:a8:
57:3f:78:e0:15:51:34:1f:db:0d:a1:29:fa:b0:55:59:db:79:
e9:83:0e:b8:31:25:2b:56:51:0c:8d:35:2f:b9:d2:66:ba:d3:
ea:da:89:70:62:d8:0e:54:ef:97:c1:f2:61:e7:8d:e5:84:db:
06:0d:0b:11:f8:4b:a7:7b:0b:49:a3:12:97:9c:58:93:a8:9c:
22:fc:0d:28:f4:97:39:8c:35:a3:f7:bc:0f:13:60:55:bc:13:
d1:d8:96:ff
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: Bewahre den Root-CA-Schlüssel besonders sicher auf - wer Zugriff darauf hat, kann Zertifikate ausstellen, die von allen vertrauenswürdigen Systemen akzeptiert werden.