Certificate Authority Examples
Diese Beispiele folgen dem Format der Kubernetes-Workshop-Beispiele: jedes Beispiel besitzt ein Haupt-README, deutsche und englische Detaildokumentation sowie kleine prüfbare Artefakte.
Alle Laufzeitergebnisse entstehen unter work/. Private Schlüssel, CSRs, Zertifikate und Evidence-Dateien aus lokalen Läufen werden nicht versioniert.
Empfohlener Ablauf:
cd examples/00-lab-skeleton
chmod +x run.sh
./run.sh
find work -maxdepth 3 -type f | sort
Sicherheitsregeln:
- keine produktiven Schlüssel verwenden
- keine echten Domains oder Kundendaten verwenden
work/vor Commits prüfen- Chain, SAN, Basic Constraints, Key Usage und EKU immer mit OpenSSL nachweisen
- öffentlich vertrauenswürdige Zertifikate nicht mit Lab-CAs verwechseln
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 versionwurde notiert, damit Ausgaben einer konkreten Tool-Version zugeordnet werden können.- Subject, Issuer, Serial und Gültigkeit wurden über
openssl x509 -nooutgeprü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
- Wer ist Owner des Zertifikats und wer darf die Ausstellung freigeben?
- Welche CA signiert und wie wird diese CA selbst geschützt?
- Welche Clients oder Systeme müssen dem Trust Anchor vertrauen?
- Welche Laufzeit ist fachlich begründet und wann startet Renewal?
- Wie wird Widerruf verteilt und wie wird geprüft, ob Clients ihn auswerten?
- Welche Logs oder Tickets beweisen Antrag, Genehmigung, Ausstellung und Änderung?
- Welche Abweichung wäre in einer öffentlichen CA nicht zulässig?
- Welche Teile des Labs müssten durch HSM, Vault, cert-manager, ACME oder SPIFFE automatisiert werden?
Betriebsnotizen
| Thema | Erwartung |
|---|---|
| Rollen | Antragsteller, Approver, CA-Operator und Auditor sind getrennt oder begründet kombiniert. |
| Schlüssel | Private Keys sind geschützt, nicht versioniert und nur für die benötigte Rolle zugänglich. |
| Zertifikate | Leaf-Zertifikate haben CA:FALSE; CA-Zertifikate haben CA:TRUE und passende Key Usage. |
| Namen | DNS- und IP-Identitäten stehen im SAN, nicht nur im Common Name. |
| Chain | Root, Intermediate und Leaf sind nachvollziehbar und korrekt verteilt. |
| Widerruf | CRL oder OCSP ist als Prozess eingeordnet, auch wenn das Lab nur lokal arbeitet. |
| Renewal | Ablaufüberwachung und Erneuerungsfenster sind dokumentiert. |
| Audit | Evidence enthält nachvollziehbare Entscheidungen, aber keine Geheimnisse. |
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.