Automatisierte Bereitstellung von TLS-Zertifikaten
Eine Erneuerung ist erst abgeschlossen, wenn der Dienst das neue Zertifikat verwendet. aethercert installiert jedes Zertifikat dort, wo TLS terminiert - in einer Windows-Rolle, auf einem Webserver, einem Load Balancer oder einer Firewall - und lädt es dort neu oder aktiviert es.
Alle Pakete der Target Registry stehen in jedem Plan zur Verfügung, auch in Community. Eigene Skripte setzen Standard oder höher voraus. Pläne und Limits ansehen
agent web-01 · package windows-iis-target 3.0.0
importensureBindingassignBindingverifyBindingcleanupwhen configured
Was es leistet
Nach der Ausstellung oder Erneuerung führt der Agent, der den privaten Schlüssel hält, das hinterlegte Deploy-Ziel aus. Ein Deploy-Ziel ist ein signiertes Paket aus der Target Registry: eine geprüfte Abfolge von Schritten, die das Zertifikat importiert, an den Dienst bindet, die Konfiguration neu lädt oder übernimmt und - wo das Produkt es zulässt - prüft, ob das neue Zertifikat ausgeliefert wird.
Ziele auf demselben Host laufen lokal: PowerShell unter Windows, Dateien plus Dienst-Reload unter Linux. Appliances und Plattformen mit Management-API (NetScaler, F5 BIG-IP, FortiGate, PAN-OS, vCenter, Kubernetes und weitere) erreicht ein Agent in Ihrem Netzwerk über diese API. Aus dem Internet wird keine Verbindung aufgebaut.
So funktioniert es
- 01
Ziel wählen
Ein Paket aus der Target Registry für das System auswählen - Microsoft IIS, Exchange, NetScaler ADC und weitere - oder es mit Verbindungsdaten als wiederverwendbares Deploy-Ziel speichern.
- 02
Der Agent erhält das Material
Der private Schlüssel verlässt nie den Agent, der ihn erzeugt hat. Bei Appliance-Zielen überträgt der Agent Zertifikat und Schlüssel innerhalb Ihres Netzwerks über die Management-API.
- 03
Das Paket führt seine Schritte aus
Importieren, binden, neu laden oder übernehmen - in der Reihenfolge, die das Paket festlegt. Jeder Schritt wird protokolliert; schlägt einer fehl, bricht der Lauf ab und meldet genau diesen Schritt.
- 04
Ergebnis und Wiederholung
Ein Erfolg wird am Zertifikat und im Ereignisprotokoll vermerkt. Fehler werden als dauerhaft oder vorübergehend eingestuft; vorübergehende werden wiederholt, bevor der Job als fehlgeschlagen gilt und ein Alarm entsteht.
Funktionen im Überblick
29 eigene Ziele
Windows-Rollen, Citrix und VMware, Load Balancer, Firewalls, Hypervisoren, nginx, HAProxy, Docker und Kubernetes - jedes ein signiertes, von aethercert gepflegtes Paket.
Bindungen statt nur Dateien
Die Pakete binden das Zertifikat an den Dienst, der es nutzt: IIS-Site-Bindings, Exchange-Dienste, den RDP-Listener, die SQL-Server-Instanz, ein NetScaler-Certkey, ein F5-Client-SSL-Profil.
Prüfung, wo das Produkt es erlaubt
Die Pakete für IIS, Exchange, StoreFront, Remote Desktop Services und nginx prüfen das Ergebnis nach der Installation. Andere Pakete melden das Ergebnis ihrer API-Aufrufe.
Alte Zertifikate aufräumen
Windows-Pakete können das ersetzte Zertifikat entfernen, damit sich keine abgelaufenen Kopien im Speicher sammeln.
Eigene Skripte
Passt kein Paket, kann ein .ps1- oder .sh-Skript laufen, das Sie in einem Verzeichnis ablegen, das root bzw. Administratoren gehört. Variablen werden als Umgebungsvariablen übergeben.
Manuelle Übergabe per E-Mail
Für Systeme, die sich nicht automatisieren lassen, verschickt aethercert die Benachrichtigung über Ihr eigenes Microsoft 365 oder SMTP, damit jemand das Zertifikat installiert.
Im Vergleich zur manuellen Bereitstellung
| Von Hand | Mit aethercert |
|---|---|
| PFX exportieren, auf den Server kopieren, importieren, Binding ändern, neu starten - für jeden Host erneut. | Dasselbe signierte Paket läuft auf jedem Host, in derselben Reihenfolge, jedes Mal. |
| Appliance-Zertifikate werden über eine Weboberfläche hochgeladen und manuell übernommen. | Das Paket lädt hoch, bindet und übernimmt über die API der Appliance. |
| Private Schlüssel wandern per E-Mail, Dateifreigabe oder USB-Stick. | Der Schlüssel entsteht auf dem Agent und gelangt nur auf das System, auf dem er installiert wird. |
| Ein fehlgeschlagener Import fällt erst auf, wenn das alte Zertifikat abläuft. | Ein fehlgeschlagener Schritt lässt den Job scheitern, erzeugt ein Ereignis und in Pro-Plänen einen Alarm. |
Unterstützte Infrastruktur
Alle eigenen Pakete, gruppiert nach Einsatzort. Jedes verlinkt auf seine Integrationsseite mit Versionen, Authentifizierung und Voraussetzungen.
Microsoft und Windows Server
Citrix und VMware
Load Balancer
Firewalls
Virtualisierung
Linux und Container
Sicherheitsaspekte
Signierte Pakete
Pakete der Target Registry sind signiert; der Agent prüft die Signatur, bevor er eines ausführt. Community-Pakete sind standardmäßig deaktiviert und unterliegen Ihrer Organisationsrichtlinie.
Konfiguration nur für Admins
Nur Administratoren und Inhaber der Organisation dürfen Deploy-Ziele anlegen oder ändern, denn diese führen Code auf Ihren Hosts aus.
Verschlüsselte Zugangsdaten
Passwörter und API-Tokens für Appliances werden als Secrets verschlüsselt gespeichert und nur für den Job an den Agent übergeben, der sie braucht.
Beispiel: ein erneuertes Zertifikat in IIS
Die Schritte des Microsoft-IIS-Pakets, so wie der Agent sie ausführt.
importZertifikat und Schlüssel auf web-01 in LocalMachine\My importieren.ensureBindingDas HTTPS-Binding der Site anlegen, falls es noch fehlt.assignBindingDas Binding auf das neue Zertifikat umstellen.verifyBindingPrüfen, dass das Binding den neuen Fingerabdruck verwendet.cleanupDas ersetzte Zertifikat entfernen, sofern konfiguriert.
Lösungen
Verwandte Funktionen
Dokumentation
Häufige Fragen
Zertifikatsbereitstellung
Verlässt der private Schlüssel meinen Server?
Nein. Der Agent erzeugt Schlüssel und Zertifikatsanforderung lokal. Bei einem Ziel auf demselben Host wird der Schlüssel dort verwendet; bei einem Appliance-Ziel überträgt der Agent ihn innerhalb Ihres Netzwerks direkt über die Management-API. Die aethercert-Steuerungsebene erhält ihn nie.
Was, wenn mein Produkt nicht in der Liste steht?
Nutzen Sie ein eigenes Skript auf dem Agent-Host oder erstellen Sie ein Paket für die Target Registry - als JSON-Manifest, mit dem Paket-Builder oder als Entwurf mit einem KI-Assistenten über MCP.
Prüft jedes Ziel die Bereitstellung?
Nein. Die Pakete für IIS, Exchange, StoreFront, Remote Desktop Services und nginx enthalten einen Prüfschritt. Bei anderen Zielen meldet aethercert das Ergebnis der API-Aufrufe oder Befehle, die das Paket ausgeführt hat.
Kann ein Zertifikat auf mehrere Server?
Ja, über eine Agent-Gruppe oder eine Zertifikatsrichtlinie. Jeder Agent führt das Deploy-Ziel für seinen eigenen Host aus.
Das nächste Zertifikat installiert sich selbst
Agent registrieren, Ziel wählen - und die nächste Erneuerung wird automatisch installiert.
Community-Tarif, keine Zahlungsdaten nötig. Offene Registrierung – Ihr Konto ist in wenigen Minuten eingerichtet.