Zum Inhalt

HTTPS auf dem Raspberry

Seit ich meine ganzen WEB-Server auf https umgestellt habe, sind mir in der letzten Zeit vermehrt Berichte in den Fokus geraten, welche von Mozillas Misstrauensstellung gegenüber den Certificate Authorities Startcom und Wosign berichteten. In diesem Google-Dokument kann man ausführlich die Gründe für das Misstrauensvotum nachlesen. Unter Anderem wird Wosign zur Last gelegt,  sie hätten SHA1-Zertifikate zurückdatiert und nähmen es wohl auch mit der Überprüfung der Antragssteller einer Domain nicht so genau. So ist es in der Vergangenheit jemanden gelungen, sich ein gültiges github-Zertifikat ausstellen zu lassen, obwohl er dazu nicht berechtigt war.

Solch ein Misstrauensvotum durch einen großen „Browser-Herstellers“ bleibt natürlich nicht ohne Folgen. Nicht nur, dass andere Unternehmen diesem folgen und die beiden CAs auf ihre Blacklist setzen werden. Auch verlieren alle neu ausgestellten Zertifikate dieser Certificate Authorities ihre Gültigkeit. Somit beginnt das große „Diese Seite ist unsicher“-Quaken der Browser, sobald man eine Website besucht, welche solch ein Zertifikat ausliefert.

Ich habe bisher überall von Startcom Zertifikate eingesetzt. Die „Israeliten“ stellten Class 1- Zertifikate mit einer Gültigkeit von einem Jahr kostenlos aus. In meinen Augen optimal für die saubere Verschlüsselung von privaten Seiten – solange sie auch von allen Browsern als gültig und sauber angesehen wird. Da sich das in nächste Zeit ändern können, bin ich nun gezwungen, mir eine andere Bezugsstelle für Zertifikate zu suchen.

Da ich kein Geld für meine Zertifikate ausgeben möchte, fiel mir Let’s Encrypt ins Auge. Let’s Encrypt ist eine Zertifizierungsstelle (CA), welche seit Ende 2015 aktiv ist und sich die Verschlüsselung sämtlicher Internetseiten auf die Fahne geschrieben hat. Dabei kommt eine Technik zum Einsatz, welche sich „vollautomatischen“ um die Ausstellung, Konfiguration und Erneuerung der Zertifikate kümmert. Die Zertifikate selbst verlieren nach 90 Tagen ihre Gültigkeit. Somit muss der Automatismus sauber laufen. Das wollte ich zuerst auf meinem Raspberry testen. Meine Vorgehensweise habe ich hier beschrieben.

Ausgehend von einem aktuellen RASPBIAN JESSIE LITE mit schon eingerichtetem Apache2, muss das Repository für die Debian-Backports zur Sourcelist des Paketmanagements  hinzugefügt werden.

# Debian Backports
 sudo cat </etc/apt/sources.list.d/debmon.list
 deb http://ftp.de.debian.org/debian jessie-backports main
 EOF

Damit es nicht zu dem folgenden Fehler

„W: GPG-Fehler: http://ftp.de.debian.org jessie-backports InRelease: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010“

bei apt-get update kommt, müssen vorher noch die zugehörigen Schlüssel importiert werden:

# Schlüssel importieren
sudo gpg --keyserver pgpkeys.mit.edu --recv-key 8B48AD6246925553
sudo gpg --keyserver pgpkeys.mit.edu --recv-key 7638D0442B90D010

Jetzt führt man das obligatorische apt-get update durch und ist ab sofort in der Lage, Certbot für die automatische Erneuerung der Let’s Encrypt-Zertifikate auf dem Raspberry zu installieren.

# Certbot installieren
sudo apt-get install python-certbot-apache -t jessie-backports

Danach startet man die automatische Einrichtung für z.B. den Apache2 mit

# Einrichtung für Apache2-Server
 sudo certbot --apache

Nachdem man die Domain(s), für welche das Zertifikat ausgestellt werden soll, angegeben hat, wird man noch nach einer Mailadresse gefragt und muss die „Terms of Service“ abnicken. Danach „rattert“ das Script durch, erstellt die nötigen Dateien und konfiguriert den Web-Server.

congrat

Ist alles ordnungsgemäß durchgelaufen, kann man mit dem folgenden Befehl noch testen, ob die automatische Erneuerung des Zertifikats läuft.

# automatische Erneuerung des Zertifikats testen
sudo certbot renew --dry-run

In meinem Fall kam es zu der folgenden Ausgabe:

Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.

error

Das lag daran, dass ich in der zugehörigen  000-default-le-ssl.conf unter /etc/apache2/sites-available/ noch keinen Servernamen für den Vhost angegeben hatte. Hat man das erledigt, verschwindet auch die Fehlermeldung.

Zum Abschluss ist es ratsam, dass man vom Ordner /etc/letsencrypt auf jeden Fall ein Backup-Archiv erstellt und es sicher ablegt. Sollte man den Server neu einrichten, dann muss man nur den Certbot neu installieren und das Backup einzuspielen. 🙂

Published inAllgemeinRaspberry

Schreibe den ersten Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.