1. Ziel

Ein Intermediate mit pathlen:0 darf keine weitere Sub-CA erzeugen; der Fehler wird kontrolliert sichtbar.

Das Lab ist absichtlich lokal und nicht produktiv. Es verwendet Dokumentationsdomänen wie example.test, erzeugt Schlüssel nur unter work/ und eignet sich deshalb für wiederholbare Trainings, Reviews und Fehleranalysen.

2. Voraussetzungen

• Ubuntu, WSL, VM oder vergleichbare Linux-Umgebung.
• openssl ist installiert und über openssl version prüfbar.
• Optional: python3 für JSON-Validierung in Modellbeispielen.
• Die Workshop-Dateien liegen lokal vor und das Beispiel wird aus seinem eigenen Verzeichnis ausgeführt.
• Keine echten produktiven Schlüssel, Zertifikate, Domains oder Kundendaten verwenden.

3. Dateien

• README.md
• docs/de/README.md
• docs/en/README.md
• run.sh
• openssl/root-ca.cnf
• openssl/intermediate-ca.cnf
• openssl/server.cnf

Die erzeugten Laufzeitartefakte landen unter work/. Dieser Pfad ist bewusst vom Repository-Inhalt getrennt, weil dort private Schlüssel, CSRs, Zertifikate, CRLs, OCSP-Antworten und Evidence-Dateien entstehen können.

4. Ausführung

cd examples/16-pathlen-basicconstraints
chmod +x run.sh
./run.sh
find work -maxdepth 3 -type f | sort

Bei OpenSSL-Beispielen lohnt sich danach eine manuelle Prüfung:

openssl x509 -in work/certs/server.crt.pem -noout -subject -issuer -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

5. Erwartetes Ergebnis

• Das Skript beendet sich mit Exit-Code 0.
• work/evidence/ enthält prüfbare Textdateien oder kopierte Modellartefakte.
• Private Schlüssel bleiben unter work/ und werden nicht committet.
• Zertifikate, Chains, CRLs oder Modellkonfigurationen sind klein genug für Review im Workshop.
• Fehlerfälle werden kontrolliert erzeugt, wenn das Beispiel Troubleshooting, Path Length oder Trust Store behandelt.

6. Erklärung

Das Beispiel trennt drei Ebenen: Konfiguration im Repository, Laufzeitergebnis unter work/ und Evidence unter work/evidence/. Diese Trennung ist wichtig, weil PKI-Arbeit sonst schnell unübersichtlich wird. Ein Zertifikat ist nur dann sinnvoll bewertbar, wenn Issuer, Subject, SAN, Basic Constraints, Key Usage, EKU, Gültigkeit, Chain und Widerrufsmodell zusammen betrachtet werden.

Für private Lab-PKIs ist eine selbst erzeugte Root-CA akzeptabel. Für öffentlich vertrauenswürdige TLS-Zertifikate reicht das nicht aus; dort gelten zusätzliche Anforderungen aus den CA/Browser Forum Baseline Requirements und auditierbare Betriebsprozesse.

7. Typische Fehler

8. Sicherheitsaspekte

• Root-Schlüssel gehören in echten Umgebungen offline oder in ein HSM, nicht auf einen Workshop-Laptop.
• Intermediate-Schlüssel brauchen klare Zugriffsrechte, Audit-Logs und Rotationsprozesse.
• End-Entity-Zertifikate dürfen nicht als CA markiert sein.
• SAN ist für Serveridentität maßgeblich; der Common Name allein ist kein belastbarer Hostnachweis.
• Private Schlüssel und Passwörter werden nicht ins Repository geschrieben.
• Evidence enthält Ausgaben, Fingerprints und Seriennummern, aber keine privaten Schlüssel.

9. Review und Evidence

Eine vollständige Abgabe enthält mindestens:

work/evidence/
  evidence.md
  server-full.txt
  fingerprint.txt
  crl-summary.txt
  revocation.txt

Nicht jede Datei entsteht in jedem Beispiel. Entscheidend ist, dass der Nachweis zum jeweiligen Lernziel passt. Bei Modellbeispielen reicht eine syntaktisch gültige und fachlich begründete Konfiguration; bei OpenSSL-Beispielen muss zusätzlich eine konkrete Prüfung mit openssl möglich sein.

Reviewfragen:

1. Welche Entität ist Subject und welche Entität ist Issuer?
2. Ist die Chain vollständig und wird der richtige Trust Anchor verwendet?
3. Welche Extensions sind kritisch und warum?
4. Wie lange ist das Zertifikat gültig und wann beginnt die Erneuerung?
5. Welche Evidence beweist, dass keine privaten Schlüssel committet wurden?
6. Wie würde ein Widerruf erkannt und verteilt?
7. Welche Abweichung wäre in einer Produktions-PKI nicht akzeptabel?
8. Welche Stelle müsste in einer CP/CPS dokumentiert werden?

10. Erweiterungsmöglichkeiten

• Beispiel um einen zweiten Hostnamen erweitern.
• Chain-Verifikation mit absichtlich falschem Intermediate ergänzen.
• Evidence in eine CI-Prüfung überführen.
• CRL Distribution Point und OCSP AIA in End-Entity-Zertifikaten vergleichen.
• Rollenmodell für Operator, Approver und Auditor dokumentieren.
• Ablaufüberwachung mit openssl x509 -checkend automatisieren.

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.