Let's Encrypt Fehler nach Systemupgrade

Begonnen von timtom, 29 November 2018, 10:36:16

Vorheriges Thema - Nächstes Thema

timtom

Hallo zusammen,

ich habe vor kurzem ein dist-upgrade gemacht. Und seit dem ist der Wurm drin. Ich nutze Let's Encrypt als Zertifikat, das ich täglich per crontab überprüfte. Seit dem Upgrade kommt folgender Fehler. Da ich kein Linux-Fachmann bin, würde ich mich freuen, wenn mir jemand helfen kann.

Requesting to rerun /opt/letsencrypt/letsencrypt-auto with root privileges...
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/dyndns.meineurl.de.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for dyndns.meineurl.de
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (dyndns.meineurl.de) from /etc/letsencrypt/renewal/dyndns.meineurl.de.conf produced an unexpected error: Failed authorization procedure. dyndns.meineurl.de (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://dyndns.meineurl.de/.well-known/acme-challenge/IWRQgBLb8Q3BoudwgAAAAAAAAAAAAAAAAAAAAA-AAAA: Connection refused. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/dyndns.meineurl.de/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/dyndns.meineurl.de/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
- The following errors were reported by the server:

   Domain: dyndns.meineurl.de
   Type:   connection
   Detail: Fetching
   http://dyndns.meineurl.de/.well-known/acme-challenge/IWRQgBLb8Q3BoudwgAAAAAAAAAAAAAAAAAAAAA-AAAA:
   Connection refused

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.


CoolTux

Er versucht http://dyndns.meineurl.de auf zu rufen. Anscheinend klappt das nicht. Ich gehe davon aus das dyndns.meineurl.de Dein Server zu Hause sein soll.
Also bitte einmal schauen ob nslookup dyndns.meineurl.de von genau dem Sevrer wo letsencrypt das Update machen will Deine externe IP aus spuckt.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

timtom

Danke schon mal für deine Hilfe:
pi@raspberrypi:~ $ nslookup dyndns.meineurl.de
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   dyndns.meineurl.de
Address: 84.xxx.xxx.xxx


Das ist identisch mit der IP von https://www.wieistmeineip.de/

CoolTux

gut das geht schon mal. Nun versucht er eine Datei zu lesen, und zwar über http

Schau mal bitte ob Du diese URL aufrufen kannst
http://dyndns.meineurl.de/.well-known/acme-challenge/IWRQgBLb8Q3BoudwgAAAAAAAAAAAAAAAAAAAAA-AAAA:

Im übrigen sollte bei diesem Aufruf der nginx schon noch laufen, sonst geht das nicht.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

timtom

#4
nginx fäuft als reverse-Proxy: https://192.168.1.202/fhem/ <-- kann aufgerufen werden

Zitat von: CoolTux am 29 November 2018, 11:40:53
[...]
Schau mal bitte ob Du diese URL aufrufen kannst
http://dyndns.meineurl.de/.well-known/acme-challenge/IWRQgBLb8Q3BoudwgAAAAAAAAAAAAAAAAAAAAA-AAAA:
Ich habe die URL auf dem PC im gleichen Netzwerk und nicht RPi aufgerufen. Dann passiert folgendes:
Forbidden
Rejected request from RFC1918 IP to public server address


Rufe ich die Seite aus dem Internet auf, passiert folgendes:
Connection refused
Description: Connection refused


UPDATE:
https://dyndns.meineurl.de/.well-known/acme-challenge/IWRQgBLb8Q3BoudwgAAAAAAAAAAAAAAAAAAAAA-AAAA:
404 Not Found
nginx/1.10.3

vbs

Du kannst letsencrypt auch so einstellen, dass es seinen eigenen Webserver startet. Der Vorteil ist, dass der einfach funktioniert (hoffentlich) und man nicht den eigenen entsprechend umkonfigurieren muss. Der Haken ist jedoch, dass der eigene Webserver dann in dem Moment nicht laufen darf. Ist aber vlt. verschmerzbar, wenn der mal nachts für ein paar Sekunden nicht erreichbar ist.

Man kann das über Hooks konfigurieren, dass der eigene Webserver automatisch gestoppt wird und später wieder gestartet wird. Ich hab das bei mir so konfiguriert in der renewal-Config:
# renew_before_expiry = 30 days
version = 0.23.0
...

# Options used in the renewal process
[renewalparams]
installer = None
account = ...
authenticator = standalone
post_hook = service nginx start
pre_hook = service nginx stop

timtom

Hmm das verstehe ich leider nicht ganz. Ich hatte mich an folgender Anleitung orientiert und an meine Umgebung angepasst.
https://haus-automatisierung.com/hardware/fhem/2016/12/30/fhem-tutorial-reihe-part-21-zugriff-auf-fhem-ueber-das-internet.html

Da ich nginx als Reverse-Proxy für FHEM nutze, habe ich dann einen Cronjob wie folgt angelegt:
0 3 * * * sudo service nginx stop && /opt/letsencrypt/letsencrypt-auto renew && sudo service nginx start

Bis zum dist-upgrade hatte das auch tadellos funktioniert.

vbs

Ich glaube, dass ist dann noch ein älterer Stand bei dir. Mittlerweile soll man wohl "certbot" aufrufen. Zum Beispiel so:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

Die möchten wohl gerne, dass nicht alle User zum exakten selben Zeitpunk auf deren Server zugreifen und daher das sleep-rand.

Übrigens falls du deinen eigenen nginx benutzen möchtest, kann der cron-job so bei dir nicht klappen, da ja explizit dein nginx vor dem letsencrypt-Lauf gestoppt wird. Benutzt du wirklich deinen eigenen nginx für letsencrypt?

timtom

Also, wie gesagt, bin ich kein Linux-Experte und habe mir mit o.g. Anleitung beholfen.

1) Grundsätzlich hatte ich nginx aus dem fhem Wiki als Reverse-Proxy zur Absicherung von fhem eingerichtet.
2) Etwas später hatte ich von Let's Encrypt gehört und nutzt jetzt Verschiedene Zertifikate.
3) Darauf hin hatte ich meine nginx Config so angepasst, dass die Lets' Encrypt Zertifikate genutzt werden.
4) Damit sich das Zertifikat automatisch erneuert, hatte ich nach o.g. Anleitung das Skript für Renew angelegt.
5) Das hat bis vor kurzem auch alles geklappt, jetzt kommt aber o.g. Fehler.

bartman121

kann es sein, dass du mit der Umstellung auf Let's Encrypt auch die Portfreischaltung für Port 80 abgeschaltet hast?

Beim erneuern der des Zertifikates wird ein http-Aufruf (Port 80) von außen versucht, bei Dir geht dieser Aufruf nicht.

BTW: warum prüfst du die Gültigkeit des Zertifikates denn täglich? Man kann im Cronjob auch andere Intervalle definieren.

Grüße

timtom

Zitat von: bartman121 am 29 November 2018, 15:01:16
kann es sein, dass du mit der Umstellung auf Let's Encrypt auch die Portfreischaltung für Port 80 abgeschaltet hast?

Also bewusst habe ich nichts gemacht. Mittlerweile bin ich mir nicht mal sicher, ob vor dem dist-upgrade alles geklappt hat :(

bartman121

Wie wäre es denn Mal in der Fritzbox (oder deinem Router) nach der Portweiterleitung zu schauen?

Als du das Zertifikat erstellt hast muss es funktioniert haben. Da man danach alles über Port 443 erreichen kann, kommen manche auf die Idee Port 80 zu sperren.

timtom

Zitat von: bartman121 am 29 November 2018, 15:31:35
Wie wäre es denn Mal in der Fritzbox (oder deinem Router) nach der Portweiterleitung zu schauen?

Als du das Zertifikat erstellt hast muss es funktioniert haben. Da man danach alles über Port 443 erreichen kann, kommen manche auf die Idee Port 80 zu sperren.
Öhhh du bist mein Held. Anscheinend hatte ich das beim Router-Austausch wohl vergessen. Ich Depp. Nur ist mir noch nie der Fehler aufgefallen. Sorry für die dann doch extrem dumme Frage ;)

Wo ich gerade dabei bin, ist mein folgender Job noch ok? Ich hatte den mit "crontab -e" anglegt.
0 3 * * * sudo service nginx stop && /opt/letsencrypt/letsencrypt-auto renew && sudo service nginx start

bartman121

keine Ahnung ob der Cronjob richtig ist, ich nutze Certbot ....

aber sudo im crontab .... dir ist schon klar, dass man crontab -e auch mit sudo aufrufen kann und damit die Befehle dort drin ohnehin im sudo/root-Content laufen ....


Wernieman

Also .. certbot und "letsencrypt" ist auf den meisten Systemen das gleiche ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html