Lets encrypt Zertifikat erneuert sich nicht

[tim11]

Hallo,

ich habe meinen Nextcloud Server Anfang des Jahres neu aufgesetzt, inklusive Lets encrypt Zertifikaten mittels ACME.

Ging soweit ganz gut, nur hat die automatische Zertifikatsverlängerung nach 90 Tagen nicht geklappt. Im Netz gibt es unzählige Beiträge zu nicht verlängerten Zertifikaten, nur sind diese auf ein bestimmtes System beschränkt. Mein Server läuft daheim auf einem NUC unter Debian 11.

Laut dem Tutorial wurde von zur Verlängerung ein cronjob für mittels crontab -l -u acmeuser eingerichtet hier

53 0 * * * "/home/acmeuser/.acme.sh"/acme.sh --cron --home "/home/acmeuser/.acme.sh" > /dev/null

, aber scheint ja wohl nicht funktioniert zu haben.

Wie kann ich die Verlängerung manuell wieder anstoßen?

Danke im voraus

[heisenberg]

Dann führe das Script doch mal ohne Ausgabeumlenkung unter dem entsprechenden Benutzer auf der Shell aus und schaue Dir dessen Ausgabe genauer an.

[tim11]

Danke für Deine schnelle Hilfe.

Führe ich das Skript aus, möchte es nähere Parameter haben:

acmeuser@***:~/.acme.sh$ ./acme.sh
https://github.com/acmesh-official/acme.sh
v3.0.2
Usage: acme.sh <command> ... [parameters ...]
Commands:
-h, --help Show this help message.
-v, --version Show version info.
--install Install acme.sh to your system.

[heisenberg]

Ich meinte natürlich so ausführen wie auch im 1. Beitrag geschrieben - aber ohne die Ausgabeumlenkung.

[tim11]

Dann erhalte ich das Größerzeichen als Prompt. Meine Bashscripting Zeiten sind viele viele Jahre her, bin inzwischen froh wenn ich noch unfallfrei den Rechner einschalten kann

Früher hätte ich alles nochmal neu aufgesetzt, learning by doing, aber sobald man Kinder hat, ist Zeit leider ein kostbares Gut

[bluestar]

So einen ähnlichen Fehler hatte ich auch.

Checke mal in /root/.acme.sh/DOAMIN/DOMAIN.csr.conf und darin folgende muss Le_API='https://acme-v02.api.letsencrypt.org/directory' gesetzt sein, ansonsten fällt acme.sh auf ZeroSSL zurück und dann klappt Lets Encrypt nicht mehr.

[weshalb]

Muss man das denn über Acme machen?

[heisenberg]

Muss man das denn über Acme machen?

Grundsätzlich gibt's da certbot als Debian-Paket. In meinem Netzwerk benutze ich an zentraler Stelle dehydrated, um im Zusammenhang mit der der Validierung via DNS meine Zertifikate zu registrieren.

Was an acme.sh gut ist, dass habe ich selbst noch nicht nachgelesen.

Steht hier:
https://github.com/acmesh-official/acme.sh

Ansonsten bin ich bei Dann erhalte ich das Größerzeichen als Prompt hier aus dem Thread ausgestiegen, wegen zu geringen Erfolgssaussichten für eine Lösung aus diversen Gründen.

[oln]

Moin,

Danke für Deine schnelle Hilfe.

Führe ich das Skript aus, möchte es nähere Parameter haben:

acmeuser@***:~/.acme.sh$ ./acme.sh
https://github.com/acmesh-official/acme.sh
v3.0.2
Usage: acme.sh <command> ... [parameters ...]
Commands:
-h, --help Show this help message.
-v, --version Show version info.
--install Install acme.sh to your system.

ich denke , dass deine Konfiguration weg ist.
Im home von dem acme-User gibt es ein .acme.sh-Ordner. Dort sollte die Konfiguration zu finden sein. Je nach Challange welche du benutzt, solle auch etwas unter /etc/letsencrypt/ zu finden sein.
Wo liegen deine Zertifikate?
Ansonsten sollte folgender Befehl dein Zertifikat erneuern:

Code: Alles auswählen

acme.sh --renew -d example.com

[weshalb]

Muss man das denn über Acme machen?

Grundsätzlich gibt's da certbot als Debian-Paket.

Ist das nicht jetzt nur noch über eine "cerbot- classic" Installation über Snapd realisierbar?

So mache ich das, seit die Erneuerungen nicht mehr funktioniert hatten. Aber eigentlich auch ganz easy.

[tim11]

Nach einem Offline-Familienurlaub kann ich mich jetzt wieder um die Onlineprobleme kümmern

An dieser Stelle schon mal danke für die tolle Hilfe. Ich werde mich heute Abend mal auf den Server schalten und Eure Beiträge durchgehen.

[tim11]

So, erste Ergebnisse: beim Versuch mittels

acme.sh --renew --log -d ****.***.de

das Zertifikat manuell zu erneuern, erhalte ich im Log:

[Di 14. Jun 18:42:02 CEST 2022] _post_url='https://acme-v02.api.letsencrypt.org/ac ... 536/8pvmYg'
[Di 14. Jun 18:42:02 CEST 2022] _CURL='curl --silent --dump-header /home/acmeuser/.acme.sh/http.header -L '
[Di 14. Jun 18:42:03 CEST 2022] _ret='0'
[Di 14. Jun 18:42:03 CEST 2022] _hcode='0'
[Di 14. Jun 18:42:03 CEST 2022] code='200'
[Di 14. Jun 18:42:03 CEST 2022] ***.***.de:Verify error:37.49.5.221: Fetching http://***.***.de/.well-known/acme-challenge/RQQT1fmobHEiNbMS3ru04JeIzQJl_********as6Js9qI: Error getting validation data
[Di 14. Jun 18:42:03 CEST 2022] pid
[Di 14. Jun 18:42:03 CEST 2022] No need to restore nginx, skip.
[Di 14. Jun 18:42:03 CEST 2022] _clearupdns
[Di 14. Jun 18:42:03 CEST 2022] dns_entries
[Di 14. Jun 18:42:03 CEST 2022] skip dns.
[Di 14. Jun 18:42:03 CEST 2022] _on_issue_err
[Di 14. Jun 18:42:03 CEST 2022] Please check log file for more details: /home/acmeuser/.acme.sh/acme.sh.log

Meine Zertifikate liegen unter /etc/letsencrypt/

hecke mal in /root/.acme.sh/DOAMIN/DOMAIN.csr.conf und darin folgende muss Le_API='https://acme-v02.api.letsencrypt.org/directory' gesetzt sein, ansonsten fällt acme.sh auf ZeroSSL zurück und dann klappt Lets Encrypt nicht mehr.

Habe ich eingefügt, aber das manuelle Erneuern klappt eben nicht.

Wenn alle Stricke reissen, kann ich dann einfach certbot nachinstallieren, oder kollidiert es dann mit einer bestehenden Config?

[heisenberg]

Code: Alles auswählen

[Di 14. Jun 18:42:03 CEST 2022] ***.***.de:Verify error:37.49.5.221: Fetching
  http://***.***.de/.well-known/acme-challenge/RQQT1fmobHEiNbMS3ru04JeIzQJl_********as6Js9qI: 
  Error getting validation data

Das bedeutet, dass die Challenge http://***.***.de/.well-known/acme-challenge/RQQT1fmobHEiNbMS3ru04JeIzQJl_********as6Js9qI nicht von aussen abgerufen werden kann.

Da ist vermutlich Deine Webserver-Konfiguration nicht korrekt. D. h. die Anfragen für /.well-known/acme-challenge/... werden nicht im richtigen Verzeichnis landen oder gar ganz anders beantwortet.

Zum testen kannst Du dort, wo für diesen VHost /.well-known/acme-challenge bei Dir im Dateisystem liegt mal eine Datei namens test.txt mit ein paar Worten Inhhalt zur Wiedererkennung ablegen.

Wenn Du Deine Konfiguration korrigiert hast und Du diese test.txt - z. B. via wget oder Browser - über die URL http://***.***.de/.well-known/acme-challenge/test.txt heruntergeladen bekommst, dann wäre dieser Fehler gelöst und Du kannst eine Zertifikatsverlängerung mal erneut versuchen. Ansonsten hilft es bestimmt, zu sehen, was Du bei Aufruf der URL ausgegeben wird.

[tim11]

Fehlgeschlagen, keine Route zum Zielrechner. Eingeloggt über Hotspot vom Smartphone. Die IPv4 wird aber korrekt angewählt. Im Netzwerk mit der internen IP geht es.

***@debian:~$ wget http://***.***.de/.well-known/acme-challenge/test.txt
--2022-06-16 11:58:20-- http://***.***.de/.well-known/acme-challenge/test.txt
Auflösen des Hostnamens ***.***.de (***.***.de)… 192.168.***.***
Verbindungsaufbau zu ***.***.de (***.***.de)|192.168.***.***|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 4 [text/plain]
Wird in »test.txt« gespeichert.

test.txt 100%[=====================================================================================================================>] 4 --.-KB/s in 0s

2022-06-16 11:58:20 (497 KB/s) - »test.txt« gespeichert [4/4]

[bluestar]

Fehlgeschlagen, keine Route zum Zielrechner. Eingeloggt über Hotspot vom Smartphone. Die IPv4 wird aber korrekt angewählt.

Dann ist deine Netzwerkkonfiguration fehlerhaft

Im Netzwerk mit der internen IP geht es.
***@debian:~$ wget http://***.***.de/.well-known/acme-challenge/test.txt
--2022-06-16 11:58:20-- http://***.***.de/.well-known/acme-challenge/test.txt
Auflösen des Hostnamens ***.***.de (***.***.de)… 192.168.***.***
Verbindungsaufbau zu ***.***.de (***.***.de)|192.168.***.***|:80 … verbunden.

Spannend du hast deine Domain intern verbogen, dass sie auf eine private IP-Adresse zeigt.

[heisenberg]

Fehlgeschlagen, keine Route zum Zielrechner. Eingeloggt über Hotspot vom Smartphone

Smartphones bekommen afaik keine öffentliche IPv4. Da ist dann NAT im Spiel. Da müsste man mehr rumbasteln um so etwas zum Laufen zu bringen. Das kann so noch nicht funktioniert haben. Hast Du auch noch einen anderen Internetanschluß?

[bluestar]

Fehlgeschlagen, keine Route zum Zielrechner. Eingeloggt über Hotspot vom Smartphone

Smartphones bekommen afaik keine öffentliche IPv4. Da ist dann NAT im Spiel. Da müsste man mehr rumbasteln um so etwas zum Laufen zu bringen. Das kann so noch nicht funktioniert haben. Hast Du auch noch einen anderen Internetanschluß?

Seinen Anschluss sollte der TE ohne Probleme via Smartphone & Hotspot testen können.

Mir stellen sich folgende Fragen:
- Passt der DNS Record auf die aktuelle IP?
- Ist im Router für 80 und 443 ein Portforwarding eingerichtet?

[tim11]

Zu der Konfiguration allgemein: die Zertifikate haben ja die 90 Tage problemlos funktioniert und auch jetzt komme ich noch über 443 auf die Seite, allerdings mit der bekannten Meldung bzgl. unsicheren Verbindung und Aufforderung zur Einrichtung einer Sicherheitsausnahme.

[bluestar]

auch jetzt komme ich noch über 443 auf die Seite, allerdings mit der bekannten Meldung bzgl. unsicheren Verbindung und Aufforderung zur Einrichtung einer Sicherheitsausnahme.

Von intern oder von extern?

[tim11]

auch jetzt komme ich noch über 443 auf die Seite, allerdings mit der bekannten Meldung bzgl. unsicheren Verbindung und Aufforderung zur Einrichtung einer Sicherheitsausnahme.

Von intern oder von extern?

Sowohl als auch, habe es eben über besagten Hotspot am Smartphone getestet. Sicherheitsmeldung kommt, Ausnahme hinzufügen und schon bin ich auf meiner Seite

[bluestar]

Sowohl als auch, habe es eben über besagten Hotspot am Smartphone getestet. Sicherheitsmeldung kommt, Ausnahme hinzufügen und schon bin ich auf meiner Seite

Kannst du von extern und intern auch über HTTP darauf zugreifen?

[tim11]

Du bist auf der richtigen Spur, ich werde automatisch auf https umgeleitet, habe es eben nur intern versucht, aber dann wird es extern analog sein. Ich kann mich erinnern, dass ich damals https erzwungen habe, da im Normalfall keine Fremden auf die Seite zugreifen, daher ausschließlich secure, aber dass das Probleme mit Sachen wie Zertifikaten mit sich bringen kann, habe ich natürlich nicht bedacht

[tim11]

Jetzt die spannende Frage: wie stellt man die Erneuerung der Zertifikate so um, dass sie auch unter 443 laufen?

[bluestar]

Jetzt die spannende Frage: wie stellt man die Erneuerung der Zertifikate so um, dass sie auch unter 443 laufen?

Gar nicht, dein Server muss für die ersten Request über HTTP für LE erreichbar sein.

https://letsencrypt.org/de/docs/challenge-types/

[tim11]

Somit ein Mal im Quartal umstellen, das Zertifikat manuell anstoßen und dann wieder zurück auf Secure? Naja, gibt schlimmeres, zumindest weiß ich jetzt woran es liegt.

Oder gibt es sonst noch einen anderen Weg, um es über Umwege zu schaffen?

Ich bedanke mich schon mal in verschärfter Form für die fantastische und zahlreiche Hilfe bei allen Helfern