01 / Der Ursprung
AUTOMATISIERTES ZERTIFIKATSMANAGEMENT
Vertrauen.
Das bleibt.
aethercert erfasst, erneuert und installiert TLS-Zertifikate automatisch auf Ihren Systemen. Manuelle Ablaufkontrollen, Erinnerungen und wiederkehrende Handgriffe entfallen.
Kostenloser Plan, keine Zahlungsdaten nötig. Während der Skalierungsphase ist aethercert nur auf Einladung verfügbar. Hinterlassen Sie Ihre E-Mail-Adresse; wir melden uns persönlich bei Ihnen.
Den Äther entdecken02 / Der Äther
Die unsichtbare Ebene dazwischen.
Der Äther bezeichnete in der griechischen Mythologie die klare Luft jenseits der sichtbaren Welt. Moderne Infrastruktur hat ihre eigene unsichtbare Ebene: Zertifikate, die Identitäten absichern und verschlüsselte Verbindungen zwischen Systemen ermöglichen.
aethercert macht diesen Bestand sichtbar, steuerbar und nachvollziehbar.
Clarity · Transparency · Knowledge
Dorthin, wo es zählt03 / Ihre Welt
Dort, wo Technik zuverlässig laufen muss.
Ihre Anwendungen, Ihr Team, Ihre Kunden. Ein Zertifikat erfüllt seinen Zweck erst im laufenden Dienst. aethercert erneuert und verteilt es dort, wo es gebraucht wird.
Die wiederkehrende Arbeit verschwindet. Die Kontrolle bleibt bei Ihnen.
- Windows- und Linux-Systeme
- Automatische Erneuerung und Bereitstellung
- Keine eingehenden Firewall-Regeln
04 / Das Fundament
Automatisierung bewährt sich im Betrieb. Zertifikate müssen rechtzeitig erneuert, am richtigen Ziel installiert und vom Dienst tatsächlich übernommen werden.
Worauf wir bauenTechnik, die sich im Betrieb bewährt.
Unsere Maßstäbe zeigen sich nicht in Schlagwörtern, sondern in Architektur, Produktentscheidungen und im täglichen Betrieb.
Verlässlichkeit
Jeder Erneuerungsversuch wird erfasst. Fehler bleiben sichtbar, erfolgreiche Abläufe belegbar.
Klarheit
Zertifikate, Ablaufdaten, Zustände und nächste Schritte stehen an einem Ort.
Sicherheit
Private Schlüssel entstehen auf Ihren Servern und verlassen diese nicht.
Nachvollziehbarkeit
Architektur, Datenflüsse, Grenzen und relevante Ereignisse sind dokumentiert.
Wissen
Verständliche Dokumentation macht technische Zusammenhänge zugänglich und Entscheidungen leichter.
Verantwortung
Wir trennen klar, was aethercert automatisiert, was lokal ausgeführt wird und wo administrative Entscheidungen bleiben.
Unabhängigkeit
Installierte Zertifikate funktionieren weiter, auch wenn aethercert vorübergehend nicht erreichbar ist.
Sorgfalt
Vom ersten Erfassen bis zur nächsten Erneuerung behandeln wir Zertifikatsbetrieb als Infrastruktur, nicht als Nebenaufgabe.
Ein durchgängiger Ablauf für den Zertifikatslebenszyklus
aethercert behandelt jedes verwaltete TLS-Zertifikat nach demselben Muster: Bestand erfassen, rechtzeitig ausstellen oder erneuern, am tatsächlichen Ziel bereitstellen und jeden Schritt protokollieren.
- 01Erfassen
- 02Ausstellen / erneuern
- 03Bereitstellen
- 04Prüfen
Zertifikatsausfälle sind vermeidbar. Trotzdem passieren sie.
Nicht, weil Teams nachlässig arbeiten. Ablaufdaten, Systeme und Zuständigkeiten sind über die Infrastruktur verteilt, während der Betrieb zuverlässig weiterlaufen muss.
Kürzere Laufzeiten erhöhen den Takt
Die Laufzeit öffentlich vertrauenswürdiger Zertifikate wird schrittweise auf 47 Tage verkürzt. Prozesse, die von Hand noch überschaubar waren, werden damit dauerhaft unpraktikabel.
Zertifikate verteilen sich über die Infrastruktur
Webserver, Mailserver, interne Anwendungen und vorgeschaltete Appliances nutzen eigene Zertifikate und jeweils unterschiedliche Installationswege.
Die eigentliche Arbeit beginnt nach der Ausstellung
Das neue Zertifikat muss auf das richtige System, in den richtigen Store und anschließend vom verwendenden Dienst übernommen werden.
Manuelle Inventare altern schnell
Excel-Listen und Kalendertermine bleiben nur dann vollständig, wenn jede Änderung an der Infrastruktur konsequent nachgetragen wird.
Fehler bleiben bis zur Wirkung unsichtbar
Ohne zentrales Monitoring fällt eine fehlgeschlagene Erneuerung oft erst durch Browserwarnungen, gestörte Integrationen oder Benutzerhinweise auf.
Zuständigkeiten verlaufen über mehrere Teams
Webbetrieb, Infrastruktur-Team und externe Dienstleister teilen sich die Verantwortung. Ohne festen Ablauf entstehen leicht Lücken.
Keiner dieser Schritte ist für sich kompliziert. Die Herausforderung liegt darin, sie dauerhaft, rechtzeitig und auf jedem System korrekt zu wiederholen. aethercert übernimmt genau diesen wiederkehrenden Betrieb.
Einmal einrichten. Danach läuft der Zyklus.
Der Agent wird pro Server einmal installiert und konfiguriert. Anschließend übernimmt aethercert den wiederkehrenden Ablauf.
Agent auf den Zielsystemen installieren
Ein Befehl mit erhöhten Rechten registriert den Windows- oder Linux-Server und installiert den Agent als Dienst. Der Agent baut ausschließlich ausgehende Verbindungen auf. Eine eingehende Firewall-Regel, ein VPN oder eine öffentliche IP-Adresse sind nicht erforderlich.
Vorhandenen Bestand erfassen
Der Agent meldet die lokal installierten Zertifikate samt Ablaufdatum. Anschließend legen Sie fest, welche Hostnamen aethercert verwalten soll, welche CA ausstellt und wo das Zertifikat bereitgestellt wird.
Erneuerung und Bereitstellung übernehmen lassen
aethercert plant die Erneuerung vor dem Ablaufdatum. Der Agent erzeugt einen neuen privaten Schlüssel, fordert das Zertifikat an, installiert es am konfigurierten Ziel und lädt den Dienst neu. Jeder Versuch wird protokolliert.
Vier Phasen, ein wiederholbarer Ablauf
Ob öffentliches Zertifikat auf einem Webserver oder internes Zertifikat aus der eigenen CA: Der Ablauf bleibt gleich und wird nach der Einrichtung automatisch wiederholt.
- 01Erfassen
Vorhandene Zertifikate sichtbar machen
Jeder Agent inventarisiert die Certificate Stores und Zertifikatsverzeichnisse auf seinem Host und meldet gefundene Zertifikate mit Ablaufdatum. Die Erfassung bleibt lokal: Der Agent scannt nicht das Netzwerk und liest kein privates Schlüsselmaterial.
- 02Ausstellen / erneuern
Ein neues Zertifikat vor Ablauf des alten
aethercert plant die Erneuerung mit einem definierten Vorlauf, standardmäßig 30 Tage. Der Agent erzeugt einen neuen Schlüssel auf dem Server und fordert ein Zertifikat bei der gewählten CA an. Das bisherige Zertifikat bleibt aktiv, bis das neue installiert ist. Fehlgeschlagene Versuche werden automatisch wiederholt.
- 03Bereitstellen
Dort installiert, wo der Dienst es verwendet
Die Erneuerung ist erst abgeschlossen, wenn der Dienst das neue Zertifikat verwendet. Der Agent schreibt es in IIS-Bindings, Exchange- oder Remotedesktop-Konfigurationen, NGINX- oder Apache-Verzeichnisse oder über die API eines Load Balancers. Er setzt erforderliche Schlüsselberechtigungen und lädt den Dienst neu.
- 04Prüfen
Geprüft und protokolliert
Jede Ausstellung, Erneuerung und Bereitstellung wird in einem unveränderlichen Protokoll erfasst. Gespeichert werden der auslösende Akteur und bei Fehlern die ursprüngliche Meldung der CA oder des Agents.
Jeder Vorgang bleibt nachvollziehbar
Das Dashboard zeigt den aktuellen Zustand. Die Historie erklärt, wie er entstanden ist.
Das Dashboard priorisiert, was Aufmerksamkeit braucht
Sie sehen Zertifikate mit Ablauf innerhalb der nächsten 30 Tage, bereits abgelaufene Zertifikate, Agents ohne aktuellen Check-in und den Status der Jobs im letzten Monat.
Jeder Versuch bleibt in der Historie
Ausstellung, Erneuerung, Installation und administrative Änderungen werden in einem unveränderlichen Protokoll erfasst. Auch ein Owner kann Einträge nicht bearbeiten oder löschen. Die Aufbewahrungsdauer beträgt je nach Tarif 7, 30 oder 90 Tage.
Fehler zeigen ihre technische Ursache
Fehlgeschlagene Jobs enthalten den ursprünglichen Fehlertext der CA oder des Agents. Dadurch lässt sich die Ursache analysieren, ohne dass Details in generischen Meldungen verloren gehen.
Vorhandenes Monitoring bleibt nutzbar
Im Pro-Tarif stellt aethercert Flottenmetriken für CheckMK, Prometheus und Grafana bereit. Relevante Ereignisse lassen sich per Webhook, Syslog/CEF oder SNMP-Trap weiterleiten.
certificate.issuedapp.example.com · EC-256 · 90 daysagent web-012m agojob.succeededdeploy to nginx :443, reloadedagent web-012m agocertificate.renewed*.internal.corp via Corp Issuing CAagent adcs-011h agojob.retry_scheduledvpn.example.com deploy failed, retry 2/3agent ns-adc3h agocertificate.discoveredportal.example.com found on ns-adcscan6h agoDort installieren, wo TLS tatsächlich endet
Die Erneuerung ist erst abgeschlossen, wenn der verwendende Dienst das neue Zertifikat übernommen hat. Der Agent installiert es direkt am konfigurierten Ziel.
- IIS-Site-Bindings
- Exchange: SMTP, IIS, POP, IMAP
- Remotedesktop und vollständige RDS-Rollen
- WinRM-HTTPS-Listener
- Windows Certificate Store
- NGINX und Apache
- Postfix und Dovecot
- Dienste, die Zertifikate aus dem Dateisystem lesen
- systemd-Reload nach der Installation
- Citrix NetScaler über die API
- Anwendungen in Docker-Containern
- Lokale Skripte auf dem Agent-Host
Öffentliche CA, interne PKI oder eigener ACME-Server
Let's Encrypt ist ohne zusätzliche CA-Konfiguration nutzbar. Google Trust Services, ZeroSSL, SSL.com und Actalis werden über ein EAB-Schlüsselpaar angebunden. Dasselbe gilt für andere ACME-Server, einschließlich selbst gehosteter Instanzen wie step-ca oder EJBCA. Active Directory Certificate Services bindet aethercert über einen Connector auf dem CA-Host an. Der CSR wird direkt vom Agent über den Connector zur CA übertragen und verlässt Ihr Netzwerk nicht.
Interne PKI automatisierenLet's Encrypt
ohne zusätzliche CA-Konfiguration
EAB-Zertifizierungsstellen
Google Trust Services, ZeroSSL, SSL.com, Actalis
Selbst gehostetes ACME
step-ca, EJBCA, eigener Server
AD CS
über den CA-Connector
Nur ausgehende Verbindungen. Private Schlüssel bleiben lokal.
Diese Punkte sind für die technische Freigabe eines Agents auf produktiven Systemen entscheidend. Sie beschreiben die aktuelle Implementierung.
Nur ausgehend
Der Agent öffnet eine HTTPS-Verbindung zur Control Plane und nimmt selbst keine Verbindungen entgegen. Es sind keine eingehende Firewall-Regel, kein VPN und keine öffentliche Adresse erforderlich. Der Betrieb hinter NAT oder Proxy funktioniert unverändert.
Ruhig im Leerlauf, schnell bei Jobs
Standardmäßig erfolgt der Check-in alle drei Stunden, im Pro-Tarif bis auf 30 Minuten konfigurierbar. Sobald ein Job ansteht, verkürzt die Control Plane das Intervall auf etwa zehn Sekunden.
Private Schlüssel entstehen am Ziel
Bei der ersten Ausstellung und bei jeder Erneuerung wird ein neuer privater Schlüssel auf dem Server erzeugt, der das Zertifikat verwendet. Er wird nicht übertragen. Die Control Plane speichert Seriennummer, Fingerabdruck und Gültigkeit.
Ein optionaler interner Listener
Der CA-Connector für Active Directory Certificate Services ist die einzige Komponente mit einem Listener. Er ist ausschließlich im internen Netzwerk für die eigenen Agents vorgesehen.
Ihr Netzwerk
aethercert-Agents
auf Ihren Servern
CA-Connector
optional, nur intern
aethercert Control Plane
nur Metadaten, Betrieb in Deutschland
Für IT-Teams ohne eigenes PKI-Spezialteam
aethercert richtet sich an Unternehmen und Dienstleister, die Zertifikate zuverlässig betreiben müssen, ohne daraus eine eigene Disziplin im Tagesgeschäft zu machen.
Was Ihre technische Freigabe wissen sollte
Die wichtigsten Eigenschaften des Agents für Architektur-, Sicherheits- und Betriebsprüfung.
Private Schlüssel bleiben auf dem Server
Der private Schlüssel wird bei der ersten Ausstellung und bei jeder Erneuerung auf dem verwendenden Host erzeugt und nicht übertragen. Die Control Plane speichert ausschließlich Metadaten wie Seriennummer, Fingerabdruck und Gültigkeitszeitraum.
Das Dashboard kann keinen ausführbaren Code hochladen
Ein Deployment-Ziel kann einen Reload-Befehl oder ein lokales Skript mit Root-Rechten ausführen. Eigene Skripte müssen bereits auf dem Agent-Host vorhanden sein. Das Dashboard referenziert sie lediglich. Variablen werden als Umgebungsvariablen übergeben und nicht in eine Shell interpoliert.
Rollen werden in der Datenbank durchgesetzt
Viewer, Member, Admin und Owner werden per Row-Level-Security durchgesetzt, nicht nur über die Oberfläche. Die Konfiguration eines Deployment-Ziels erfordert Admin-Rechte, da sie einem Deployment näherkommt als einer reinen Zertifikatseinstellung. Multi-Faktor-Authentifizierung ist verpflichtend und kann nicht deaktiviert werden.
Betrieb in Deutschland
Die Anwendung läuft bei Hetzner in Nürnberg, die Datenbank bei Supabase in Frankfurt. Cloudflare dient als TLS-terminierender Proxy und verarbeitet den Datenverkehr, speichert jedoch keine Anwendungsdaten. Private Schlüssel und Zertifikate bleiben auf Ihren eigenen Systemen.
Häufige Fragen
Funktionsweise
Was passiert, wenn ein Zertifikat bald abläuft?
Für ein von aethercert ausgestelltes Zertifikat wird die Erneuerung standardmäßig 30 Tage vor Ablauf eingeplant. Das bisherige Zertifikat bleibt aktiv, bis das neue installiert ist. Fehlgeschlagene Versuche werden bis zu dreimal wiederholt. Der ursprüngliche Fehlertext der CA erscheint in der Job-Historie. Bereits erkannte, aber noch nicht verwaltete Zertifikate kann aethercert nicht selbst erneuern. Sie erscheinen jedoch in derselben nach Ablaufdatum sortierten Übersicht.
Wie funktioniert die Erneuerung genau?
Technisch handelt es sich um eine Neuausstellung. Der Agent erzeugt auf dem Server einen neuen privaten Schlüssel, fordert ein neues Zertifikat an, installiert es am konfigurierten Deployment-Ziel und lädt den Dienst neu. Das Zertifikat erhält eine neue Seriennummer und einen neuen Fingerabdruck. Konfigurationen mit Certificate Pinning müssen entsprechend angepasst werden.
Kann aethercert bereits vorhandene Zertifikate verwalten?
Agents erfassen vorhandene Zertifikate mit ihrem Ablaufdatum und zeigen sie im Dashboard an. Für diese Zertifikate liegen jedoch weder der private Schlüssel noch die ursprüngliche Ausstellungskonfiguration vor, daher kann aethercert sie nicht direkt erneuern. Um ein Zertifikat zu übernehmen, legen Sie ein verwaltetes Zertifikat für dieselben Namen an. Künftige Ausstellungen und Erneuerungen laufen dann über aethercert.
Was passiert, wenn ein Server vorübergehend offline ist?
Der ausstehende Job bleibt in der Warteschlange und wird beim nächsten Check-in des Agents übernommen. Das bereits installierte Zertifikat funktioniert währenddessen weiter. Das standardmäßige Vorlauffenster von 30 Tagen schafft ausreichend Reserve für vorübergehende Ausfälle.
Zugriff und Sicherheit
Braucht aethercert eingehenden Zugriff auf mein Netzwerk?
Nein. Agents bauen ausschließlich ausgehende HTTPS-Verbindungen auf. Eine eingehende Firewall-Regel, ein VPN oder eine öffentliche IP-Adresse sind nicht erforderlich. Nur der optionale Connector für Active Directory Certificate Services stellt im internen Netzwerk einen Listener für die eigenen Agents bereit. Aus dem Internet muss er nicht erreichbar sein.
Worauf hat der Agent Zugriff?
Der Zugriff ist auf den Host beschränkt, auf dem der Agent installiert ist. Dort läuft er mit administrativen Rechten, da diese für Änderungen am Windows Certificate Store und für das Neuladen von Diensten erforderlich sind. Er liest lokale Certificate Stores und Zertifikatsverzeichnisse zur Bestandserfassung und schreibt verwaltete Zertifikate ausschließlich an die konfigurierten Ziele. Andere Systeme im Netzwerk werden nicht untersucht.
Was passiert mit privaten Schlüsseln?
Der Agent erzeugt bei jeder Ausstellung und Erneuerung einen privaten Schlüssel auf dem Server, der ihn verwendet. Der Schlüssel wird nicht übertragen. aethercert speichert nur Zertifikatsmetadaten wie Seriennummer, Fingerabdruck und Gültigkeitszeitraum. Verlorene Schlüssel kann die Plattform deshalb nicht wiederherstellen. Nach einem Serververlust wird das Zertifikat neu ausgestellt.
Wo läuft aethercert?
Die Control Plane mit dem Dashboard wird in Deutschland betrieben. Die Anwendung läuft bei Hetzner in Nürnberg, die Datenbank bei Supabase in Frankfurt. Cloudflare dient als TLS-terminierender Proxy und DDoS-Schutz, speichert jedoch keine Anwendungsdaten. Die Agents laufen in Ihrer eigenen Infrastruktur.
Was passiert, wenn aethercert selbst nicht erreichbar ist?
Installierte Zertifikate funktionieren ohne Verbindung zu aethercert weiter. Während eines Ausfalls pausiert lediglich die Planung neuer Jobs. Sobald die Control Plane wieder erreichbar ist, werden ausstehende Erneuerungen fortgesetzt. Das standardmäßige Vorlauffenster von 30 Tagen bietet dafür ausreichend Reserve.
Einsatz
Welche Server werden unterstützt?
Unterstützt werden Windows Server mit einem Agent als Windows-Dienst und Linux-Systeme mit systemd. Der Agent benötigt lokale Administrator- beziehungsweise Root-Rechte und ausschließlich ausgehenden HTTPS-Zugriff auf die Control Plane. Zertifikate können außerdem auf Citrix NetScaler und in laufenden Docker-Containern bereitgestellt werden.
Muss ich ACME, DNS-01 oder PKI verstehen, um aethercert zu nutzen?
Nein. Für die Einrichtung eines Zertifikats geben Sie den Hostnamen an, wählen eine Zertifizierungsstelle und legen das Bereitstellungsziel fest. Let's Encrypt ist bereits vorkonfiguriert. Die technische Funktionsweise ist dokumentiert, für den laufenden Betrieb ist dieses Wissen jedoch nicht erforderlich.
Kann ein IT-Dienstleister mehrere Kundenumgebungen verwalten?
Ja. Im MSP-Tarif ist jeder Kunde eine getrennte Organisation mit eigenen Daten, Agents und Zugriffsrechten. Alle Kunden werden über ein zentrales Konto und eine konsolidierte Rechnung verwaltet. Mitarbeiterzugriffe lassen sich auf bestimmte Kunden und Rollen beschränken.
Gibt es einen kostenlosen Tarif zum Ausprobieren?
Ja. Free umfasst ein Let's-Encrypt-Zertifikat, einen Agent und eine Domain und erfordert keine Zahlungsdaten. Damit lässt sich der vollständige Ablauf auf einem realen Server testen. Während der Skalierungsphase ist die Registrierung nur auf Einladung möglich und beginnt mit einer kurzen Warteliste.
Weitere Details finden Sie in der Dokumentation. Den Funktionsumfang der einzelnen Tarife zeigt die Preisseite.
Zertifikatsbetrieb aus der manuellen Routine nehmen
Testen Sie aethercert kostenlos mit einem Server und einem Zertifikat in Ihrer eigenen Infrastruktur. Wenn der Ablauf passt, erweitern Sie die Bereitstellung schrittweise.
Kostenloser Plan, keine Zahlungsdaten nötig. Während der Skalierungsphase ist aethercert nur auf Einladung verfügbar. Hinterlassen Sie Ihre E-Mail-Adresse; wir melden uns persönlich bei Ihnen.