mTLS ist leistungsstark — aber solange PKI-Betrieb schwierig bleibt, können Organisationen es nicht breit einsetzen.
Die meisten Organisationen möchten mTLS nutzen, aber Zertifikatausstellung, CA-Verwaltung, CSR-Vorbereitung, P12-Packaging und Benutzerverteilung landen verstreut über separate Teams, separate Werkzeuge und manuelle Befehle. Das Authentifizierungsmodell, das sicher sein sollte, wird aufgeschoben, weil es zu schwierig zu betreiben ist, oder auf nur wenige Systeme beschränkt.
Das Problem ist in Test- und Staging-Umgebungen noch deutlicher sichtbar. Ein Entwicklerteam dazu zu bringen, schnell eine Test-CA aufzusetzen, ein Client-Zertifikat auszustellen, ein P12 zu exportieren und es in eine Anwendung einzubinden, hängt meist von langen Befehlsketten ab. Wenn dieser Prozess nicht standardisiert ist, erfindet jedes Team seinen eigenen Ansatz, und die Zertifikatverwaltung wird fragmentiert.
Die Client-Zertifikat-Verteilung ist eine eigene Herausforderung. Ein Zertifikat für einen Benutzer, ein Gerät, einen Partner oder eine IoT-Einheit zu erstellen; es mit einem Passwort zu schützen; die richtige Kette einzubetten; den Fingerabdruck zu erfassen; und bei Bedarf neu auszustellen erfordert alles operative Disziplin. Wenn diese Disziplin nicht in das Werkzeug integriert ist, degradiert der Prozess schnell zu manuellen Dateiaustauschen.
Zertifikat-Kettenvalidierungsfehler, fehlende Intermediate-Zertifikate, falsche Schlüsseltypen, kurz vor dem Ablauf stehende Zertifikate oder falsche SAN-Felder können alle direkte Ausfälle verursachen. Wenn CN, SAN, Aussteller, Algorithmus, Schlüssellänge und Gültigkeitsbereich nicht in dem Moment sichtbar sind, in dem ein Zertifikat geladen wird, werden Probleme in der Regel erst bemerkt, wenn Benutzer bereits betroffen sind.
Der CA-Verwaltungsansatz von TR7 macht PKI zugänglich und prüfbar, indem Zertifikatausstellung, Signierung, Konvertierung, Parsing und Ablaufverfolgung vollständig geräteinternen abgewickelt werden.
Unser Ansatz
TR7 präsentiert die CA-Verwaltung als integrierten PKI-Workflow, der Zertifikatausstellung, Hierarchie, Validierung und Formatkonvertierung abdeckt.
Client-Zertifikate werden geräteinternen ausgestellt
TR7 kann ein Client-Zertifikat aus einem CN und optionalen Feldern erstellen, einen CSR generieren, ihn mit der integrierten CA signieren und eine P12-Ausgabe produzieren. Dieser Ablauf macht die mTLS-Zertifikatausstellung nicht von externen Befehlsketten abhängig.
CA- und Sub-CA-Kette unterstützt mTLS-Signierung
Das integrierte CA-Zertifikat und der Schlüssel können Client-Zertifikate signieren. Das Hinzufügen der Kettendatei zur P12-Ausgabe reduziert Probleme durch fehlende Ketten auf der Client-Seite.
Parse- und Validierungs-Pipeline extrahiert Zertifikat-Metadaten
Wenn ein Zertifikat geladen wird, werden CN, SAN, Aussteller, Algorithmus, Schlüssellänge und Gültigkeitsdaten sofort geparst. Ein Dual-Parser-Ansatz bietet robustere Metadaten-Extraktion über verschiedene Zertifikatformate hinweg.
PEM-, PFX/P12- und Schlüsselformate werden konvertiert
TR7 kann einen Schlüssel und ein Zertifikat aus einem PFX extrahieren oder ein PFX/P12-Paket aus PEM-Inhalt erstellen. Passwort-Hinzufügen/-Entfernen und RSA/ECDSA-Schlüsseltyp-Operationen vervollständigen den Zertifikat-Lebenszyklus.
Fähigkeiten
Die CA-Verwaltung von TR7 deckt das gesamte Zertifikatsleben ab — eine interne PKI-Hierarchie mit Profilen, Geräte-Enrolment, Sperrung mit CRL und OCSP-Responder sowie die tägliche CSR-, Signier- und P12-Arbeit — alles innerhalb des ADC.
Eine zweistufige interne PKI — eine Root, darunter eine Server-CA und eine Geräte-CA
TR7 stellt aus einer eigenen Hierarchie aus statt aus einem einzigen flachen Signierer: eine bewusst ruhende Root, darunter eine Server-CA und eine Geräte-CA. Zertifikate entstehen aus Profilen — TLS-Server, internes mTLS, VPN-Gerät — sodass Laufzeit, Schlüsselalgorithmus, Extended Key Usage und SAN-Muster einmal festgelegt und jedes Mal angewendet werden; jedes ausgestellte Zertifikat landet in einem durchsuchbaren Register statt im Home-Verzeichnis von irgendwem. Private Schlüssel liegen hinter einer Key-Store-Abstraktion — genau das macht den späteren Wechsel auf ein HSM zu einer Konfigurationsänderung statt zu einem Migrationsprojekt.
Client-Zertifikatausstellung kombiniert CSR, CA-Signierung und P12-Ausgabe
Der createClientCertificate-Ablauf kann ein Client-Zertifikat mit CN, Passphrase, Gültigkeitstagen, E-Mail- und Organisationsfeldern ausstellen. Ein Schlüssel wird generiert, ein CSR vorbereitet, die CA signiert ihn und eine P12-Ausgabe wird produziert. Die Ausgabe kann P12-Binärdaten, SHA1-Fingerabdruck, CN und Erstellungs-Metadaten enthalten. Dies macht das Ausstellen eines mTLS-Zertifikats für einen neuen Benutzer, ein Gerät oder einen Partner unkompliziert.
Geräte-Enrolment, bei dem der Schlüssel auf dem Gerät entsteht und es nie verlässt
Geräte melden sich selbst an: Das Schlüsselpaar entsteht im Secure Element des Telefons oder im TPM des Notebooks, wird als nicht exportierbar markiert, und zu TR7 reist nur ein Signieranfrage — die Geräte-CA signiert sie. Niemand verschickt eine P12-Datei per Mail, niemand legt einen privaten Schlüssel auf eine Freigabe, und ein gestohlenes Backup enthält keine nutzbare Identität. Das ausgestellte Zertifikat trägt die eigene Kennung des Geräts als Subject: Das Gerät ist ein eigener Principal, getrennt von der Person davor — genau das erlaubt einer Zugriffsrichtlinie, beide zu prüfen, ohne sie zu vermengen. Das Enrolment läuft über SCEP — das Protokoll, das Geräteverwaltungsplattformen ohnehin sprechen.
CSR-Generierung vereinfacht die Arbeit mit externen CA-Prozessen
TR7 kann einen CSR mit parametrisierten Subject-Feldern generieren. Organisation, CN und E-Mail werden auf kontrollierte Weise zur Zertifikatanforderung hinzugefügt. Die Organisation kann mit der integrierten CA signieren oder den CSR an einen externen Unternehmens-CA-Prozess senden. TR7 passt sich sowohl an unabhängige PKI-Abläufe als auch an bestehende Unternehmens-Signierungsprozesse an.
CA-Signierung erstellt die mTLS-Zertifikatkette geräteinternen
Client-Zertifikate können mit dem integrierten CA-Zertifikat und CA-Schlüssel signiert werden. Das Standardmodell verwendet SHA256-Digest, 2048-Bit-RSA und eine 365-tägige Gültigkeit. Das signierte Zertifikat kann als mTLS-Client-Identität dienen. Mit der internen Hierarchie dahinter deckt das die mTLS-Landschaft selbst ab und nicht nur die einfachen Fälle — ein externer PKI-Server ist eine Wahl, keine Voraussetzung.
Sperrung, die wirklich geprüft wird — eine CRL und ein OCSP-Responder, nicht nur Stapling
Ein Zertifikat wird auf seiner eigenen Seite mit Grundcode gesperrt, und ab diesem Moment passiert zweierlei: Es fällt aus der nächsten veröffentlichten CRL, und der eingebaute OCSP-Responder antwortet für es mit "gesperrt". Genau diesen Responder überlassen die meisten Plattformen jemand anderem — und er ist es, der eine Zugriffsentscheidung in Millisekunden nachfragen lässt, statt einer Liste zu vertrauen, die heute Morgen aktuell war. Der Unterschied ist wichtig: OCSP-Stapling am Frontend belegt, dass Ihr Serverzertifikat noch gültig ist; dies belegt, dass ein Client- oder Gerätezertifikat es nicht mehr ist.
PFX- und P12-Operationen bieten bidirektionale Zertifikatkonvertierung
TR7 kann den privaten Schlüssel und den Zertifikatinhalt aus einem PFX/P12-Paket extrahieren. In umgekehrter Richtung kann es ein PFX/P12-Paket aus Schlüssel- und Zertifikatinhalt erstellen. Dies macht den Umgang mit Zertifikaten aus Windows-basierten Systemen oder Paketformaten, die von verschiedenen Umgebungen benötigt werden, unkompliziert. Das Zertifikatformat ist kein Hindernis mehr für Anwendungsmigrationen.
RSA- und ECDSA-Schlüsseloperationen unterstützen moderne Anwendungsszenarien
TR7 kann den Schlüsseltyp unterscheiden und RSA/ECDSA-basierte Zertifikatoperationen verarbeiten. Schlüsselschutz-Operationen wie das Hinzufügen oder Entfernen einer Passphrase können ebenfalls in derselben Konvertierungs-Pipeline durchgeführt werden. Dies hilft dabei, Schlüssel von Legacy-Diensten für moderne Anwendungsanforderungen vorzubereiten. Zertifikatoperationen werden zu kontrollierter Objektverarbeitung statt zu manuellem Dateibearbeiten.
Zertifikat-Metadaten-Extraktion bietet Transparenz und Prüfbarkeit
Wenn ein Zertifikat geladen wird, können SAN-Felder, CN, Aussteller, Algorithmus, Schlüssellänge, Gültigkeitsbeginn und Ablaufdatum alle geparst werden. Diese Informationen stehen für die Benutzeroberfläche und Berichte zur Verfügung. Das Betriebsteam kann schnell sehen, welches Zertifikat welche Domainnamen abdeckt und wann es abläuft. Das Zertifikatinventar hängt nicht mehr von manuellen Dateinamen ab.
SHA1-Fingerabdruck-Generierung vereinfacht Zertifikatabgleich
TR7 kann einen SHA1-Fingerabdruck für ein Zertifikat extrahieren und normalisieren. Der Fingerabdruckwert kann für den Client-Zertifikat-Abgleich, die Protokollführung und die operative Nachverfolgung verwendet werden. Dies ist besonders nützlich bei mTLS-Client-Identitäten, um zu unterscheiden, welches Zertifikat zu welchem Benutzer oder Gerät gehört. Die Zertifikatverteilung wird nachverfolgbarer.
Kettenaufbau-Unterstützung bettet die Intermediate-Kette in P12 ein
Die CA-Kette kann während des P12-Exports in das Paket aufgenommen werden. Dies reduziert Kettenprobleme auf der Client-Seite, die durch ein fehlendes Intermediate verursacht werden. Die Organisation, die ein Zertifikat verteilt, kann die notwendigen Ketteninformationen in einer einzigen Datei mitliefern. Dies vereinfacht den Betrieb insbesondere bei Mobil-, Desktop- und Partner-Verteilungsszenarien.
Zertifikat-Ablaufbenachrichtigung macht das Ausfallrisiko frühzeitig sichtbar
Das Standard-Benachrichtigungsmodell kann so konfiguriert werden, dass 30 Tage vor Ablauf eines Zertifikats ein Alarm erzeugt wird. In Verbindung mit dem Benachrichtigungssystem können Alarme per E-Mail, SMS oder über andere Kanalflüsse zugestellt werden. Dies reduziert plötzliche Produktionsausfälle durch abgelaufene Zertifikate. Die Zertifikat-Erneuerungsverfolgung hängt nicht mehr von manuellen Kalendererinnerungen ab.
Operative Tiefe
Zuverlässiger CA-Betrieb erfordert, dass Dateipfade, Standard-Kryptoparameter, temporäre Dateibereinigung, Subject-Bereinigung und Namespace-Isolierung gemeinsam berücksichtigt werden.
Zertifikatdateipfade
Das Server-Zertifikat, CA-Zertifikat und CA-Schlüssel werden an bestimmten Dateipfaden auf dem System gespeichert. Das CA-Zertifikat unter /etc/ca.crt und der CA-Schlüssel unter /etc/ca.key werden für die mTLS-Signierungskette verwendet. Temporäre Client-Zertifikat-Ausstellung läuft in einem separaten temporären Verzeichnis.
Standard-Kryptoparameter
Die Standard-Zertifikatausstellung verwendet 365-tägige Gültigkeit, 2048-Bit-Schlüsselgröße, SHA256-Digest und TR7-Organisationsinformationen. Dies sind Baseline-Startparameter. Gültigkeitszeitraum und Zertifikatfelder sollten gemäß der Sicherheitsrichtlinie der Organisation geplant werden.
Bereinigung temporärer Dateien
Während der Zertifikatausstellung werden temporäre Dateien wie Schlüssel, CSR, Zertifikat und P12 erstellt. Unabhängig davon, ob die Operation erfolgreich ist oder fehlschlägt, werden diese Dateien bereinigt. Dieses Verhalten reduziert das Risiko, dass sensible private Schlüsselreste nach der Ausstellung auf dem System verbleiben.
Subject-Feld-Bereinigung
Sonderzeichen in Subject-Feldern wie CN werden in eine sichere Form umgewandelt. Dies verhindert, dass unerwartete Zeichen während der Befehlsausführung und Dateigenerierung Probleme verursachen. Der Zertifikatausstellungs-Ablauf wird vorhersehbarer.
Namespace-Bewusstsein
Zertifikatausstellung und OpenSSL-Operationen können mit Netzwerk-Namespace-Bewusstsein ausgeführt werden. Dies hilft dabei, dass Operationen in mandantenfähigen oder isolierten Netzwerkkontexten in der richtigen Umgebung laufen. Zertifikatoperationen laufen nicht aus dem Takt mit dem Mandanten- oder Netzwerk-Isolationsmodell.
Dual-Parser-Resilienz
Für das Zertifikat-Parsing können zwei verschiedene Parser-Ansätze verwendet werden. Wenn ein Parser bei einem bestimmten Format versagt, tritt der andere Parser als Fallback ein. Dieses Design macht die Metadaten-Extraktion robuster für Zertifikate aus verschiedenen Quellen.
Wann zu verwenden
mTLS-Client-Zertifikate an Mobilgeräte verteilen
Die Organisation kann ein 1-jähriges, passwortgeschütztes P12 mit einem eindeutigen CN für jedes Mobilgerät ausstellen. Diese Ausgabe wird per MDM auf das Gerät übertragen, und die Client-Zertifikat-Identität wird für AAM- oder API-Zugriff verwendet.
Zertifikat-Identität für B2B-Partner-API-Zugriff
Für jeden Partner kann ein separates Client-Zertifikat ausgestellt werden, wobei der CN der Partner-Identität zugeordnet wird. TR7 kann über die Zertifikat-Identität in mTLS-Zugriffsprotokollen nachverfolgen, welcher Partner auf welche API zugreift.
Zertifikatausstellung beim IoT-Geräte-Onboarding
Eine IoT-Geräte-Seriennummer kann als CN verwendet werden, und für jedes Gerät kann ein separates Zertifikat ausgestellt werden. Während der Fertigung oder Installation wird das P12-Paket auf das Gerät geladen, und die Geräteidentität wird über das Zertifikat verifiziert.
Schnelle selbstsignierte CA in Testumgebungen
Das Entwicklungsteam kann kurzlebige Zertifikate in Staging ausstellen und an Test-Backends verteilen. mTLS- und Zertifikatketten-Verhalten können validiert werden, ohne auf einen externen PKI-Prozess zu warten.
Häufig gestellte Fragen
Kann TR7 Client-Zertifikate ohne externen PKI-Server ausstellen?
Kann TR7 unsere interne CA sein, oder signiert es nur Client-Zertifikate?
Wie sperren wir ein Zertifikat und sind sicher, dass es wirklich nicht mehr funktioniert?
Kann die P12-Ausgabe direkt an einen Benutzer oder ein Gerät verteilt werden?
Kann TR7 einen CSR zur Übermittlung an eine Unternehmens-CA generieren?
Wie funktioniert die Konvertierung zwischen PFX/P12 und PEM?
Wie werde ich benachrichtigt, wenn ein Zertifikat dem Ablauf naht?
Welche Kryptoparameter werden für die mTLS-Zertifikatausstellung verwendet?
mTLS-Zertifikatausstellung geräteinternen verwalten
CSR-Generierung, CA-Signierung, P12-Verteilung und Zertifikat-Metadaten-Verfolgung — ohne externen PKI-Server. Lassen Sie uns ein Live-Setup in Ihrer eigenen Umgebung durchgehen.