kaffeeringe.de

Verschlüsselung: Mein erstes Let’s Encrypt Zertifikat

Foto: Christian Schnettelker - CC BY 2.0

„Alles verschlüsseln, was man verschlüsseln kann,“ lautet die Losung spätestens seit Edward Snowden uns vor Augen geführt hat, was die Geheimdienste alles überwachen. So nach und nach kommen die verschiedenen Initiativen dazu auch in Fahrt. Ein Flaschenhals waren bisher immer die Kosten für Zertifikate. Let’s Encrypt will das ändern und bietet seit Anfang Dezember kostenlose SSL-Zertifikate an. Ich habe die freien Tage genutzt, um mir mein erstes eigenes Zertifikat zu erstellen und zu installieren.

Die meiste Zeit ist für den vergeblichen Versuch draufgegangen, Let’s Encrypt mit meinem Provider All-Inkl.com zu verkuppeln. Letztlich ist es daran gescheitert, dass All-Inkl.com selbst schon an einer Implementierung im Backend arbeitet, die freigeschaltet wird, sobald Let’s Encrypt die Beta-Phase verlässt.

Auf einem anderen Server aber ging es. Let’s Encrypt bietet einen Client, der die Zertifikate erstellt und installiert – allerdings klappt das so ganz automatisch nicht mit dem nginx-Webserver. Da musste ich ein wenig basteln:

Im Homeverzeichnis habe ich mir ein Verzeichnis SSL angelegt:

1
mkdir SSL

Dann habe ich mir den Let’s Encrypt-Client direkt aus dem Git installiert:

1
2
3
sudo apt-get install git
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Der Client legt eine Datei mit einem Namen und Inhalt aus zufälligen Zeichen an, die Let’s Encrypt dann versucht über das Internet aufzurufen. So stellt der Dienst fest, ob ich berechtigt bin, das Zertifikat für die Domain zu beantragen. Die Datei liegt dann im Verzeichnis .well_known/acme_challenge – Dieses Verzeichnis hält man am besten aus dem normalen Webverzeichnis heraus und lässt dort auch nur die Auslieferung reiner Text-Dateien zu. Deswegen lege ich die Zertifikate ab unter /var/www/letsencrypt:

1
sudo mkdir /var/www/letsencrypt

Diese Location muss nun dem nginx bekannt gemacht werden. In der Config musste ich dazu ergänzen:

1
2
3
4
5
6
7
location ^~ /.well-known/acme-challenge {
  default_type text/plain;
  root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
  return 404;
}

Jetzt kann ich das Zertifikat beantragen:

1
sudo ./letsencrypt-auto certonly --webroot -w /var/www/letsencrypt -d MYDOMAIN.COM

Nun ändere ich die Zugriffsrechte für die Zertifikatsdateien, so dass da nur herankommt, wer es wirklich muss:

1
2
3
4
chmod 600 /etc/letsencrypt/live/MYDOMAIN.COM/fullchain.pem
chmod 600 /etc/letsencrypt/live/MYDOMAIN.COM/privkey.pem
chmod 600 /etc/letsencrypt/live/MYDOMAIN.COM/chain.pem
chmod 600 /etc/letsencrypt/live/MYDOMAIN.COM/cert.pem

SSL bzw. TLS läuft üblicherweise auf Port 443 – auf dem hat mein Webserver bisher nicht gelauscht. Das muss ich jetzt umstellen und ich werden auch gleich einstellen, dass alle unverschlüsselten Anfragen auf Port 80 umgeleitet werden. In der Config steht dann am Anfang:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
server {
        listen 80;
        server_name MYDOMAIN.COM;
        return 301 https://MYDOMAIN.COM$request_uri;
}

server {
        listen  443;

        ssl on;

        ssl_certificate /etc/letsencrypt/live/MYDOMAIN.COM/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/MYDOMAIN.COM/privkey.pem;

Nun muss der Webserver einmal die neue Config laden:

1
sudo service nginx restart

Und schon ist die gesamte Site nur noch per HTTPS erreichbar!

Die Zertifikate von Let’s Encrypt sind nur 90 Tage gültig. Da ich keine Lust habe, das immer manuell zu machen, habe ich mir ein kleines Shell-Script geschrieben:

1
2
cd ~/SSL
nano update.MYDOMAIN.COM

Darin steht:

1
2
3
4
5
6
7
8
9
10
#!/bin/bash

letsencrypt/letsencrypt-auto certonly --renew-by-default --webroot -w /var/www/letsencrypt -d MYDOMAIN.COM

chmod 600 /etc/letsencrypt/live/MYDOMAIN.COM/fullchain.pem
chmod 600 /etc/letsencrypt/live/MYDOMAIN.COM/privkey.pem
chmod 600 /etc/letsencrypt/live/MYDOMAIN.COM/chain.pem
chmod 600 /etc/letsencrypt/live/MYDOMAIN.COM/cert.pem

service nginx restart

Und das rufe ich in der Crontab automatisch immer am 15. jeden Monats, morgens um 6:10 Uhr auf:

1
sudo nano /etc/crontab

Der neue Eintrag lautet:

1
10 6   15 * *   root    ~/SSL/update.MYDOMAIN.COM

Damit der Cron-Dienst das auch weiß, muss auch der einmal neu gestartet werden:

1
sudo service cron restart

Fertig.

Soweit ich das verstanden habe, funktioniert das meiste davon bei Apache als Webserver schon automatisch. Auf SSL umstellen muss man den Server trotzdem noch manuell. Für einen Service in der Beta-Phase läuft es aber schon ganz gut und auch die anderen Experimente, über die ich auf dem Weg gelesen habe, sehen vielversprechend aus. Wenn Hoster wie All-Inkl.com das System dann in ihre Kundenverwaltung einbinden, ist das nur noch ein Häkchen, das man setzen muss. Das ist gut – aber auch nur die halbe Miete. Die Umstellung einer bestehenden WordPress-Seite auf SSL hat sich auch schon nicht als ganz so einfach herausgestellt. Insgesamt wird das aber ein Schritt dazu sein, dass Verschlüsselung immer normaler wird.

Kommentare

Kai

Super, dann wollen wir hoffen, dass die Beta-Phase bald beendet wird!

Danke, dass Du mir die Anfrage bei Allinkl erspart hast!

Schreibe einen Kommentar

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

Möchtest Du benachrichtigt werden, wenn Dir hier jemand antwortet?