TLSPilot: Certificate Lifecycle Management

Zwei Kräfte wirken gleichzeitig.

Mandanten ermöglichen eine Gruppierung von Zertifikaten und auch Credentials. Dies ermöglicht nicht nur eine schönere Ordnung, falls diese nach Teams oder Kunden aufgeteilt werden sollen, sondern ermöglicht es auch, Issuers auf bestimmten Mandanten einzuschränken oder Berechtigungen/Rollen nur auf bestimmte Mandanten auswirken zu lassen:

Falls schon eine Enterprise CA (AD Certificate Services) in der Domäne verfügbar sein sollte, dann wird diese durch TLSPilot automatisch erkannt. Alle Templates, auf welche der Management-Service Zugriff erhält und Server Authentifizierungszertifikate ermöglicht, können so direkt in TLSPilot eingebunden, durch diesen bezogen und auf die Deployment Targets übertragen werden:

TLSPilot Private CA ist ideal für Zertifikate, die keine Redundanz bei der CRL-Prüfung haben müssen. Zum Beispiel für Entra AppReg-Authentifizierung, etc. TLSPilot Private CA bietet verschiedene Key Algorythmen (inkl. ECC) und lässt auch eine CRL-Prüfung über OCSP zu:

Alles, was dem ACMEv2-Standard folgt, kann ich TLSPilot als Public Cert-Quelle eingetragen werden. Von rein kostenlosen Public Cert anbietern, wie Let's Encrypt, ZeroSSL, etc., bishin zu kommerziellen CAs, welche ACMEv2 unterstützen. Die Einbindung erfolgt in TLSPilot modular über JSON-Definitionsdateien, welche auch einfach selbst geschrieben werden können. Viele Anbieter sind schon enthalten - und benötigen nur noch eine Konfiguration.

Die Validierung der Domänen erfolgt über DNS-01, HTTP-01 oder auch TLS-ALPN-01. Viele DNS-Provider sind schon enthalten - zudem auch manuelle DNS-Konfiguration und alle, welche nach RFC2136 funktionieren. HTTP-01 kann sogar auf dem Management-Host selbst terminiert werden mit eigenem Listener:

Der Katalog mit direkten Deployment Targets ist riesig und viele Deployments lassen sich auch mit einem Dateipfad für Zertifikat und Key, sowie einem konfigurierbaren Dienstneustart/Codeblock in Powershell steuern (falls Edition "Custom Deployments" beinhaltet).

Viele Applikationen werden unter NginX, Apache, IIS, etc. betrieben und können mit diesen einzelnen Deployment-Targets schon allesamt unterstützt werden. Mit Custom Deployments ist auch Powershell-Code für eigene Deployments erlaubt. Solange es also eine Schnittstelle/API auf dem Zielsystem gibt, ist ein Deployment mit TLSPilot möglich.

Alle unterstützten Deployment Targets anzeigen

Beispiel eines Deployments Helpers, welcher RBAC mit Entra ID als Identity Provider oder einen Azure Application Gateway konfiguriert, um die notwendigen Berechtigungen für künftige Deployments zu erhalten. Alles nach Best Practice und Least Privilege Prinzip:

Damit TLSPilot von überall dort, wo du es wünschst auch verwaltbar wird, gibt es auch ein WebUI, welches einfach über den Webbrowser erreicht werden kann. Natürlich mit Authentifizierung über einen Identity Provider (AD oder Entra ID). Es sieht nicht nur gleich aus, wie das Management Tool: Es verhält sich auch genau gleich:

Role-based Access Control lässt genau und granular festlegen, welche Person oder welche Gruppe (inkl. Nested Groups) welche Zugriffsrechte erhalten sollen. Zudem kann auf jeden Zertifikat oder Credential die Vererbung auch unterbrochen und durch explizite Berechtigungen ersetzt werden:

TLSPilot beinhaltet auch ein eigenes Backupformat, welches auch automatisch alle 24 Stunden erstellt werden kann. Ein Restore von einzelnen Komponenten, welche sich verändert haben, ist so ganz einfach möglich. Mit einem Migration Backup kann die Installation auch sehr einfach und rasch auf einen anderen Server übertragen werden:

Egal, ob ein normaler Renew im Renewal-Fenster, ein forcierter Renew oder auch ein Revoke mit Ersatz-Zertifikat: Gleich danach werden die Deployments erneut gestartet und die Health des Deployment-Ziels geprüft. Sei es manuell oder auch im Hintergrund im regulären Cycle, der alle 24 Stunden läuft. Auch die Versionierung bleibt übersichtlich - mit Roll-Back Möglichkeit und in der History sind alle Aktionen zusätzlich zum Log auch aufgelistet:

Einfach, übersichtlich und klar. Das war unser Kredo bei der Entwicklung von TLSPilot. Jeder soll sich so rasch wie möglich darin zurechtfinden und Dinge dort finden, wo man diese auch erwartet:

TLSPilot weiss genau, wann der Erneuerungszeitraum für jedes einzelne Zertifikat beginnt und wann er es zu erneuern versuchen soll. Auch bei unterschiedlichen Quellen mit unterschiedlichen Laufzeiten - und auch dann, wenn sich diese immer weiter verkürzen:

Jedes Deployment Target wird regelmässig - konfigurierbar - auf die Korrektheit überprüft. Wenn etwas nicht mehr passen sollte, kann dies auch einen Alert auslösen auf Wunsch. Pro Zertifikat sind mehrere Deployment Targets möglich, welches jedes einzeln aktiviert/pausiert werden kann:

Die Secrets werden gesichert im Windows Credential Store (Local Machine) abgelegt oder können auch aus anderen Quellen kommen. Vom Azure Key Vault, über Delinea, CyberArk, BeyondTrust bishin zu anderen unterstützen Passwort Safes. Auch gMSA/dMSA mit rotierenden Passwörtern oder Zertifikate als Secrets sind möglich:

Mit Alerts können bei spezifischen Ereignissen, Meldungen an unterschiedliche Kanäle ausgelöst werden. Den Alert-Kanal, sowie auch die Ereignisse lassen sich detailliert konfigurieren:

Ob Event Logs von Windows oder klassische Log-Dateien oder auch beides in Kombination - neben Alerts können alle operativen Aktionen, Audits von manuellen Vorgängen, sowie auch Debug-Informationen jederzeit übersichtlich aufgezeichnet und nachgeschlagen werden:

Noch mehr Automatisierung gewünscht? Kein Problem: Neben dem Management Tool und WebUI bietet TLSPilot auch ein komplettes API, sowie ein PowerShell-Modul, welche alle Funktionen auch direkt ansprechen lassen: