Let’s Encrypt: Kostenloses SSL/TLS Zertifikat erstellen

20 Dez
20. Dezember 2015

Let’s Encrypt ist eine Zertifizierungsstelle, die kostenlose X.509-Zertifikate für Transport Layer Security (TLS; umgangssprachlich SSL) anbietet. TLS ist eine gängige Methode im Internet Datenübertragungen abzusichern. Der Prozess der Erstellung, Validierung, Signierung, Einrichtung und Erneuerung von Zertifikaten wurde dabei, entgegen vieler anderer kommerzieller Zertifizierungsstellen, automatisiert. Let’s Encrypt ist eine Initiative von der gemeinnützigen Internet Security Research Group (ISRG) mit den Hauptsponsoren Electronic Frontier Foundation (EFF), die Mozilla Foundation, Akamai und Cisco Systems. Ziel des Projekts ist es verschlüsselte Verbindungen im Internet breit zu etablieren. Um ein X.509-Zertifikat zu erhalten, konnte man bislang eines selbst signieren, was Nachteile mit sich brachte, erhielt dieses mit vielen Restriktionen kostenlos bei StarCom oder musste sich ein solches für eine teils nicht unerhebliche Jahresgebühr bei einer Zertifizierungsstelle wie Thawte, RapidSSL, GEO Trust, GlobeSSL, Comodo oder VeriSign, kaufen.

Wie man ein kostenloses SSL bzw. TLS Zertifikat bei Let’s Encrypt erstellen kann, sodass man es z.B. für einen Apache Webserver oder einen FTP-Server verwenden kann, erkläre ich in folgendem Artikel. Dieses Vorgehen wird im Folgenden in einer Debian Linux Umgebung durchgeführt und kann daher bspw. auch auf dem Raspberry Pi unter Raspbian angewendet werden.

Hinweis: Falls du ein SSL/TLS Zertifikat für z.B. deinem Raspberry Pi mit einer DynDNS Subdomain wie .no-ip.org oder .myfritz.net erstellen möchtest, die häufig verwendet werden, wirst du merken, dass dies auf Grund von einer Beschränkung von Zertifikaten je Domain nicht funktionieren wird. Bei Anbietern wie No-IP.org oder Do.de (meine persönliche Empfehlung) kannst du jedoch für wenige Euro pro Jahr eine eigene Domain mieten, womit du solche Problem umgehst.

Step 1

Zunächst sollte sichergestellt werden, dass Git installiert wird, da wir später darüber Software der Zertifizierungsstelle Let’s Encrypt herunterladen werden.

sudo apt-get install git

Step 2

Wir können nun den ACME Client von Let’s Encrypt herunterladen und anschließend mit letsencrypt-auto alle Abhängigkeiten des Clients selbstständig installieren lassen.

cd /opt
sudo git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

Step 3 (optional)

Falls ein Dienst, wie ein Webserver, auf Port 80 läuft, muss dieser temporär zur Erzeugung eines Zertifikats gestoppt werden.

Apache2
sudo /etc/init.d/apache2 stop

nginx
sudo /etc/init.d/nginx stop

Step 4

Jetzt ist es bereits möglich ein Zertifikat zu erstellen. Dazu bedienen wir uns folgender Anweisung. Der Parameter --rsa-key-size gibt dabei die Länge des Zetifikatschlüssels an. Diese liegt normalerweise bei 2048-bit. Wir erhöhen diese im Beispiel auf 4096-bit. Außerdem muss über den Parameter -d angegeben werden für welche Domain bzw. welche Domains das Zertifikat ausgestellt werden soll. Bei Webservern wäre bspw. eine Variante mit und ohne www. sinnvoll. Die erste Domain sollte die Haupt-Domain sein auf der die Anwendung läuft.

Beim ersten Aufruf des Client muss man eine E-Mail-Adresse hinterlegen, die im Falle einer Sicherheitslücke in den Zertifikaten zur Kontaktaufnahme genutzt wird und im Falle dessen, dass man sein Zertifikat verloren hat, zur Wiederherstellung verwendet wird. Außerdem wird man aufgefordert die Nutzungsbedingungen von Let’s Encrypt durchzulesen und diesen zuzustimmen.

./letsencrypt-auto certonly --rsa-key-size 4096 -d domain.de -d www.domain.de

Anschließend sind in dem Ordner unter /etc/letsencrypt/live/domain.de/ (domain.de durch deine Domain ersetzen) folgende Dateien enthalten. Da die Rechte der Ordner sehr restriktiv sind kann man in diesen nur als root Benutzer wechseln.

  • cert.pem: Öffentliches Zertifikat
  • chain.pem: Intermediate Zertifikat
  • fullchain.pem: cert.pem und chain.pem zusammen
  • privkey.pem: Privater Schlüssel des Zertifikats
Step 5 (optional)

Bevor wir fortfahren sollten wir ggf. den Dienst auf Port 80 wieder starten, damit dieser nicht länger als nötig nicht erreichbar ist.

Apache2
sudo /etc/init.d/apache2 start

nginx
sudo /etc/init.d/nginx start

Step 6

Abschließend muss das Zertifikat in der Anwendung für die es bestimmt ist eingebaut werden. Da dies bei jeder Anwendung anders funktioniert, empfehle ich in der Dokumentation der jeweiligen Software z.B. Apache2 oder nginx nachzuschlagen.

So einfach ist es ein Let’s Encrypt Zertifikat zu erstellen und zu verwenden. Beachtet werden sollte, dass die Zertifikate nur eine Gültigkeit von 90 Tagen haben. Welche Gründe zu dieser Entscheidung geführt haben erklärt Let’s Encrypt in ihrem Blog. Daher muss das Zertifikat regelmäßig erneuert werden.

Zertifikat erneuern

Um ein Zertifikat zu erneuern reicht es folgenden Befehl aufzurufen. Dabei muss bei dem Parameter -d die Haupt-Domain des zu erneuernden Zertfikats angegeben werden. Zuvor muss wieder, falls vorhanden, der Dienst auf Port 80 gestoppt werden.

/opt/letsencrypt/letsencrypt-auto --renew certonly -d domain.de

Dies lässt sich auch als Cronjob automatisiert ausführen. Beachtet werden sollte, dass der Dienst, der das Zertifikat nutzt, in der Regel dieses neu einlesen muss oder neugestartet werden muss. Im folgenden Beispiel fügen wir die Zeile am Ende der Crontab Datei ein, welche einmal im Monat das Zertifikat erneuert und den Apache2 bzw. nginx Server automatisch die Konfigurationen neu einlesen lässt. Falls der Editor nano voreingestellt ist lässt sich die Datei mittels STRG + X, Y und Enter speichern.

crontab -e

Apache2

nginx

Außerdem kann es passieren, dass das Zertifikat aus gegeben Gründen, z.B. Diebstahl des Private Keys, widerrufen werden muss. Auch dieser Vorgang ist mit Let’s Encrypt Zertifikat ganz einfach zu bewerkstelligen.

Zertifikat widerrufen

Um ein Zertifikat zu widerrufen muss folgender Befehl aufgerufen werden. Dabei muss domain.de durch die Haupt-Domain des zu erneuernden Zertifikats ersetzt werden.

/opt/letsencrypt/letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/domain.de/fullchain.pem

Dir hat der Artikel gefallen?
Teile ihn mit deinen Freunden!
41 Antworten
  1. Johnny says:

    Hallo Jan,
    Danke für den Artikel.
    Ich habe auch nach deinen Anleitungen meinen kleinen Owncloud-Raspi-Server laufen. Bisher ist der hinter der Fritzbox mit einem eigens signierten Zertifikat erreichbar. Das funktioniert soweit auch ganz gut, aber ohne die gültige Zertifizierungsstelle muss ich auf diversen Programmen und Diensten, die auf die Owncloud zugreifen irgendwelche workarounds zum ignorieren des Zertifikats aktivieren.
    Ich habe bereits vorher versucht mit Let’sEncrypt ein Zertifikat zu bekommen dies wurde mir immer mit
    „There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: myfritz.net“
    quittiert.
    Logisch, wenn man bedenkt, wieviele myfritz.net domains es alleine in Deutschland gibt.
    Komme ich da ohne eigene dns nicht weiter?

    Gruß Johnny

    Antworten
    • Jan Karres says:

      Danke für deinen Hinweis. Habe ich nachgesehen und du brauchst in der Tat i.d.R. eine eigene Domain. Ich habe den Artikel dahingehend überarbeitet.

      Antworten
  2. Stephan says:

    Hallo Jan,
    vielen Dank für die Anleitung.
    Kann die Erneuerung des Zertifikats nicht per cron Job automatisiert werden?
    Viele Grüße und schöne Feiertage

    Antworten
  3. Maik says:

    Hallo Jan,
    habe das Zertifikat wie von dir beschrieben erstellt.
    Leider bekomme ich jetzt die Fehlermeldung „Permission denied“, sobald ich auf den Ordner mit demZertifikat zugreifen möchte.
    Habe schon versucht die Schreib- und Leserechte zu verändern, aber ohne Erfolg.

    Beste Grüße

    Antworten
    • Georg Schmucker says:

      Probier mal mit root rechten drauf zu zugreifen. Falls du mit der grafischen oberfläche bzw. dem dateimanager drauf zugreifen willst, gib im terminal bzw console: sudo nautilus
      ein. Aber funktioniert nur mit gnome bzw. wenn nautilus installiert ist.

      Antworten
    • Jan Karres says:

      Georg hat das schon ganz richtig erklärt. Habe im Artikel darauf hingewiesen. Danke!

      Antworten
  4. LXNOOB says:

    Hallo Jan, ich habe einen Artikel gefunden, der sich mit Let´s Encrypt beschäftigt. Könnte dich und andere interessieren:
    http://www.spiegelfechter.com/wordpress/132589/kostenlose-sicherheit-drum-pruefe-was-sich-ewig-bindet
    Und dann noch eine Anregung für deinen schönen Blog hier. Wie wäre es, wenn du mal was über E-Book Server schreibst? Ich nenne hier mal „Library aka CPS“ und „bicbucstriim“. Schöne Feiertage weiterhin.

    Antworten
  5. Tom says:

    Vielen Dank für die wie immer ausführlichen Info’s. Hätte ich nicht schon ein SSL Zertifikat würde ich mir eins von Let’s Encrypt besorgen.

    Grüße
    Tom

    Antworten
    • Tom says:

      Hab jetzt zum testen auf einer meiner Seiten das SSL Zertifikat installiert. Funktioniert absolut problemlos. Danke für den Tip 🙂

      Beste Grüße
      Tom

      Antworten
  6. Jochen says:

    Hallo Jan,

    in diesem Artikel wird beschrieben, wie eine Owncloud mit Let’sEncrypt-Zertifikat und dyddns eingesetzt werden kann:
    https://decatec.de/home-server/owncloud-auf-ubuntu-server-mit-nginx-mariadb-und-php/

    Widerspricht das nicht den hier genannten Erfahrungen, dass dies nicht geht?

    Mich interessiert die Absicherung einer Owncloud-Installation auf einem Raspi. Allerdings nutze ich kein dyndns, sondern eine Umleitung auf einer Domain, die mir gehört. Diese Umleitung wird durch ein Skript, das auf dem Raspi läuft, aktuell gehalten. Stellt sich die Frage, ob das mit einem solchen Zertifikat machbar ist.

    Antworten
    • DecaTec says:

      Hallo Jochen,

      ich bin der Autor des von dir genannten Artikels, daher bin ich mal so frei und antworte an dieser Stelle:
      Prinzipiell kann man Let’s Encrypt auch mit DynDNS-Domains nutzen. Allerdings hat LE hier ein Limit von: 5 Zertifikate innerhalb von 7 Tagen für eine Domain. Wenn sich natürlich viele Leute, die einen speziellen DynDNS-Dienst nutzen, Zertifikate besorgen, dann ist hier irgendwann mal Schluss und man erhält vom LE-Client eine Fehlermeldung. Ich persönlich hatte mit einer DynDNS-Domain keine Probleme, was allerdings daran liegen kann, dass ich einer der ersten war, die hierfür ein Zertifikat erstellt haben.

      Aber selbst wenn das Zertifikat ausgestellt werden kann: Das Problem kann jederzeit wieder auftreten, wenn das Zertifikat nach 90 Tagen erneuert werden muss. Daher würde ich die Verwendung von LE über eine DynDNS-Domain nicht empfehlen.

      Es gibt allerdings einen Trick, wie man dieses Problem umgehen kann: Man besorgt sich eine eigene Domain für ein paar Euro im Jahr von einem beliebigen Webhoster. Durch einen CNAME-Eintrag wird dann die Domain mit der DynDNS-Domain verknüpft. Mehr Infos dazu in diesem Artikel: https://decatec.de/home-server/https-fuer-alle-ssl-zertifikate-mit-lets-encrypt-fuer-nginx/

      Gruß,
      Jan

      Antworten
  7. Dani says:

    Hallo,
    wichtig ist auch zu wissen, dass man neben Port 80 auch HTTPS-Port 443 freigeben muss (Firewall, eigene Erfahrung), damit Lets Encrypt funktioniert, sonst bekommt man immer eine Fehlermeldung, dass die Domain nicht erreichbar sei.

    Und muss man beim Cron-Job nicht erst den Webserver stoppen, wenn man es über das ACME Protokoll macht? (Bei Manual Mode, bei dem ein File auf den eigenen Webserver geladen wird, natürlich nicht)

    PS: Als Dyn-DNS-Anbieter kann ich ddnss.de sehr empfehlen

    Antworten
    • RMTX99 says:

      Hallo,

      genau das Problem steht mir im Weg!
      Ich würde ja im Router auch gerne den Port 80 freigeben … da es sich jedoch um ein Speedport Model handelt geht das nicht (dieser ist laut Fehlermeldung für interne Zwecke reserviert … was zum Kuckuck…). Weiß jemand, wie man das umgehen kann oder hat jemand das gleiche Problem?

      Viele Grüße
      RMTX99

      Antworten
  8. Andi says:

    Hallo zusammen,
    bei myfritz.net kam bei mir auch die genannte Fehlermeldung. Aber meine Subdomain bei anydns.info ging dann problemlos.
    Ich erstellte das Zertifikat nicht direkt am (Banana) Pi, sondern unter Fedora, wo es sich per „dnf install letsencrypt“ direkt installieren lässt. Dann kommt halt noch etwas Kopiererei
    Den Pi musste ich kurzfristig auf exposed host stellen und den Internetzugang der Fritzbox deaktivieren, da die per Port 443 erreichbar ist.
    Mein probehalber Test der Erneuerung nach 3-4 Wochen hat nicht geklappt, zu früh sagte letsencrypt. Da bräuchte man in cron ein @bimonthly

    Kann ich das Zertifikat eigentlich neben dem Pi auch in die FritzBox einspielen? Die Subdomain ist ja identisch.

    Antworten
  9. Markus says:

    Hey Jan,

    warum erstellst du mit deiner Anleitung denn kein eigenes Zertifikat für jankarres.de? 😉

    LG

    Antworten
  10. Paul says:

    Hey, danke für den Beitrag. Leider habe ich negative Erfahrungen mit den kostenlosen Zertifikaten gemacht, die werden dann teilweise vom Browser geblockt und am Ende gehts nichts mehr. ;(
    Jetzt hab ich etwas Angst, dass auf einer produktiven Webseite einzusetzen.
    Gruß Paul

    Antworten
  11. Tom says:

    Toll Anleitung. Vielen Dank dafür.
    Ich frage mich wie lange es dauern wird bis kostenpflichtige kleinere SSL Zertifikate vom Markt verschwinden werden.

    Beste Grüße
    Doktor Geek

    Antworten
  12. Dietmar says:

    Hallo Jan,

    ich habe noch einen anderen Beitrag über Let’s Encrypt gelesen, in dem darauf hingewiesen wird, dass durch die vielen Änderungen, die der Let’s Encrypt Client machen kann, durchaus ein Sicherheitsrisiko besteht.

    Hier der entsprechende Beitrag: https://www.serverpedia.de/lets-encrypt-gratis-ssl-zertifikate-frei-haus/

    Was ist deine Meinung dazu? Ist das nur ein theoretisches Risiko oder durchaus etwas, was man bedenken sollte?

    Antworten
  13. blueT says:

    Hallo, danke für die Anleitung. Eine Frage zur Erneuerung des Zertifikats: wenn ich

    /opt/letsencrypt/letsencrypt-auto –renew certonly -d domain.de

    aufrufe, erhalten ich den Fehler:

    „letsencrypt: error: ambiguous option: –renew could match –renew-by-default, –renew-hook“

    Mit –renew-by-default kann ich das Zertifikat zwar erneuern, muss dann aber den Dialog bestätigen, womit sich das dann nicht mehr im cron benutzen lässt. Irgendeine Idee?

    Antworten
    • Dirk says:

      Mit der zusätzlichen Option „–standalone“ lässt sich Prozess wieder automatisieren. Also:
      >> sudo /opt/letsencrypt/letsencrypt-auto certonly –renew-by-default –standalone -d domain.com

      Antworten
  14. Ingolf says:

    Hallo Jan,
    auch von mir DANKE für die tolle Anleitung. Habe das im März 2016 umgesetzt und es hat auch alles super funktioniert. Der Cron-Job hat Ende März das Zertifikat erneuert. Leider hat es Ende April nicht mehr automatisch funktioniert. Heute habe ich mal geschaut, was da los ist und siehe da: Das gleiche Problem wie mein Vorgänger BLUET. Der neue Client scheint irgendwie anders zu funktionieren. –renew certonly funktioniert nicht mehr. Irgendjemand eine Idee, wie man das wieder so hinbekommt, das das ein Cron-Job erledigen kann?

    Antworten
    • Ingolf says:

      Dank Dirks Antwort geht es jetzt auch bei mir wieder. Falls es noch jemanden interessiert, hier mein neuer Eintrag im crontab:
      @monthly sudo service nginx stop && /opt/letsencrypt/letsencrypt-auto –renew-by-default certonly –standalone -d domain.com && sudo service nginx restart

      Antworten
      • Rene says:

        mit der Option renew ohne Parameter werden durch die aktuelle Version des Clients alle Zertifikate, die erneuert werden müssen, automatisch erneuert.

        Außerdem sollte nginx nicht gestopppt und dann neu gestartet werden, sondern mittels reload die Konfiguration neu eingeladen werden, so dass als Eintrag in Crontab damit empfehlenswert wäre:
        @monthly /opt/letsencrypt/letsencrypt-auto renew && sudo service nginx reload

        Viele Grüße

        Antworten
  15. Ingolf says:

    irgendwie werden hier doppelte — verschluckt:
    @monthly sudo service nginx stop && /opt/letsencrypt/letsencrypt-auto —renew-by-default certonly —standalone -d domain.com && sudo service nginx restart

    vor renew und vor standalone müssen doppelte – sein!

    Antworten
  16. Tobi G. says:

    Hi, also ich habe das Zertifikat wie beschrieben erstellt und eingebunden bekommen. Danke dafür !
    Das ganze läuft auf einem PI hinter meiner Fritzbox auf Port 80 und 443.
    Ich habe jetzt einen zweiten PI installiert, der eine getrennten eigenen Domain bedienen soll.
    Als Domainnamen sind xxx.spdns.org und yyy.spdns.org registriert. beide erreich ich auch aus dem Internet, die xxx mit https (diese war zuerst da und mit dieser wurde das Zertifikat erstellt.) Die yyy erreiche ich zwar auch (Port 8080) aber nicht auf dem https (433). Ich kann mir auch kein neues (zweite) Zertifikat erstellen. Ich bin newbie, denke aber ich mache hier was prinzipielles falsch. Ich hatte auch bereits beide apache gestoppt.

    Danke für eure Hilfe.
    T.

    Antworten
    • Tobias says:

      Hallo nochmal, keiner eine Idee ?

      Antworten
      • Dani says:

        Hi! Mach doch einfach ein Zertifikat für beide Domains! Beachte, dass insbesondere Subdomains von DDNS Anbietern bei der Vergabe beschränkt werden (nur n Zertifikate pro Stunde).

        An die Portfreigabe gedacht?

        Melde dich einfach nochmal unter diesem Kommentar!

        Antworten
        • Tobias says:

          Hi DANI, danke für die Info, das habe ich gemacht, dass passt auch. Mein Problem ist, wie kann ich das Zertifikat auf den zweiten Server installieren. Also, wo liegt es auf Server1 um es zu kopieren, und wie bekomme ich es auf Server2 eingebunden ? Sicherlich kein Hexenwerk, aber ich bin noch zu frisch im LINUX/UNIX/PI…

          Antworten
          • Dani says:

            Achso ok 🙂

            apt-get install rsync

            Du erstellst in /opt/copy_certs.sh ein Shell-Skript, das die Zertifikatsdateien bei Änderungen kopiert.


            rsync -L /etc/letsencrypt/live/example.tld/fullchain.pem user@server2:/etc/letsencrypt/live/example.tld/fullchain.pem
            rsync -L /etc/letsencrypt/live/example.tld/privkey.pem user@server2:/etc/letsencrypt/live/example.tld/privkey.pem

            Hinweis: Das Argument -L sorgt dafür, dass die Dateien nur kopiert werden, wenn sie neuer sind. Außerdem muss auf server2 die Ordnerstruktur vorhanden sein (/etc/letsencrypt/live). RSync nutzt SSH, um die Dateien zu kopieren.

            Dann noch chmod +x /opt/copy_certs.sh
            Zum Test einmal ausführen mit /opt/copy_certs.sh

            Also du tragst mit
            crontab -e
            folgendes in die sog. Crontab-Datei ein, die Befehle zu einer bestimmten Zeit ausführen kann. (Hier kommt ja auch der renew Befehl von LE hin)


            @monthly /opt/copy_certs.sh

            So sollte es gehen…

          • Tobias says:

            Hallo DANI, danke. ich bekomme allerdings diese Fehlermeldung:
            rsync: mkstemp „/etc/letsencrypt/live/domain.de/.fullchain.pem.YuHZrr“ failed: Permission denied (13)

            Was und wie muss ich die Rechtevergabe denn hier für das RSYNC ändern ?

            Nimmt denn der server2 dann automatisch das https:// an oder muss ich dem noch sagen, dass er ein Zertifikat hat ?

          • Dani says:

            du machst zuerst
            sudo su
            und dann crontab -e
            damit root rsync aufruft.

            Ja, du musst den Webserver wie auf server1 konfigurieren.

          • Tobias says:

            Sorry nochmal,
            also ich habe das wie unten beschrieben alles geändert und zum testen ausgefhrt.
            sudo su war gesetzt. Trotzdem laufe ich in diese Fehler.

            root@PI3:/opt# chmod +x /opt/copy_certs.sh
            root@PI3:/opt# /opt/copy_certs.sh
            pi@nextpi’s password:
            rsync: mkstemp „/etc/letsencrypt/live/domain.tg/.fullchain.pem.Y6FfWc“ failed: Permission denied (13)
            rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
            pi@nextpi’s password:
            rsync: mkstemp „/etc/letsencrypt/live/domain.de/.privkey.pem.xb3sNH“ failed: Permission denied (13)
            rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
            root@PI3:/opt#

          • Dani says:

            Das sieht danach aus, als hätte der User keinen (Schreib)Zugriff auf dem anderen Server (Da bin ich mir allerdings nicht so sicher). Mach halt auf dem anderen Server chown pi /etc/letsencrypt/live (ist ja ein Server hinter nem Router) oder benutze gleich den root User.

  17. Skillkiller says:

    Hallo,
    ich habe Probleme bei der ab Step 2. Kannst du mir bitte sagen wie ich diesen Fehler beheben kann ?
    Ich habe das Log auf Pastebin hochgeladen.
    https://pastebin.com/5y4gXPs6

    Antworten
  18. Christoph Dyllick-Brenzinger says:

    Hallo Jan,
    wieder mal ein sehr guter Artikel zum Thema Raspberry Pi. Let’s Encrypt hat sich ja in den letzten Monaten wirklich zu einer zuverlässigen Lösungen für Privat und Business gemausert.

    Ich würde gerne noch auf zwei Ergänzungen hinweisen, die ich in einem eigenen Artikel verarbeitet habe:
    https://www.ionas-server.com/blog/lets-encrypt-zertifikat-mit-dem-raspberry-pi/

    1) man kann let’s encrypt auch so verwenden, dass man nur den Port 443 öffnet. Das ganze geht mit sogenannten pre-hooks und post-hooks. Vereinfacht gesprochen, beendet der acme-bot kurz den Webserver, startet einen eigenen kleinen Webserver, der auf Port 443 auf die Antwort der Zertifizierungsstelle horcht.
    2) du beschreibst nur die Einrichtung unter Apache, jedoch setzen viele User ganz bewußt nginx auf einem Raspberry Pi ein, da dieser weniger Ressourcen verbraucht.

    Vielleicht hilft es ja dem einen oder anderen.

    Viele Grüße
    Christoph

    Antworten
  19. Simon says:

    Hallo Jan,

    ich habe auf meinem Raspperry Pi eine Seafile Cloud eingerichtet und die Verbindung mittels Let’s Encrypt Zertifikat verschlüsselt. Dabei habe ich mich an diese Anleitung gehalten: https://blog.tausys.de/2016/02/02/lets-encrypt-nginx-und-viele-hosts/

    Bisher funktioniert auch alles soweit. Allerdings hätte ich noch einige Verständnisfragen zu diesem Vorgehen.

    1. Was hat es mit dem Webroot auf sich? Welche Funktion steckt dahinter bzw. wie funktioniert es?

    2. Warum muss ich beim Let’s Encrypt Zertifikat diesen Weg gehen? Warum funktioniert es nicht so wie bei einem selbst erstellten Zertifikat, indem ich einfach den Pfad der Zertifikate in der entsprechenden Config-Datei des Nginx-Servers anpasse?

    Viele Grüße

    Simon

    Antworten
  20. Marco says:

    Hallo,

    ersteinmal vielen Dank für die Anleitung!

    Wenn ich versuche, mein Zertifikat zu erneuern erhalte ich folgende Fehlermeldung:

    /opt/letsencrypt/letsencrypt-auto –renew certonly -d xxx.spdns.de
    Requesting root privileges to run certbot…
    /home/pi/.local/share/letsencrypt/bin/letsencrypt –renew certonly -d xx.spdns.de
    usage:
    letsencrypt-auto [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] …

    Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
    it will attempt to use a webserver both for obtaining and installing the
    cert.
    certbot: error: ambiguous option: –renew could match –renew-by-default, –renew-with-new-domains, –renew-hook

    Hat jemand einen Tipp?

    Antworten

Trackbacks & Pingbacks

  1. […] nächsten Schritte habe ich vom Blogeintrag von Jan Karren: Let’s Encrypt: Kostenloses SSL/TLS Zertifikat erstellen entnommen. Was ihr hier lest ist also nur eine sehr kurze Zusammenfassung eines viel […]

Antworten

Kommentar verfassen

JanKarres.de © 2007-2017