Let’s Encrypt – SSL

SSL – Jeder kennt das grün hervorgehobene https:// in der Browserleiste. Es steht für Vertrauen und Sicherheit, für eine seriöse Seite. Bislang waren SSL-Zertifikate sehr kostenintensiv, doch seit einiger Zeit bietet das OpenSource-Projekt letsencrypt.org Zertifikate für jeden an – kostenfrei!Das es mehr als nur notwendig ist ein SSL-Zertifikat für seine Seite zu besitzen wurde spätestens mit dem neuen Update von Firefox klar. Es droht sonst nicht nur ein schlechtes Ranking bei Google sondern auch eine Abschreckung von Usern durch die Nachricht beim Eingeben in Formulare. Daher gibt es nun vorab für die Leser des Webmasterchannels ein Tutorial, wie das begehrte HTTPS auf die Browserleiste gezaubert wird!

Dieser Artikel erschien zuerst in der AWMpro #17

In Diesem Artikel werden wir zwei Dinge tun: Anfangs verschaffen wir uns einen kleinen Überblick zum Thema ohne ins technische Detail zu gehen. Anschließend werden wir via NGINX (ubuntu) aus einer http:// Domain, eine https:// Domain machen.

Einführung – Ein sicheres Web

Das Web soll sicherer werden. An sich eine gute Sache, doch irgendwie machte kaum jemand mit. Woran kann das liegen? Oft stellte sich gerade im Webmaster-Bereich die Frage nach der Notwendigkeit, da SSL Zertifikate schnell zu einem enormen Kostenfaktor werden konnten. Doch das hat sich vergangenes Jahr geändert. Mit dem “Let’s Encrypt”-Projekt wurden nun kostenfreie SSL-Zertifikate zur Verfügung gestellt. Jedem!

Nun, wo der Kostenfaktor keine Ausrede mehr darstellt, sollte es jedem ein Leichtes sein auf SSL (Heute TSL oder HTTSL genannt) umzustellen. Schließlich bringt so ein Umstieg auch einige Vorteile mit sich. SSL steht für Sicherheit und Vertrauen. Und gerade Google möchte diese Sicherheit im Web fördern, weswegen kleine Ranking-Boni dafür verteilt werden. Mehr noch, Chrome gehört zu den am weitesten verbreiteten Browsern und immer öfter kommt es vor, dass dieser vor unsicheren Seiten warnt. Andere populäre Browser folgen diesem Beispiel und orientieren sich stark an den von Google ausgesprochenen Empfehlungen zu unsicheren Webseiten. User werden so geblockt und schnell abgeschreckt. Langfristig kann man davon ausgehen, dass Rankings dadurch verloren gehen. Mit einem SSL-Zertifikat hingegen, bekommt er, der User, das leuchtend grüne vertrauenswürdige https:// angezeigt und der User fühlt sich auf der Seite sicher. Dadurch wird er auch eher bereit sein, seine Daten einzutragen oder sich anzumelden.

Was man als Webmaster zu beachten hat

Nun, beim Umstellen auf https:// sind mir einige Stolpersteine aufgefallen. Das Generieren eines SSL-Zertifikats und das Umstellen des Servers und der Domain war ein Leichtes. Allerdings gab es nun hier und da auch Probleme mit der Darstellung oder Inhalte, die nicht geladen wurden, da die Verlinkungen nicht mehr richtig funktionierten. Soll bedeuten: Deine CSS- oder JS-Datei bindest Du mit dem Pfad src=”http://….” ein. Diese Dateien werden aufgrund von https nicht gefunden und oder blockiert. Also: Alles abändern auf src=”https://….” , oder noch besser, gerade für künftige Seiten, nur noch ein einfaches src=”//….”. So wird automatisch Dein Pfad zu http:// oder https:// , je nachdem ob Du Deine Seite mit oder ohne SSL betreibst. Dasselbe gilt auch für a href, img src und allem, bei dem man einen Dateipfad findet. (Wenn Du local entwickelst kann es zu Fehlern kommen.)

Es gibt auch noch einige andere Bedingungen zu erfüllen, damit Dein https:// grün erscheint. Ein SSL-Zertifikat alleine reicht nicht aus. Vielmehr muss der Content auf dem eigenen Server liegen oder eingebundener Content muss mindestens ebenfalls über https eingebunden sein. Sobald man z.B. ein Bannerimage via http:// Pfad einbindet, verschwindet das grüne https:// eurer Seite. Zudem erscheint in der Adressleiste des Chrome Browsers ein Schild, welches bei Mouseover den Hinweis gibt, dass diese Seite Inhalte von unsicheren Drittseiten eingebunden hat.

Dies zu wissen ist besonders wichtig bei der Arbeit mit Partnerprogrammen. Deren Inhalte können auf http wie auch https liegen. Generell ist hier jeder Anbieter anders gestrickt. So sind z.B. alle Inhalte von CamPartner und DatingPartner bereits auch via https verfügbar.

Das ist besonders Vorteilhaft, wenn man vorwiegend mit den PHP-Portalen arbeitet und diese auf https umstellen möchte.

Aber genug der Theorie, jetzt machen wir unsere Seiten “sicher”.

inhalt1

 

Tutorial

Let’s Encrypt mit Ubuntu + NGINX

Voraussetzung:

Wenn Du Dich mit einem Account verbindest der über ROOT-Rechte verfügt, kannst Du in den folgenden Befehlen den Befehl sudo weglassen.

 

Schritt 1 – Installieren von Let’s Encrypt Client

Es gibt verschiedene Möglichkeiten ein Zertifikat von Let’s Encrypt zu generieren. In diesem Beispiel nutzen wir den “certbot” von https://certbot.eff.org. Diesen werden wir nun in Schritt 1 Installieren unter dem Verzeichnis /usr/local/sbin mit den folgenden Befehlen:

 

$ cd /usr/local/sbin   

$ sudo wget https://dl.eff.org/certbot-auto

 

Nun solltest Du eine Version von certbot-auto im Verzeichnis liegen haben. Dies kannst Du Dir mit dem Befehl ls anzeigen lassen.

Als nächstes musst Du diesem Script Rechte geben, damit es auch korrekt ausgeführt wird. Dazu nutzt man den Befehl:

$ sudo chmod a+x /usr/local/sbin/certbot-auto

Das certbot-auto Script sollte nun bereit zur Nutzung sein.

 

Schritt 2 – Zertifikat erhalten

Let’s Encrypt bietet eine Vielzahl an Möglichkeiten ein SSL Zertifikat zu erhalten. Zum Beispiel über verschiedene Plugins. Natürlich nicht nur für NGINX, sondern auch für APACHE. Für die Handhabung der Zertifikate nutzt Du in diesem Beispiel das Webroot Plugin. Dies benötigt keine weitere Installation. Es macht nichts anderes als in dem Root-Verzeichnis der Webseite, die SSL erhalten soll, einen speziellen /.well-known Ordner anzulegen. Um sicherzugehen, dass dieser Ordner von NGINX auch gelesen wird, modifizieren wir die NGINX Config. Diese befindet sich in /etc/nginx/sites-available/default . Wenn Du virtuelle Server, also mehrere Domains betreibst, wirst Du sicherlich auch mehrere .conf Dateien haben. Hier musst Du jede Domain conf anpassen, die ein SSL Zertifikat erhalten soll.
Du kannst die Dateien mithilfe von nano (dem integrierten Texteditor) direkt im Terminal bearbeiten oder es mit jedem beliebigen Texteditor und einer SFTP-Verbindung tun. Falls nicht geht das ganz schnell mit $ sudo apt-get install nano . Verwende einfach den Befehl $ nano /etc/nginx/sites-available/default und schon kannst Du Dateien im Terminal bearbeiten.

Dazu im Abschnitt Server einfach folgendes hinzufügen:

 

server {

     .    .    .

     location ~ /.well-known {

          allow all;

     }

     .    .    .

}

 

Tipp: Im Texteditor nano bedeutet dieses Zeichen ^ die Taste strg.

Nun kann man die Datei speichern und auf Fehler prüfen mit dem Befehl:

$ sudo nginx -t

Wenn alles in Ordnung ist starten wir NGINX neu mit:

$ sudo service nginx restart

Nun ist es wichtig das ROOT-Verzeichnis der Webseite zu kennen, der man ein SSL Zertifikat hinzufügen möchte. Also das Verzeichnis in dem die Webseite liegt. Dieser Pfad wird nämlich unser webroot-path im nächsten Befehl. Mit dem -d Options Befehl geben wir den Domainnamen unserer Webseite an. Man kann auch mehrere Domainnamen angeben, z.B. mit und ohne www. Wichtig ist, dass die Domain hierarchisch in der richtigen Reihenfolge benannt wird. Im Beispiel jetzt farblich hervorgehoben:

$ certbot-auto certonly -1 webroot --webroot-path=/usr/share/nginx/html -d example.com -d www.example.com

WICHTIG: Der Certbot benötigt Superuser-Privilegien. Sollte er diese nicht haben, wirst Du jedesmal aufgefordert werden das entsprechende Passwort einzugeben.

Nicht erschrecken. Wenn Du den Certbot das erste Mal ausführst wirst Du nun mit lauter Meldungen überhäuft. Das ist sozusagen die Erstinstallation in der alle vom Certbot benötigten Scripte installiert werden. Jedes weitere Mal geht es direkt los.

Ebenso wirst Du beim ersten Start von Certbot einmalig nach einer Mailadresse gefragt. Ausnahmsweise solltest Du hier keine Fake-Mail angeben. Diese wird für wichtige Benachrichtigungen genutzt oder zur Wiederherstellung von verloren gegangen Zertifikat-Keys. Danach musst Du noch den Terms of Use zustimmen. Schon wird dein SSL-Zertifikat für die von Dir angegebene Domain generiert. Es sollte dann ein Text erscheinen, der ungefähr so aussieht:

IMPORTANT NOTES:
 - If you lose your account credentials, you can recover through
 e-mails sent to sammy@digitalocean.com
 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/example.com/fullchain.pem. Your
 cert will expire on 2018-01-02. To obtain a new version of the
 certificate in the future, simply run Let's Encrypt again.
 - Your account credentials have been saved in your Let's Encrypt
 configuration directory at /etc/letsencrypt. You should make a
 secure backup of this folder now. This configuration directory will
 also contain certificates and private keys obtained by Let's
 Encrypt so making regular backups of this folder is ideal.
 - If like Let's Encrypt, please consider supporting our work by:

Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 Donating to EFF:                    https://eff.org/donate-le

Zum einen sieht man das Ablaufdatum und zum anderen den Pfad zu den Zertifikaten. Um sicherzugehen, dass alles vorhanden ist kannst Du folgenden Befehl ausführen:

$ sudo ls -l /etc/letsencrypt/live/example.com

Danach solltest Du diese zu Gesicht bekommen:

lrwxrwxrwx 1 root root 40 Jan  2 11:21 cert.pem -> ../../archive/example.com/cert1.pem

lrwxrwxrwx 1 root root 41 Jan  2 11:21 chain.pem -> ../../archive/example.com/chain1.pem

lrwxrwxrwx 1 root root 45 Jan  2 11:21 fullchain.pem -> ../../archive/example.com/fullchain1.pem

lrwxrwxrwx 1 root root 43 Jan  2 11:21 privkey.pem -> ../../archive/example.com/privkey1.pem

Wer auf noch mehr Sicherheit setzt, kann sich an dieser Stelle nun eine “Diffie-Hellman Group”, eine 2048-bit-Verschlüsselung generieren. Dazu ist nur ein einfacher Befehl nötig:

$ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Das dauert nun eventuell einige Minuten aber danach hat man eine starke DH Group im Verzeichnis /etc/ssl/certs/dhparam.pem .

Schritt 3 – Konfigurieren von SSL

Jetzt wo wir ein gültiges SSL-Zertifikat haben, müssen wir unserer Seite auch sagen, dass es dieses nutzen soll, damit wir unser begehrtes Grünes bekommen.

Dafür öffnen wir die NGINX Config der Seite, welche SSL erhalten soll. In diesem Beispiel bleiben wir bei default.

Im Block server löschen wir die ersten beiden Zeilen:
 
 listen 80 default_server;

listen [::]:80 default_server ipv6only=on;

und ersetzen diese mit folgendem:

listen 443 ssl;

server_name example.com www.example.com;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Falls man die Diffie-Hellman Verschlüsselung nutzt, muss an diese Stelle noch einiges mehr hinzugefügt werden:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_prefer_server_ciphers on;
 ssl_dhparam /etc/ssl/certs/dhparam.pem;
 ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
 ssl_session_timeout 1d;
 ssl_session_cache shared:SSL:50m;
 ssl_stapling on;
 ssl_stapling_verify on;
 add_header Strict-Transport-Security max-age=15768000;

Außerhalb des Serverblocks den wir gerade angepasst haben, erstellen wir noch einen zweiten Serverblock mit dem wir eine permanente 301 Weiterleitung von http auf https einrichten. Ich persönlich erstelle diesen gerne vor dem eigentlichen Serverblock.

server {

     listen 80;

     server_name example.com www.example.com;

     return 301 https://$host$request_uri;

}

Somit werden nun alle vorherigen http://-Links und Aufrufe direkt auf die neue https://-Version umgeleitet.

Schritt 4 – Renew / Auto Renew

Ein SSL-Zertifikat besitzt lediglich die Gültigkeit von nur einem Jahr. Danach muss das Zertifikat erneuert werden. Das kann man zum einen Manuell tun, oder auch automatisch. Dies ist sinnvoll, da man oft nicht mitbekommt wann denn nun ein Zertifikat verfällt und es sich auch schnell um sehr viele Zertifikate handeln kann. Hierfür legen wir ganz einfach einen neuen CRONJOB an, also einen Befehl, den der Server zu einem bestimmten Zeitpunkt wiederholt ausführen soll.

Als erstes, zum Verständnis einmal, wie man ein Zertifikat manuell erneuert. Dafür benötigt man nur den einfachen Befehl:

$ certbot-auto renew

Nun prüft der certbot alle vorhandenen Zertifikate und verlängert diese, wenn es denn nötig ist. Da wir aber gerade erst die Zertifikate neu angelegt haben, würden wir folgende Meldung erhalten:

The following certs are not due for renewal yet:

/etc/letsencrypt/live/example.com/fullchain.pem (skipped)

No renewals were attempted.

 

Damit dieser Vorgang nun regelmäßig automatisch ausgeführt wird, legen wir nun einen CRONJOB an. Wir öffnen einen neuen CRONTAB mit dem Befehl:

$ sudo crontab -e

Und tragen die folgenden Zeilen ein:

30 2 * * 1 /etc/local/sbin/certbot-auto renew >> /var/log/ssl-renew.log

35 2 * * 1 /etc/init.d/nginx reload

 

Speichern und fertig. Schon hat man einen cronjob der den Befehl certbot-auto renew jeden Montag um 02:30 ausführt und NGINX um 02:35 neu lädt. Der Vorgang und die Meldungen werden als log im Pfad /var/log/ssl-renew.log gespeichert.

Fertig!

 

Das war’s. Schon läuft Deine Domain dauerhaft mit einem gültigen SSL Zertifikat. Wenn Du dazu auch noch alle weiteren oben genannten Bedingung erfüllst, dann erscheint dein https:// auch im sicheren Grün.

Wenn nicht, dann nutze die Webkonsole um herauszufinden welche Dateien oder Links / Pfade dein grünes https verhindern. Dazu einfach per Rechtsklick das Kontextmenü aufrufen, Element untersuchen auswählen und schon erscheint das Entwicklerfenster von Chrome.
Dort findest Du die Konsole in der alle Fehler der Webseite ausgegeben werden. Darin wird auch aufgeführt, was die Ursache dafür ist, dass dein https kein sicheres https ist. Bereinige diese Fehler auf deiner Seite und alles ist im grünen Bereich.

Categories
Know-HowSEOTutorialsWeb-Tech
No Comment

Leave a Reply

Der Countdown läuft! AC Kickoff 2018!

Ab morgen gibt es 1€ extra pro Lead*!
Jetzt schnell noch Kampagnen anpassen: https://t.co/gRyoFvvLUN

Mehr Infos gibt es hier: https://t.co/x1l5EpfZRG

*Lead = Double Opt In

AC Kickoff 2018: Amateurcommunity PPL + Revshare stornofrei!
Mehr erfahren -> https://t.co/MPlOex9UU5

Good things come to those who wait – And you have clearly waited enough for the shiny new Webmasterchannel! 🤩🤩🤩

Check out all about it on the blog.
https://t.co/sEK2JWViMM

And because we are working on our own page and the #SEO on it atm - have some cool #SeoTips ! 👌

Magazin

RELATED