DecaTec

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

Let’s Encrypt: Umstieg von Certbot auf acme.sh (nginx)

Let's Encrypt Logo

Im letzten Artikel ging es um das Erstellen von TLS-Zertifikaten von Let’s Encrypt. Als Client kam hier acme.sh zum Einsatz. In meinen bisherigen Artikeln habe ich bisher immer Certbot als Client für Let’s Encrypt empfohlen. Da acme.sh meiner Meinung nach allerdings einige Vorteile bietet, wird dies vermutlich auch meine zukünftige Empfehlung zur Generierung von TLS-Zertifikaten von Let’s Encrypt sein.

Da aber etliche Leser meines Blogs wohl noch Certbot nutzen, möchte ich in diesem Artikel einen Leitfaden zum Umstieg auf acme.sh nachliefern.

Besonders wichtig dürfte die Umstellung auf acme.sh für Debian-Nutzer sein, da die in den Paketquellen enthaltene Certbot-Version nur ein Validierungsverfahren beherrscht, welches Let’s Encrypt bald nicht mehr unterstützen wird (mehr Infos dazu gibt es hier).

Wer Certbot bisher noch nicht verwendet hat: Dieser Artikel richtet sich ausschließlich an Umsteiger von Certbot zu acme.sh. Wer das erste mal TLS-Zertifikate erzeugen möchte, der sollte sich an den Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx halten.

Update-Historie (letztes Update 15.06.2019)
  • 15.06.2018:
    • 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.
  • 13.02.2018:
    • Hinweis für die Berechtigungen des Verzeichnisses /var/www/letsencrypt hinzugefügt.
  • 11.02.2019:
    • Hinweis auf Überschreiben der Crontab durch Installation von acme.sh hinzugefügt/Sichern der bestehenden Crontab.
  • 10.02.2019:
    • Reihenfolge der im Tutorial ausgeführten Schritte angepasst – das Umkopieren der alten Zertifikate war nicht notwendig, da diese von Certbot in einem anderen Verzeichnis gespeichert wurden.

 

Voraussetzungen

Ich gehe im Folgenden davon aus, dass die TLS-Zertifikate mit Certbot gemäß dem Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban erstellt wurden.

Im Detail heißt dies:

  • Certbot wurde installiert und der automatisch eingerichtete Cronjob zur Erneuerung der Zertifikate wurde genutzt.
  • Es wurden durch Certbot bereits Zertifikate generiert (d.h. der Webserver ist fertig eingerichtet und im Router sind die entsprechenden Port-Weiterleitungen bereits eingerichtet).
  • Die Zertifikate sind im Verzeichnis /etc/letsencrypt/live/meinedaomin.de gespeichert (meinedomain.de dient hier nur als Beispiel-Domain) und bestehen aus den Dateien cert.pem, chain.pem, fullchain.pem und privkey.pem.
  • Diffie-Hellman-Parameter sind ebenfalls bereits vorhanden (/etc/nginx/ssl/dhparams.pem).

Vorbereitungen – alte Zertifikate kopieren

Bevor die neuen Zertifikate erstellt werden können, müssen die alten Zertifikate erst einmal an eine andere Stelle kopiert werden. Dies ist notwendig, da bei der späteren Deinstallation von Certbot der komplette Order /etc/letsencrypt entfernt wird.

Damit diese Kopie der Zertifikate (temporär) vom Webserver verwendet wird, sind die SSL-Einstellungen im Gateway-Host zu bearbeiten:

Hier sind die Verzeichnis-Angaben für die Zertifikat-Dateien anzupassen:

Ein Neustart von nginx sollte dann problemlos verlaufen und die (temporären) Zertifikate werden genutzt:

Certbot deinstallieren

Nun kann Certbot komplett vom System entfernt werden. Mit der Installation von Certbot wurden nicht nur die Programm-Dateien installiert, sondern es wurde darüber hinaus noch ein Cronjob eingerichtet, der für die automatische Erneuerung der Zertifikate sorgt. Diesen Cronjob kann man mit folgendem Befehl ermitteln:

In der Auflistung sollte dann der Cronjob von Certbot auftauchen:

systemctl list-timers listet den Cronjob von Certbot

systemctl list-timers listet den Cronjob von Certbot

Als erstes sollte Certbot deinstalliert werden. Dies geschieht über folgenden Befehl:

Dies deinstalliert neben den Programm-Dateien auch noch sämtliche Konfigurationen, Abhängigkeiten und auch die alten Zertifikate.

Anschließend sollte ein systemctl list-timers den Cronjob für Certbot nicht mehr aufführen und Certbot ist restlos vom System entfernt worden.

Neue Zertifikate generieren

Der Einfachheit halber werden am besten gleich ganz neue Zertifikate über acme.sh erstellt. Das sollte kein Problem darstellen, wenn man die alten Zertifikate nicht ein paar Tage zuvor mit Certbot erstellt hat – Let’s Encrypt hat gewisse „Rate Limits“, d.h. man kann in einem bestimmten Zeitraum nur eine gewisse Anzahl an Zertifikaten beantragen (siehe hier).

Details zu dem Vorgehen und zur „Installation“ von acme.sh sind im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx zu finden, daher hier im Schnelldurchlauf.

Wichtig: Falls bereits Cronjobs (für den Root-User) eingerichtet sind, dann solltet ihr euch vorher die aktuelle Crontab sichern, da acme.sh diese bei der Installation ungefragt überschreibt:

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

Nun legen wir zunächst das Verzeichnis an, in dem später die Zertifikate gespeichert werden:

Bevor wir nun die Zertifikate erzeugen, stellen wir zunächst noch sicher, dass beim Verzeichnis /var/www/letsencrypt die korrekten Besitzrechte gesetzt sind:

Die Generierung der Zertifikate erfolgt dann über einen Befehl.
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.

Da wird am Webserver ansonsten nichts bzgl. Let’s Encrypt geändert haben, sollte die Generierung der Zertifikate erfolgreich abgeschlossen werden können.

Die Diffie-Hellman-Parameter müssen nicht neu generiert werden, sondern können wiederverwendet werden. Dennoch kopieren wir die Datei an einen anderen Speicherort, somit ist das Vorgehen zum vorherigen Artikel identisch:

Einbinden der neuen Zertifikate

Nun können die neu Generierten Zertifikate auch schon eingebunden werden. Für eine bessere Übersichtlichkeit lagern wir dazu aber auch noch sämtliche Webserver-Einstellungen bzgl. SSL in eine eigene Datei aus.

Wichtig: Diese Datei darf nicht in dem Verzeichnis gespeichert werden, in dem nginx die virtuellen Hosts erwartet (also /etc/nginx/conf.d).

Hier werden nun die folgenden Anweisungen aufgenommen:

Die markierten Zeilen betreffen die neuen Zertifikat-Dateien, alle anderen Anweisungen sind identisch zu den Anweisungen im Gateway-Host.

Damit die SSL-Einstellungen nur noch aus der Datei ssl.conf gezogen werden, muss der Gateway-Host angepasst werden:

Sämtliche Einstellungen, die schon in der ssl.conf aufgeführt werden, sind aus dem Gateway-Host zu entfernen. Diese werden dann durch eine einzige Zeile ersetzt (am besten direkt nach der Direktive server_name):

Ein Neustart des Webservers bindet nun die neuen Zertifikate ein und sollte ohne Fehlermeldung ablaufen. Falls hier dennoch Fehler auftreten, sind vermutlich noch ein paar SSL-Anweisungen doppelt vorhanden (im Gateway-Host und in der ssl.conf). Welche Anweisungen zum Fehler führen, kann man einfach mit folgendem Befehl herausfinden:

Abschlussarbeiten

Zum Schluss können noch die (kopierten) alten Zertifikate und Diffie-Hellman-Parameter entfernt werden:

Überprüfung der neuen Zertifikate

Zum Schluss können die neuen Zertifikate noch getestet werden. Hierzu ist der SSL Server Test von Qualys SSL Labs gut geeignet. Hier sollte ein Rating mit A+ und 100% in allen Kategorien erreicht werden können:

Ergebnis des SSL-Tests

Ergebnis des SSL-Tests

Falls die Bewertung schlechter ausfällt, sollten sollten nochmals die Einstellungen des Webservers kontrolliert werden, v.a. die Anweisungen in der ssl.conf.

Erneuerung der Zertifikate

Die Zertifikate von Let’s Encrypt nur eine begrenzte Gültigkeit von 90 Tagen (Begründung siehe hier), danach müssen sie erneuert werden.

acme.sh hat aber bereits bei der Installation einen Cronjob eingerichtet, der sich um die automatische Erneuerung der Zertifikate kümmert – hier ist also nach dem ersten Generieren der Zertifikate nichts weiter zu tun.

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

Fazit

Der Artikel hat gezeigt, wie man von Certbot auf acme.sh für die Generierung von Let’s Encrypt Zertifikaten umsteigen kann. Darüber hinaus wurde die Verwaltung der SSL-Einstellungen am Webserver vereinfacht, indem die entsprechenden Anweisungen in eine eigene Datei ausgelagert wurden.

Nach Erfolgreicher Umstellung sollte man nur mal nach ca. 90 Tagen (Gültigkeitsdauer der Let’s Encrypt Zertifikate) kontrollieren, ob die Zertifikate auch automatisch erneuert wurden. Ist dies der Fall, kann man sich entspannt zurück lehnen und muss sich nicht mehr manuell um die Zertifikate oder deren Erneuerung kümmern.

Weiterführende Artikel

Links

, , , , , , , , , , ,

Kommentare: 35

  • Michael sagt:

    Sehr gute Anleitung mal wieder!
    Danke!

  • Jens sagt:

    Lieber Jan,

    die Anleitung war gut nachvollziehbar. Folgende kleine Hinweise:
    – Leider wurde bei mir mit dem Befehl „apt-get purge certbot“ der Ordner /etc/letsencrypt mit entfernt und ich musste das Zertifikat neu erzeugen.
    – Im letzten Löschbefehl für die alten DH-Parameter ist ein kleiner Buchstabendreher drin (Ordnen nginx).
    – Außerdem habe ich mit dem Parameter –domain oo.meinedomain.de beim acme_Aufruf noch die Subdomain des Onlyoffice-Servers mit aufgenommen.

    Ein schönes Wochenende noch

    Jens

    • Jan sagt:

      Hi Jens,

      danke für den Hinweis. Ich habe das Tutorial nochmals angepasst. Nun werden die alten Zertifikate anfangs an einen anderen Speicherort kopiert und die SSL-Einstellungen im Gateway-Host (temporär) angepasst, so dass Certbot nun gefahrlos entfernt werden kann.
      Und ja, man kann auch gleich mehrere Domains mit einem Zertifikat bestücken: Einfach mittels -d domain1.de -d domain2.de weitere Domains mit dem Befehl zur Generierung der Zertifikate angeben.

      Gruß,
      Jan

  • Heiko sagt:

    Hallo Jan,
    ich habe deine Anleitung befolgt und es hat auch alles geklappt. Jetzt nach einem Neustart des Servers startet nginx nicht mehr. Der Befehl nginx -t gibt folgendes aus:

    nginx: [alert] could not open error log file: open() „/var/log/nginx/error.log“ failed (13: Permission denied)
    2019/02/10 13:22:36 [warn] 1805#1805: the „user“ directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
    2019/02/10 13:22:36 [emerg] 1805#1805: BIO_new_file(„/etc/letsencrypt/meinedomain.de/fullchain.pem“) failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen(‚/etc/letsencrypt/meinedomain.de/fullchain.pem‘,’r‘) error:2006D080:BIO routines:BIO_new_file:no such file)
    nginx: configuration file /etc/nginx/nginx.conf test failed

    • Jan sagt:

      Hi Heiko,

      ja, mein Fehler. Durch die Deinstallation von Certbot werden die alten Zertifikate gleich mit entfernt. Besser gesagt, das ganze Verzeichnis /etc/letsencrypt.
      Ich habe den Artikel nochmals überarbeitet, so dass nun die alten Zertifikate ganz am Anfang an einen anderen Speicherort kopiert werden und von dort (temporär) bei nginx eingebunden werden.

      In deinem konkreten Fall kannst du dir nun behelfen, indem du einfach die Backups der alten Zertifikate nutzt. Wenn du diese z.B. unter /etc/cert-backup gespeichert hast, dann reicht es im Gateway-Host den Speicherort der Zertifikate anzupassen:
      ssl_certificate /etc/cert-backup/live/meinedomain.de/fullchain.pem;
      ssl_certificate_key /etc/cert-backup/live/meinedomain.de/privkey.pem;
      ssl_trusted_certificate /etc/cert-backup/live/meinedomain.de/chain.pem;

      Danach sollte nginx wieder gestartet werden können und du kannst mit der Generierung der Zertifikate mittels acme.sh fortfahren.

      Gruß,
      Jan

    • Heiko sagt:

      Jetzt scheint es wieder zu gehen: Mein Ordner /etc/letsencrypt (und damit auch der Unterordner meinedomain.de) war weg. Ich habe diesen jetzt neu angelegt und bin deine Anleitung noch einmal neu durchgegangen, jetzt startet nginx wieder.

      Ich hoffe, dass ich mir jetzt nicht sonst irgendetwas zerschossen habe, aber es läuft wieder und der SSL-Scan (Scan, nicht die Cache-Ergebnisse) sieht gut aus.

      Liebe Grüße und vielen Dank

      • Jan sagt:

        Hi Heiko,

        super, danke für die Rückmeldung!
        Wenn nginx gestartet werden kann und der SSL-Test auch grünes Licht gibt, dann sieht das alles gut aus. Sollte eigentlich keine Probleme mehr geben.

        Gruß,
        Jan

    • Heiko sagt:

      Oh, habe deine Antwort zu spät gelesen. Bin aber froh, dass der entfernte letsencrypt-Ordner „normal“ ist und ich nicht versehentlich noch anderes gelöscht habe. Danke für die schnelle Antwort! :-)

  • abweichler sagt:

    Hallo Jan!
    Herzlichen Dank für deine Anleitung!
    Ich habe dazu kurz folgende Frage: Würdest du grundsätzlich den Umstieg von Certbot auf acme.sh empfehlen? Falls ja, wann sollte der Umstieg spätestens stattfinden bzw. ist schon bekannt ab wann genau das Zertifizierungsverfahren nicht mehr unterstützt wird?

    • Jan sagt:

      Hi,

      ja, acme.sh unterstützt meines Wissens nach alle Featurees von Let’s Encrypt. Da du das Skript auch ganz einfach Updaten kannst (Anleitung siehe hier), bist du damit nicht mehr abhängig von einer Programm-Version in den Paketquellen deiner Distribution.
      Daher würde ich generell den Umstieg empfehlen.

      Das alte Validierungsverfahren wird meines Wissens nach ab dem 15.02. von Certbot nicht mehr unterstützt. Zertifikate, die vor diesem Datum ausgegeben wurden, sind natürlich noch die vollen 90 Tage lang gültig.

      Gruß,
      Jan

  • Niklas sagt:

    Hallo Jan,

    habe auch diese tolle Anleitung hier umgesetzt, was soweit auch sehr gut geklappt hat. Leider wurde bei der „Installation“ von acme.sh wohl nicht nur ein neuer cronjob angelegt, sondern gleich die gesamte crontab des ausführenden Nutzers überschrieben. Mein zuvor eingerichteter cronjob für NextcloudBackup.sh war anschließend jedenfalls weg, nebst dem obligatorischen Erläuterungen zu Beginn der crontab (Ubuntu Server).

    Grüße
    Niklas

    • Jan sagt:

      Hi Niklas,

      danke für den Hinweis! Ich konnte das Verhalten nachvollziehen, eine bestehende Crontab wird einfach ungefragt überschrieben. Ist evtl. ein Bug des „Installers“ von acme.sh.
      Auf jeden Fall habe ich die beiden Artikel über acme.sh mit einem deutlichen Hinweis ergänzt, dass man vor der Installation die aktuelle Crontab wegsichern sollte.

      Ist mir so auch noch nicht aufgefallen, da das Erstellen der TLS-Zertifikate immer der erste Schritt auf einer neu aufgesetzten Maschine war, welcher einen Cronjob verlangt hat.
      Beim Umstieg von Certbot ist das natürlich etwas suboptimal, da gebe ich dir recht.

      Gruß,
      Jan

  • Ben sagt:

    Hi Jan,
    Hi @ all,

    für euch zur Info, falls jemand auf das gleiche Problem stößt.
    Ich hatte das Problem das acme.sh einen Fehler ausgab:
    Can not write token to file : /var/www/letsencrypt/.well-known/acme-challenge/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

    Dies lag bei mir daran, das die Berechtigung auf den Ordner /var/www/letsencrypt/.well-known/acme-challenge auf root root standen.
    Ich habe den Ordner …/.well-known/acme-challenge gelöscht und neu angelegt. Anschließend habe ich dem Ordner plus Unterordner per chown auf den Webserver User berechtigt.
    Danach hat es funktioniert.

    @Jan: Kannst du mir sagen ob diese Berechtigung so i.O. ist? Das Verzeichnis sollte ja durch den Web-Server User, i.d.R. www-data, beschreibar sein oder?

    Danke!

    Gruß
    Ben

  • Hans sagt:

    Hallo Jan,

    klasse Anleitung. Eigentlich hat alles funktioniert. Aber wenn ich Nextcloud aufrufen möchte, bekomme ich ERR_CONNECTION_REFUSED.

    In nginx log finde ich irgendwie nichts.

    nginx -t sagt, dass alles in Ordnung ist.

    Idee?

    VG
    Hans

    • Jan sagt:

      Hi Hans,

      siehst du vielleicht in der Developer Console im Browser einen genauen Fehler (Shortcut F12)? Was sagt der SSL-Test von Qualys zu deiner Seite?
      Ohne Logs, etc. ist es erst einmal schwierig, den genauen Fehler zu finden.

      Gruß,
      Jan

      • Hans sagt:

        Hallo Jan,

        gestern Abend habe ich aus meinem internen Netz nicht geschafft über die Internet Adresse die Nextcloud Startseite aufzurufen. Von der Arbeit geht es?

        Vor dem Zertifikatswechsel hat es funktioniert? Über die interne IP funktioniert es aber.

        Beim SSL Test bekomme ich nur ein A. Der KEy Exchange ist nur bei 90%. Bei den Handshake Simulationen Android 5.0.0;6.0; Chrome 49; Firefox 31.3.0;47 und IE 11/win Phone 8.1 habe ich einen „Server sent fatal alert: handshake_failure“

        Gruß
        Hans

        • Jan sagt:

          Hi Hans,

          also wenn es „von außen“ funktioniert, dann läuft die Cloud ja erst einmal.
          Wenn es intern im LAN nicht geht, dann hilft wohl nur ein tracert auf die Domain um zu sehen, wo der Request hingeht.

          Auch bei einem Key Exchange von „nur“ 90% sollte ein A+ Rating herauskommen. Evtl. ist HSTS nicht korrekt eingerichtet? Das sollte dann eigentlich immer für ein A+ sorgen.

          Gruß,
          Jan

          • Hans sagt:

            Hi Jan,

            ich schaue mal später mit einem tracert nach.

            Wie und wo richte ich denn HSTS korrekt ein?

            Gruß
            Hans

          • Jan sagt:

            Hi Hans,

            HSTS wird durch folgende Zeile aktiviert:
            add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;";

            Falls du mehrere Subdomains nutzt, ist es in diesem Zusammenhang wichtig, dass bei allen vorhandenen Subdomains HSTS aktiviert wurde.

            Gruß,
            Jan

          • Hans sagt:

            Hallo Jan,

            ich habe noch neben nextcloud auch netdata und shellinabox aus meinem Server also meinedomain.de/nextcloud und meinedomain.de/netdata.

            Sind das jetzt Subdomänen? Eigentlich sind das locations, oder Wenn ja, im Gateway Host habe ich Zeile auch nicht im Bereich Nextcloud sondern wir bei Dir in den Artikeln beschrieben ist.

            Sonst betreibe ich nichts, wo ich die HSTS vergessen haben könnte.

            Gruß
            Hans

          • Jan sagt:

            Hi Hans,

            korrekt, das sind keine Subdomains. Hast du schon kontrolliert, ob du den HSTS Header evtl. irgendwo doppelt setzt? Die ganzen Header-Infos dürfen nur einmal gesetzt werden, ansonsten werden diese meistens ignoriert.

            Gruß,
            Jan

          • hans sagt:

            Hallo Jan,

            sorry, dass ich mich nicht gemeldet habe.

            Ich hatte die Anweisung

            add_header Strict-Transport-Security „max-age=63072000; includeSubdomains; preload;“;

            auch noch im Nextcloud virtuellen Host. Dort auskommentiert und den kompletten Rechner neu gestartet. Leider keinen Erfolg

            Bekomme ich aus dem Protokoll der Überprüfung noch mehr raus, wo der Fehler steckt?

            Gruß
            Hans

          • Jan sagt:

            Hi Hans,

            ich habe hier noch einen anderen Hinweis gefunden. Probiert mal aus, eine einfache HTML-Seite direkt in der Root-Domain zu hosten. Dann den SSL-Test nochmals ausführen. Danach sollte ein A+ Rating rauskommen.

            Gruß,
            Jan

          • Hans sagt:

            Hallo Jan,

            ich habe unter /var/www eine einfache html Seite (Test nginx Seite, dass der Server korrekt läuft) eingestellt.
            Server komplett neu gestartet und leider immer noch ein „A“.
            Ich kann Dir auch gerne per direkter Mail meine Domain angeben. Vielleicht siehst Du etwas im Protokoll, was nicht richtig ist.

            Gruß Hans

          • Jan sagt:

            Hi Hans,

            ja, kannst mir gern mal die URL per Mail zukommen lassen. Dann schaue ich die Tage mal drüber.

            Gruß,
            Jan

          • Hans sagt:

            Hallo Jan,

            habe an die support at deca… sie geschickt.
            Gruß
            Han

  • Hans sagt:

    Hallo Jan,

    irgendwie habe ich auch ein weiteres „Problem“. Wenn ich mich mit meinem normalen User einlogge erhalte ich folgenden Hinweis (habe Ubuntu landscapes installiert, wodurch ich beim Einloggen einen Status erhalte, z.B. Pakete zu installieren usw.):

    -bash /home/hans/.acme.sh/scme.sh.env: Keine Berechtigung

    Möchten ich den Befehl acme.sh –list ausführen bekomme ich Befehl nicht gefunden.

    Als root funktioniert der Befehl.

    Den Umstieg habe ich als root gemacht. In Homeverzeichnis von hans ist aber ein Verzeichnis .acme.sh.

    Funktioniert jetzt die Aktualisierung? Kann ich den Hinweis (keine Berechtigung) loswerden?

    Gruß
    Hans

    • Jan sagt:

      Hi Hans,

      diese Meldung kann ignoriert werden. Sie wird verursacht, weil acme.sh als Root-User installiert wurde und der „normale“ User bei dir keine Berechtigungen auf das Skript hat (Owner ist ja Root).
      acme.sh muss nicht unbedingt als Root-User installiert/ausgeführt werden, allerdings gestaltet sich die ganze Sache dann etwas komplizierter: Der entsprechende User braucht erst mal ein Home-Verzeichnis. Darüber hinaus braucht er Schreibrechte auf /etc/letsencrypt. Zu guter Letzt brauch er ebenfalls die Rechte, die Befehle nach dem Erneuern der Zertifikate ohne Root-Passwort ausführen zu dürfen (also z.B. nginx neu starten). Das macht die Sache meiner Meinung nach nur unnötig kompliziert, daher lasse ich das Skript einfach als Root-User laufen.

      Edit: Ich habe hier auch noch einen Hinweis im allgemeinen Artikel über acme.sh ergänzt.

      Gruß,
      Jan

  • Ole sagt:

    Hi,

    wie immer gut, leider kann ich das skript gar nicht ausführen..ich bekomme
    „command not found“, eben auch bei acme.sh -h.

    download klappt:
    [Wed Apr 24 19:31:24 UTC 2019] Good, bash is found, so change the shebang to use bash as preferred.
    [Wed Apr 24 19:31:24 UTC 2019] OK
    [Wed Apr 24 19:31:24 UTC 2019] Install success!

    ich sehe die sh-Datei, dann kann sie aber nicht ausführen (als root)

    weder mit ./ noch bash noch mit sh vorne weg…
    auch ausführbar machen bringt nicht…

    Jem,and ne Ahnung ne Idee?

    • Jan sagt:

      Hi Ole,

      du bist nun innerhalb weniger Tage der zweite, der anscheinend mit dem Alias für acme.sh Probleme hat.
      wenn dieser Alias nicht funktioniert, dann musst du über den absoluten Pfad des Shell-Skripts gehen. Dieses ist hier zu finden ~/.acme.sh/acme.sh (also in einem versteckten Verzeichnis im Home-Verzeichnis des Users).
      Darüber sollte das dann eigentlich funktionieren.

      Welche Distribution und Version verwendest du? Vielleicht gibt es ja bei bestimmten Kombinationen Probleme.

      Gruß,
      Jan

  • Jürgen Fuchs sagt:

    Lieber Jan, vielen Dank erstmal für die tollen Anleitungen. Mit deiner Hilfe konnte ich Nextcloud und Onlyoffice (relative) mühelos auf meiner Intel-NUC installieren, obwohl ich ein blutiger Linux-Anfänger bin.

    Nun habe ich Certbot gemäß deiner Anleitung wieder deinstalliert, was zur Folge hat, dass die Verbindung zu Onlyoffice in der Subdomain nicht mehr sicher ist.

    Ich vermute, dass die Deinstallation von Certbot auch die Zertifikate der Subdomain für Onlyoffice entfernt hat, denn diese wurden ja mit Certbot erzeugt.

    Gibt es eine Möglichkeit, die Zertifikate für die Onlyoffice-Subdomain mit acme.sh zu generieren? Oder muss das zwingend mit Certbot gemacht werden?

    Vielen Dank für einen kurzen Hinweis und viele Grüße

    Jürgen

    • Jan sagt:

      Hallo Jürgen,

      klar, das ist auch mit acme.sh möglich. Du kannst hier (ähnlich wie bei certbot auch) mehrere (Sub-)Domains in ein Zertifikat packen. Die zusätzlichen Domains werden hier mittels -d angehängt. Das ganze könnte dann so aussehen:
      acme.sh --issue -d meinedomain.de -d office.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"

      Wenn du zusätzlich ECC-Zertifikate nutzt (siehe hier), dann muss der entsprechende Befehl natürlich auch hier um eine weitere Sub-Domain ergänzt werden.

      Gruß,
      Jan

Schreibe einen Kommentar

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