TLS-Gate: NetBox-Connector Schritt 4, Geräte-Zertifikate der Node-CA

Von: Branko → OZMAI, Crew
Stand: 11. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3, keine automatische Geltung, kein Brain-Status)
Charakter: NACHTRAG zu 2026-10-11_TLS-GATE-NETBOX-SPIEGEL-LIVE-SEEDS-OZM03-NACHTRAG_BRANKO.md.
Quelle: Repo TLS-Gate-Mock-Pipeline main 84a6925 (Code) + 5f8dae9 (VM-Tests), ungetaggt. Entwurf docs/DESIGN_NETBOX_CONNECTOR.md §6.
Belege: lokal 39 von 39 Suiten grün, darunter test_device_cert 42 (neu) und test_netbox_ui 18. VM aus 84a6925 (dirty=0): run 91, p3 48, p4 54, p5 31, p6 22, p7 53, p8 23, p9 4 (neu).

Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

1. Entscheidung

Branko, 11.10.: „nein, kein mac/wg ins zertifikat — schritt 4 starten“. Im Entwurf steht das als N8: Das Zertifikat trägt nur den Gerätenamen. Die Bindung Gerät ↔ Fingerabdruck steht nur in device_certs und im Audit, weil ein Zertifikat weitergereicht wird.

2. Gebaut 🧪 (im Wurzel-Repo, nicht live)

  • node_ca.php device-issue <nb-id> <csr>, device-list, device-cert, device-revoke.
  • Ausgestellt wird nur, wenn alles zutrifft:
  • Das Gerät steht im Spiegel der eigenen Gruppe und ist nicht weg. NetBox bleibt führend.
  • Der Zugang hat Kontobindung. Krümel-Tenants bekommen in Schritt 4 keine Zertifikate (Regel b).
  • Es gibt noch kein gültiges Zertifikat für dieses Gerät. Sonst heißt es erst widerrufen, kein stilles Umbinden (N5).
  • Das CSR-Subject ist genau CN=<gerätename>. Ein OU mit einer MAC wird abgelehnt, weil openssl_csr_sign den Subject sonst ins Zertifikat übernehmen würde.
  • Die CSR-Signatur ist gültig. Das belegt, dass der Absender den Schlüssel besitzt.
  • Der private Schlüssel entsteht auf dem Gerät und kommt nie ins Gate.
  • Zertifikat: CN + SAN DNS:<gerätename>, CA:FALSE, nur clientAuth, 90 Tage, nicht öffentlich vertrauenswürdig. Der Test prüft im Text und im DER-Kodierten, dass weder MAC noch wg-Key noch NetBox-ID darin stehen.
  • Daten: device_certs und device_cert_revocations sind nur anhängbar (Trigger unter SQLite und MariaDB, Migration 0007). Widerrufene Geräte-Zertifikate stehen in derselben CRL wie widerrufene Bestellungen. openssl verify -crl_check meldet sie als widerrufen. Danach ist eine Neuausstellung mit neuem Schlüssel möglich.
  • Audit: cli.node_ca_device_issue. Bei ok mit Anker netbox:<id>, SHA-256, Seriennummer, Tenant und ctx.build. Bei einer Ablehnung mit grund, es wird nichts angelegt. Dazu cli.node_ca_device_revoke.
  • Web: netbox.php (Wurzel) zeigt je Gerät den Stand des neuesten Zertifikats. Ausgestellt wird nur auf der Node.

3. Was nicht gebaut ist, und warum

❓ Wo stellt die Node-CA für die ozm-Knoten aus? Die Node-CA ist im Frontend native_php bewusst nicht enthalten (native_php/README.md, „Bewusst nicht enthalten“), und aus diesem Frontend werden die VM-Knoten ozm01–03 gebaut. Auf ozm03 kann deshalb heute nichts ausgestellt werden. Die VM führt nur die Tabellen mit (p9 prüft auch, dass dort keine Node-CA liegt). Die frühere Entscheidung hat der Entwickler nicht von sich aus umgestoßen. Zur Wahl stehen:
1. Die Node-CA kommt ins Frontend, als eigener, gekennzeichneter Baustein.
2. Die Node-CA bleibt auf der Ansible-Node (Wurzel), und die ozm-Knoten bekommen die Zertifikate von dort.
3. Ein eigener CA-Knoten, getrennt vom Frontend.

4. Offen

  • ❓ Ort der Node-CA (§3), Entscheidung Branko.
  • ⬜ Geführter Reset bei hardware_geaendert: Widerruf und Neuausstellung als ein Schritt.
  • ⬜ Zertifikate für Krümel-Tenants (Regel b).
  • ⬜ Kein echtes Gerät hat bisher ein Zertifikat. Alle Belege stammen aus synthetischen Tests.