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 18.06.2020)- 18.06.2021:
- Aufruf von acme.sh mit Parameter „server“, so dass Zertifikate über Let’s Encrypt bezogen werden.
- 03.02.2020:
- Cipher Suite DHE-RSA-AES256-GCM-SHA384 entfernt.
- 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.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.
Inhalt
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.
mkdir -p /etc/certs-temp cp -r /etc/letsencrypt/* /etc/certs-temp
Damit diese Kopie der Zertifikate (temporär) vom Webserver verwendet wird, sind die SSL-Einstellungen im Gateway-Host zu bearbeiten:
nano /etc/nginx/conf.d/meinedomain.de.conf
Hier sind die Verzeichnis-Angaben für die Zertifikat-Dateien anzupassen:
ssl_certificate /etc/certs-temp/live/meinedomain.de/fullchain.pem; ssl_certificate_key /etc/certs-temp/live/meinedomain.de/privkey.pem; ssl_trusted_certificate /etc/certs-temp/live/meinedomain.de/chain.pem;
Ein Neustart von nginx sollte dann problemlos verlaufen und die (temporären) Zertifikate werden genutzt:
service nginx restart
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:
systemctl list-timers
In der Auflistung sollte dann der Cronjob von Certbot auftauchen:
Als erstes sollte Certbot deinstalliert werden. Dies geschieht über folgenden Befehl:
apt-get purge certbot
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.
Hinweis: acme.sh sollte nicht mit Root-Rechten ausgeführt werden. Am besten legt man dafür einen speziellen User an. Wie man dazu vorgehen kann, ist im oben genannten Artikel detailliert erklärt.
Wichtig: Falls bereits Cronjobs (für den entsprechenden User) eingerichtet sind, dann solltet ihr euch vorher die aktuelle Crontab sichern, da acme.sh diese bei der Installation ungefragt überschreibt:
crontab -l > crontab.bak
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 und passen die Rechte an:
mkdir -p /var/www/letsencrypt/.well-known/acme-challenge chown -R www-data:www-data /var/www/letsencrypt chmod -R 775 /var/www/letsencrypt mkdir -p /etc/letsencrypt/meinedomain.de chown -R www-data:www-data /etc/letsencrypt chmod -R 775 /etc/letsencrypt
Die Generierung der Zertifikate erfolgt dann über einen Befehl. Dieser muss mit dem speziell eingerichteten User ausgeführt werden:
su - letsencrypt
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.
acme.sh --issue -d meinedomain.de --server letsencrypt --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 "sudo /bin/systemctl reload nginx.service"
Da wird am Webserver ansonsten nichts bzgl. Let’s Encrypt geändert haben, sollte die Generierung der Zertifikate erfolgreich abgeschlossen werden können.
Anschließend kann man wieder auf den normalen User wechseln:
exit
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:
mkdir -p /etc/nginx/dhparams cp /etc/nginx/ssl/dhparams.pem /etc/nginx/dhparams/dhparams.pem
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).
mkdir -p /etc/nginx/snippets nano /etc/nginx/snippets/ssl.conf
Hier werden nun die folgenden Anweisungen aufgenommen:
# Certificates used ssl_certificate /etc/letsencrypt/meinedomain.de/fullchain.pem; ssl_certificate_key /etc/letsencrypt/meinedomain.de/key.pem; # This should be ca.pem (certificate with the additional intermediate certificate) # See here: https://certbot.eff.org/docs/using.html ssl_trusted_certificate /etc/letsencrypt/meinedomain.de/ca.pem; # Diffie-Hellman parameter, recommended 4096 bits ssl_dhparam /etc/nginx/dhparams/dhparams.pem; # Not using TLSv1 will break: # Android <= 4.4.40 # IE <= 10 # IE mobile <=10 # Removing TLSv1.1 breaks nothing else! # TLSv1.3 is not supported by most clients, but it should be enabled. ssl_protocols TLSv1.2 TLSv1.3; # Cipher suite from https://cipherli.st/ # Max. security, but lower compatibility ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384'; # Cipher suite from https://wiki.mozilla.org/Security/Server_Side_TLS #ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; # (Modern) cipher suite from https://mozilla.github.io/server-side-tls/ssl-config-generator/ #ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; # Use multiple curves. ssl_ecdh_curve secp521r1:secp384r1; # Server should determine the ciphers, not the client ssl_prefer_server_ciphers on; # OCSP Stapling # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; resolver 192.168.178.1; # SSL session handling ssl_session_timeout 24h; ssl_session_cache shared:SSL:50m; ssl_session_tickets off;
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:
nano /etc/nginx/conf.d/meinedomain.de.conf
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):
include /etc/nginx/snippets/ssl.conf;
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:
nginx -t
Abschlussarbeiten
Zum Schluss können noch die (kopierten) alten Zertifikate und Diffie-Hellman-Parameter entfernt werden:
rm -r /etc/certs-temp rm -r /etc/nginx/ssl
Ü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:
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:
acme.sh --list
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
- Let’s Encrypt Zertifikate mit acme.sh und nginx
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
- Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten
Sehr gute Anleitung mal wieder!
Danke!
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
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
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
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
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
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
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! :-)
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?
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
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
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
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
Kommando zurück, leider kommt der Fehler immer noch…
Der Debugoutput sagt: Keine Berechtigung.
Hi Ben,
wie rufst du acme.sh auf? Versuch mal sudo acme.sh…
Gruß,
Jan
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
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
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
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
Hi Jan,
ich schaue mal später mit einem tracert nach.
Wie und wo richte ich denn HSTS korrekt ein?
Gruß
Hans
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
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
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
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
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
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
Hi Hans,
ja, kannst mir gern mal die URL per Mail zukommen lassen. Dann schaue ich die Tage mal drüber.
Gruß,
Jan
Hallo Jan,
habe an die support at deca… sie geschickt.
Gruß
Han
Hi,
wie habt ihr das Problem am Ende gelöst?
Ich hab mich die letzten 3 Tage fast bekloppt gegooglet mit exakt derselben Problematik. Am Ende lag es dadran, dass die IPv6 Ports für den Server in meiner Fritzbox nich geöffnet werden dürfen.
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
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
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?
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
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
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
Hallo Jan,
herzlichen Dank für die schnelle Antwort. Nun klappt alles wieder wie gehabt.
Viele Grüße
Jürgen
Hi Jan,
kurze Info. Ich habe in meinem nginx error log folgende Meldunge gehabt
“‘
26145#26145: ocsp.int-x3.letsencrypt.org could not be resolved (110: Operation timed out) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: „/etc/letsencrypt/domain.com/ecc/fullchain.pem“
“‘
Ich hab etwas gebraucht um dahinter zu kommen. Anscheinend hat bei mir das aktivierte OCSP Stapling mit deinem DNS resolver 192.168.178.1 zu Problemen geführt.
Ich habe nun den resolver auf 1.1.1.1 (cloudflare) geändert und nun klappt es.
Ich denke mein Hoster hat einfach eine andere IP Struktur und 192.168.178.1 führt nicht zum Auflösen der Domain. Vielleicht kannst du das erwähnen falls jemand anderes auch das Problem hat.
Hallo Frank,
die 192.168.178.1 wird hier nur beispielhaft aufgeführt. Dies muss einfach eine IP eines DNS-Servers sein. Die meisten Router im Heimbereich dienen im LAN auch als DNS-Server, daher gebe ich hier einfach die IP des Routers an.
Wenn du hier eine andere IP nutzt, oder dein Router kein DNS-Server ist, musst du hier eine andere IP angeben. Cloudflare ist eine Möglichkeit, auch wenn ich aus Sicht der Privatsphäre und Datenschutz eher einen „freien“ DNS-Server empfehlen würde, z.B. den DNS-Server von Digitalcourage.
Gruß,
Jan
Hi Jan,
Ein sehr gute Beschreibung.
ich bin noch Anfänger auf den Server Gebiet und komme immer besser in der Materie zurecht.
Da ich paar Probleme habe bin ich auf deine Anleitung gestoßen.
Nur das ich bei der Erstellung Zertifikaten habe bekomme die Meldung:
meinedomäne.de:Verify error:Invalid response from https://meinedomäne.de/.well-known/acme-challenge/Chj2_wBLLqNvm9w_M5s44RfDWIMYIvwjIXOG1sdBIQc
Hallo Patrick,
dann sieht es so aus, als ob die Domain nicht richtig konfiguriert wurde (tippe da mal auf DynDNS/Router-Einstellung). Wenn er die Domain an sich erreichen könnte, dann sollte eine andere Fehlermeldung kommen.
Am besten mal acme.sh mit dem Parameter „–debug“ aufrufen, vielleicht kommt hier eine aussagekräftigere Fehlermeldung.
Gruß,
Jan
Hallo Jan, ich bin auf deine Antwort für Patrik gesoßen und bekomme die gleiche Fehlermeldung. Ich bin ebenfalls Server-Neuling.
Mein System:
Ubuntu Server 20…LTS auf Rasberry Pi 4 8GB
Ich nutze php-Skrpt auf meinen Webspace um mir meine Dyndns-Adresse zu besorgen. Das klappt auch wunderbar.
Ich habe auch schon 2 vhosts angelegt und kann beide über http ansteuern. die erste über port 80, die zweite über einen anderen port (xxxx).
beide index.html dateien werden angezeigt.
Den Server steuer ich also über die Externe-IP meines Routers an.
Hast du irgendeinen Tipp was man dabei beachten muss? Also bezüglich der Zertifikaterstellen bei meinen Voraussetzungen?
Grüße
Hi,
kannst du mal diesen Tipp ausführen? Das zielt dann genau auf das Verzeichnis ab, in dem auch Let’s Encrypt nach der Verifikation sucht.
Gruß,
Jan
Hallo Jan,
bei mir läuft seit gestern etwas mit dem cron nicht mehr. Ich habe nach deinen Anleitungen Onlyoffice und Hybrid-Zertifikate erstellt und auch acme nicht mehr als root ausführen lassen – dachte ich zumindest. Jetzt bekam ich diese Mail:
Cron „/root/.acme.sh“/acme.sh –cron –home „/root/.acme.sh“ > /dev/null
[Sa 28. Sep 00:53:02 CEST 2019] Error, can not get domain token entry meinedomain.de
[Sa 28. Sep 00:53:02 CEST 2019] Please add ‚–debug‘ or ‚–log‘ to check more details.
[Sa 28. Sep 00:53:02 CEST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
[Sa 28. Sep 00:53:02 CEST 2019] Error renew meinedomain.de.
[Sa 28. Sep 00:54:08 CEST 2019] Error, can not get domain token entry meinedomain.de
[Sa 28. Sep 00:54:08 CEST 2019] Please add ‚–debug‘ or ‚–log‘ to check more details.
[Sa 28. Sep 00:54:08 CEST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
[Sa 28. Sep 00:54:08 CEST 2019] Error renew meinedomain.de_ecc.
[Sa 28. Sep 00:55:09 CEST 2019] Error, can not get domain token entry office.meinedomain.de
[Sa 28. Sep 00:55:09 CEST 2019] Please add ‚–debug‘ or ‚–log‘ to check more details.
[Sa 28. Sep 00:55:09 CEST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
[Sa 28. Sep 00:55:09 CEST 2019] Error renew office.meinedomain.de.
[Sa 28. Sep 00:56:12 CEST 2019] Error, can not get domain token entry office.meinedomain.de
[Sa 28. Sep 00:56:12 CEST 2019] Please add ‚–debug‘ or ‚–log‘ to check more details.
[Sa 28. Sep 00:56:12 CEST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
[Sa 28. Sep 00:56:12 CEST 2019] Error renew office.meinedomain.de_ecc.
Das aktuellen Zertifikate sind noch eine Weile gültig, aber offensichtlich verlängert er sie ja nicht mehr. Mit den github-Infos konnte ich nicht viel anfangen, die versuchte Neuinstallation von acme.sh hat nicht geholfen. Hast du eine Idee?
Liebe Grüße
Friedrich
Hallo Friedrich,
führ doch bitte mal die Befehle zum Erzeugen der Zertifikate nochmals auf der Kommandozeile aus (hier brauchst du dann zusätzlich vermutlich den Parameter „–force“). Hier solltest du dann eine detailliertere Beschreibung finden, was beim Erzeugen/Erneuern der Zertifikate nicht funktioniert.
Gruß,
Jan
Hallo Jan,
das ist das Merkwürdige: Die manuelle Erzeugung der Zertifikate (als User letsencrypt) funktioniert problemlos. Kann es sein, dass der cronjob noch durch den root-user ausgeführt wird?
Liebe Grüße
Hi,
kontrollier mal, ob bei „crontab -e“ (als Root-User ausgeführt) der Cronjob noch drin hängt. Dann ist acme.sh vermutlich auch noch unter dem Root-User „installiert“. Dann einfach „acme.sh –uninstall“ (als Root!).
„sudo -u letsencrypt crontab -e“ sollte dann den Cronjob für für acme.sh unter dem User letsencrypt anzeigen.
Gruß,
Jan
Ha, du hattest Recht, der stand noch mit drin. Ich erinnere mich auch, dass ich bei der Umstellung vor einem Monat oder so eine Fehlermeldung beim Deinstallieren hatte. Letzte Nacht habe ich die gleiche Mail wieder erhalten, ich denke aber, dass das Problem jetzt gelöst hat und ich keine Nachrichten mehr bekomme.
Nach der Deinstallation wurde ich noch darauf hingewiesen, dass man die Keys noch manuell löschen könnte. Kann ich das machen, oder sind das die gleichen, die jetzt vom user letsencrypt genutzt werden?
Vielen Dank für die Hilfe und herzliche Grüße
Friedrich
Hi,
also dann war das eine Mail, die von dem „doppelt installierten“ acme.sh kam.
Löschen kannst du nun alles, was im Home-Verzeichnis des Users liegt, unter dem acme.sh zuvor ausgeführt wird (und jetzt nicht mehr).
Gruß,
Jan
Moin Jan,
ich hatte denselben Fehler gemacht wie Friedrich. acme.sh lief noch unter root. Dort habe ich ihn jetzt deinstalliert und beim user letsencrypt installiert. Das hat alles geklappt. wenn ich acme.sh –list zeigt er mir aber nicht das bereits bestehende Zertifikat, das jetzt abgelaufen ist. Wie kann ich das bekannt machen?
Herzliche Grüße
Hi Michael,
führe einfach nochmal die Befehle zur Zertifikats-Generierung aus und anschließend nochmal den List-Befehl (beides unter dem User letsencrypt). Dann sollten die Zertifikate eigentlich angezeigt werden. Wenn der List-Befehl keine Ergebnisse liefert, wird auch die automatische Erneuerung nicht funktionieren.
Gruß,
Jan
Hallo Jan,
wir hatten schon in deinem vorherigen Chat zum Thema Let’s Encrypt geschrieben. Es hat alles nicht funktioniert, weswegen ich mich entschieden habe certbot zu deinstallieren und acme.sh nochmal komplett neu zu installieren. Eine gänzlich schlechte Idee von mir!
Ich habe versucht die Zertifikate von grund auf zu erneuern:
Beim Befehl die Zertifikate über den User letsencrypt (letsencrypt@mail:/root$) zu installieren (acme.sh …) kommt jedoch eine Fehlermeldung, dass ich in die Log-Datei von acme zu schauen habe.
Mein acme.sh.log: https://drive.google.com/open?id=1GHO8EXJva53OeIlZ29Hqhd-9wBAU88C_ (Google-Drive-Link, Nextcloud funktoniert nicht mehr -sry)
Wenn ich die Zertifikate mit acme.sh –list anzeigen lasse, werden diese auch angezeigt:
Main_Domain: smuehl.de KeyLength:“4096″ SAN_Domains: mail.ddns.smuehl.de,mail.smuehl.de,www.smuehl.de Created:- Renew:-
Die Zertifikate in /etc/letsencrypt/meinedomain.de sind weg, weswegen meine Seite nicht mehr funktioniert. Auch der Test über ssllabs.com verrät nichts gutes (fehlende Zertifikate und mismatch)
In der Log-Datei gibt das System dem User Letsencrypt nicht die nötigen Berechtigungen bei „chown“, was mich auf das Problem von Ben weiter oben gebracht hat. Kann die Verweigerung der Zertifikatserstellung doch an den fehlenden Rechten liegen? Mit „sudo“ funktioniert der Befehl via letsencrypt@mail:/root$ nicht.
Wie könnte ich das denn lösen, dass meine Zertifikate neu erstellt werden? Tausend Dank für eine Rettung meiner Webpage.
Hi Sascha,
wegen den Berechtigungen: Hast du den User letsencrypt in die Grupper www-data aufgenommen und auf alle entsprechenden Verzeichnisse ein „chmod -R 775 …“ gemacht?
Das Log sagt des weiteren noch „connection refused“. Wenn das kein Folgefehler sein sollte, dann mal einen Blick ins nginx Log werfen.
Wichtig: Nun nicht einfach zig mal die Ausstellung der Zertifikate über acme.sh anstoßen – da wirst du irgendwann für ein paar Tage geblockt.
Leg mal im entsprechenden Verzeichnis (/var/www/letsencrypt/.well-known/acme-challenge/) einfach eine Text-Datei an (z.B. test.txt – Inhalt beliebig). Dann rufst du mal http://domain.de/.well-known/acme-challenge/test.txt im Browser auf (HTTP, nicht HTTPS). Hier sollte die Datei dann angezeigt werden. Falls nicht, dann schau mal das error.log von nginx. Hier sollte dann stehen, wo er nach dieser Datei sucht. Dies sollte einen Hinweis darauf geben, was bei dir nicht funktioniert.
Erst wenn dieser Zugriff per Browser klappt, kannst du wieder acme.sh zum Generieren der Zertifikate verwenden.
Gruß,
Jan
Hallo Jan,
vielen Dank für deine Antwort. Genau das war der Fehler. Hatte ich dann in einem anderen Forum von dir gefunden.
1. Nutzer letsencrypt Gruppe www-data hinzugefügt:
„usermod -a -G www-data letsencrypt“
2. Verzeichnisstruktur angepasst
3. RSA-Zertifikate und ECDSA-Zertifikate erstellt.
Es funktioniert alles wunderbar
Hallo Jan, vielen Dank für diesen tollen Beitrag. Leider muss ich Dich doch noch mal belästigen. Bei der Einrichtung hat soweit alles geklappt. Ich bin genau diesen Anweisungen gefolgt. Nun ist mein Zertifikat für meine Domain abgelaufen. Der Befehl: acme.sh –renew -d mschmoll.goip.de –force –debug quittiert folgenden Fehler:
[Mo 31. Jan 17:41:25 CET 2022] uri=’https://acme-v02.api.letsencrypt.org/acme/chall-v3/73835649800/wa44Xw‘
[Mo 31. Jan 17:41:25 CET 2022] _currentRoot=’/var/www/letsencrypt‘
[Mo 31. Jan 17:41:25 CET 2022] wellknown_path=’/var/www/letsencrypt/.well-known/acme-challenge‘
[Mo 31. Jan 17:41:25 CET 2022] writing token:Iq7e97zJR2FXq6NvUWam7i2CynnmdpfFlibVWEWqdXQ to /var/www/letsencrypt/.well-known/acme-challenge/Iq7e97zJR2FXq6NvUWam7i2CynnmdpfFlibVWEWqdXQ
[Mo 31. Jan 17:41:25 CET 2022] Changing owner/group of .well-known to www-data:www-data
[Mo 31. Jan 17:41:25 CET 2022] chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/c2_QJn9qCLex6ovQrr6NGdNxS8pSbk-hHSg8tUPPc2I‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/vpPI_9KAcVki8i8xs2JR8jYr40eQR0xdccoBn92LTIM‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/-oiqwx7ImMGkrmxhr9CEJq8tAFT5a1V-R02vS0WguGs‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/Iq7e97zJR2FXq6NvUWam7i2CynnmdpfFlibVWEWqdXQ‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/text.txt‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/U809Vl3f2V2K5IOwW5a1dcj-Clm93zg9qnjo5-IXwZk‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/test.txt‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/prnFzD3Djed-dUbNW1DJpi6jQ2eNobRVJtqTYppcJf0‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge/test33.txt‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known/acme-challenge‘ wird geändert: Vorgang nicht zulässig
chown: der Eigentümer von ‚/var/www/letsencrypt/.well-known‘ wird geändert: Vorgang nicht zulässig
[Mo 31. Jan 17:41:25 CET 2022] url=’https://acme-v02.api.letsencrypt.org/acme/chall-v3/73835649800/wa44Xw‘
[Mo 31. Jan 17:41:25 CET 2022] payload='{}‘
[Mo 31. Jan 17:41:25 CET 2022] POST
[Mo 31. Jan 17:41:25 CET 2022] _post_url=’https://acme-v02.api.letsencrypt.org/acme/chall-v3/73835649800/wa44Xw‘
[Mo 31. Jan 17:41:25 CET 2022] _CURL=’curl –silent –dump-header /home/letsencrypt/.acme.sh/http.header -L -g ‚
[Mo 31. Jan 17:41:25 CET 2022] _ret=’0′
[Mo 31. Jan 17:41:25 CET 2022] code=’200′
[Mo 31. Jan 17:41:25 CET 2022] trigger validation code: 200
[Mo 31. Jan 17:41:25 CET 2022] Pending, The CA is processing your order, please just wait. (1/30)
[Mo 31. Jan 17:41:25 CET 2022] sleep 2 secs to verify again
[Mo 31. Jan 17:41:27 CET 2022] checking
[Mo 31. Jan 17:41:27 CET 2022] url=’https://acme-v02.api.letsencrypt.org/acme/chall-v3/73835649800/wa44Xw‘
[Mo 31. Jan 17:41:27 CET 2022] payload
[Mo 31. Jan 17:41:27 CET 2022] POST
[Mo 31. Jan 17:41:27 CET 2022] _post_url=’https://acme-v02.api.letsencrypt.org/acme/chall-v3/73835649800/wa44Xw‘
[Mo 31. Jan 17:41:27 CET 2022] _CURL=’curl –silent –dump-header /home/letsencrypt/.acme.sh/http.header -L -g ‚
[Mo 31. Jan 17:41:28 CET 2022] _ret=’0′
[Mo 31. Jan 17:41:28 CET 2022] code=’200‘
[Mo 31. Jan 17:41:28 CET 2022] mschmoll.goip.de:Verify error:Invalid response from http://mschmoll.goip.de/.well-known/acme-challenge/Iq7e97zJR2FXq6N…. [149.233.137.25]:
[Mo 31. Jan 17:41:28 CET 2022] Debug: get token url.
[Mo 31. Jan 17:41:28 CET 2022] GET
[Mo 31. Jan 17:41:28 CET 2022] url=’http://mschmoll.goip.de/.well-known/acme-challenge/Iq7e97zJR2FXq6…‘
[Mo 31. Jan 17:41:28 CET 2022] timeout=1
[Mo 31. Jan 17:41:28 CET 2022] _CURL=’curl –silent –dump-header /home/letsencrypt/.acme.sh/http.header -L -g –connect-timeout 1′
403 Forbidden
403 Forbidden
nginx
[Mo 31. Jan 17:41:28 CET 2022] ret=’0′
[Mo 31. Jan 17:41:28 CET 2022] Debugging, skip removing: /var/www/letsencrypt/.well-known/acme-challenge/Iq7e97zJR2FXq6NvUWam7i2CynnmdpfFlibVWEWqdXQ
[Mo 31. Jan 17:41:28 CET 2022] pid
[Mo 31. Jan 17:41:28 CET 2022] No need to restore nginx, skip.
[Mo 31. Jan 17:41:28 CET 2022] _clearupdns
[Mo 31. Jan 17:41:28 CET 2022] dns_entries
[Mo 31. Jan 17:41:28 CET 2022] skip dns.
[Mo 31. Jan 17:41:28 CET 2022] _on_issue_err
[Mo 31. Jan 17:41:28 CET 2022] Please add ‚–debug‘ or ‚–log‘ to check more details.
[Mo 31. Jan 17:41:28 CET 2022] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
[Mo 31. Jan 17:41:28 CET 2022] url=’https://acme-v02.api.letsencrypt.org/acme/chall-v3/73835649800/wa44Xw‘
[Mo 31. Jan 17:41:28 CET 2022] payload='{}‘
[Mo 31. Jan 17:41:28 CET 2022] POST
[Mo 31. Jan 17:41:28 CET 2022] _post_url=’https://acme-v02.api.letsencrypt.org/acme/chall-v3/73835649800/wa44Xw‘
[Mo 31. Jan 17:41:28 CET 2022] _CURL=’curl –silent –dump-header /home/letsencrypt/.acme.sh/http.header -L -g ‚
[Mo 31. Jan 17:41:29 CET 2022] _ret=’0′
[Mo 31. Jan 17:41:29 CET 2022] code=’400‘
[Mo 31. Jan 17:41:29 CET 2022] Diagnosis versions:
openssl:openssl
OpenSSL 1.1.1f 31 Mar 2020
apache:
apache doesn’t exist.
nginx:
nginx version: nginx/1.21.6
built by gcc 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
Der Letsencrypt-Nutzer hat Lese-/Schreibrechte in .well-known/acme-challenge. Ein Testdateiaufruf über http://… wird mit Error404 quittiert; ich denke weil das Zertifikat abgelaufen ist. An was denke ich gerade nicht? Wo ist mein Denkfehler? Liegt es daran, dass der Zertifikataussteller nicht an den Token kommt? Muss ich dann ganz neue Zertifikate ausstellen und an die richtigen Stellen kopieren?
Ich würde das gerne verstehen.
Danke im Voraus für deine Mühe!
Besten Gruß Magnus
Hi Magnus,
ja, Let’s Encrypt kann den Token nicht lesen, daher schlägt die Generierung fehlt. Das mit der Testdatei (siehe hier) kennst du ja bereits. Das muss vor der Generierung funktionieren. Wenn nicht, dann analysiere mal die Webserver-Logs, hier ist zu entnehmen, wo er hier nach Dateien sucht. Letzten Endes ist es dann vermutlich ein Problem mit dem vHost, der die Well-Known-URL für LE behandeln soll.
Bitte erst mit der Test-Datei ausprobieren und nicht immer wieder versuchen, ein Zertifikat zu generieren, denn du stößt hier schnell ans Rate-Limit und dann ist die Domain bei LE erst einmal für ein paar Tage gesperrt.
Gruß,
Jan