Lets Encrypt in eigener Umgebung nutzen

Hier ist auch schon von @129580 der Knackpunkt der Grundidee angesprochen worden. Normal kümmert sich jeder Client selber drum und besorgt sich automatisch selber das benötigte Certifikat.

Es wird nicht von einem Server gemacht der das verteilt. Wildcard Certifikate gibt’s zwar, aber ob man‘s braucht.

Problematisch könnt‘s dann vielleicht bei Loadbalancing werden.

Ich habe auch nur ein zentrales System, was für mich die Zertifikatverwaltung macht - aus unterschiedlichen Gründen.
Das Teil prüft einmal wöchentlich, ob Zertifikate erneuert werden müssen und führt das dann entsprechend automatisch aus. Die Verifikation erfolgt dabei per DNS. Die Challenges kann mein System per HTTP-API an den PowerDNS-Server geben, der das dann in der entsprechenden Zone veröffentlicht und die Slaves triggert, das sofort zu übernehmen.

Die dabei erstellten Zertifikate werden in ein Verzeichnis auf diesem System kopiert und können von dort per HTTP abgerufen werden.
Die Betonung liegt dabei auf Zertifikate - die Private Keys lasse ich nicht automatisch austauschen und kopiere die einmalig manuell auf neu angeschlossenen Systeme. Bei den Zertifikaten und Chainfiles ist es egal, die sind ja eh öffentlich.

Einmal wöchentlich, aber einen Tag später als mein Certbot-System, rufen die angeschlossenen Server per Script die Zertifikatsdateien ab, installieren diese und laden die verknüpften Dienste neu. Das sind bei mir Webserver, Mailserver und Jabber.

Funktioniert seit über einem Jahr ganz wunderbar


(Für interessierte Nerds)
Momentan teste ich meine neue HTTPS-API, wo der Client-Server sich mit seinem aktuellen Private Key authentifziert (TLS Client Auth) und damit seinen neuen Private Key abrufen kann. Dann kann ich auch den Key-Rollover automatisieren und sogar - getriggert durch das Abrufen des Keys - automatisch neue TLSA-Records veröffentlichen

Servus,

ich nutze nur getssl auf meinem Server. Was mich an den ganzen Automatismen stört, wenn der kein neues Zertifikat abholen kann, er danach trotzdem den Apache reloaded und der dann auf die Nase fälllt.
Gleiches gilt für Postfix.

Grüße, Henere

Hi,


Warum sollte dein Apache auf die Nase fallen? Wenn der Lets Encrypt Client kein Zertifikat beziehen kann, dann ist immer noch das alte Zertifikat vorhanden. Dann kann es nur unter Umständen sein, dass die Besucher bei deiner Website aufgrund des abgelaufenen Zertifikats eine Zertifikatswarnung erhalten. In solch einem Fall könnte man eine Notification an den zuständigen Admin einrichten mitsamt Logs, damit dieser sich darum kümmert. Und der Renew bzw. der Cronjob dazu sollte man mindestens ein paar Tage (am besten mindestens eine Woche) vor dem Ablauf des Zertifikates durchführen, damit ein Admin auf solche Fehler reagieren kann.

Außerdem Reload != Restart. Bei einem Reload führt der Apache erstmals ein Config Test durch. Schlägt dies fehl, weil ein Zertifikat nicht vorhanden ist, obwohl ein Zertifikat im vhost angegeben wurde, dann führt er keinen Reload durch. Bei einem Restart würde der Dienst sofort neugestartet werden - ohne Test. Wenn er dann beim Hochfahren des Dienstes diesen Fehler feststellt, dann würde der Apache Prozess nicht mehr hochkommen. Deshalb sollte man generell nach Konfigurationsänderungen immer den Reload Befehl verwenden - niemals Restart

Viele Grüße,
Exception

Moin, bekomme es nicht mehr ganz zusammen. Ich versuche es mal:

GetSSL hat das Zertifikat verschoben um dann das Neue zu holen. Wenn das nicht geklappt hat, war das alte aber nicht mehr an der gewohnten Stelle (working). Dann kam der Restart für den Apachen.
Das war eine uralte getssl Version, die ich mit Helfe eines Programmieres dann entsprechend angepasst hatte.
Läuft bis heute einwandfrei.
Hab nicht geschaut, ob die neuen Versionen, gerade der CertBot, es anders machen. Ich hatte mich eben nur daran erinnert, was damals bei den Tests schief gelaufen ist.

Henere