Revoking and deleting certificate 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:

 

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:

 

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.

 

 

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:

 

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

How to install the Nextcloud Desktop Client at Ubuntu

Derzeit ist es sehr schwer einen Client für Linux/Ubuntu zu finden, der direkt aus Paketquellen zu installieren geht. Nachfolgend habe ich eine Doku dazu gefunden:

https://help.nextcloud.com/t/linux-distribution-packages-for-the-desktop-clients-help-out/2538/34#post_35

https://www.c-rieger.de/how-to-install-nextcloud-desktop-client-for-ubuntu/

http://repo.morph027.de/nextcloud-client.php

Ich habe mich dann aber für das folgende Repository entschieden:
https://launchpad.net/~nextcloud-devs/+archive/ubuntu/client
Ubuntu hat jetzt ein offizielles Repository zur Verfügung gestellt.

Repository einbinden und NextCloud-Client installieren:

Wenn beim o.g. Befehl („add-apt-repository“) folgender Fehler kommt, dann muss das Paket „software-properties-common“ nachinstalliert werden:

How to extend the OwnCloud LDAP Schema with additional attributes

In meinem letzten Beitrag hatte ich beschrieben, wie man den LDAP-Server um die Quotadefinitionen für Owncloud, bzw. NextCloud erweitern kann.

Hier möchte ich kurz ergänzen, wie man weitere Attribute hinzufügen kann, um z.B. weitere Cloudinstanzen mit eigenen Quotadefinitionen zu versorgen.

Hier möchte ich einfach kurz den Weg beschreiben, wie dies z.B. mit phpLDAPAdmin erledigt werden kann. Dazu muss man sich im Config-Backend anmelden und dann in die Schemadefinitionen (cn=config => cn=schema) wechseln.

Weiterlesen

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: