25. März 2016

Let's Encrypt Zertifikate auf einem Webhosting Account bei webgo einrichten

Der Webhosting Provider webgo.de hat die automatisierte Erstellung von SSL Zertifikaten von Let's Encrypt in die Webhosting Pakete integriert. Praktischerweise muss daher Let's Encrypt nicht selbst installiert werden. Das Zertifikat wird im Webspace Admin mit ein paar Klicks generiert. Damit lassen sich verschlüsselte Verbindungen auch im Shared Hosting einfach realisieren.

1. Webseite vorbereiten

Zugang zu versteckten Verzeichnissen

Damit alles reibungslos klappt, sollten einige Dinge beachtet werden. Es wird automatisch eine Textdatei mit einem von Let's Encrypt generierten Inhalt erstellt. Diese wird unter der URL http://www.domain.de/.well-known/von-lets-encrypt-vorgegebener-dateiname eingestellt. Let's Encrypt prüft, ob der Inhalt der Textdatei (ein zufällig generierter kurzer Zeichensalat) unter der angegebenen Adresse im Internet erreichbar ist. Kann Let's Encrypt es lesen, wird daraufhin das Zertifikat für www.domain.de erstellt. Das alles passiert automatisch.

Allerdings ist das Verzeichnis .well-known durch den vorangehenden Punkt ein verstecktes Verzeichnis. Manche CMS blockieren den öffentlichen Zugang zu versteckten Verzeichnissen aus Sicherheitsgründen in ihren Standardeinstellungen.

Ist das der Fall, muss zuerst das Blockieren versteckter Verzeichnisse aufgehoben werden. Im Normalfall ist dieser Eintrag in der Datei .htaccess im Root Verzeichnis der Webseiten Installation zu finden. Drupal z.B. hat in seiner .htaccess folgenden Eintrag:

#RewriteRule "(^|/)\." - [F]

Diese Zeile wird wie oben mit einem # für die Dauer der Zertifikatserstellung auskommentiert. Sobald das Zertifikat erstellt ist, kann das # wieder gelöscht werden.

Ist eine*r sich unsicher, ob versteckte Verzeichnisse zugänglich sind, kann das auch leicht selbst ausprobiert werden. Dazu wird eine beliebige Textdatei mit einem Texteditor erstellt (wichtig, keine Worddatei oder ähnliches - das Format muss Plain Text sein). Z.B. die Datei 'test-datei' mit dem Inhalt 'Alles in Ordnung, versteckte Verzeichnisse sind öffentlich zugänglich.' Jetzt wird noch ein versteckter Ordner erstellt, z.B. .test-ordner (mit einem Punkt anfangen), und die test-datei dort hineingeschoben. Das ganze wird auf den Webspace in das Rootverzeichnis der Webseiten Installation hochgeladen. Im Browser wird jetzt www.domain.de/.test-ordner/test-datei aufgerufen.

Zugang zu verstecktem Verzeichnis auf der Webseite ueberpruefen

Der Ordner .well-known/von-lets-encrypt-vorgegebener-dateiname wird übrigens später automatisch wieder gelöscht.

Weiterleitung von domain.de auf www.domain.de

Besteht bereits eine Weiterleitung von domain.de auf www.domain.de, oder vice versa, muss diese auch zuerst aufgehoben werden. Zumindest war das bei mir der Fall. Ich habe es mit einer bestehenden Weiterleitung versucht, aber die Zertifikatserstellung brach mit einer Fehlermeldung ab. Erst nachdem ich die Weiterleitung in der .htaccess auskommentiert hatte, lief die Zertifikatserstellung problemlos. Bei Drupal sieht die Weiterleitung so aus (nicht-www auf www):

#RewriteCond %{HTTP_HOST} .
#RewriteCond %{HTTP_HOST} !^www\. [NC]
#RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Es gibt aber verschiedene Schreibweisen, z.B.:

#RewriteCond %{HTTP_HOST} !^www\.xyzdomain\.de$
#RewriteRule ^(.*)$ www.xyzdomain.de/$1 [L,R=301]

Das kann einfach ebenso wie oben mit einem # auskommentiert werden.

2. Zertifikatserstellung im Webspace Admin

Jetzt kann das Zertifikat erstellt werden. Dazu im Webspace Admin einloggen, und unter Paket-Verwaltung → SSL 'SSL anlegen' klicken.

Bei SSL Modus einfach 'Mit Let's Encrypt generieren' auswählen, darunter die Domain auswählen, und eine Mail Adresse angeben. Praktischerweise lässt sich auch die automatische Verlängerung aktivieren.

Die Bitlänge der Verschlüsselung von 2048 ist für Normalfälle ausreichend. Wird die Bitlänge auf 4096 verdoppelt, ist die Entschlüsselung 6-7 Mal langsamer. Das muss aber jede*r für sich selbst entscheiden. Hier gibt es einen Threat mit verschiedenen Meinungen dazu (englisch): Default RSA key bitlength should be 4096.

Außerdem ist zu bedenken, dass die Webhosting Pakete zwar preisgünstig sind, aber deswegen natürlich nicht dieselbe Serverleistung wie ein VServer oder Root Server haben.

In die Felder CRT, CSR, PrivateKey und CA wird nichts eingetragen, sondern einfach auf 'anlegen' geklickt.

Let's Encrypt Zertifikat im Webspace Admin generieren

Die Erstellung des Zertifikats ging bei mir sehr schnell, es dauerte gerade mal 15 Sekunden. Das hängt natürlich von der Verbindung ab. Die Seiten sind dann für kurze Zeit nicht erreichbar, da der Apache Server neu gestartet werden muss. Danach kann https://www.domain.de aufgerufen werden.

Aus einer Mail vom webgo Kundenservice:

"Da jeder Kunde seinen eigenen Apache besitzt, startet dieser immer einmal neu, wenn man Einstellungen im Webspace Admin vornimmt, die einen Apache-Neustart benötigen. Die Seiten sind dann ca. 1 - 2 Minuten nicht erreichbar. Aber das ist normal."

Beim Aufruf der Seite sollte nun das Schloss-Symbol erscheinen, beim Klick darauf 'Sichere Verbindung' und 'Verifiziert mit Let's Encrypt'.

Im Browser verschluesselte Verbindung ueberpruefen

webgo erstellt für jede neue Domain ein neues Zertifikat. Let's Encrypt erlaubt die Erstellung von 5 Domain Zertifikaten pro Woche, danach muss gewartet werden.

Weiterleitungen

Mein Ziel war es, alle URLs, unter der die Seite erreichbar ist, auf https://www.domain.de umzuleiten. Das sind bei mir die URLs http://www.domain.de (die unverschlüsselte Variante), http://domain.de, und https://domain.de.

Für www.domain.de als auch für domain.de muss je ein Zertifikat erstellt werden. Aus Let's Encrypts Sicht kann ein Zertifikat auch für mehrere Domains erstellt werden. Im Webspace Admin kann allerdings nur jeweils eine Domain ausgewählt werden, so dass jedesmal ein neues Zertifikat erstellt wird.

Nach der Erstellung habe ich in der .htaccess die Weiterleitung von domain.de auf www.domain.de aktiviert, indem ich in den vorher auskommentierten Zeilen das # gelöscht habe.

Die Weiterleitung von http://www.domain.de auf die verschlüsselte Variante https://www.domain.de lässt sich entweder durch einen Eintrag in der .htaccess oder auch ganz bequem im Webspace Admin vornehmen. Dazu im Webspace Admin einloggen, und unter Paket-Verwaltung → Domainverwaltung die domain.de und www.domain.de bearbeiten. Dort unter 'http automatisch zu https umleiten' 'ja' anklicken.

Domain Weiterleitung auf https

Die Reihenfolge ist: zuerst von domain.de auf www.domain.de, und dann von http auf https; auch wenn diese Einträge in der .htaccess stehen.

Eine Weiterleitung ist grundsätzlich eine gute Sache, um Duplicate Content zu vermeiden. Let's Encrypt wird auch von allen gängigen Browsern unterstützt. Hier eine Liste der Browser, die Let's Encrypt unterstützen.

Für zusätzliche Sicherheit kann auch HTTP Strict Transport Security (HSTS) zu der .htaccess hinzugefügt werden:

Header set Strict-Transport-Security "max-age=10886400"

Damit wird eine https Verbindung erzwungen, und für den angegebenen Zeitraum im Browser zwischengespeichert. So wird der Browser beim nächsten Besuch alle Elemente der Webseite von Anfang an über https aufrufen - das verhindert mögliche Angriffe.

Die max-age wird in Sekunden angegeben. Sollte später aus irgendwelchen Gründen die Webseite unverschlüsselt per http verbunden werden, z.B. weil Zertifikate gelöscht werden sollen, muss diese Zeile zuerst in der .htaccess gelöscht werden, ansonsten ist der Aufruf der Seite nicht möglich.

Die Speicherfrist gilt auch für alle Besucher*innen der Webseite,  d.h. wird für eine Webseite die verschlüsselte Verbindung zurückgenommen, werden sich Besucher*innen so lange nicht mit der Webseite verbinden können, solange der angegebene Speicher in ihrem Browser aktiv ist. Auf der anderen Seite ist ein langer Zwischenspeicher wiederum sinnvoll, da auch bei längerer Abwesenheit sich Besucher*innen gefahrlos verbinden können.

3. Probleme mit der Webseite

Manche Seiten wurden nicht richtig dargestellt oder sogar Veränderungen an der .htaccess scheinbar nicht wirksam. In der Regel lag es am Browser Cache, der Zwischenspeicherung der Webseiten. Den Browser neu zu starten hat bei mir das Problem gelöst. Auch kann im Webspace Admin unter Server → Apache Status der Apache Server neu gestartet werden, gegebenfalls auch das errorlog heruntergeladen werden.

Mixed Content

Beim ersten Aufruf der verschlüsselten Seite war das ganze Design zerstört, und der Browser warnte mich vor einer unsicheren Verbindung. Das lag an Mixed Content, d.h. einige Teile der Website werden durch die verschlüsselte Verbindung ausgeliefert, andere noch über die unverschlüsselte http Verbindung. Zuerst sollte herausgefunden werden, welche Teile genau unverschlüsselt übermittelt werden. Dazu wird der Quellcode der Seite aufgerufen. In Firefox geht das mit der rechten Maustaste, und dann 'Seitenquelltext anzeigen'. Irgendwo steht dann so etwas wie:

href="http://www.domain.de/zum-beispiel/pfad-zu-meinen-bildern/bild.jpg"

Es kann auch etwas anderes als Bilder oder Grafiken sein, z.B. Scripte. Zuerst wird geschaut, ob sich dieser Pfad auch mit einer verschlüsselten Verbindung aufrufen lässt. Dazu wird der Pfad in einen neuen Browsertab kopiert, und das http zu https umgeändert. Da ich keine externen Inhalte habe, konnte ich den Inhalt auch über https aufrufen. Die Lösung war einfach: ich musste mich nur auf der Webseite einloggen und den Webseiten Cache löschen. Eventuell müssen auch einige Einstellungen im Backend der Webseite vorgenommen werden, z.B. wenn Inhalte einen absoluten Pfad haben, der mit http angegeben ist.

Werden dagegen auf der Website externe Inhalte eingebunden, so sollte sich vorher erkundigt werden, ob die Zertifizierung mit Let's Encrypt vernünftigerweise realisierbar ist, und ob externe Inhalte auch über https eingebunden werden können. Hier noch ein weiterer Threat (englisch): How will LE be addressing mixed content?

Datenschutz und OCSP mit Webserver Apache 2.2

Beim Aufruf von verschlüsselten Seiten wird aus Sicherheitsgründen überprüft, ob das Zertifikat noch gültig ist oder zurückgerufen wurde. Oft führen die Zertifikatsaussteller Listen, in denen zurückgerufene Zertifikate aufgeführt sind, so auch Let's Encrypt.

Bei Webseiten, die unter Apache 2.2 laufen (wie auch diese Seite), ist die Technik so strukturiert, dass der Browser der Besucher*innen einer Webseite eine Anfrage an die Zertifikatsstelle stellt, ob das Zertifikat noch gültig ist. Dabei werden sensible Daten wie die IP-Adresse, User Agent string, und die zu besuchende Webseite an die Server von Let's Encrypt übermittelt.

Let's Encrypt benutzt diese Daten nicht um Personen zu identifizieren. Die Daten werden innerhalb von sieben Tagen gelöscht, oder nachdem sie für Fehleranalysen gebraucht wurden. Nachzulesen ist das unter Privacy Policy - Public User.

Das Übermitteln von IP Informationen ist nicht nur spezifisch für Let's Encrypt, sondern betrifft andere verschlüsselte Seiten und Zertifikatsstellen genauso. Es ist ganz üblich, aber dadurch nicht weniger schlecht. Einzige Abhilfe schafft ein Upgrade zu Apache 2.4, in der diese Technik verbessert wurde, so dass keine sensiblen Informationen der Besucher*innen mehr übermittelt werden.

4. Fazit

Meiner Meinung nach ist Let's Encrypt gerade für kleinere Seiten, wie sie im Webhosting und im Shared Hosting laufen, gut geeignet (sie haben eher weniger externe Inhalte, und benötigen eher keine Wildcard Zertifikate oder Extended Validation). Gerade dort lässt es sich aber meistens ohne die Unterstützung des Providers nicht einrichten.

Deswegen an dieser Stelle ein Lob an webgo, dass sie Let's Encrypt unterstützen und den Benutzer*innen eine einfache Umsetzung möglich machen!

Einerseits wird die Privatsphäre der Webseiten Besucher*innen besser geschützt, trotz des Mankos mit OCSP. Andererseits ist es auch für mich sicherer, mich über eine verschlüsselte Verbindung einzuloggen und Inhalte zu bearbeiten.

 

Update 29.3.16: Abschnitt zu HSTS und OCSP hinzugefügt.

Kommentare

Hallo!
Danke für den interessanten Beitrag, auch wenn er jetzt schon ein Jahr alt ist. Ich habe auch bei Webgo meine Webseite gehostet und dort auch eine owncloud eingerichtet. Dort verwende ich https mit Let's Encrypt. Allerdings wird die seite z.B. im Firefox als unsichere Verbindung angezeigt und man muß immer eine Ausnahme hinzufügen. Das macht das für meine Zwecke eigentlich unbrauchbar. Wenn ich mir den Unterschied zu deinem Zertifikat ansehe, fällt mir auf, daß meines von "Internet Widgits Pty Ltd", deines direkt von Let's Encrypt validiert wird. Wie kommt es zu diesem Unterschied? Habe ich was anders gemacht?

seb

Hallo seb,

sorry für die späte Veröffentlichung. Die Kommentar-Email-Benachrichtigung muss mir durch die Lappen gegangen sein...dein Problem hast du vermutlich schon längst gelöst. Trotzdem meine Meinung dazu:

In Kürze: Ich würde den webgo Support kontaktieren.

Let's Encrypt beruht auf einem Programm, dass auf dem Server installiert werden muss. Ich gehe davon aus, dass du wie ich ein Shared Hosting - Webhosting - Paket hast. Dort gibt es keinen root-Zugriff, d.h. von uns Kunden können keine Programme auf dem Server installiert werden. Auf Shared Hosting hat webgo das selbst installiert und konfiguriert.

Das Zertifikat sollte natürlich von Let's Encrypt kommen, und sonst von niemandem! Falsche Zertifikate sind ein Sicherheitsrisiko und untergraben das Vertrauen.

Es sollte natürlich nicht sein, dass noch eine Ausnahmeregel hinzugefügt werden muss. Soweit ich das sehe, kannst du selbst nichts machen, wenn sonst alles normal läuft und die Webseite normal funktioniert.

Ich hatte auch mal kurze Zeit owncloud installiert und ein Let's Encrypt Zertifikat darauf laufen. Es gab damit keine Probleme.

Es gibt aber noch eine Ausnahme: in Unternehmensnetzwerken werden manchmal Zertifikate ausgetauscht, damit der von aussen kommende Internetverkehr auf Malware gescannt werden kann. Wird dann eine Webseite von innerhalb des Unternehmens aufgerufen, zeigt sie ein anderes Zertifikat. Allerdings dürfte in so einem Fall Firefox keine Warnung auswerfen.

Hallo Faennj,

hab vielen Dank für deine Antwort!
In der Tat, das Problem habe ich schon lösen können. Ich habe bei Webgo übersehen, daß dort mehrer Optionen der jeweiligen Zertifizierung angeboten werden. Versehentlich hatte ich seinerzeit die Webgo-Eigene, statt Let's Encrypt verwendet.
Nun habe ich es richtig eingestellt und es funktioniert fabelhaft!
Webgo hat Serverseitig alle Voraussetzungen geschaffen, incl. der halbjährlichen Aktualisierungen per Script automatisiert!
Also alle läuft wie erhofft.

Viele Grüße!
h.

Hallo seb, vielen Dank für dein Feedback:), das könnte auch für andere nützlich sein. Ich dachte, dass es vielleicht ein Serverfehler wäre. Ich hatte vergessen, dass webgo auch noch seit jeher Shared SSL Zertifikate anbietet. Die sind natürlich nicht so toll, weil sich mehrere ein Zertifikat teilen, während bei Let's Encrypt jede*r ein eigenes Zertifikat bekommt. Nach der Einrichtung der Zertifikate hatte ich mir den Abschnitt im Webspace Admin auch nie wieder angeschaut - dank automatischer Aktualisierung:). Ich bin auch froh, dass das so gut klappt dank der Leute von Let's Encrypt und webgo. Gruß und noch einen schönen Feiertag, Faennj

Neuen Kommentar schreiben

You must have Javascript enabled to use this form.