PKI und Zertifikatslebenszyklus

Zusammenfassung. Diese Seite beschreibt die CA-Hierarchie und den Lebenszyklus von Zertifikaten, Aufträgen und CA-Schlüsseln: Antrag, Auftrag, Freigabe, Ausstellung, Erneuerung, Sperrung, Statusverteilung, Offline-Wurzel und Zeremonien. Jede Organisation hat ihre eigene Hierarchie; die Abläufe gelten in jeder Installation gleich, unabhängig vom Betriebsmodell.

• Wurzel-CA – oberste CA, selbstsigniert, dauerhaft offline.
• Ausstellende CA – von der Wurzel zertifizierte CA einer Organisation oder eines Partners; stellt Systemzertifikate aus.
• CA-Generation – CA mit eigenem Schlüssel; ein Schlüsselwechsel erzeugt eine neue Generation.
• Profilvorlage – in der Verwaltung gepflegte Vorlage, aus der ein Auftrag erzeugt wird.
• Profilklasse – im Regelwerk des Workers festgelegte Kategorie mit verbindlichen Regeln (Laufzeit, Erweiterungen, Freigaberegel, manuell oder automatisch).
• CSR – Zertifikatsantrag nach PKCS #10 mit Signatur des Antragstellers als Besitznachweis.

graph TD
  W[Wurzel-CA<br/>offline, Sicherheitsmodul] --> C1[Ausstellende CA Partner A<br/>nameConstraints: partner-a.example<br/>pathLen 0]
  W --> C2[Ausstellende CA Partner B<br/>nameConstraints: partner-b.example<br/>pathLen 0]
  C1 --> S1[lager.partner-a.example]
  C1 --> S2[maschine7.werk.partner-a.example]
  C2 --> S3[bestellung.partner-b.example]
  classDef off fill:#e1dfdd,stroke:#323130,color:#201f1e
  classDef ca fill:#fde7e9,stroke:#a4262c,color:#201f1e
  classDef ee fill:#deecf9,stroke:#0078d4,color:#201f1e
  class W off
  class C1,C2 ca
  class S1,S2,S3 ee

Der Inhalt eines CA-Zertifikats ist im Werkzeug der Wurzel fest vorgegeben und nicht frei konfigurierbar: cA=TRUE, pathLenConstraint=0, keyUsage nur keyCertSign und cRLSign, nameConstraints kritisch. Jeder Mandant hat mindestens eine eigene ausstellende CA; keine CA wird zwischen Mandanten geteilt. Je Algorithmusgeneration gibt es eine eigene CA – eine klassische CA wird nicht nachträglich hybrid, sondern durch eine hybride Generation abgelöst.

Die folgenden Profile zeigen den Aufbau mit den Vorgabewerten. Parametersätze und Laufzeiten folgen Kryptographie und Post-Quanten-Übergang und den Vorgabewerten in Betrieb und Notfall.

Ausstellende CA eines Partners (hybrid)

Version:                 3
Seriennummer:            <vom Werkzeug der Wurzel, mindestens 64 Bit Zufall>
Signaturalgorithmus:     ecdsa-with-SHA384 (1.2.840.10045.4.3.3)
Aussteller:              CN=<Wurzel-CA>
Gültigkeit:              5 Jahre (Vorgabe)
Subjekt:                 CN=<Name der CA>, O=<Mandant>
Öffentlicher Schlüssel:  EC P-384
Erweiterungen:
  basicConstraints       kritisch: cA=TRUE, pathLenConstraint=0
  keyUsage               kritisch: keyCertSign, cRLSign
  nameConstraints        kritisch: permittedSubtrees dNSName=l.example
  subjectKeyIdentifier, authorityKeyIdentifier
  cRLDistributionPoints  URL der Sperrliste der Wurzel (Verteilung)
  authorityInfoAccess    caIssuers: URL des Wurzelzertifikats (Verteilung)
  subjectAltPublicKeyInfo (2.5.29.72)  nicht kritisch: ML-DSA-87, 2.16.840.1.101.3.4.3.19
  altSignatureAlgorithm   (2.5.29.73)  nicht kritisch: ML-DSA-87, 2.16.840.1.101.3.4.3.19
  altSignatureValue       (2.5.29.74)  nicht kritisch: ML-DSA-Signatur der Wurzel

Systemzertifikat

Version:                 3
Seriennummer:            <vom CA-Worker, mindestens 64 Bit Zufall>
Signaturalgorithmus:     ecdsa-with-SHA384
Aussteller:              CN=<Name der CA>, O=<Mandant>
Gültigkeit:              30 Tage automatisch, höchstens 1 Jahr manuell
Subjekt:                 CN=lager.l.example, O=<Mandant, vom Worker gesetzt>
Öffentlicher Schlüssel:  EC P-256 (vom System erzeugt)
Erweiterungen:
  basicConstraints       kritisch: cA=FALSE
  keyUsage               kritisch: digitalSignature
  extendedKeyUsage       serverAuth (1.3.6.1.5.5.7.3.1), clientAuth (1.3.6.1.5.5.7.3.2)   nach Profilklasse
  subjectAltName         dNSName=lager.l.example                           genau einer
  subjectKeyIdentifier, authorityKeyIdentifier
  cRLDistributionPoints  URL der Sperrliste der CA
  authorityInfoAccess    caIssuers: URL des CA-Zertifikats
  subjectAltPublicKeyInfo (2.5.29.72)  ML-DSA-65 (vom System erzeugt)
  altSignatureAlgorithm   (2.5.29.73)  ML-DSA-87
  altSignatureValue       (2.5.29.74)  ML-DSA-Signatur der CA

Agentenzertifikat. Schlüsselagenten prüfen sich nur gegenseitig; klassische Gegenstellen sehen ihre Zertifikate nie. Ein Agentenzertifikat ist deshalb ein reines ML-DSA-Zertifikat nach RFC 9881: Subjektschlüssel ML-DSA-65, Signatur der CA mit ML-DSA-87, subjectAltName mit dem DNS-Namen des Rechners, extendedKeyUsage mit der Kennung für Schlüsselagenten, Laufzeit 30 Tage mit automatischer Erneuerung.

Wirkung der Namensbeschränkung. Nach RFC 5280 erlaubt die Beschränkung dNSName=l.example den Namen l.example und jeden Namen, der durch Voranstellen weiterer Labels entsteht, etwa lager.l.example oder maschine7.werk.l.example; l.example.attacker.example und xl.example sind nicht erlaubt.

sequenceDiagram
  participant AS as Antragsteller
  participant VE as Verwaltung oder Enrollment
  participant DB as Datenbank
  participant FG as Freigebende Person
  participant WK as CA-Worker
  participant RG as Register
  participant HS as Sicherheitsmodul
  AS->>VE: CSR (Besitznachweis), Profilvorlage, DNS-Name
  VE->>VE: CSR prüfen, Vorlage auflösen,<br/>Auftrag als JSON erzeugen
  VE->>DB: Auftrag (Bytes), Hash
  FG->>DB: Freigabe = Signatur über Hash
  WK->>DB: Auftrag und Freigaben lesen
  WK->>WK: Prüfung gegen Regelwerk
  WK->>RG: Absicht mit Seriennummer
  WK->>HS: TBS signieren (ML-DSA, dann klassisch)
  WK->>RG: Ergebnis
  WK->>DB: Projektion des Zertifikats
  DB-->>AS: Zertifikat über Verwaltung oder Protokoll

Inhalt eines Auftrags (Pflicht): Formatkennung und -fassung, Auftragskennung, Mandant, Herkunft, Korrelationskennung, Idempotenzschlüssel des Antragstellers, Antragsteller, ausstellende CA mit Fingerabdruck, Profilklasse, informativ Profilvorlage und Fassung, Zertifikatsart, öffentlicher Schlüssel (bei hybrid beide), CSR und Hash, Subject, SAN-Liste, vollständige Erweiterungen mit Kritikalität, Signaturalgorithmus, Gültigkeitsbeginn und -ende, geforderte Freigaberegel, Erstellungszeit, Frist. Nicht im Auftrag: die Seriennummer.

Prüfungen des Workers: Freigabe bzw. Attestierung gegen Regelwerk; Regel ist die für die Profilklasse vorgeschriebene (ein Auftrag kann sich keine mildere aussuchen); CA zugelassen und gehört zum Mandanten; Besitznachweis (bei hybrid für beide Schlüssel); Name im Namensraum; nur erlaubte Erweiterungen; Laufzeit; Frist; Auftrag nicht storniert; Auftrag noch nicht ausgeführt.

stateDiagram
  [*] --> pending_approval : Auftrag erzeugt
  pending_approval --> approval_complete : Freigaben eingereicht
  pending_approval --> canceled : Stornierung
  approval_complete --> claimed : Worker beginnt
  approval_complete --> canceled : Stornierung
  claimed --> issued : Ergebnis im Register
  claimed --> rejected : Regelverstoß oder Höchstzahl Versuche
  pending_approval --> expired : Frist überschritten
  issued --> [*]
  rejected --> [*]
  canceled --> [*]
  expired --> [*]

pending_approval, approval_complete und claimed stehen in der Datenbank; issued und rejected sind verbindlich nur im Register und werden in die Datenbank gespiegelt. Kommt eine Stornierung zu spät, wird das bereits ausgestellte Zertifikat gesperrt. Die Zustandsnamen sind die Werte, die die Verwaltungs-API liefert.

Eine Erneuerung ist ein neuer Antrag mit neuem Auftrag; das alte Zertifikat bleibt bis zu seinem Ablauf gültig. Automatische Profilklassen erneuern, sobald nur noch ein Drittel der Laufzeit übrig ist; die Mindestlaufzeit beträgt drei Tage. Manuelle Klassen verlangen eine neue Freigabe.

stateDiagram
  [*] --> erzeugt : im Sicherheitsmodul
  erzeugt --> zertifiziert : Zeremonie
  zertifiziert --> aktiv : im Regelwerk freigeschaltet
  aktiv --> nur_sperrlisten : Restlaufzeit kleiner als längste Profillaufzeit
  nur_sperrlisten --> stillgelegt : letztes ausgestelltes Zertifikat abgelaufen
  stillgelegt --> vernichtet : Zeremonie
  aktiv --> stillgelegt : Kompromittierung
  vernichtet --> [*]

• Wechsel (Rollover): Ein neuer Schlüssel ist eine neue CA-Generation mit neuem Zertifikat; derselbe Schlüssel wird nicht neu zertifiziert. Die alte Generation signiert nur noch Sperrlisten.
• Sicherung: nur über den Mechanismus des Sicherheitsmoduls und unter Mehrpersonenregel.
• PIN: im Geheimnisspeicher des Betriebssystems des Worker-Hosts; Zeremonien unter Quorum.
• Überwachung: Signaturzähler des Moduls werden mit dem Register abgeglichen; eine Abweichung ist ein Kompromittierungsverdacht.

sequenceDiagram
  participant L as Zeremonieleitung
  participant V as Verwahrer (Quorum)
  participant Z as Zeuge
  participant R as Wurzel (offline)
  participant K as Zweiter Kanal
  L->>R: CSR der ausstellenden CA (Datenträger)
  K->>L: Fingerabdruck des Schlüssels und Namensraum,<br/>abgelesen an der Konsole des Worker-Hosts
  L->>L: Abgleich CSR gegen zweiten Kanal
  V->>R: Aktivierung des Wurzelschlüssels
  R->>R: CA-Zertifikat mit festem Inhalt signieren
  Z->>Z: Protokoll gegenzeichnen
  R->>L: CA-Zertifikat, Wurzel-Sperrliste,<br/>öffentlicher Teil des Protokolls

Laufzeiten, Quoren, Takt der Zeremonien und nextUpdate der Wurzel-Sperrliste stehen als Vorgabewerte auf der Seite Betrieb und Notfall.

• Keine Vertrauensbeziehungen zwischen Organisationen; sie beschreibt Föderation und bilaterales Vertrauen.
• Kein OCSP. Die Statusauskunft erfolgt über Sperrlisten, die der TLS-Adapter im Takt lädt.
• Keine Personenzertifikate für die Anmeldung von Menschen an Anwendungen. TrustBridge identifiziert Systeme, Dienste und Agenten; persönliche Freigabe-Schlüssel dienen nur der Freigabe.