TrustFabric ersetzt certsrv, certtmpl und pkiview durch eine containerisierte Plattform —
ein Inventar, ein Freigabemodell und ein Ausstellungskern über mehrstufige ADCS und öffentliche CAs hinweg.
Mit einem Tier-0-isolierten Sicherheitskern, der niemals auf der CA selbst läuft; die CA verwaltet ein Windows-Agent auf einem Mitgliedsserver.
Docker · Kubernetes & Helm · Windows-CA-Agent per MSI · Tier 0 und Tier 1 getrennt
certutil für den Rest.Zertifikatsverwaltung unter Windows heißt oft noch: certsrv, certtmpl, pkiview. Drei Fenster, drei Sichten, keine davon beantwortet die Fragen, die wirklich zählen: Welche Zertifikate laufen in dreißig Tagen ab? Wem gehören sie? Warum bekommt dieses Gerät keines?
Gleichzeitig ist die PKI zu einem der kritischsten Systeme im Unternehmen geworden. Eine abgelaufene CRL legt ganze Landschaften still — VPN, WLAN, Smartcard-Logon, Anwendungs-TLS — und niemand wird vorher gewarnt. Die Werkzeuge stammen aus einer Zeit, in der das noch verzeihlich war.
TrustFabric ist kein Aufsatz auf diese Werkzeuge. Es ersetzt sie — und beantwortet die Fragen, die sie nie stellen konnten.
Die CA ist ein Tier-0-System, deshalb läuft der TrustFabric-Kern nie auf ihr. Ein Windows-CA-Agent — ein Dienst mit MSI-Installer auf einem Mitgliedsserver, unter einem gMSA-Dienstkonto — spricht per DCOM mit der CA und ist über mTLS mit angeheftetem Zertifikat an den Kern gebunden. Ausstellungskern und Audit-Kette leben in einem isolierten Tier-0-Container; Web-Oberfläche, API und Protokoll-Adapter in Tier 1. Dazwischen: eine schmale, kommandoförmige Schnittstelle, die nur das durchlässt, was für den jeweiligen Surface ausdrücklich erlaubt ist.
Alle überwachen Ablaufdaten. TrustFabric erneuert Sperrlisten rechtzeitig, bevor sie ablaufen können, meldet fremde CAs im Verzeichnis, setzt zuerst einen umkehrbaren Hold und lässt jede Tier-0-Änderung von einer zweiten Person freigeben.
Eine abgelaufene Sperrliste ist ein häufiger selbstverschuldeter PKI-Ausfall. Je CA lässt sich einschalten, dass TrustFabric eine neue CRL anfordert, bevor die alte abläuft, die Veröffentlichung an den CDP- und AIA-Adressen nachprüft und Kritisches wiederholt meldet.
Eine Enterprise-CA lässt sich mit wenigen Rechten aufsetzen, und dann vertraut ihr die ganze Domäne. TrustFabric gleicht die CA-Objekte im Verzeichnis mit dem Soll ab, alle sechs Stunden und auf Anforderung: NTAuth, Stamm-CAs, AIA und Enterprise-CAs.
Ein Widerruf ist endgültig. TrustFabric setzt ein Zertifikat zuerst auf einen umkehrbaren Hold (certificateHold), den eine Person setzen und wieder aufheben kann; der endgültige Widerruf braucht eine zweite Person. Bündelaktionen sind begrenzt.
Änderungen an CA-Konfiguration, Vorlagen, Sub-CA-Anträgen und breiten Delegationen laufen als Antrag mit Diff und brauchen die Freigabe einer zweiten Person. Bei Vorlagen zeigt der Editor die ESC-Befunde vorher und nachher.
Statt Standardvorlagen zu pflegen, führt die Baseline gehärtete TF-Vorlagen für Intune, NPS, Codesigning, Smartcard (YubiKey/PIV) und mehr ein und zieht die Standardvorlagen stufenweise zurück, mit Abhängigkeitsprüfung vorher.
Jede Änderung einer Vorlage wird versioniert; zwei Versionen lassen sich feldgenau vergleichen. Eine Abweichung vom gemerkten Stand erscheint als Drift.
TrustFabric findet doppelte und schwache Schlüssel im Bestand, klassifiziert jedes Zertifikat nach Quantenanfälligkeit und liest den Schlüsselspeicher der CAs (Software oder HSM) aus.
Der NIS2-Bericht ordnet Befunde, Inventar, Ereigniskette und Vier-Augen-Entscheidungen den Maßnahmen nach Art. 21 Abs. 2 zu, mit IT-Grundschutz-Modulen; Risikoklassen folgen den Schwellen der BSI TR-02102-1. Die Zuordnung ist eine eigene Herleitung und kein Konformitätsnachweis.
Das Fundament trägt alles; darüber stehen die ADCS-Verwaltung, die Protokolle und öffentlichen CAs, Sicherheit und Compliance sowie der Betrieb. Ein Teil davon ist bisher nur gegen eine Laborumgebung oder mit Testdiensten geprüft.
Die Fähigkeiten, auf denen jede andere Funktion aufsetzt.
Ein Inventar über ADCS-Hierarchien (laufend über den CA-Agent abgeglichen), öffentliche CAs, Netzwerk-Discovery und CT-Logs. Durchsuchbar (auch per Regex), filterbar, als CSV oder JSON exportierbar.
Der Stand jeder Zertifikatvorlage wird gesichert und per Inhalts-Hash verglichen; eine Abweichung vom gemerkten Stand wird sichtbar und lässt sich bestätigen.
Jedes Ereignis trägt den Hash seines Vorgängers; nachträgliches Umschreiben bricht die Kette. Ein täglicher Ketten-Check vergleicht gegen einen außerhalb gehaltenen Anker. Alarme gehen per Mail, Webhook oder Teams.
Wer darf welche Vorlage mit welchen Namens- und SAN-Regeln für wen beantragen? Delegationen sind befristet; breite Delegationen brauchen ein zweites Augenpaar.
ACME, SCEP, EST, CMP, REST, MCP und die Weboberfläche münden in dieselbe Ausstellungslogik: eine Regel gilt überall, ein Audit-Eintrag pro Vorgang.
Sicherheitskern und Protokoll-Surfaces laufen in getrennten Prozessen. Ein Tier-1-Prozess startet nicht, wenn eine Tier-0-Datenbankverbindung konfiguriert ist; dazwischen nur eine schmale, kommandoförmige Schnittstelle (Intake, mTLS).
Dienst mit MSI-Installer auf einem Mitgliedsserver, nicht auf der CA. Er spricht per DCOM mit der CA (empfohlen mit gMSA-Dienstkonto), ist über mTLS mit angeheftetem Zertifikat an den Kern gebunden und aktualisiert sich über die Oberfläche.
Anmeldung per Active Directory (LDAPS) oder Entra ID, dazu Break-Glass-Konten mit TOTP. Sechs Rollen: der Auditor liest, der PKI-Operator bedient, der Plattform-Admin konfiguriert, der Key-Recovery-Officer gibt nur Schlüsselwiederherstellungen frei.
Alles, was certsrv, certtmpl und pkiview können, und was sie nie konnten.
Ausgestellte, ausstehende, fehlgeschlagene und gesperrte Zertifikate mit Suche über Subject, SAN, Seriennummer und Vorlage (auch Regex) sowie einer ASN.1-Baumansicht. Die CA-Warteschlange lässt Anträge ausstellen oder ablehnen. Hold, Freigabe und Widerrufsantrag laufen auch gebündelt (bis 200 je Lauf).
Alle Vorlagen-Attribute lesen, Versionen mit feldgenauem Diff vergleichen, als JSON exportieren. Änderungen laufen als Antrag mit Vier-Augen-Freigabe und ESC-Vorschau; veröffentlichen und zurückziehen ebenso.
Gehärtete TF-Vorlagen für Kerberos-Authentifizierung, Webserver, Computer, OCSP, Intune (SCEP und PKCS), NPS, Codesigning, Smartcard-Anmeldung (YubiKey/PIV), Registrierungs-Agent, Key-Recovery-Agent und Benutzer-Verschlüsselung. Die Standardvorlagen werden stufenweise zurückgezogen, mit Abhängigkeitsprüfung.
Registry-Einstellungen der CA lesen und über eine Positivliste ändern: mit Diff, Vier-Augen-Freigabe und Rollback. Das Sicherheitsprotokoll der CA erscheint als Betriebsprotokoll.
PKI-Zustand: Hierarchiekarte, CRL, Delta-CRL, AIA und OCSP einschließlich LDAP-CDP werden geprüft; Auffälligkeiten gehen als Alarm an die Benachrichtigungskanäle.
„Warum bekommt dieses Konto kein Zertifikat?“ Die Analyse prüft Vorlagenrechte, Veröffentlichung und Autoenrollment; die Fehlersuche ordnet Meldungen und HRESULTs einer Ursache zu. Regelbasiert, keine Black-Box-KI.
Zertifikate werden Konten und Geräten zugeordnet: verwaiste Zertifikate, doppelte oder schwache Schlüssel und Lücken beim Autoenrollment erscheinen als Befund.
Der Antrag geht als Datei zur Offline-Root, das signierte Zertifikat kommt zurück und wird streng geprüft; die Freigabe braucht vier Augen. Die Root-CRL wird mit Alarm vor Ablauf überwacht.
Wiederherstellungsanträge mit Begründung; Freigabe und Abruf nur durch die Rolle Key-Recovery-Officer, die ein Plattform-Admin nicht ersetzen kann. TrustFabric sieht den Klartext-Schlüssel nie.
Anwender und Power User beantragen Zertifikate selbst, innerhalb ihrer Delegation; Schlüssel entstehen im Browser. Ablauf-Erinnerungen kommen per Mail.
Sechs Zugangswege zum Ausstellungskern und die Anbindung öffentlicher Aussteller.
RFC 8555 mit External Account Binding, http-01 und dns-01. Webserver und Ingress-Controller holen Zertifikate wie bei Let's Encrypt, aber aus der eigenen CA. Gegen certbot, acme.sh und lego getestet.
SCEP (RFC 8894) mit Einmal-Challenge für Netzwerkgeräte, EST (RFC 7030) für moderne Clients; beide am selben Ausstellungskern.
Lightweight-Profil mit Passwortschutz (PBM), Anträge, Polling und Bestätigung; auch Anträge mit ML-DSA-Schlüsseln.
REST-API mit OpenAPI-Beschreibung und eine MCP-Schnittstelle (Streamable HTTP) für Werkzeuge und KI-Agenten, jeweils mit API-Schlüsseln oder Entra-App-Tokens und innerhalb derselben Delegationsgrenzen.
ACME-Client mit External Account Binding; dns-01 manuell, per RFC 2136 (TSIG) oder Azure DNS; SwissSign zusätzlich über die RA-REST-API. Mit Kosten- und Kontingentlogik und Freigabe nach Kosten.
Die Certificate-Transparency-Logs (über crt.sh) werden auf die eigenen Domänen und erwartete Aussteller überwacht; ein unerwartetes Zertifikat ist ein Befund.
TLS-Endpunkte aus konfigurierten Zielen und Netzen werden gescannt und mit dem Inventar abgeglichen.
Prüfen, belegen, absichern.
Das Audit prüft zwölf ESC-Pfade, der Bekannte-Bugs-Scan ESC17; vier weitere (ESC8, 10, 13, 14) sind ausdrücklich als nicht automatisch geprüft ausgewiesen (siehe unten). Befunde lassen sich beheben oder mit Begründung als erwartet bestätigen.
Jedes gültige Zertifikat erhält eine Risikoklasse mit Gründen (keine Punktzahl); der Bestand ist als CycloneDX-CBOM exportierbar.
Audit-Bericht und NIS2-Bericht (Maßnahmen nach Art. 21 Abs. 2, mit zugeordneten IT-Grundschutz-Modulen) als HTML und PDF; die Zuordnung ist eine eigene Herleitung, keine amtliche.
Ampel je Komponente: Sicherheitsheader, Transport, Datenbankrolle, ablaufende Geheimnisse, Anmeldefehlversuche, Abhängigkeitsberichte und ein Befundregister.
TrustFabric selbst, abgebildet auf BSI IT-Grundschutz (Modulebene), ISO/IEC 27001:2022 Anhang A und NIS2 Art. 21, mit PDF. Eine eigene Zuordnung, kein Zertifikat.
Die Geheimnisse von TrustFabric lassen sich per PKCS#11 (SoftHSM2 getestet; YubiHSM 2) oder Azure Managed HSM schützen. Für CA-Schlüssel erkennt der Agent Software- und HSM-Schlüsselspeicher und meldet Befunde, darunter den YubiHSM-Zugriff (ESC12).
Eine Matrix Quelle → Ziel mit Port, Protokoll, Pflicht oder optional und den echten Werten der Installation, als CSV für das Firewall-Team.
Lokale Notfallkonten nur per Kommandozeile, mit TOTP und Alarm an alle Kanäle; Sitzungen lassen sich beenden, Refresh-Token werden rotiert und auf Wiederverwendung geprüft.
Wie TrustFabric läuft und gepflegt wird.
Einzelknoten-Profil und ein gestuftes Profil mit getrennten Netzen für Tier 0, Intake und Tier 1; ein Image, die Surfaces werden per Umgebungsvariable gewählt.
Helm-Chart mit Kern und je einem Deployment pro Surface, Migrations-Hook, NetworkPolicies und schreibgeschützten Nicht-Root-Containern. Gerendert und geprüft, noch nicht in einem echten Cluster installiert.
Schema-Migrationen sind ein eigener Schritt (--migrate) mit getrennten Rollen für Migration und Betrieb; Prometheus-Endpunkt, Alarme per Mail, Webhook und Teams, Hintergrundjobs für Inventar, Monitoring und Ablauf-Erinnerungen.
Die CI erzeugt SBOMs (CycloneDX) und Schwachstellenberichte für .NET und npm; sie erscheinen in der Oberfläche unter Plattform › Sicherheit.
Oberfläche und Hilfeartikel sind deutsch; jede Ansicht hat eine eingebaute Hilfe mit Erklärung und Quellen.
845 Artikel zu ADCS, PKI und Windows-Ereignissen, jeder mit Herausgeber, Datum und Link zur Quelle; Texte sind Zusammenfassungen, eigene Herleitungen sind als solche markiert. Die Suche findet auch Ereignis-IDs sowie KB-, CVE- und ESC-Nummern.
Regeln aus den Artikeln laufen gegen die gespeicherten Daten (CA-Konfiguration, CA-Zertifikate, Vorlagen mit Rechten, Monitoring). Jeder Treffer nennt Belege, Artikel und einen Fix-Vorschlag: eine Schaltfläche mit Vier-Augen-Antrag, wo es einen sicheren Weg gibt, sonst die Befehle zum Kopieren. Dreizehn Regeln; was sich nicht automatisch prüfen lässt, steht mit Grund und Prüfung von Hand dabei.
Die Ereignisprotokolle aller CA-Hosts einer Umgebung werden gleichzeitig gesammelt und nach Anbieter und ID gruppiert, mit Artikel und Fix-Vorschlag. Unbekannte Ereignisse bleiben „unbekannt“; Ereignisse, die zu einer Änderung aus TrustFabric passen, gelten als erwartet.
Läuft der CA-Agent auf dem Responder-Host, startet er den Online-Responder-Dienst neu, recycelt einen freigegebenen Anwendungspool oder führt iisreset aus; Letzteres nur für den Plattform-Admin mit Bestätigung. Eine Operation je 60 Sekunden und Host, jede mit Zustand vorher und nachher im Ereignisverlauf. Hostnamen werden auch über Alias-Namen zugeordnet, etwa für Lastverteiler.
Die ESC-Angriffspfade auf ADCS sind seit Jahren öffentlich dokumentiert. TrustFabric prüft dreizehn davon automatisch (zwölf im Konfigurationsaudit: ESC1 bis ESC7, ESC9, ESC11, ESC12, ESC15 und ESC16; ESC17 im Bekannte-Bugs-Scan) gegen Vorlagen, Berechtigungen und CA-Konfiguration; ESC8, ESC10, ESC13 und ESC14 sind nicht automatisch prüfbar und stehen in der Oberfläche als „nicht automatisch geprüft“ mit Grund und Prüfung von Hand. Dazu kommen ein Konfigurationsaudit und der Abgleich des Verzeichnisses mit den erwarteten Zertifizierungsstellen.
„Harvest now, decrypt later“ ist keine Theorie mehr. TrustFabric klassifiziert jedes Zertifikat im Inventar nach Quantenanfälligkeit, nimmt Zertifikatsanforderungen mit ML-DSA-Schlüsseln (FIPS 204) an und reicht sie unverändert an die CA weiter. Der gesamte kryptografische Bestand lässt sich als CycloneDX-CBOM exportieren — als Grundlage für die Planung.
Ob eine ADCS selbst ML-DSA-Zertifikate ausstellt, hängt von der CA-Version ab und ist in TrustFabric bisher nicht gegen eine solche CA geprüft.
TrustFabric ist keine Insel. Was Zertifikate ausstellt, hält oder braucht, wird über Protokoll-Adapter, API und die genannten Schnittstellen angebunden.
Mit dem Bechtle-Konto anmelden. Wer noch keinen Zugang hat, beantragt ihn über Microsoft My Access; freigeschaltet wird nach Prüfung, danach ist die Rolle Leser aktiv. Für ein Gespräch über Ihren PKI-Betrieb genügt eine E-Mail.
Kontakt: ccmw.westfalen-niederrhein@bechtle.com