PKI-Lab mit Root-CA und Teilnehmer-CA: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 1: Zeile 1:
 
=PKI mit Root-CA und Sub-CA (Beispiel it213)=
 
=PKI mit Root-CA und Sub-CA (Beispiel it213)=
  
In diesem Beispiel wird eine einfache PKI aufgebaut.
+
In diesem Beispiel wird eine einfache PKI aufgebaut.
Der Trainer betreibt eine Root-CA.
+
 
Die Teilnehmer erzeugen eine Sub-CA, die von der Root-CA signiert wird.
+
Der Trainer betreibt eine Root-CA.
 +
 
 +
Die Teilnehmer erzeugen eine Sub-CA, die von der Root-CA signiert wird.
 +
 
 
Mit dieser Sub-CA werden anschließend Server-Zertifikate signiert.
 
Mit dieser Sub-CA werden anschließend Server-Zertifikate signiert.
 +
  
 
==Root-CA erstellen==
 
==Root-CA erstellen==
 +
 
Die Root-CA ist der Vertrauensanker der PKI und ist selbstsigniert.
 
Die Root-CA ist der Vertrauensanker der PKI und ist selbstsigniert.
  
Zeile 17: Zeile 22:
  
 
==Root-CA auf Clients installieren==
 
==Root-CA auf Clients installieren==
 +
 
Damit Clients den Zertifikaten vertrauen, muss die Root-CA im Trust-Store installiert werden.
 
Damit Clients den Zertifikaten vertrauen, muss die Root-CA im Trust-Store installiert werden.
 +
  
 
===Debian===
 
===Debian===
*cp ca.crt /usr/local/share/ca-certificates/
 
  
 
Das Root-Zertifikat wird in den lokalen CA-Speicher kopiert.
 
Das Root-Zertifikat wird in den lokalen CA-Speicher kopiert.
  
*update-ca-certificates
+
*cp ca.crt /usr/local/share/ca-certificates/
  
 
Der Trust-Store wird aktualisiert.
 
Der Trust-Store wird aktualisiert.
 +
 +
*update-ca-certificates
  
  
 
===Rocky / RHEL===
 
===Rocky / RHEL===
*cp ca.crt /etc/pki/ca-trust/source/anchors/
 
  
 
Das Root-Zertifikat wird in den Anchor-Store kopiert.
 
Das Root-Zertifikat wird in den Anchor-Store kopiert.
  
*update-ca-trust extract
+
*cp ca.crt /etc/pki/ca-trust/source/anchors/
  
 
Der System Trust Store wird neu erzeugt.
 
Der System Trust Store wird neu erzeugt.
 +
 +
*update-ca-trust extract
  
  
 
==Sub-CA Request erzeugen (Beispiel it213)==
 
==Sub-CA Request erzeugen (Beispiel it213)==
 +
 
Der Teilnehmer erzeugt einen privaten Schlüssel und eine Certificate Signing Request für seine CA.
 
Der Teilnehmer erzeugt einen privaten Schlüssel und eine Certificate Signing Request für seine CA.
  
Zeile 46: Zeile 56:
  
 
==Sub-CA durch Root signieren==
 
==Sub-CA durch Root signieren==
*Die Root-CA signiert die Teilnehmer-CA. Dadurch entsteht die Zertifikatskette.
+
 
 +
Die Root-CA signiert die Teilnehmer-CA. Dadurch entsteht die Zertifikatskette.
  
 
*openssl x509 -req -in it213-ca.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out it213-ca.crt -days 1460 -extfile <(printf "basicConstraints=CA:TRUE\nkeyUsage=keyCertSign,cRLSign")
 
*openssl x509 -req -in it213-ca.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out it213-ca.crt -days 1460 -extfile <(printf "basicConstraints=CA:TRUE\nkeyUsage=keyCertSign,cRLSign")
  
*Das signierte CA-Zertifikat kann kontrolliert werden.
+
Das signierte CA-Zertifikat kann kontrolliert werden.
  
 
*openssl x509 -in it213-ca.crt -text -noout
 
*openssl x509 -in it213-ca.crt -text -noout
 +
  
 
==Hinweis zum privaten Schlüssel==
 
==Hinweis zum privaten Schlüssel==
Der private Schlüssel der CA wird nur zum Signieren von Zertifikaten benötigt.
+
 
 +
Der private Schlüssel der CA wird nur zum Signieren von Zertifikaten benötigt.
 +
 
 
Zum Prüfen der Zertifikatskette werden nur die öffentlichen Zertifikate verwendet.
 
Zum Prüfen der Zertifikatskette werden nur die öffentlichen Zertifikate verwendet.
  
 
Beispiel:
 
Beispiel:
  
web.crt
+
<pre>
it213-ca.crt
+
www.it213.int.crt
 +
it213-ca.crt
 
ca.crt
 
ca.crt
 +
</pre>
  
 
Die Prüfung erfolgt über die Signaturen der Zertifikate.
 
Die Prüfung erfolgt über die Signaturen der Zertifikate.
Zeile 68: Zeile 84:
  
 
==Server-Schlüssel und CSR erzeugen==
 
==Server-Schlüssel und CSR erzeugen==
 +
 
Der Teilnehmer erzeugt einen Schlüssel und eine CSR für seinen Server.
 
Der Teilnehmer erzeugt einen Schlüssel und eine CSR für seinen Server.
  
*openssl req -new -newkey rsa:2048 -nodes -keyout www.it213.lab.key -out www.it213.lab.csr -subj "/CN=www.it213.lab"
+
*openssl req -new -newkey rsa:2048 -nodes -keyout www.it213.int.key -out www.it213.int.csr -subj "/CN=www.it213.int"
 +
 
  
 
==Server-Zertifikat signieren==
 
==Server-Zertifikat signieren==
 +
 
Die Sub-CA signiert das Server-Zertifikat.
 
Die Sub-CA signiert das Server-Zertifikat.
  
*openssl x509 -req -in web.csr -CA it213-ca.crt -CAkey it213-ca.key -CAcreateserial -out web.crt -days 365
+
*openssl x509 -req -in www.it213.int.csr -CA it213-ca.crt -CAkey it213-ca.key -CAcreateserial -out www.it213.int.crt -days 365
  
 
Das Server-Zertifikat kann kontrolliert werden.
 
Das Server-Zertifikat kann kontrolliert werden.
  
*openssl x509 -in web.crt -text -noout
+
*openssl x509 -in www.it213.int.crt -text -noout
  
  
 
==Fullchain erstellen==
 
==Fullchain erstellen==
 +
 
Damit Clients die Zertifikatskette aufbauen können, muss der Server die Intermediate-CA mitliefern.
 
Damit Clients die Zertifikatskette aufbauen können, muss der Server die Intermediate-CA mitliefern.
  
 
Dazu wird eine Fullchain-Datei erstellt.
 
Dazu wird eine Fullchain-Datei erstellt.
  
*cat web.crt it213-ca.crt > fullchain.pem
+
*cat www.it213.int.crt it213-ca.crt > fullchain.pem
  
Die Reihenfolge ist wichtig:
+
Die Reihenfolge ist wichtig.
  
web.crt
+
<pre>
 +
www.it213.int.crt
 
it213-ca.crt
 
it213-ca.crt
 +
</pre>
  
  
 
==Zertifikatskette prüfen==
 
==Zertifikatskette prüfen==
 +
 
Die komplette Zertifikatskette kann mit OpenSSL überprüft werden.
 
Die komplette Zertifikatskette kann mit OpenSSL überprüft werden.
  
*openssl verify -CAfile ca.crt -untrusted it213-ca.crt web.crt
+
*openssl verify -CAfile ca.crt -untrusted it213-ca.crt www.it213.int.crt
  
  
 
==PKI-Struktur==
 
==PKI-Struktur==
 +
 +
<pre>
 
Kit Root CA
 
Kit Root CA
 
  └── it213-ca
 
  └── it213-ca
       └── web.it213.lab
+
       └── www.it213.int
 +
</pre>
 +
 
 +
Der Client kennt die Root-CA aus dem Trust-Store.
 +
 
 +
Der Server liefert beim TLS-Handshake das Server-Zertifikat und die Sub-CA.
  
Der Client kennt die Root-CA aus dem Trust-Store. 
 
Der Server liefert beim TLS-Handshake das Server-Zertifikat und die Sub-CA. 
 
 
Der Client kann damit die vollständige Zertifikatskette prüfen.
 
Der Client kann damit die vollständige Zertifikatskette prüfen.

Version vom 14. März 2026, 11:25 Uhr

PKI mit Root-CA und Sub-CA (Beispiel it213)

In diesem Beispiel wird eine einfache PKI aufgebaut.

Der Trainer betreibt eine Root-CA.

Die Teilnehmer erzeugen eine Sub-CA, die von der Root-CA signiert wird.

Mit dieser Sub-CA werden anschließend Server-Zertifikate signiert.


Root-CA erstellen

Die Root-CA ist der Vertrauensanker der PKI und ist selbstsigniert.

  • openssl req -new -x509 -newkey rsa:4096 -nodes -keyout ca.key -out ca.crt -days 3650 -subj "/CN=Kit Root CA"

Das Zertifikat kann anschließend kontrolliert werden.

  • openssl x509 -in ca.crt -text -noout


Root-CA auf Clients installieren

Damit Clients den Zertifikaten vertrauen, muss die Root-CA im Trust-Store installiert werden.


Debian

Das Root-Zertifikat wird in den lokalen CA-Speicher kopiert.

  • cp ca.crt /usr/local/share/ca-certificates/

Der Trust-Store wird aktualisiert.

  • update-ca-certificates


Rocky / RHEL

Das Root-Zertifikat wird in den Anchor-Store kopiert.

  • cp ca.crt /etc/pki/ca-trust/source/anchors/

Der System Trust Store wird neu erzeugt.

  • update-ca-trust extract


Sub-CA Request erzeugen (Beispiel it213)

Der Teilnehmer erzeugt einen privaten Schlüssel und eine Certificate Signing Request für seine CA.

  • openssl req -new -newkey rsa:4096 -nodes -keyout it213-ca.key -out it213-ca.csr -subj "/CN=it213 Lab CA"


Sub-CA durch Root signieren

Die Root-CA signiert die Teilnehmer-CA. Dadurch entsteht die Zertifikatskette.

  • openssl x509 -req -in it213-ca.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out it213-ca.crt -days 1460 -extfile <(printf "basicConstraints=CA:TRUE\nkeyUsage=keyCertSign,cRLSign")

Das signierte CA-Zertifikat kann kontrolliert werden.

  • openssl x509 -in it213-ca.crt -text -noout


Hinweis zum privaten Schlüssel

Der private Schlüssel der CA wird nur zum Signieren von Zertifikaten benötigt.

Zum Prüfen der Zertifikatskette werden nur die öffentlichen Zertifikate verwendet.

Beispiel:

www.it213.int.crt
it213-ca.crt
ca.crt

Die Prüfung erfolgt über die Signaturen der Zertifikate.


Server-Schlüssel und CSR erzeugen

Der Teilnehmer erzeugt einen Schlüssel und eine CSR für seinen Server.

  • openssl req -new -newkey rsa:2048 -nodes -keyout www.it213.int.key -out www.it213.int.csr -subj "/CN=www.it213.int"


Server-Zertifikat signieren

Die Sub-CA signiert das Server-Zertifikat.

  • openssl x509 -req -in www.it213.int.csr -CA it213-ca.crt -CAkey it213-ca.key -CAcreateserial -out www.it213.int.crt -days 365

Das Server-Zertifikat kann kontrolliert werden.

  • openssl x509 -in www.it213.int.crt -text -noout


Fullchain erstellen

Damit Clients die Zertifikatskette aufbauen können, muss der Server die Intermediate-CA mitliefern.

Dazu wird eine Fullchain-Datei erstellt.

  • cat www.it213.int.crt it213-ca.crt > fullchain.pem

Die Reihenfolge ist wichtig.

www.it213.int.crt
it213-ca.crt


Zertifikatskette prüfen

Die komplette Zertifikatskette kann mit OpenSSL überprüft werden.

  • openssl verify -CAfile ca.crt -untrusted it213-ca.crt www.it213.int.crt


PKI-Struktur

Kit Root CA
 └── it213-ca
      └── www.it213.int

Der Client kennt die Root-CA aus dem Trust-Store.

Der Server liefert beim TLS-Handshake das Server-Zertifikat und die Sub-CA.

Der Client kann damit die vollständige Zertifikatskette prüfen.