DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

Let’s Encrypt Zertifikate mit acme.sh und nginx

Let's Encrypt Logo

Wer eine eigene Website oder auch eine Nextcloud-Instanz betreibt, der sollte auch großen Wert auf Sicherheit legen. In der heutigen Zeit gehört dabei HTTPS zum Sicherheits-Standard, wenn es um die verschlüsselte Übertragung von Daten im Internet geht.

Um die eigene Seite mittels HTTPS abzusichern, ist zunächst einmal ein SSL-Zertifikat notwendig. Früher musste man sich ein solches Zertifikat von einer Zertifizierungsstelle für viel Geld kaufen. Im Jahr 2015 trat jedoch Let’s Encrypt auf den Plan – eine Zertifizierungsstelle, die kostenlos Zertifikate für TLS anbietet, um damit verschlüsselte Verbindungen im Web zum Standard zu machen. Gerade im privaten Bereich hat sich Let’s Encrypt zu einem de-facto Standard entwickelt.

Seitdem kann sich jedermann selbst Zertifikate für HTTPS ausstellen lassen. Dazu wird lediglich ein Let’s Encrypt Client benötigt, der die eigentliche Generierung der Zertifikate übernimmt. In meinen Tutorials habe ich bisher immer Certbot als Client für Let’s Encrypt empfohlen, da dieses Programm in den Paketquellen fast aller Distributionen enthalten ist. Dennoch könnte sich genau dieser Umstand als Nachteil erweisen. So schaltet Let’s Encrypt aus Sicherheitsgründen das Validierungsverfahren „TLS-SNI-01“ bald ab. Nutzer von Debian laufen bald Gefahr, dass die Zertifikate nicht mehr erneuert werden können, da die Version von Certbot in Debian Stable zu alt ist und keine anderen Validierungsmethoden unterstützt (siehe hier).

Ein alternativer Let’s Encrypt Client ist acme.sh. Wie der Name bereits vermuten lässt, handelt es sich hierbei um ein reines Shell-Skript, welches die Generierung der Zertifikate übernimmt. Man ist damit nicht mehr von Programmen in den Paketquellen der Linux-Distributionen abhängig. Darüber hinaus ist acme.sh ein sehr fortschrittlicher Client, der bisher alle Features von Let’s Encrypt unterstützt. Grund genug, die diesen Let’s Encrypt Client einmal genauer anzusehen.

Der Artikel basiert dabei auf Ubuntu Server 18.04 LTS, alle gezeigten Schritte sollten sich aber auch auf anderen Distributionen umsetzen lassen. Als Webserver kommt nginx zum Einsatz.

Update-Historie (letztes Update 17.08.2019)
  • 17.08.2019:
    • acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher wird für die Ausführung von acme.sh ein spezieller User angelegt.
  • 24.07.2019:
    • Anpassungen für TLSv1.3 (ssl_ciphers und ssl_ecdh_curve).
  • 15.06.2019:
    • ECDHE-RSA-AES256-SHA384 aus den ssl_ciphers entfernt (wird beim Qualys SSL Labs Test als „weak“ eingestuft).
  • 18.05.2019:
    • Hinweis hinzugefügt, dass bei der Generierung der Zertifikate am besten Copy&Paste und „Suchen & Ersetzen“ genutzt wird.
  • 18.02.2019:
    • Hinweis für Meldung „-bash: /home/user/.acme.sh/acme.sh.env: Permission denied“ hinzugefügt.
  • 13.02.2019:
    • Hinweis für die Berechtigungen des Verzeichnisses /var/www/letsencrypt hinzugefügt.
  • 11.02.2019:
    • Anleitung zum Upgrade von acme.sh hinzugefügt.
    • Hinweis auf Überschreiben der Crontab durch Installation von acme.sh hinzugefügt/Sichern der bestehenden Crontab.
  • 09.02.2019:
    • Hinweis auf neuen Artikel zum Umstieg von Certbot auf acme.sh hinzugefügt.

 

Installation von acme.sh

Es handelt sich bei acme.sh nur um ein Skript, jedoch kann es in gewisser Art installiert werden. Die Installation beinhaltet hauptsächlich die Einrichtung eines Cronjobs zur automatischen Erneuerung ausgestellter Zertifikate.

acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher legen wir einen speziellen User an und fügen diesen der Gruppe www-data hinzu:

Der User braucht nun die Berechtigungen, um nginx später ohne Passwort neu laden zu können:

Am Ende wird folgende Zeile hinzugefügt:

Für die Installation von acme.sh wechseln wird nun den User:

Hinweis: Wenn ein bereits bestehender User für die Generierung der Zertifikate genommen wird, sollte nun kontrolliert werden, ob bereits Conjobs für diesen User angelegt wurden, da acme.sh bei der Installation sämtliche bereits bestehenden Conjobs überschreibt.

Falls bereits Cronjobs eingerichtet sind, dann solltet ihr euch daher vorher die aktuelle Crontab sichern:

Nach der Installation von acme.sh können mittels dieser Datei die „alten“ Cronjobs wieder mit contab -e hinzugefügt werden.

Diese Installation besteht eigentlich nur in der Ausführung des Skripts mit bestimmten Parametern und gestaltet sich recht einfach. Dazu gibt es eine spezielle Seite, die das Skript zur Installation beinhaltet: https://get.acme.sh.

Hinweis: Es ist immer gefährlich, eine unbekannte Quelle direkt in die Shell zu pipen, da man nie so genau weiß, was diese Quelle (in diesem Fall das Skript genau ausführt). Man sollte sich die Quelle (in diesem Fall https://get.acme.sh) vor der Ausführung des Befehle genau ansehen und überprüfen, ob hier nichts verdächtiges passiert. Für wen das Pipen auf die Shell nicht in Frage kommt, der findet noch ein paar alternative Installationsmöglichkeiten auf der Wiki-Seite des GitHub-Projekts.

Die "Installation" von acme.sh

Die „Installation“ von acme.sh

Nach der Installation muss das Terminal einmal geschlossen und wieder geöffnet werden. Alternativ kann man den Rechner auch einfach neu starten.

Damit ist die Installation bereits abgeschlossen, so dass wir wieder auf den normalen User wechseln können:

Als nächstes wird das System auf die Verwendung von SSL-Zertifikaten vorbereitet.

Vorbereitung des Systems

Zunächst richten wir die benötigten Verzeichnis ein, die später für die Zertifiakt-Generierung benötigt werden. Ebenfalls passen wir gleich die Berechtigungen entsprechend an:

Ich nutze hier immer einen Unterordner, der mit der Domain übereinstimmt, für welche die Zertifikate ausgestellt werden sollen (in diesem Beispiel einfach meinedomain.de).

Als nächstes muss der Webserver in der Lage sein, über HTTP (Port 80) im Unterverzeichnis /.wellknown/acmechallenge für Let’s Encrypt erreichbar zu sein. Im virtuellen Host für die entsprechende Domain könnte dies dann folgendermaßen aussehen:

Zertifikate mit acme.sh erzeugen

Nach den Vorbereitungen sind wir nun soweit, dass wir Zertifikate über acme.sh ausstellen lassen können.

Ich gehe im folgenden davon aus, dass auf dem System bereits nginx als Webserver installiert und eingerichtet wurde. Für die Generierung der Zertifikate wird daher der sog. Webroot-Modus genutzt. acme.sh unterstützt allerdings auch andere Modi (z.B. einen Standalone-Modus, wenn kein Webserver auf dem System läuft). Es gibt auch einen speziellen Modus für nginx, allerdings werden hier die virtuellen Hosts vom Webserver bei der Generierung/Erneuerung der Zertifikate kurzzeitig verändert/ausgetauscht. Da ich meine vHosts lieber unangetastet lassen möchte, nutze ich daher immer nur den Webroot-Modus.

Zunächst wechseln wir auf den speziell angelegten User:

Ein Zertifikat wird durch einen einzigen Befehl erzeugt.
Tipp: Am besten übernimmt man den Befehl mittels Copy&Paste in einen beliebigen Text-Editor, mit dem man dann die Domain mit „Suchen und Ersetzen“ einfach durch die tatsächlich verwendete Domain einfügt. Auf diese Weise kann man Tippfehler vermeiden.

Mit den Parametern werden die Details zu Generierung der Zertifikate angegeben:

  • Mit -d meinedomain.de wird die Domain angegeben, für die das Zertifikat erzeugt werden soll.
  • --keylength 4096 gibt die Schlüssellänge des RSA-Zertifikats an. Standardmäßig werden hier 2048 Bit verwendet. Das ist in der Regel ausreichend, jedoch sollte man für erhöhte Sicherheit auf eine Schlüssellänge von 4096 Bit setzen.
  • Mit -w /var/www/letsencrypt wird das Verzeichnis angegeben, in dem die Challenge-Dateien gespeichert werden. Dies muss das Verzeichnis sein, welches bei nginx als root Verzeichnis für /.well-known/acme-challenge angegeben wurde (im jeweiligen virtuellen Host).
  • acme.sh speichert die Zertifikat-Dateien im Verzeichnis ~/.acme.sh/meinedomain.de. Es wird davon abgeraten, diese Dateien direkt in den virtuellen Hosts des Webservers zu referenzieren. Aus diesem Grund wird mit den Parametern --key-file , --ca-file , --cert-file und --fullchain-file die Speicherorte der Dateien angegeben, wo die entsprechenden Dateien „installiert“ werden sollen. Nur diese Dateien werden dann später in den vHosts von nginx eingebunden.
  • --reloadcmd gibt den Befehl an, der nach erfolgreicher Ausstellung/Erneuerung der Zertifikate ausgeführt werden soll. Damit der Webserver die neuen Zertifikate korrekt einbinden kann, wird nginx hier einfach kurz neu gestartet. Wenn hier mehrere Befehle ausgeführt werden sollen, sind diese durch ein Semikolon zu trennen.

Nach dem Generieren können alle von acme.sh ausgestellten Zertifikate auf dem System durch folgenden Befehl angezeigt werden:

Ebenfalls wird durch diesen Befehl die Gültigkeitsdauer der Zertifikate angezeigt (dazu später mehr).

Nun wechseln wir wieder auf den normalen User zurück:

Diffie-Hellman-Parameter erzeugen

Die Zertifikate selbst sind der wichtigste Punkt, wenn es um die Verschlüsselung der Verbindung über HTTPS geht. Um die Sicherheit noch weiter zu erhöhen, sollten noch sog. Diffie-Hellman-Parameter genutzt werden. Ohne nun die technischen Details zu beleuchten, geht es um einen sicheren Schlüsselaustausch bei Verbindungsaufbau. Die Generierung des Schlüssels muss dabei nur einmal erfolgen.

Achtung: Die Erzeugung der Diffie-Hellman-Parameter dauert gerade auf schwächerer Hardware sehr lange. Hier muss man bis zur Fertigstellung u.U. mehrere Stunden warten. In diesem Fall kann auch eine Schlüssel mit „nur“ 2048 Bit berechnet werden (die Zahl des zweiten Befehls gibt hierbei die Länge des Schlüssels in Bit an). Auf stärkerer Hardware ist allerdings eine Schlüssellänge von 4096 Bit empfehlenswert.

Einbinden der Zertifikate in nginx

Die Zertifikate können nun einfach mit nginx verwendet werden. Ich beschränke mich hier auf das reine Einbinden der Zertifikate und der entsprechenden SSL-Einstellungen.

Damit das Ganze übersichtlich bleibt, lagere ich die SSL-Settings immer in eine spezielle Datei aus, die dann später in die virtuellen Hosts eingebunden wird. Auf diese Weise sind alle Einstellungen bzgl. SSL nur an einem Ort zu finden.

Dazu legen wir zunächst eine neue Datei an:

Hier werden dann ausschließlich die Anweisungen für SSL aufgeführt:

Neben dem Einbinden der eigentlichen Zertifikate dienen alle weiteren Anweisung ebenso der Sicherheit/Verschlüsselung. Daher bitte auch die Kommentare in der Datei beachten.

Im jeweiligen virtuellen Host für HTTPS ist dann einfach diese ssl.conf einzubinden:

Wichtig: Die SSL-Anweisungen dürfen nicht doppelt im server-Block für HTTPS aufgeführt werden. Wenn hier bereits Optionen angegeben sind, die ebenfalls in der Datei ssl.conf aufgeführt sind, dann sind diese im server-Block für HTTPS zu entfernen.

Nach einem Neustart des Webservers sollten die Zertifikate korrekt eingebunden worden sein:

Überprüfung der Zertifikate

Abschließend lohnt eine Überprüfung der Zertifikate. Hierzu ist der SSL Server Test von Qualys SSL Labs gut geeignet. Mit der gezeigten Konfiguration sollte ein Rating mit A+ und 100% in allen Kategorien erreicht werden:

Ergebnis des SSL-Tests

Ergebnis des SSL-Tests

Falls hier eine niedrigere Bewertung angezeigt werden sollte, liegt dies vermutlich an der SSL-Konfiguration des Webservers. In diesem Fall sollten die entsprechenden Anweisungen der Datei ssl.conf nochmals kontrolliert werden.

Erneuerung der Zertifikate

Die Zertifikate von Let’s Encrypt sind nur für die Dauer von 90 Tagen gültig (Begründung siehe hier) und müssen anschließend erneuert werden.

Bei der Installation von acme.sh wurde ein Cronjob angelegt, der regelmäßig prüft, ob Zertifikate erneuert werden müssen und diese Erneuerung dann ggf. automatisch ausführt. Im Grunde genommen muss man sich daher gar nicht weiter um die Zertifikate kümmern.

Dennoch sollte man nach dem initialen Ausstellen der Zertifikate und Ablauf der 90 Tage kontrollieren, ob die automatische Erneuerung auch wirklich durchgeführt wurde.

Die Gültigkeitsdauer der installierten Zertifikate kann wieder mit folgendem Befehl ermittelt werden:

Upgrade von acme.sh

Für acme.sh werden regelmäßig auch Updates veröffentlicht (siehe GitHub Release-Page). In diesem Fall kann das Skript mit nur einem Befehl auf den neusten Stand gebracht werden:

Das Reizvolle daran ist nun, dass man diese Updates komplett ohne Abhängigkeiten von den Paketquellen der jeweiligen Distributionen einspielen kann.

Fazit

acme.sh macht als Let’s Encrypt Client einen sehr soliden Eindruck. Die Bedienung gestaltet sich recht einfach und da es sich um ein reines Shell Skript handelt, ist man unabhängig von Programmversionen in den Paketquellen einzelner Linux-Distributionen. Ebenfalls wird automatisch ein Cronjob für die Erneuerung der Zertifikate angelegt, so dass man sich nach der ersten Generierung der Zertifikate nicht mehr um deren Erneuerung kümmern muss. Aus genau diesen Gründen werde ich in Zukunft auch acme.sh als Let’s Encrypt Client empfehlen.

Abschließend noch ein Hinweis für Webserver-Admins, die noch einen anderen Let’s Encrypt Client verwenden und auf acme.sh umsteigen wollen: Der nächste Artikel hier im Blog wird den Umstieg zu acme.sh im Detail beleuchten…

Update: Der Artikel zum Umstieg von Certbot auf acme.sh ist online: Let’s Encrypt: Umstieg von Certbot auf acme.sh (nginx)

Weiterführende Artikel

Links

, , , , , , , , , , ,

Kommentare: 48

  • Hans sagt:

    Hallo Jan,

    kannst du die Quelle unbedenklich empfehlen?

    Gruß Hans

    • Jan sagt:

      Hi Hans,

      ich denke es geht um die Installation von acme.sh durch das Pipen einer URL in die Bash: Aus meiner Sicht ja. Ich habe den Hinweis hauptsächlich hinzugefügt, weil das für viele Leute ein absolutes No-Go ist.
      Falls du Bedenken hast, einfach mal einen Blick auf die alternativen Installations-Methoden werfen.

      Gruß,
      Jan

  • Marcus sagt:

    Vielen Dank für die Anleitung!
    Wie entfernt man denn den Certbot sauber?
    Sonst laufen die Zertifikate ja parallel oder?

    • Jan sagt:

      Hi Marcus,

      für Umsteiger von Certbot (so wie ich das in meinen Tutorials immer empfohlen habe) auf acme.sh wird die Tage noch ein Folge-Artikel online gehen. Da sollten dann alle Details erklärt werden.

      Gruß,
      Jan

  • Stefan sagt:

    Hallo Jan,

    hat wunderbar geklappt, konnte meine Test NC erfogreich unstellen.

    Gruß Hans

  • Thomas sagt:

    Hallo Jan,
    für meine Nextcloud-Installation habe ich von aussen nur 443 geöffnet, bzw. oder redirect auf meinem ddl-router konfiguriert.
    Für dieses Verfahren benötigt man ja Port 80.
    Gibt es eine Möglichkeit die Öffnung von Port 80 ins Internet zu verhindern und alternativ einen anderen Port zu verwenden?
    Viele Grüße
    Thomas

    • Jan sagt:

      Hi Thomas,

      ich glaube, dass Let’s Encrypt nur über Port 80 geht. Aber das sollte kein Problem sein: Wenn du die Weiterleitung auf Port 80 aktivierst, kannst du ja über den virtuellen Host regeln, dass ausschließlich Anfragen von Let’s Encrypt entgegen genommen werden. Alles andere kann entweder blockiert werden (deny all) oder auf den entsprechenden HTTPS-Server-Block weiter geleitet werden.

      Gruß,
      Jan

  • Thoams sagt:

    Hallo Jan,

    kannst Du mir noch einen konkreten Hinweis geben, wie ich diesen Ausschuss über den Virtuellen Host bewerkstelligen kann?

    Als Basis: Ich habe mich bisher immer an Deine Konfiguration gehalten.

    Vielen Dank und Grüße

    Thomas

    • Jan sagt:

      Hi Thomas,

      ich würde es mal mit diesem server-Block für HTTP probieren:
      server {
      listen 80 default_server;
      listen [::]:80 default_server;
      server_name meinedomain.de 192.168.178.60;

      root /var/www;

      location ^~ /.well-known/acme-challenge {
      proxy_pass http://127.0.0.1:81;
      proxy_redirect off;
      }

      deny all;
      }

      Damit sollten eigentlich nur noch Anfragen von Let’s Encrypt durchkommen.

      Gruß,
      Jan

      • Thomas sagt:

        Hallo Jan,

        habe heute morgen auch erfolgreich auf Acme.sh umgestellt. Vielen Dank für die Erklärung auch im anderen Post. Eine Bemerkung noch: bei mir hat das purge dazu geführt, dass auch die alten Zertifikate weg waren :-/

        Viele Grüße

        Thomas

        • Jan sagt:

          Hi Thomas,

          vielen Dank für den Hinweis! Da war eh irgendwie der Wurm drin, da Certbot seine Zertifikate in einem anderen Verzeichnis speichert (/etc/letsencrypt/live/meinedomain.de). D.h. das umständliche Umkopieren der Zertifikate war gar nicht notwendig. Ich habe das Tutorial gleich mal angepasst. Nun sollte der Umstieg generell noch einfacher von der Hand gehen.
          Sorry für die Unannehmlichkeiten!

          Gruß,
          Jan

  • Ole sagt:

    Hallo und erst einmal vielen Dank für dein Howto. eine Frage:

    „Bei der Installation von acme.sh wurde ein Cronjob angelegt, der regelmäßig prüft …“

    Seit der Installation des Scriptes bekomme ich folgende Fehlermeldung:
    >>> -bash: /home/user/.acme.sh/acme.sh.env: Keine Berechtigung

    Viele Grüße
    Ole

    • Jan sagt:

      Hi Ole,

      diese Meldung kannst du ignorieren. Sie wird dadurch verursacht, dass das Skript als Root-User installiert/ausgeführt wird. Der normale User, mit dem du erst einmal in der SSH-Session „ankommst“, hat ja zunächst einmal keine Root-Rechte (erst nach dem „sudo -s“).
      Das Skript läuft aber trotzdem einwandfrei, auch wenn die Meldung nach dem Login etwas irreführend ist.

      Ich habe hier noch einen Hinweis im Artikel ergänzt.

      Gruß,
      Jan

      • Christian sagt:

        Hallo Jan,

        wenn die Installation von acme.sh mit „sudo -i“ im Kontext von root ausgeführt wird, wird acme.sh im HOME-Verzeichnis von root installiert und auch das Script .bashrc vom root und nicht des normalen User angepasst. Die Fehlermeldung erscheint dann nicht mehr. Allerdings funktioniert dann der alias auf acme.sh bei „sudo -s“ nicht, nur halt wieder mit „sudo -i“ im richtigen Kontext von root.
        Alternativ kann man in einem Workaround die .bashrc des normalen User in der Art:
        if [ „$USER“ = root ]; then
        . „/MeinBenutzer/.acme.sh/acme.sh.env“
        if
        anpassen. Auch dann wird der Fehler nicht mehr ausgelöst.

        Gruß
        Christian

        • Jan sagt:

          Hi Christian,

          ich betrachte die Fehlermeldung eher als Warnung und ignoriere diese einfach. Bisher hatte ich damit noch keine Probleme.
          Wer die Meldung allerdings wirklich weg haben will, kann deinen Tipp natürlich mal ausprobieren. Danke dafür.

          Gruß,
          Jan

  • Felix sagt:

    Hi Jan,
    wasmacht der resolver 192.168.178.1; genau? Ist damit der DNS-Resolver gemeint? Braucht man den bei einem gehosteten vServer auch?
    Aktuell habe ich die IP-Adresse 127.0.0.1 eingetragen und es scheint keine Probleme zu geben.

    • Jan sagt:

      Hallo Felix,

      mit „resolver“ benennst du einfach einen DNS-Server, der für evtl. auftretende DNS-Anfragen genutzt wird. Im Heim-Bereich ist das meistens einfach der Router, hier kann aber auch ein beliebiger DNS-Server eingesetzt werden, z.B. der DNS-Server von Digitalcourage.
      Anscheinend können bei dir auch über den localhost (127.0.0.1) DNS-Anfragen bearbeitet werden, oder der Server braucht in diesem Fall keine DNS-Auflösung.

      Gruß,
      Jan

      • Felix sagt:

        Hallo Jan,
        der 127.0.0.1 hat zwar funktioniert, hab jetzt aber trotzdem mal den DNS Server meines vServer Providers eingetragen. Hab das Gefühl, dass die Seiten jetzt teilweise schneller laden. Kann mich aber auch täuschen.
        Vielen Dank aber für die schnelle Antwort.

  • Bayram sagt:

    Hallo,

    ich habe auch ein Problem. Ich habe jetzt zwei Weiterleitungen hintereinander, da ich mein Dyndns Dienst nicht direkt am Host funktioniert.
    Also example1.de leitet an ein example2.net weiter. Example2.net wird jeden Tag mit meinem IP versorgt. Jetzt wird aber example1.de nicht als sichere Seite erkannt. Wie kann ich ein Schlüssel erzeugen, der für beide Host gilt? example1.de und example2.net

    Vielen Dank im voraus.

    • Jan sagt:

      Hallo Bayram,

      von was für einer Weiterleitung sprechen wir hier? HTTP 301 oder 302?
      Wenn es wirklich nur eine Weiterleitung ist, benötigst du für beide Domains ein gültiges Zertifikat. Da jedoch dein Server hinter example2.net liegt, kann dieser auch nur das Zertifikat für diese Domain erstellen. Für die erste Domain (example1.de) muss das Zertifikat woanders herkommen (vermutlich vom Domain-Provider).

      Gruß,
      Jan

  • Aki sagt:

    Hi Jan,

    danke für das Tutorial, versuche Nextcloud gerade einzurichten. Ich komme aber leider nicht weiter. Du schreibst bei Vorbereitung des Systems:

    „Neben dem Einbinden der eigentlichen Zertifikate dienen alle weiteren Anweisung ebenso der Sicherheit/Verschlüsselung. Daher bitte auch die Kommentare in der Datei beachten.
    Im jeweiligen virtuellen Host für HTTPS ist dann einfach diese ssl.conf einzubinden“

    Wo genau muss die eingebunden werden?

    • Jan sagt:

      Hi,

      die Einbindung (include) erfolgt durch folgende Zeile:
      include /etc/nginx/snippets/ssl.conf;

      Das ganze muss direkt in einem location-Block passieren, der für HTTPS zuständig ist (also auf Port 443 lauscht).

      Gruß,
      Jan

  • Hendrik sagt:

    Hallo,
    ich möchte gerade von Certbot auf acme.sh switchen, komme aber nicht über die Zertifikatserstellung hinaus . Alles schon mehrere Male wiederholt…

    [So 28. Jul 18:47:27 BST 2019] Single domain=’xxx.xxx.myfritz.net‘
    [So 28. Jul 18:47:27 BST 2019] Getting domain auth token for each domain
    [So 28. Jul 18:47:29 BST 2019] Getting webroot for domain=’xxx.xxx.myfritz.net‘
    [So 28. Jul 18:47:30 BST 2019] Verifying: xxx.xxx.myfritz.net
    mkdir: das Verzeichnis „/var/www/letsencrypt/.well-known“ kann nicht angelegt werden: Keine Berechtigung
    /home/pi/.acme.sh/acme.sh: Zeile 4230: /var/www/letsencrypt/.well-known/acme-challenge/dOfMqvrZdNXjmpO-DKURocRdbhTm2hlMCK-htrWp-i8: Datei oder Verzeichnis nicht gefunden
    [So 28. Jul 18:47:30 BST 2019] xxx.xxx.myfritz.net:Can not write token to file : /var/www/letsencrypt/.well-known/acme-challenge/dOfMqvrZdNXjmpO-DKURocRdbhTm2hlMCK-htrWp-i8
    [So 28. Jul 18:47:30 BST 2019] Please check log file for more details: /home/pi/.acme.sh/acme.sh.log

    • Hendrik sagt:

      Wo fängt man denn am besten mit der Fehlersuche an? Berechtigung des Ordners? Das Log gibt mir selber nicht viel her!?

    • Jan sagt:

      Hallo Hendrik,

      der erste Fehler ist hier vermutlich, dass er das Verzeichnis /var/www/letsencrypt/.well-known nicht anlegen kann. Versuch daher mal folgendes vor dem Aufruf von acme.sh):
      mkdir -p /var/www/letsencrypt/.well-known
      chown -R www-data:www-data /var/www/letsencrypt/.well-known

      Danach nochmal der Aufruf von acme.sh.
      Nutzt du acme eigentlich als Root-User?

      Gruß,
      Jan

      • Hendrik sagt:

        Vielen Dank, das wollte ich sogar auch noch machen…Aber mit der Recherche ist das aus’m Kopf verschwunden.
        Funktioniert leider nicht.
        Wenn du meinst, ob ich unter „Sudo -su“ (bin relativer Laie) arbeite, dann nein. Aber Acme aber unter BEIDEN Varianten „installiert“ und bekomme die selben fehler

      • Hendrik sagt:

        Ok, „Wer lesen kann, ist klar im Vorteil „… Root-Modus..
        Mit Sudo -s installiert und auch die Ordner angelegt, terminal neu gestartet, besser.
        Ich komme zwar weiter, trotzdem mit Fehlermeldung..

        xxx.xxx.myfritz.net:Verify error:Fetching http://xxx.xxxi.myfritz.net/.well-known/acme-challenge/RGYYOraEeN-U7fAFhpTPxj95HsUmBBTEJXQhP76qyCo: Connection refused

        und

        timeout=1
        [Mo 29. Jul 20:38:07 BST 2019] _CURL=’curl -L –silent –dump-header /root/.acme.sh/http.header -g –connect-timeout 1′
        [Mo 29. Jul 20:38:08 BST 2019] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 28
        [Mo 29. Jul 20:38:08 BST 2019] ret=’28‘
        [Mo 29. Jul 20:38:08 BST 2019] Debugging, skip removing: /var/www/letsencrypt/.well-known/acme-challenge/GRBoRpZX3RAnHBDWVH4X7NJA6RcHaiTtFNwmie1Lny8
        [Mo 29. Jul 20:38:08 BST 2019] pid
        [Mo 29. Jul 20:38:08 BST 2019] No need to restore nginx, skip.
        [Mo 29. Jul 20:38:08 BST 2019] _clearupdns
        [Mo 29. Jul 20:38:08 BST 2019] dns_entries
        [Mo 29. Jul 20:38:08 BST 2019] skip dns.
        [Mo 29. Jul 20:38:08 BST 2019] _on_issue_err
        [Mo 29. Jul 20:38:08 BST 2019] Please add ‚–debug‘ or ‚–log‘ to check more details.
        [Mo 29. Jul 20:38:08 BST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
        [Mo 29. Jul 20:38:08 BST 2019] url=’https://acme-v02.api.letsencrypt.org/acme/challenge/YUu333YCEsiLrtMaWH2YCUvmiSnStOYSthyPjwBT2M0/18885521816′
        [Mo 29. Jul 20:38:08 BST 2019] payload='{}‘
        [Mo 29. Jul 20:38:08 BST 2019] POST
        [Mo 29. Jul 20:38:08 BST 2019] _post_url=’https://acme-v02.api.letsencrypt.org/acme/challenge/YUu333YCEsiLrtMaWH2YCUvmiSnStOYSthyPjwBT2M0/18885521816′
        [Mo 29. Jul 20:38:08 BST 2019] _CURL=’curl -L –silent –dump-header /root/.acme.sh/http.header -g ‚
        [Mo 29. Jul 20:38:09 BST 2019] _ret=’0′
        [Mo 29. Jul 20:38:09 BST 2019] code=’400‘
        [Mo 29. Jul 20:38:09 BST 2019] socat doesn’t exists.

        • Jan sagt:

          Hallo Hendrik,

          so wie es aussieht, läuft er in einem Timeout beim Zugriff auf die Validation-URL. Hast du hier vielleicht noch eine Firewall aktiv, die den Zugriff über Port 80 sperrt?
          Ansonsten mal eine einfache txt-Datei in dem Ordner erstellen, der von Let’s Encrypt zur Validierung genutzt wird. Anschließend versuche mal, die Datei im Browser abzurufen. Erst wenn das geht, wird auch die Generierung der Zertifikate funktionieren. Wenn es nicht klappt, wirf mal einen Blick ins nginx error.log.

          Gruß,
          Jan

          • Hendrik sagt:

            Ich habe meine Fritzbox und ufw kontrolliert- offen. Geoip mal testweise für US geöffnet, auch nicht…
            Egal: Ich nehme das zum Anlass, deine kompletten Tutorials von vorn zu implementieren und nicht mehrere Anleitungen von Blogs zusammen zu würfeln!

            DANKE bis hierhin und vielleicht bis bald ;-)

  • Andreas sagt:

    Hallo Jan,

    ich setze mir gerade einen Nextcloud Server neu auf und versuche gerade acme.sh die Zertifikate zu erzeugen.

    Meine Vorgehensweise:
    *) curl https://get.acme.sh | sh
    *) Terminal geschlossen und mit sudo -s neu gestartet
    *) acme.sh –issue -d meinedomain.de –keylength 4096 -w /var/www/letsencrypt –key-file /etc/letsencrypt/meinedomain.de/key.pem –ca-file /etc/letsencrypt/meinedomain.de/ca.pem –cert-file /etc/letsencrypt/meinedomain.de/cert.pem –fullchain-file /etc/letsencrypt/meinedomain.de/fullchain.pem –reloadcmd „systemctl reload nginx.service“ gestartet.

    Nun bekomme ich eine Fehlermeldung: acme.sh: Befehl nicht gefunden.

    Was kann die Ursache sein, dass das Script nicht startet.
    Mit sudo funktionert es nicht. Als normaler User: Keine Berechtigung.

    • Jan sagt:

      Hallo Andreas,

      das ist normal, wenn man acme.sh als Root-User installiert hat. Dann funktioniert der Alias „acme.sh“ auch nur mit Root-Rechten.
      Um das Skript dennoch aufzurufen, muss man es über das korrekte Verzeichnis starten:
      cd /home/USER/.acme.sh
      ./acme.sh PARAMETER

      USER und PARAMETER sind natürlich noch zu ersetzen.

      Gruß,
      Jan

      • Ben sagt:

        Ich klinke mich mal kurz ein, da ich bei acme.sh auch Rechteprobleme habe und die Anleitungen dies leider nicht ganz abdekcen. acme.sh empfiehlt ja ohne root-Rechte zu arbeiten und zu installieren.

        Ich erhalte als root und manuelle Navigation zum acme.sh Speicherort beim Ausführen folgende Meldung:
        „It seems that you are using sudo, please read this link first:
        https://github.com/Neilpang/acme.sh/wiki/sudo

        Passieren tut natürlich nichts

        • Jan sagt:

          Hallo Ben,

          du kannst acme.sh natürlich auch als Non-Root-User einrichten. Dann sollte der Aufruf auch ohne sudo problemlos funktionieren.
          Die von dir erwähnte Meldung habe ich allerdings noch nicht zu Gesicht bekommen.

          Gruß,
          Jan

          • Jan sagt:

            Hallo Bernd,

            OK, nun weiß ich, was du meinst. Tatsächlich kommt mit der aktuellsten Version von acme.sh eine Fehlermeldung, wenn man es per sudo ausführt.
            Ich habe mal sämtliche Artikel, die sich um acme.sh drehen erweitert: Am besten richtet man sich dazu einen speziellen User an, der dann für die Generierung und Verwaltung der Zertifikate zuständig ist.

            Auf jeden Fall danke für den Hinweis!

            Gruß,
            Jan

          • Andreas sagt:

            Hallo Jan,
            nun versuche ich nach dem Update von Deinen Seiten es nochmals:
            Jetzt mit einer anderen Meldung:

            [So Aug 18 17:02:34 CEST 2019] Create account key ok.
            [So Aug 18 17:02:34 CEST 2019] Registering account
            [So Aug 18 17:02:35 CEST 2019] Registered
            [So Aug 18 17:02:35 CEST 2019] ACCOUNT_THUMBPRINT=’xxx‘
            [So Aug 18 17:02:35 CEST 2019] Creating domain key
            [So Aug 18 17:02:36 CEST 2019] The domain key is here: /home/letsencrypt/.acme.sh/meinedomain.de/meinedomain.de.key
            [So Aug 18 17:02:36 CEST 2019] Single domain=’meinedomain.de‘
            [So Aug 18 17:02:36 CEST 2019] Getting domain auth token for each domain
            [So Aug 18 17:02:37 CEST 2019] Getting webroot for domain=’meinedomain.de‘
            [So Aug 18 17:02:37 CEST 2019] Verifying: meinedomain.de
            [So Aug 18 17:02:40 CEST 2019] meinedomain.de:Verify error:Fetching http://meindomain.de/.well-known/acme-challenge/hWjfH7OBq4mo5uOCWcg4oK0eT42wtO2wkcyVu30uJP4: Connection refused
            [So Aug 18 17:02:40 CEST 2019] Please add ‚–debug‘ or ‚–log‘ to check more details.
            [So Aug 18 17:02:40 CEST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh

  • Andreas sagt:

    Hallo,
    jetzt habe ich meine Virtualbox zurückgesetzt, nochmals ohne Tippfehler nochmals durchlaufen lassen:

    [So Aug 18 17:39:40 CEST 2019] Create account key ok.
    [So Aug 18 17:39:40 CEST 2019] Registering account
    [So Aug 18 17:39:41 CEST 2019] Registered
    [So Aug 18 17:39:41 CEST 2019] ACCOUNT_THUMBPRINT=’nrkqn6-w02ktxfbKrqoQ9zx2aC8rX4r1LfYfRWOvCsA‘
    [So Aug 18 17:39:41 CEST 2019] Creating domain key
    [So Aug 18 17:39:44 CEST 2019] The domain key is here: /home/letsencrypt/.acme.sh/meinedomain.de/meinedomain.de.key
    [So Aug 18 17:39:44 CEST 2019] Single domain=’meinedomain.de‘
    [So Aug 18 17:39:45 CEST 2019] Getting domain auth token for each domain
    [So Aug 18 17:39:45 CEST 2019] Getting webroot for domain=’meinedomain.de‘
    [So Aug 18 17:39:46 CEST 2019] Verifying: meinedomain.de
    /home/letsencrypt/.acme.sh/acme.sh: Zeile 4242: /var/www/letsencrypt/.well-known/acme-challenge/hHpnSZKiUbyF-VKQH_C5NkOAUCd11TlFYF7wXJ4JhiE: Keine Berechtigung
    [So Aug 18 17:39:46 CEST 2019] meinedomain.de:Can not write token to file : /var/www/letsencrypt/.well-known/acme-challenge/hHpnSZKiUbyF-VKQH_C5NkOAUCd11TlFYF7wXJ4JhiE
    [So Aug 18 17:39:46 CEST 2019] Please add ‚–debug‘ or ‚–log‘ to check more details.
    [So Aug 18 17:39:46 CEST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh

    • Jan sagt:

      Hi,

      das sieht so aus, als ob die Berechtigungen nicht passen. Der LE-User muss zunächst Mitglied der Gruppe www-data sein und alle betroffenen Verzeichnisse (/etc/letsencrypt und /var/www/letsencrypt) müssen „www-data:www-data“ als Owner haben und die Berechtigungen 775.
      acme.sh wird dann als User letsencrypt ausgeführt und es sollten keine Probleme mehr mit den Berechtigungen geben.

      Gruß,
      Jan

      • Andreas sagt:

        Hallo Jan,
        nochmals alles kontrolliert:
        *) /etc/letsencrypt = www-data (www-data)
        *) /var/www/letsencrypt = www-data (www-data)

        ebenfalls nochmals kontrolliert:
        *) chmod 775 /var/www/letsencrypt
        *) chmod 775 /etc/letsencrypt

        Es kommt nach wie vor die Fehlermeldung.

        Ich bin mit meinem Latein am Ende

        • Jan sagt:

          Hallo Andreas,

          der Fehler ist noch folgender?
          /home/letsencrypt/.acme.sh/acme.sh: Zeile 4242: /var/www/letsencrypt/.well-known/acme-challenge/hHpnSZKiUbyF-VKQH_C5NkOAUCd11TlFYF7wXJ4JhiE: Keine Berechtigung

          Versuch mal, mit dem User für Let’s Encrypt eine Datei (test.txt) im Verzeichnis /var/www/letsencrypt/.well-known/acme-challenge/ anzulegen. Wenn dies klappt, sollte auch acme.sh funktionieren. Andernfalls stimmt etwas mit den Berechtigungen nicht, oder der User für Let’s Encrypt gehört nicht zur Gruppe www-data.

          Gruß,
          Jan

          • Andreas sagt:

            Das Anlegen einer txt Datei hat unter letsencrypt funktioniert.

            Nochmals nach Deinen Vorgaben alles kontrolliert. Gleiches Ergebnis.

            Gruß Andreas

          • Andreas sagt:

            Hallo Jan,
            kann es sein, dass es an meiner VM liegt, das ich keine Connection zusammen bekomme?

            Dem Router eine feste IP mit der MAC Adresse aus der Virtualbox zugewiesen. Externe IP passt mit der DynDNS zusammen.

            Ins Internet komme ich ja auch und kann arbeiten.

            Da muss irgendwo anders „der Hund begraben“ sein.

            LG Andreas

          • Jan sagt:

            Hallo Andreas,

            in den Befehlen zu acme.sh haben sich noch ein paar Fehler versteckt. Ich habe dies korrigiert. Bitte nochmal von vorn ausführen.

            Gruß,
            Jan

          • Andreas sagt:

            Hallo Jan,
            gestern nochmals die VM neu gestartet und Punkt für Punkt abgearbeitet. Es ist alles ohne Probleme durchgelaufen.
            Ich möchte mich auf diesem Wege bei Dir für Deine kompetente Unterstützung bedanken.

            # Gehört aber glaube ich in die Rubrik Ubuntu Server #
            Eine Frage hätte ich noch:
            Die Ports 80, 81 und 82 muss ich auf meinen Router freigeben oder nicht?

            LG aus Wien

          • Jan sagt:

            Hallo Andreas,

            danke für die Rückmeldung.

            Für dieses Setup müssen nach außen nur die Ports 80 und 443 geöffnet sein. Die Ports 81 und 82 werden nur intern auf der gleichen Machine verwendet und müssen nicht in der Firewall frei gegeben werden.

            Gruß,
            Jan

  • Gerd-Ulrich Meyer sagt:

    Hallo,
    deine Anleitung kommt mir eigentlich gerade ganz recht, da ich für 2 Projekte zwingend SSL brauche. Allerdings stehe ich vor folgendem Problem: Beim (etwas länglichen und dahier hier abgekürzten) Befehl „acme.sh […]“, den ich wegen headless-Betrieb dann doch abtippen musste, erhalte ich folgende Meldung:
    [Sun 6 Oct 20:28:50 BST 2019] Only RSA or EC key is supported. keyfile=/home/letsencrypt/.acme.sh/ca/acme-v02.api.letsencrypt.org/account.key
    [Sun 6 Oct 20:28:50 BST 2019] Please add ‚–debug‘ or ‚–log‘ to check more details.
    [Sun 6 Oct 20:28:50 BST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh

    Den Parameter will ich gern noch hinzufügen (nützt es was in diesem Fall?), aber sehe ich das richtig, dass ich jetzt kein(e) Zertifikat(e) erhalten habe?

    Raspberry Pi 3b+ mit Raspbian GNU/Linux 10 (buster)

    • Jan sagt:

      Hi,

      ich denke, dass es sich da um dieses Problem handelt (Link), auch wenn die Fehlermeldung hier anscheinend so gar nicht passt.
      Probier doch einfach mal die Lösung aus, vielleicht ist das Problem damit ja schon behoben.

      Gruß,
      Jan

Schreibe einen Kommentar

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