Let’s Encrypt unter Ubuntu und Nginx einrichten

Vor einigen Tagen habe ich damit begonnen alle von mir betriebenen Webseiten auf TLS umzustellen. Dabei nutzte ich Zertifikate der Zertifizierungsstelle Let’s Encrypt. Let’s Encrypt ging dabei im letzten Jahr in Betrieb und liefert kostenlose Zertifikate für TLS. Die CA wird dabei unter anderem von der EFF und Mozilla unterstützt. Im Gegensatz zu anderen Lösungen ist der Prozess bei Let’s Encrypt hochgradig automatisiert, so das die Einrichtung schnell von statten geht.

Der offizielle Client hört dabei auf den Namen Certbot (früher Let’s Encrypt Client) und implementiert das ACME-Protokoll (Automated Certificate Management Environment) über welches der Prozess abgewickelt wird. Neben dem offiziellen Client gibt es viele weitere Clients welche das ACME-Protokoll implementieren. Um Let’s Encrypt unter Ubuntu zu nutzen, muss im ersten Schritt der Client installiert werden:

apt-get install letsencrypt

Nachdem der Client installiert wurde, kann mit der Erzeugung der Zertifikate begonnen werden. Im Gegensatz zu Apache wird unter Nginx die automatische Einrichtung nicht unterstützt. Aus diesem Grund werden nur die Zertifikate mit dem Client erzeugt. Dies geschieht mit dem Befehl:

letsencrypt certonly

Damit wird der interaktive Modus gestartet in welchem das Zertifikat erzeugt werden kann. Zuerst wird nach einer Mailadresse gefragt, mit welcher das Recovery in Notfällen möglich ist. Anschließend müssen die allgemeinen Geschäftsbedingungen akzeptiert werden. Nun wird nach den Domains gefragt, für welche ein Zertifikat erstellt werden soll. Hier kann man mehrere Domains per Komma bzw. Leerzeichen getrennt angeben – allerdings scheint dies in der aktuellen Version nicht zu funktionieren. Stattdessen wird nur für die erste angegebene Domain ein Zertifikat erzeugt. Standardmäßig benötigt Certbot während der Generierung der Zertifikate Zugriff auf den Port 80. Hintergrund für dieses Verhalten ist das der Client kurz einen Webserver aufsetzt um die Kommunikation mit der CA durchzuführen.

Abgelegt werden die erzeugten Zertifikate dabei im Ordner /etc/letsencrypt/. In diesem Ordner liegen neben den Stammzertifikaten auch die eigentlichen Zertifikate für die einzelnen Domains. Nun kann dieses Zertifikat in Nginx eingebunden werden. Dazu muss die Konfigurationsdatei der jeweiligen Seite (z.B. /etc/nginx/sites-available/example) geöffnet werden. Im ersten Schritt wurde dazu in der Konfiguration eine Weiterleitung eingerichtet:

server {
        listen 80;
        listen [::]:80;

        server_name .example.org;

        return 301 https://$host$request_uri$is_args$args;
}

Diese Weiterleitung sorgt dafür das eine Verbindung über unverschlüsseltes HTTP automatisch auf die verschlüsselte Variante umgeleitet wird. Weiter geht es mit der Konfiguration der verschlüsselten Verbindung:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;

        ...

Jedes erzeugte Zertifikat von Let’s Encrypt ist 90 Tage lang gültig, so das ein automatischer Prozess eingerichtet werden sollte um die Zertifikate automatisch zu erneuern. Mit dem Befehl:

letsencrypt renew --agree-tos

kann dabei der Erneuerungsprozess angestoßen werden. Möchte man das ganze ohne Risiko testen, so sollte der Parameter –dry-run angefügt werden.

letsencrypt renew --agree-tos --dry-run

Bei der Erneuerung der Zertifikate kann es nun vorkommen das man den Nginx-Server vorher beenden muss. Das ganze kann man in ein Skript gießen:

#!/bin/sh
service nginx stop
letsencrypt renew --agree-tos
service nginx start

Dieses Skript kann man nun zum Beispiel einmal in der Nacht per Cronjob ausführen. Der Client überprüft dabei ob eine Erneuerung notwendig ist und führt diese dann automatisch durch.

HTTPS für Gogs aktivieren

Nach der Installation von Gogs läuft dieses standardmäßig über unverschlüsseltes HTTP. Um dies zu ändern muss die app.ini welche sich im Verzeichnis gogs/custom/conf/ befindet bearbeitet werden:

nano app.ini

In der Sektion Server welche für gewöhnlich so aussieht:

[server]
DOMAIN = example.org
HTTP_PORT = 3000
ROOT_URL = http://example.org:300/
DISABLE_SSH = false
SSH_PORT = 22
OFFLINE_MODE = false

müssen einige Änderungen vorgenommen werden. Die Schlüssel PROTOCOL, CERT_FILE und KEY_FILE werden hinzugefügt und die ROOT_URL angepasst. Danach sollte die Server-Sektion in etwa so aussehen:

[server]
DOMAIN = example.org
HTTP_PORT = 3000
PROTOCOL = https
ROOT_URL = https://example.org:300/
CERT_FILE = custom/https/cert.pem
KEY_FILE = custom/https/key.pem
DISABLE_SSH = false
SSH_PORT = 22
OFFLINE_MODE = false

Nachdem die Konfiguration gespeichert wurde muss das passende Zertifikat erzeugt werden:

cd custom
mkdir https
cd https
./gogs cert -ca=true -duration=8760h0m0s -host=example.org

Damit ist Gogs nach einem Neustart des Service per HTTPS und damit verschlüsselt erreichbar.

Certificate pinning im Browser

Beim sogenannten Certificate pinning werden Zertifikate, welche für die Verschlüsselung von Webseiten und anderen Diensten genutzt werden, lokal gespeichert. Dies hat den Vorteil, das dass Zertifikat nicht einfach unbemerkt durch ein anderes Zertifikat ausgetauscht werden kann und erschwert damit das abhören von SSL/TLS-Verbindungen.

Die App konnte im App Store nicht gefunden werden. :-(

Leider ist diese Funktionalität in den gängigen Browsern nicht vorhanden. Mit dem Firefox-AddOn Certificate Patrol kann man ein solches Certificate pinning im Browser nachrüsten. Zertifikate müssen dabei einmalig akzeptiert werden – anschließend wird man informiert, wenn sich das Zertifikat ändert. Damit ist es für einen Angreifer wesentlich schwieriger geworden, dem Nutzer falsche Zertifikate unterzuschieben.

SSL und TLS Zertifikate testen

Wer seine Domains mit Zertifikaten für SSL bzw. TLS ausgerüstet, um den Aufruf per HTTPS zu ermöglichen, fragt sich am Ende wie sinnvoll das ganze konfiguriert ist.

Eine Auswertung für heise.de

Eine Auswertung für heise.de

Mit dem SSL-Test von Qualys kann man das unter ssllabs.com/ssltest/ herausfinden. Nach dem Test erfolgt eine Auswertung, welche mit einer Gesamtnote bewertet wird. Anschließend finden sich in tabellarischer Form die Einzelergebnisse.

Probleme bei der Aktualisierung des Netzwerkes einer WordPress-Multisite-Installation

Bei einer WordPress Multisite-Installation gibt es unter Updates den Punkt Netzwerk aktualisieren. Wenn man seine Multisite-Installation mit selbstsignierten Zertifikaten betreibt, kann es dabei zu folgender Fehlermeldung kommen:

https://wordpress.example.com/mysite1

Warnung! Problem beim aktualisieren von https://wordpress.example.com/mysite1. Vermutlich gab es einen Zeitablauf. Die Fehlermeldung lautet: SSL certificate problem: self signed certificate

Um das Problem zu lösen packt man folgendes Plugin, in den WordPress-Plugin-Ordner:

<?php
/*
* Plugin Name: Deactivate SSL Verify
* Description: Deactivate SSL verification
* Author: seeseekey
* Author URI: https://seeseekey.net
* Plugin URI: https://seeseekey.net
*/
add_filter('https_ssl_verify', '__return_false');
add_filter('https_local_ssl_verify', '__return_false');

Nachdem das Plugin aktiviert wurde, kann die Aktualisierung des Netzwerkes durchgeführt werden. Anschließend kann das Plugin wieder deaktiviert werden.