Aktuelle Version vom 3. Juni 2026, 14:27 Uhr

Schaubild

[Bearbeiten]

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

Firefox / Chrome / Mozilla

Müssen getrennt importiert werden.

Sub-CA Request erzeugen (Beispiel it213)

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

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

Der Certificate Signing Request muss nun zur Zertifizierungsstelle

http://dnsgw.int

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

Die Zertifikate können nun hier runtergeladen werden

http://dnsgw.int/uploads

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

Variable setzen

CA=it213-ca
FQDN=www.it213.int

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

Erstellen

openssl req -new -newkey rsa:2048 -nodes -keyout $FQDN.key -out $FQDN.csr -subj "/CN=$FQDN"

Anzeigen

openssl req -in $FQDN.csr -text -noout

Server-Zertifikat signieren

Die Sub-CA signiert das Server-Zertifikat und fügt einen Subject Alternative Name hinzu.

Signieren

openssl x509 -req -in $FQDN.csr -CA $CA.crt -CAkey $CA.key -CAcreateserial -out $FQDN.crt -days 365 -extfile <(printf "subjectAltName=DNS:$FQDN")

Anzeigen

openssl x509 -in $FQDN.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 $FQDN.crt $CA.crt > $FQDN-fullchain.pem

Die Reihenfolge ist wichtig.

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

Zum Ziel kopieren

scp $FQDN-fullchain.pem $FQDN.key kit@$FQDN:

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.

Troubleshooting: OpenSSL & PKI Fehler

Fehlermeldung / Symptom	Mögliche Ursache	Lösung
"Self-signed certificate in certificate chain"	Der Client vertraut der Root-CA nicht oder die Root-CA wurde nicht im Trust-Store installiert.	Prüfen, ob update-ca-certificates (Debian) oder update-ca-trust (Rocky) ausgeführt wurde. Browser ggf. neu starten.
"Depth lookup: unable to get local issuer certificate"	Die Intermediate-CA (Sub-CA) fehlt in der Kette, die der Server ausliefert.	Prüfen, ob die Datei fullchain.pem korrekt erstellt wurde (Reihenfolge!) und im Webserver (SSLCertificateFile / ssl_certificate) eingebunden ist.
"Certificate is not valid for 'xyz.int'"	Der Subject Alternative Name (SAN) fehlt oder ist falsch geschrieben.	Zertifikat prüfen mit: openssl x509 -in cert.crt -text -> Suche nach "X509v3 Subject Alternative Name".
"Verification error: certificate has expired"	Systemzeit auf Server oder Client ist falsch (häufig bei VMs nach Suspend).	Datum/Uhrzeit mit dem Befehl date prüfen und ggf. per NTP synchronisieren.
"Modulus mismatch"	Der private Schlüssel passt kryptografisch nicht zum vorliegenden Zertifikat.	Vergleichen der MD5-Hashes beider Dateien (siehe unten unter "Nützliche Befehle").
"CA:FALSE" bei der Sub-CA	Die Sub-CA wurde ohne die Extension basicConstraints=CA:TRUE signiert.	Die Sub-CA ist nicht berechtigt, weitere Zertifikate zu signieren. Sub-CA mit den richtigen Extensions neu erstellen.

Nützliche Prüfbefehle für die Administration

Modulus-Check (Passen Key und CRT zusammen?)

Um sicherzustellen, dass ein Zertifikat zu einem Private Key gehört, müssen die Modulus-Hashes identisch sein:

openssl x509 -noout -modulus -in www.it213.int.crt | openssl md5

openssl rsa -noout -modulus -in www.it213.int.key | openssl md5

TLS-Handshake live testen

Simuliert einen Verbindungsaufbau und zeigt die vom Server gesendete Zertifikatskette an:

openssl s_client -connect localhost:443 -showcerts

Zertifikatsinhalt schnell prüfen

openssl x509 -in fullchain.pem -text -noout

Python Webserver mit SSL/TL

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