1. Ziel

Ein kompromittiertes Zertifikat wird widerrufen, Ersatz wird erzeugt und die Kommunikationsspur dokumentiert.

Dieses Dokument ergänzt das Haupt-README um fachliche Einordnung, Reviewfragen und Betriebsbezug. Es ist keine öffentliche CA-Betriebsanleitung, sondern ein reproduzierbares Lern- und Analysebeispiel.

2. Was gemacht wird

Das Beispiel wird lokal ausgeführt, erzeugt nur temporäre Artefakte unter work/ und dokumentiert den Nachweis unter work/evidence/. Je nach Thema werden Root, Intermediate, CSR, Serverzertifikat, Clientzertifikat, CRL, Widerruf oder ein Automatisierungsmodell erstellt.

Die Arbeitsschritte sind bewusst klein gehalten:

1. Konfigurationsdateien lesen.
2. Skript ausführen.
3. Evidence prüfen.
4. OpenSSL-Ausgaben interpretieren.
5. Fehlerfall oder Betriebsfrage diskutieren.
6. Cleanup und Schutz privater Schlüssel bestätigen.

3. Warum es gemacht wird

PKI-Fehler sind selten reine Syntaxfehler. Häufig ist ein Zertifikat technisch erzeugt, aber fachlich falsch: falscher Issuer, falscher SAN, zu lange Gültigkeit, fehlende Key Usage, unklare Chain, fehlender Widerruf oder ungeschützter privater Schlüssel. Dieses Beispiel zwingt deshalb jede technische Aktion in eine Review-Struktur.

4. Typische Kommandos

openssl version
openssl req -in work/csr/server.csr.pem -noout -subject -text 2>/dev/null || true
openssl x509 -in work/certs/server.crt.pem -noout -subject -issuer -serial -dates 2>/dev/null || true
openssl x509 -in work/certs/server.crt.pem -noout -text 2>/dev/null | sed -n '/X509v3 extensions:/,/Signature Algorithm/p' || true
openssl verify -CAfile work/root/certs/root.crt.pem -untrusted work/intermediate/certs/intermediate.crt.pem work/certs/server.crt.pem 2>/dev/null || true
find work/evidence -type f -maxdepth 2 -print 2>/dev/null | sort || true

5. Erfolg prüfen

• Das Skript endet ohne unerwarteten Fehler.
• Die Evidence-Dateien passen zum Thema des Beispiels.
• End-Entity-Zertifikate haben CA:FALSE.
• CA-Zertifikate haben CA:TRUE und passende Key Usage.
• Serverzertifikate enthalten SANs.
• Chain-Verifikation trennt Root als Trust Anchor und Intermediate als untrusted Chain-Zertifikat.
• Widerruf, OCSP oder CRL werden nicht behauptet, ohne Nachweis oder klare Lab-Grenze.

6. Typische Fehler

7. Sicherheitsaspekte

In echten PKIs müssen Root- und Intermediate-Schlüssel stärker geschützt werden als in diesem Lab. Root-Schlüssel werden typischerweise offline gehalten, Intermediate-Schlüssel werden durch HSM, strenge Dateirechte, Audit-Logs und getrennte Rollen geschützt. Für öffentlich vertrauenswürdige Zertifikate gelten zusätzliche Anforderungen, die in diesem Workshop nur eingeordnet, aber nicht simuliert werden.

8. Realistischer Einsatz

Dieses Muster lässt sich auf interne TLS-Zertifikate, mTLS zwischen Services, Kubernetes Ingress, Vault PKI, cert-manager, Smallstep, SPIFFE/SPIRE und klassische Unternehmens-PKIs übertragen. Entscheidend ist nicht das Tool, sondern die Beweisführung: wer signiert, wofür gilt das Zertifikat, wie wird Vertrauen verteilt, wann wird erneuert und wie wird widerrufen.

9. Workshop-Durchführung

1. Lernziel laut vorlesen und Scope begrenzen.
2. Repository-Dateien von Laufzeitartefakten unterscheiden.
3. OpenSSL-Konfiguration öffnen und relevante Sections markieren.
4. Private-Key-Pfade identifizieren.
5. CSR-Subject und SANs prüfen.
6. CA-Extensions vor der Signatur erklären.
7. Zertifikat erzeugen oder Modellartefakt validieren.
8. Issuer und Subject vergleichen.
9. Basic Constraints und Key Usage interpretieren.
10. Chain-Verifikation ausführen.
11. Fehlerfall absichtlich reproduzieren, falls das Beispiel ihn vorsieht.
12. Evidence-Dateien öffnen und auf private Schlüssel prüfen.
13. Betriebsfrage stellen: Wer besitzt dieses Zertifikat?
14. Sicherheitsfrage stellen: Wie wäre Kompromittierung erkennbar?
15. Renewal-Frage stellen: Wann muss gehandelt werden?
16. Widerrufsfrage stellen: Welche Clients prüfen CRL oder OCSP?
17. Audit-Frage stellen: Welche Entscheidung ist nachvollziehbar?
18. Cleanup durchführen.
19. Abweichungen dokumentieren.
20. Ergebnis in ein kurzes Review-Fazit überführen.

10. Review-Matrix

Offizielle Referenzen

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile: https://datatracker.ietf.org/doc/html/rfc5280
• CA/Browser Forum Baseline Requirements: https://cabforum.org/working-groups/server/baseline-requirements/requirements/
• NIST SP 800-57 Part 1 Revision 5: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• OpenSSL Manual Pages: https://www.openssl.org/docs/manpages/

Beispielanhang: Evidence, Transfer und Betrieb

Dieser Zusatzteil macht das Beispiel als Trainingsbaustein vollständiger. Er ist bewusst auf reale PKI-Fragen begrenzt: Zertifikatsinhalt, Vertrauenskette, Schlüsselmaterial, Widerruf, Erneuerung, Audit und Übergabe in einen Betriebsprozess.

Evidence-Checkliste

• openssl version wurde notiert, damit Ausgaben einer konkreten Tool-Version zugeordnet werden können.
• Subject, Issuer, Serial und Gültigkeit wurden über openssl x509 -noout geprüft.
• SAN, Basic Constraints, Key Usage und EKU wurden aus dem Zertifikatstext extrahiert.
• Die Chain wurde mit Root als Trust Anchor und Intermediate als Chain-Zertifikat geprüft.
• Fehlerfälle wurden nicht nur beschrieben, sondern mit kontrolliertem Exit-Code oder Evidence-Datei sichtbar gemacht.
• Private Schlüssel wurden nicht in Evidence-Dateien kopiert.
• Laufzeitartefakte liegen unter work/ und sind vom Repository-Inhalt getrennt.
• Cleanup ist möglich, indem work/ entfernt wird.

Transferfragen

1. Wer ist Owner des Zertifikats und wer darf die Ausstellung freigeben?
2. Welche CA signiert und wie wird diese CA selbst geschützt?
3. Welche Clients oder Systeme müssen dem Trust Anchor vertrauen?
4. Welche Laufzeit ist fachlich begründet und wann startet Renewal?
5. Wie wird Widerruf verteilt und wie wird geprüft, ob Clients ihn auswerten?
6. Welche Logs oder Tickets beweisen Antrag, Genehmigung, Ausstellung und Änderung?
7. Welche Abweichung wäre in einer öffentlichen CA nicht zulässig?
8. Welche Teile des Labs müssten durch HSM, Vault, cert-manager, ACME oder SPIFFE automatisiert werden?

Betriebsnotizen

Review-Fazit

Ein Beispiel ist erst abgeschlossen, wenn die technische Ausführung, die fachliche Erklärung und der Sicherheitsnachweis zusammenpassen. Für CA-Workshops ist das wichtiger als die reine Befehlsfolge, weil ein Zertifikat auch dann gefährlich sein kann, wenn OpenSSL es erfolgreich erzeugt hat.