Automatische Zertifikatserneuerung
Jedes Zertifikat erhält bei der Ausstellung ein Erneuerungsdatum. Ist es erreicht, stellt aethercert die Erneuerung ein, der Agent erzeugt einen neuen Schlüssel, die Zertifizierungsstelle signiert, und das Deploy-Ziel installiert das Zertifikat - ohne Ticket.
Automatische Erneuerung ist in jedem Plan enthalten. Community erneuert über Let's Encrypt; andere Zertifizierungsstellen setzen Standard oder höher voraus. Pläne und Limits ansehen
Was es leistet
Die Erneuerung wird pro Zertifikat geplant, eine einstellbare Anzahl Tage vor Ablauf: standardmäßig 30, möglich sind 1 bis 90. Die Steuerungsebene stellt einen Erneuerungsjob für den zuständigen Agent ein. Der Agent erzeugt lokal ein neues Schlüsselpaar, beantragt das Zertifikat bei der hinterlegten Zertifizierungsstelle und führt das Deploy-Ziel aus.
Derselbe Ablauf gilt für öffentlich vertrauenswürdige ACME-Zertifizierungsstellen, für eine interne CA - Active Directory Certificate Services über den CA Connector, ein internes ACME oder einen REST-Signierendpunkt - und für PSW-Group-Bestellungen über den Certificate Connector.
So funktioniert es
- 01
Eingeplant
Der Scheduler findet Zertifikate im Erneuerungsfenster und stellt je einen Erneuerungsjob ein.
- 02
Abgeholt
Der Agent sieht den Job beim nächsten Check-in. Wartende Arbeit verkürzt den Check-in auf Sekunden.
- 03
Ausgestellt
Neuer Schlüssel und CSR auf dem Agent; je nach Zertifizierungsstelle ACME-Challenge, Anfrage über den CA Connector oder kommerzielle Bestellung.
- 04
Installiert und erfasst
Das Deploy-Ziel läuft, neue Seriennummer, Fingerabdruck und Ablaufdatum werden gespeichert, die nächste Erneuerung wird geplant.
Funktionen im Überblick
Erneuerungsfenster pro Zertifikat
1 bis 90 Tage vor Ablauf. Kurzlebige Zertifikate können später, langlebige früher erneuert werden.
Wiederholungen mit Einstufung
Ein Job wird bis zu dreimal wiederholt. Ratenlimits und Netzwerkfehler werden anders behandelt als eine Fehlkonfiguration, die nie gelingen wird.
Leases
Ein Job, den ein danach verschwundener Agent beansprucht hat, wird nach Ablauf der Lease wieder freigegeben. Ein abgestürzter Host blockiert keine Erneuerung.
Schlüsseltypen
Standardmäßig EC P-256; EC P-384, RSA 2048 und RSA 4096, wenn ein System sie verlangt. Community nutzt EC P-256.
Neu ausstellen und widerrufen
Ein Zertifikat bei Bedarf neu ausstellen - nach einer Schlüsselkompromittierung oder SAN-Änderung - oder über dieselbe Jobwarteschlange widerrufen.
Öffentliche und private CAs
Let's Encrypt, Google Trust Services, ZeroSSL, SSL.com, Actalis, beliebige ACME-Server, AD CS, eine REST-CA und PSW Group.
Im Vergleich zur manuellen Erneuerung
| Von Hand | Mit aethercert |
|---|---|
| Ablaufdaten stehen in einer Tabelle oder Kalendererinnerung. | Jedes Zertifikat hat sein eigenes Erneuerungsdatum und wird automatisch eingeplant. |
| Der CSR entsteht auf dem Rechner, der gerade zur Hand war. | Der Agent auf dem Zielhost erzeugt für jede Erneuerung einen neuen Schlüssel. |
| Erneuern und Installieren sind getrennte Aufgaben, oft verschiedener Personen. | Ausstellung und Bereitstellung laufen als ein Job; nach Erfolg wird die nächste Erneuerung geplant. |
| Eine fehlgeschlagene Erneuerung fällt auf, wenn Nutzer Browserwarnungen melden. | Fehler werden wiederholt, protokolliert und in Pro-Plänen an Ihr Monitoring gemeldet. |
Zertifizierungsstellen und Validierungsverfahren
Die Erneuerung funktioniert mit jeder Zertifizierungsstelle, die aethercert anbindet, und mit jedem Challenge-Typ des Agents.
Sicherheitsaspekte
Jedes Mal ein neuer Schlüssel
Jede Erneuerung erzeugt auf dem Agent ein neues Schlüsselpaar. Schlüsseldateien werden nur für den Besitzer lesbar geschrieben.
Einmal-Signiertokens für AD CS
Der CA Connector nimmt eine Anfrage nur mit einem kurzlebigen, für genau diesen Job ausgestellten Token an und gleicht die angefragten Namen damit ab.
Gehärtete Challenge-Verarbeitung
HTTP-01-Tokens der CA werden geprüft, bevor sie zu Dateinamen werden. Eine manipulierte CA-Antwort kann nicht außerhalb des Webroots schreiben.
Beispiel: Erneuerung von app.example.com
Ein Let's-Encrypt-Zertifikat mit 30 Tagen Erneuerungsfenster, bereitgestellt in nginx.
Tag 60Das Erneuerungsfenster öffnet sich; ein Job für den Agent web-01 wird eingestellt.Schlüsselweb-01 erzeugt einen neuen EC-P-256-Schlüssel und CSR.dns-01Der TXT-Eintrag wird über Ihren DNS-Anbieter veröffentlicht und validiert.DeployDas nginx-Paket schreibt die Dateien, lädt nginx neu und prüft das ausgelieferte Zertifikat.ErfasstNeues Ablaufdatum gespeichert; nächste Erneuerung 30 Tage davor geplant.
Häufige Fragen
Automatische Erneuerung
Wann wird ein Zertifikat erneuert?
Eine einstellbare Anzahl Tage vor Ablauf, standardmäßig 30, möglich sind 1 bis 90. Das Fenster gilt pro Zertifikat oder pro Zertifikatsrichtlinie.
Was passiert, wenn eine Erneuerung fehlschlägt?
Der Job wird bis zu dreimal wiederholt. Schlägt er weiter fehl, gilt er als fehlgeschlagen, ein Ereignis wird protokolliert und - in Plänen mit Monitoring-Integrationen - ein Alarm gesendet. Das alte Zertifikat bleibt in Betrieb.
Wird der alte Schlüssel wiederverwendet?
Nein. Der Agent erzeugt für jede Erneuerung ein neues Schlüsselpaar.
Kommt das mit kürzeren Zertifikatslaufzeiten zurecht?
Die Erneuerung richtet sich nach Ablaufdatum und Erneuerungsfenster jedes einzelnen Zertifikats. Kürzere Laufzeiten bedeuten häufigere, aber ebenso unbeaufsichtigte Erneuerungen.
Schluss mit dem Nachhalten von Ablaufdaten
Stellen Sie Ihr erstes Zertifikat aus - die Erneuerung ist bereits geplant.
Community-Tarif, keine Zahlungsdaten nötig. Offene Registrierung – Ihr Konto ist in wenigen Minuten eingerichtet.