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.
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.
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/
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.
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 addressRufe ich die Seite aus dem Internet auf, passiert folgendes:
Connection refused
Description: Connection refusedUPDATE:
http
s://dyndns.meineurl.de/.well-known/acme-challenge/IWRQgBLb8Q3BoudwgAAAAAAAAAAAAAAAAAAAAA-AAAA:
404 Not Found
nginx/1.10.3
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
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.
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?
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.
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
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 :(
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.
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
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 ....
Also .. certbot und "letsencrypt" ist auf den meisten Systemen das gleiche ...
Ich habe wohl das selbe Problem. Kann ich irgendwie in Lets Encrypt einstellen, dass nicht auf Port 80 sondern auf Port 443 die Antwort kommt, so dass ich nur diesen freigeben muss?
NEIN
Edit:
Wenn Du darüber nachdenkst ist es logisch. Deren Dienst will nachgucken, ob der Server auch von Dir "kontrolliert" wird. 433 geht nicht, da Du dafür ein Zertifikat brauchst ... also ein "Henne/Ei-Problem".
Was mich immer wieder wundert ist der Gedanke, das Port 80 unsicher ist. NEIN es ist NICHT unsicher, nur abhörbar. Warum schaltest Du nicht einfach auf Port 80 einen reinen Statischen Webserver?? Wenn es unsicher ist, ist auch 433 unsicher. PUNKT.
ganz ruhig Wernieman :D und danke für die Erklärung. Das heißt ich muss den Port 80 freigeben. Mal schauen ob ich das vielleicht dann automatisch mit FHEM mache, wenn gebraucht. Dank dir.
Warum lässt Du nicht offen?
Siehe auch:
https://forum.fhem.de/index.php/topic,96461.0.html (https://forum.fhem.de/index.php/topic,96461.0.html)
Mich nervt schon, dass ich 443 offen habe für Alexa. Am liebsten hätte ich keinen Port offen. Aber einen Tod muss man wohl sterben.