Archiv der Kategorie: Linux

Automatically renew certificates issued with the certbot-auto script-framework

Die mit Letsencrypt erstellten Zertifikate haben per üblicherweise eine Laufzeit von 90 Tagen. Dies bedeutet natürlich, dass diese auf Grund ihrer relativ kurzen Laufzeit sehr schnell wieder ablaufen. Hier macht es keinen Sinn, zu versuchen, die Ablaufdaten der Zertifikate manuell überwachen zu wollen.

Der sinnvollste und einzig valide Weg ist daher die Überwachung und Erneuerung der Zertifikate per Cron zu automatisieren.

Hier möchte ich daher jetzt meinen Weg darstellen, wie ich die automatischen Überwachung und Erneuerung der Zertifikate umgesetzt habe.

Dafür habe ich mir 2 Bash-Scripts geschrieben, da mir die im Internet verfügbaren Lösungen alle nicht so recht gefallen haben.

Folgendes Script ruft das certbot-auto Script auf und erneuert die Zertifikate, falls notwendig. Über den Parameter „CERTBOT_PARAM“ kann man noch steuern, ob das certbot script wenig, oder gar keine Rückmeldung geben soll. Die Details dazu bitte in der Anleitung zu Letsencrypt nachlesen. Wenn ein Zertifikat erneuert wurde, dann wird der sog. „Renew-Hook“ ausgeführt. Hier in diesem Fall auch ein selbstgeschriebenes Script, welches mir dann eine Mail sendet, dass Zertifikate erneuert worden sind.

 

Hier kommt noch das Script für den Renew-Hook:

Dazu kommen nun noch die Konfigurationsfiles für den Cronjob und die Logrotation:

Dieses Setup funktioniert bei mir bisher prima. Ich bekomme nur eine Mail, wenn ein Zertifikat erneuert worden ist. Klar, die Ausgabe aus dem Log kann man noch verbessern. Bisher habe ich aber dazu noch keine Zeit gefunden. Mir ging es mit dieser Artikelreihe hier darum, einmal exemplarisch zu zeigen, wie Zertifikate mit Letsencrypt komplett implementiert werden können. Dieser Artikel ist vorerst der Abschluß dieser Reihe, da nun alle wichtigen Themen behandelt worden sind.

Später werde ich noch einmal einen Artikel schreiben, wie Letsencrypt z.B. per Cron aktialisiert werden kann, wenn man es, so wie ich, nicht aus den Paketquellen installiert hat.

Folgende Artikel gehören zu dieser Reihe der Implementierung von Letsencrypt Zertifikaten:
————————————————————

Monitoring the certificate lifetime data

LetsEncrypt server certificates setup for Apache Webserver on Debian

Requesting certificates with certbot-auto and configuring the apache webserver

Revoking and deleting certificates with the certbot-auto script framework

Automatically renew certificates issued with the certbot-auto script-framework

 

Revoking and deleting certificates with the certbot-auto script framework

Wenn ein Zertifikat, welches mit CertBot erstellt wurde, nicht mehr benötigt wird, kann man dieses auch ganz einfach über das Script-Framework deaktivieren und deinstallieren, damit es beim automatischen Erneuern nicht immer wieder unnötigt mit verlängert wird und als Ballast im System verbleibt.

Im folgenden beschreibe ich ganz kurz den Mechanismus:

 

Folgende Artikel gehören zu dieser Reihe der Implementierung von Letsencrypt Zertifikaten:
————————————————————

Monitoring the certificate lifetime data

LetsEncrypt server certificates setup for Apache Webserver on Debian

Requesting certificates with certbot-auto and configuring the apache webserver

Revoking and deleting certificates with the certbot-auto script framework

Automatically renew certificates issued with the certbot-auto script-framework

 

Requesting certificates with certbot-auto and configuring the apache webserver

In meinem vorangegangenen Beitrag LetsEncrypt server certificates setup for Apache Webserver on Debian habe ich kurz beschrieben wie man am besten LetsEncrypt auf einem Debian Server installiert. Ich habe mich bewußt für den beschriebenen Weg entschieden, da ich es nicht aus den Paketquellen installieren wollte, wobei das natürlich genauso gut funktioniert. Mit der nachfolgenden Beschreibung kann man aber dann genauso umgehen.

Mit dem Script certbot-auto kann man ganz leicht neue Zertifikate beantragen und auch im Apache Webserver konfigurieren.

Übersicht der aktuell konfigurierten Zertifikate erhält man mit dem Befehl „certbot-auto certificates“.

Es empfiehlt sich übrigens den Schalter „--no-self-upgrade“ zu benutzen, um zu verhindern, dass sich das Script selbstständig aktualisiert. Besser ist es, die Aktualisierung in einer Testumgebung vorzunehmen um den produktiven Betrieb nicht zu gefährden.

Jetzt führen wir kurz den Befehl zum Beantragen eines Zertifikates aus:

Um mehrere Subdomains in einem Zertifikat zu beantragen, kann man auch mehrere „-d“ Parameter ergänzen:

 

Jetzt noch das Zertifikat im Apache konfigurieren. In der Apache VHOST-Datei folgende Werte einfügen:

 

Folgende Artikel gehören zu dieser Reihe der Implementierung von Letsencrypt Zertifikaten:
————————————————————

Monitoring the certificate lifetime data

LetsEncrypt server certificates setup for Apache Webserver on Debian

Requesting certificates with certbot-auto and configuring the apache webserver

Revoking and deleting certificates with the certbot-auto script framework

Automatically renew certificates issued with the certbot-auto script-framework

 

LetsEncrypt server certificates setup for Apache Webserver on Debian

Dieser Beitrag soll zeigen, wie mit wenig Aufwand Zertifikate des Dienstes Let’s Encrypt unter Debian installiert werden können. Dazu muss natürlich selbst die Software noch installiert werden. Außerdem möchte ich auch noch die Benutzung und Konfiguration der Zertifikate im Apache Webserver zeigen. In einem weiteren Artikel werde ich auch noch die SSL-Konfiguration des Apache Webservers zeigen. Die Verlinkung dazu erfolgt dann später noch.

Installation von LetsEncrypt und CertBot

Erstmal clonen wir die Software aus dem GIT-Repo von Let’s Encrypt:

Hier das Listing  aus /opt/letsencrypt:

certbot-auto Script testen und aufrufen

Beim Erstaufruf des certbot-auto Scripts werden die Softwarevoraussetzungen geprüft und vom Script selbst werden div. Pakete nachinstalliert. Am besten benutzt man dafür den Befehl „certbot-auto certificates“

Im folgenden Artikel wird der genaue Beantragungsprozeß und die Installation im Apache-Server beschrieben.

 

 

Folgende Artikel gehören zu dieser Reihe der Implementierung von Letsencrypt Zertifikaten:
————————————————————

Monitoring the certificate lifetime data

LetsEncrypt server certificates setup for Apache Webserver on Debian

Requesting certificates with certbot-auto and configuring the apache webserver

Revoking and deleting certificates with the certbot-auto script framework

Automatically renew certificates issued with the certbot-auto script-framework

 

Es gibt keine öffentlichen Schlüssel für die folgenden Schlüssel-IDs

Gestern habe ich in meiner Ubuntu-Installation folgenden Fehler bekommen:

Auf der Kommandozeile dann folgenden Befehl eingeben:

Danach wurde der Schlüssel aktualisiert und nun funktioniert wieder alles bestens.

Monitoring the certificate lifetime data

Ich habe alle Zertifikate in einem Verzeichnis liegen und verweise mit der Apachekonfiguration dann auf die da liegenden *.crt Files. Folgendes Script darf dazu als Beispiel dienen.

Dann habe ich noch ein Wrapper-Script geschrieben, zum Aufruf per Cron:

Dann noch unter /etc/cron.d/ eine Datei „check_certificate_validity“ mit folgendem Inhalt anlegen:

 

Folgende Artikel gehören zu dieser Reihe der Implementierung von Letsencrypt Zertifikaten:
————————————————————

Monitoring the certificate lifetime data

LetsEncrypt server certificates setup for Apache Webserver on Debian

Requesting certificates with certbot-auto and configuring the apache webserver

Revoking and deleting certificates with the certbot-auto script framework

Automatically renew certificates issued with the certbot-auto script-framework

 

Using ArgBash to generate the Call Parameters for Bash-Scripts

Gerade jetzt im aktuellen Linux-Magazin habe ich folgenden Artikel entdeckt: Werkzeuge im Kurztest Tooltipps — Argbash.

Das Tool ArgBash gefällt mir persönlich sehr gut. Und so nutzte ich die Gelegenheit um das Tool gleich einmal zu testen.

Ein guter Start ist das Quickstart Tutorial auf der Dokumentationsseite des Projektes. Ich habe nun als erstes mir das GIT-Repo ausgecheckt.

Ein kurzer Check mit dem Beispiel von der Quickstart Sektion zeigt, dass das Script prima funktioniert:

Damit wird ein kleines Script generiert, welches nur das parsen der o.g. Parameter übernimmt. Natürlich muss dann das Script noch mit Leben gefüllt werden.

Interessanter dürfe dann aber der Abschnitt sein, wo der Parsing-Code in ein extra Script ausgelagert wird. Das muss ich aber noch mal testen:

http://argbash.readthedocs.io/en/latest/example.html#separating-the-parsing-code

LDAP CRC „ldif_read_file: checksum error“ Fehler beheben

Ich habe gerade vor einiger Zeit bei mir im LDAP Server einen Fehler entdeckt, den ich nicht verstanden habe und der mich irgendwie irritiert hat. Ich dachte zuerst schon an meiner Konfiguration sei etwas kaputt.

Es handelt sich um die folgende Fehlermeldung:

Leider ist es schwierig, gerade zu dieser Meldung irgendwie sinnvolle Antworten im Web zu finden, daher möchte ich hier eine Lösung aufzeigen, die bei mir gut funktioniert hat. Der korrekte Weg wäre wohl mit ldapmodify zu arbeiten, da wusste ich aber nicht, wie ich das genau anstellen sollte.
Die Warnung sollte man schon Ernst nehmen. Keine Garantie für irgendwelche nachfolgenden Fehler. Nun gut, bei mir hat es funktioniert.

Als Unterstützung habe ich den Artikel vom Blog LDAP: How to fix „ldif_read_file: checksum error“ benutzt. (Im gerade genannten Blog, gibt es noch einen kleinen Fehler. Wenn ich eine Datei mit „=,{,}“ oder ähnliches im Dateinamen habe, sollte ich noch Anführungszeichen um den Dateinamen setzen. Das ist bei mir natürlich korrigiert.

Als erstes benötigt man das Tool „crc32“. Hier gibt es eine Beschreibung wie es zu installieren ist How to check crc of a file?

Nun zu den Steps an sich:

 

Debian 8.0 – Jessie – PHP 7.0 installieren

Motiviert durch den Artikel auf schroeffu.ch: Debian 8 ‚Jessie‘: PHP7 neben PHP5 installieren habe ich auf meiner VM ebenfalls mal PHP 7.0 installiert.

Angelehnt, an die im o.g. Blog genannten Schritte habe ich folgendes gemacht:

Die php.ini für PHP7.0 musste ich nicht anpassen, da ich meine Anpassungen für den Apache in der zugehörigen VHOST.ini vornehme.

PHP 7.0 aktivieren im Apache:

Wie im Blog oben beschrieben, bitte zwingend immer ein PHP-Modul im Apache aktivieren, da sonst der PHP-Quellcode an den Browser ausgeliefert wird!!

Bei mir im Nextcloud musste ich noch folgende PHP-Pakete nachinstallieren, da ich sonst ziemlich seltsame Fehler bekam:

Die folgende PHP Pakete waren noch notwendig:

 

Managing OwnCloud and NextCloud User Quota with my LDAP Server

Es hat mich schon immer gestört, dass ich mit meinem LDAP-Server zwar die User verwalten kann, aber z.B. die UserQuota für meinen OwnCloud-Server immer noch per Hand in selbigem eintragen muss. Warum eigentlich? Nach etwas Suchen im Internet fand ich das GIT-Repository OwnCloud LDAP Schema von Valery Tschopp. Zuerst war mir nicht klar, ob ich das Schema überhaupt für meine aktuelle NextCloud Installation nutzen könnte, da das Schema für den Owncloud 6.0 Server geschrieben wurde? Zumindest ist die Doku für den 6er Server verlinkt. Nun gut, es funktioniert auch mit dem NextCloud 9.0.53 Server.

Zuerst clonen wir das GIT-Repo:

Ich benutze für meinen LDAP-Server das cn=config Backend. Dafür muss ich mich als root anmelden und dann den Befehl ldapadd benutzen. Daher spiele ich das Schema mit folgendem Commando ein:

Im oben genannten Link und in der README.md stehen die Details zum prüfen der Erweiterung.

Nun muss ich mich am LDAP-Server (an der GUI oder per ldif-patch) anmelden und dem User die Objektklasse „Owncloud“ hinzufügen, um anschließend dann das Attribut „ownCloudQuota“ hinzu fügen. Mache ich dann zur Kontrolle einen ldif Export, sieht das wie folgt aus: