Sent from Hauptstadt!

ein Blog für den geneigten Leser

Let’s Encrypt mit Hosteurope WebHosting nutzen

Tags: ,

Kategorie Web | 21 Kommentare »

Auch für kleinere private Webseitenbetreiber, wie mich, wird es immer wichtiger, die eigenen Seiten per verschlüsselter https:// Verbindung anzubieten. Der Kauf eines SSL Zertifikats ist aber ein sehr teurer (ca. 100€ pro Jahr), was sich natürlich für den kleinen privaten Blog von nebenan nicht lohnt. Glücklicherweise kann man sich mit Let’s Encrypt kostenlose SSL Zertifikate ausstellen lassen. Ich habe einige Skripte geschrieben, um diese effizient zu erstellen und zu erneuern.

Warum überhaupt verschlüsselter Zugriff?

Seit den Snowden Enthüllungen muss man davon ausgehen, dass unser gesamtes Surfverhalten mitgeschnitten wird. Webseiten Betreiber können ihre Nutzer dagegen schützen, indem sie ihre Inhalte über verschlüsselte Verbindungen (https://) zur Verfügung stellen. Um Webseiten Betreiber zur Umstellung auf verschlüsselte Verbindungen zu motivieren, hat Google angekündigt, die Verschlüsselung positiv bei der Platzierung in seinen Suchergebnislisten zu berücksichtigen. Bei den Browser Herstellern wie Firefox und Google Chrome wird sogar diskutiert, dass demnächst unverschlüsselt zur Verfügung stehende Seiten nicht mehr abrufbar sind. Ob es wirklich soweit kommt, wird sich noch zeigen.

Kostenlose SSL Zertifikate mit Let’s Encrypt

Um seine eigene Homepage oder den eigenen Blog verschlüsselt anzubieten, muss man auf dem Webserver ein SSL Zertifikat installieren. Die meisten Webhosting Anbieter sind gern bereit, solch ein Zertifikat gegen Bares auszustellen. Für kommerzielle Angebote wie Banken, Social Networks, Web Shops, Online Communities oder Nachrichtenportale fallen die dabei entstehenden Kosten von einigen hundert Euros pro Jahr nicht weiter ins Gewicht. Anders ist die Lage für private Seiten, die keinen oder nur sehr geringen Umsatz generieren.

Glücklicherweise kann man mit dem Community Dienst Let’s Encrypt kostenlose SSL Zertifikate ausstellen. Im Gegensatz zu kommerziellen Zertifikaten findet hier keine Identitätsprüfung statt, sondern es wird lediglich bestätigt, dass der Zertifikatsersteller Zugriff auf den Webserver der Domain hat. Während der Ausstellung des Zertifikats muss man deshalb eine kleine von Let’s Encrypt vorgegebene Datei auf der eigenen Domain platzieren, deren Vorhandensein von Let’s Encrypt geprüft wird. Anschließend erhält man das SSL Zertifikat, das man dann in seinen Webserver einbinden muss. Dabei ist zu beachten, dass Let’s Encrypt Zertifikate immer nur eine Gültigkeit von 90 Tagen haben. Man muss diesen Vorgang also regelmäßig wiederholen.

Let’s Encrypt mit Webhosting Paketen nutzen

Idealerweise läuft der gesamte Ausstellungs- und Prüfprozess vollständig automatisiert ab. Dazu benötigt man allerdings vollen Zugriff auf die Konfigurationsdateien seines Webservers. Gerade im Bereich privater Webseiten ist dies aber nicht gegeben, da häufig so genannte Webhosting Pakete genutzt werden. Bei diesen teilen sich viele Kunden einen Webserver und jeder Kunde hat nur Zugriff auf seine Dateien, nicht aber die Konfiguration des Webservers.

Dieser Blog und meine anderen Domains und Sub-Domains laufen in einem solchen Webhosting Paket von Hosteurope. Dieses Paket kann ich über eine Online Oberfläche, dem so genannten KIS, konfigurieren. Idealerweise würde Hosteurope in diese Oberfläche einen Knopf einbauen, um automatisch ein kostenloses SSL Zertifikat über Let’s Encrypt zu generieren und einzubinden. Daran hat Hosteurope allerdings kein Interesse, da sie natürlich viel lieber teure SSL Zertifikate verkaufen wollen.

Halbautomische Generierung von SSL Zertifikaten

Glücklicherweise kann man bei Hosteurope auch SSL Zertifikate einbinden, die man nicht bei ihnen bestellt hat. Deshalb kann ich das SSL Zertifikat auf meinem heimischen Rechner mit Let’s Encrypt erzeugen und anschließend manuell bei Hosteurope über das KIS einbinden. Dazu benutze ich das certbot Werkzeug sowie eine kleine Sammlung selbst geschriebener Skripte. Die Skripte reduzieren den Gesamtaufwand auf unter 5 Minuten aller 90 Tage. Der zeitraubendste Schritt ist das Einbinden des neuen Zertifikats über das Hosteurope KIS.

Die Skripte übernehmen dabei folgende Schritte:

  • Aufruf des certbot Werkzeug mit den nötigen Parametern.
  • Für jede Domain hochladen der Let’s Encrypt Prüfdatei mittels FTP auf den Hosteurope Webserver.

Ich habe meine Skripte mit Anleitung bei GitHub zur Verfügung gestellt. Mit kleinen Eingriffen dürften sich die Skripte sicher leicht auch an andere Webhosting Betreiber anpassen lassen.

Notizen für mich selbst

Mit folgendem Kommando kann man den Inhalt eines Zertifikats auf der Kommandozeile anzeigen:

openssl x509 -in cert.pem -text

Bei Hosteurope muss man die folgenden beiden Dateien im KIS hochladen:

  • fullchain.pem
  • privkey.pem

Diese liegen bei mir im Verzeichnis /etc/letsencrypt/live/HAUPTDOMAIN und sind nur für den root Nutzer lesbar.

21 Kommentare to “Let’s Encrypt mit Hosteurope WebHosting nutzen”

  1. Sebastian sagt:

    @Markus: Ja, in dem Skript kannst du beliebig viele Domains und Sub-Domains eintragen. Das generierte Zertifikat deckt die dann alle ab. Einzige Voraussetzung ist, dass du per FTP Zugriff auf den Webserver und die Pfade hast, auf den die Domains liegen.

    Ich persönlich sehe keinen Vorteil, einzelne Zertifikate zu generieren, solange es einem nur um Let’s Encrypt geht. Läuft natürlich auf einer deiner Domains ein kommerzielles Angebot wie ein Online Shop, solltest du für diesen ein professionelles Zertifikat kaufen und im KIS dann nur für diese Domain einbinden.

  2. Markus sagt:

    Klasse Arbeit, vielen Dank!
    Eine Frage habe ich dennoch: könnte man mit dem Skript auch ein einzelnes Zertifikat für mehrere secondary level Domains generieren, die alle auf dem gleichen HE-Server liegen? In dem Beispiel domains.json ist eine Domain und dazugehörige Subdomain erwähnt…

    Oder sollte man lieber ohnehin für jede Domain ein eigenes Zertifikat erzeugen und über KIS einbinden?

    Gruß
    Markus

  3. Markus sagt:

    Super, das sieht gut aus. Solange es nicht stört, dass die einzelnen Domains in dem Multidomain-Zertifikat für jeden sichtbar sind, ist es in Ordnung. Einzeln einbinden kann ich sie immer noch.

    Nochmal dicker Dank!

  4. Markus sagt:

    Es hat funktioniert!

    Meine domains.json:
    {
    „domain1.de“: „pfad1“,
    „domain2.de“: „pfad2“
    }

    Funktioniert beim Aufruf https://domain1.de, aber nicht bei https://www.domain1.de

    Sollte dann die domains.json so aussehen:
    {
    „domain1.de“: „pfad1“,
    „www.domain1.de“: „pfad1“,
    „domain2.de“: „pfad2“,
    „www.domain2.de“: „pfad2“
    }

    Oder würde dann die redundante Angabe des gleichen Pfades stören (weil jeweils die challenge überschrieben wird)?

    Vielleicht ist auch so etwas möglich?
    {
    „domain1.de, http://www.domain1.de„: „pfad1“,
    „domain2.de, http://www.domain2.de„: „pfad2“
    }

  5. Markus sagt:

    Im letzten Beispiel natürlkich ohne „http://“ (ist irgendwie reingerutscht…).

  6. Sebastian sagt:

    @Markus: Also aus Sicht der Suchmaschinenoptimierung (SEO) solltest du dafür sorgen, dass dein Inhalt nur unter genau einem Domainnamen erreichbar ist. Deshalb leite doch alle Anfragen mittels .htaccess Datei von z.B. example.com auf http://www.example.com um!

    Weiterhin solltest du auch sicherstellen, dass deine Domain nur über https:// und nicht mehr per http:// erreichbar ist, indem du auch hier die Anfragen entsprechend per .htaccess umleitest. Wie das geht, findest du auf unendlich vielen Artikeln im Netz.

    Dann erübrigt sich auch die Frage, weil du nur die Domain genau einmal aufnimmst. Ansonsten ist dein erstes Beispiel richtig. Die Domains werden sequentiell validiert und die Tokens werden jeweils auch in Dateien mit zufälligen Dateinamen gespeichert. Es dürfte sich also nichts überschreiben.

    Noch ein Tipp: Nutze unbedingt die Staging Umgebung von Let’s Encrypt für deine Versuche, sonst sperrt dich der Produktionsserver bei denen schnell aus :-) Wenn du dann alle Parameter korrekt hast, musst du das Zertifikat noch einmal auf der richtigen Umgebung erstellen.

  7. Markus sagt:

    Bin Deinem Rat gefolgt und jeweils in .htaccess auf www und https umgeleitet. Diese Anleitung, die Skripte und Deine Hilfe haben mir den Zugang zu den SSL-Zertifikaten von Lets Encrypt sehr erleichtert!

  8. Hartmut sagt:

    Mir ist nicht klar, ob ich certbot installieren muss und wenn ja, was. Jedenfalls bekomme ich die Meldung
    „certbot: not found“, wenn ich neu.py starte („sudo python3 neu.py“ als Superuser in Linux Mint Konsole).

    (In einstellungen.json steht bei mir noch „staging“: true, um die Angaben in den .json-Dateien zu testen.)

  9. Sebastian sagt:

    @Hartmut: Ja, du musst natürlich certbot installiert haben. Schau dir nochmal die Anleitung auf https://github.com/steinsag/hosteurope-letsencrypt an.

  10. Markus sagt:

    Sollte man in Falle einer Änderung in domains.json (Domains dazugekommen oder in der Liste gelöscht, die Hauptdomain bleibt) für eine Verlängerung neu.py starten oder verlaengern.py?

  11. Sebastian sagt:

    Soweit ich weiß, lässt sich ein bestehendes Zertifikat nicht um zusätzliche Domains erweitern. Man muss deshalb ein neues erstellen, also neu.py.

  12. Markus sagt:

    Vielen Dank Sebastian, habe ein neues Zertifikat mit neu.py generiert und bei HE eingebunden. Deine Skripte machen das SSL-Zertifikat-Handling zum Kinderspiel!

  13. Frank sagt:

    Hi, vielen Dank für die Skripte. Kurze Frage: certbot legt die .pem-Dateien in den beiden Unterordnern keys und csr ab. Da komme ich nur über die root-Shell hin, richtig? Und außerdem heißen die zB 0000_csr-certbot.pem. Muss ich die vor dem Hochladen noch umbenennen – und wenn ja, wie? Danke, Frank

  14. Sebastian sagt:

    Also bei mir legt certbot die Dateien unter /etc/letsencrypt/live/HAUPTDOMAIN/ ab. Die beiden Dateien, die ich für Hosteurope benötige, heißen dann fullchain.pem und privkey.pem. An diese Dateien komme ich auch nur mit dem root Nutzer. Die kann man so direkt hochladen ohne sie vorher umzubenennen.

    Ich habe den Blogbeitrag entsprechend ergänzt.

  15. kraeMit sagt:

    Hi,
    warum nicht einen Cronjob einrichten? M.W. geht das auch mit einem Webserver Paket, siehe https://www.hosteurope.de/faq/webserver-dedicated/allgemeines-webserver/cronjob-webserver/?zanpid=9324_1517948951_207d6436c1777a65da61a9b5cbcd864e&_$ja=tsid:66382|cgn:143466|kw:zanox#datenbank-backup.

    Gruß
    kraeMmit

  16. Sebastian sagt:

    @kraeMit: Bei dem von mir verwendeten Webpacket besteht keinerlei Shell Zugriff. Es ist kein dedicated Server.

  17. Jochen sagt:

    Hi Sebastian,
    mir ist nicht ganz klar, wie ich certbot installiere. Vielleicht ist mein Englisch zu schlecht oder ich übersehe Platzhalter?
    Auf der certbot-Seite steht unter https://certbot.eff.org/docs/install.html#certbot-auto was ich einzugeben habe. Wo? In die Windows-Befehlszeile? Ersetze ich [user] und [webserver] oder bleibt das?

  18. Sebastian sagt:

    @Jochen: Da kann ich leider nicht behilflich sein. Ich habe meine Skripte nur unter Linux getestet und bin mir auch nicht sicher, ob certbot überhaupt unter Windows läuft.

  19. Hermann sagt:

    Hallo, danke für den blog-Artikel, hat funktioniert.

    @Jochen: certbot ist nur für Linux-Systeme (Unix-artige)

    Zur certbot-Installation:
    Habe mich dabei hieran gehalten:
    https://certbot.eff.org/lets-encrypt/ubuntutrusty-other

    Man wählt zum einen das Betriebssystem auf dem certbot laufen soll (bei mir Ubuntu).

    Als Server-Software würde ich als nächstes mal „none of the above“ ausprobieren.
    Ich wählte beim ersten Versuch missverständlicherweise Apache, weil ich den durch LAMPP habe. Alllerdings wurde ein Apache-Plugin mitinstalliert, wodurch offenbar mein LAMPP-Apache zerschossen wurde. (der certbot lief jedoch erfolgreich)

    Ohne Apache-Plugin bietet er folgende Installationsschritte für Ubuntu an:
    $ sudo apt-get update
    $ sudo apt-get install software-properties-common
    $ sudo add-apt-repository universe
    $ sudo add-apt-repository ppa:certbot/certbot
    $ sudo apt-get update
    $ sudo apt-get install certbot

  20. Thomas sagt:

    Hi,

    ersteinmal vielen dank für die schönen Scripte. Sie funktionieren sowohl unter FreeBSD (TrueNAS 12) als auch unter Linux. Nun möchte ich auch den Letzten Schritt meistern und scheitere und scheitere. Ich komme einfach nicht weiter.

    # python3 set_certificate.py
    Traceback (most recent call last):
    File „set_certificate.py“, line 72, in
    asyncio.get_event_loop().run_until_complete(set_certificate())
    File „/usr/lib/python3.8/asyncio/base_events.py“, line 616, in run_until_complete
    return future.result()
    File „set_certificate.py“, line 45, in set_certificate
    browser = await launch({‚headless‘: True, ’slowMo‘: 1, ‚devtools‘: True})
    File „/usr/local/lib/python3.8/dist-packages/pyppeteer/launcher.py“, line 307, in launch
    return await Launcher(options, **kwargs).launch()
    File „/usr/local/lib/python3.8/dist-packages/pyppeteer/launcher.py“, line 168, in launch
    self.browserWSEndpoint = get_ws_endpoint(self.url)
    File „/usr/local/lib/python3.8/dist-packages/pyppeteer/launcher.py“, line 227, in get_ws_endpoint
    raise BrowserError(‚Browser closed unexpectedly:\n‘)
    pyppeteer.errors.BrowserError: Browser closed unexpectedly:

    Ich habe dafür eine neue VM mit Ubuntu Server 20.04.03 LTS installiert und nur die nötigen Pakete. Bin echt am Verzweifeln.

    Kann mir jemand sagen, ob es überhaupt noch funktioniert? Wie kann ich das ganze zum Laufen bringen?

    VG
    Thomas

  21. Sebastian sagt:

    Das wird so nicht funktionieren. Auch wenn man es nicht sieht, wird trotzdem ein Chrome Browser von dem Skript gestartet, der dann die Seite aufruft und das Zertifikat auf der entsprechenden Seite hochlädt. Auf einem reinen Server OS kann der Browser aber nicht starten, da er kein Display hat. Ich fürchte, dieser Fall kann von den Skripten nicht unterstützt werden :-/

Schreiben sie ein Kommentar