Automatische Verlängerung von Let's Encrypt-Zertifikat

[chrisiwien]

Hallo d00p!

Vor ein paar Monaten habe ich meinen Server auf nginx umgestellt, nur klappt schon zum zweiten Mal die automatische Let's Encrypt-Verlängerung nicht (für den einzigen SSL-vhHost am Server).

Den Ordner /etc/apache2/ habe ich auf dem Server belassen.

Ich habe es mittlerweile hinbekommen dass ein neues Zertifikat für diesen SSL-vHost aktiv ist, aber ich frage mich ob ich in drei Monaten nicht wieder vor dem selben Problem stehe...

Folgende Schritte habe ich manuell unternommen (in der Reihenfolge):

1. php /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug - Kein Erfolg, in Froxlor wurde trotzdem das alte, ungültige Zertifikat angezeigt.
2. Das ungültige Zertifikat in Froxler gelöscht (x-Button).
3. Erneut php /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug ausgeführt, nun war das neue Zertifikat in Froxlor sichtbar.
4. Trotzdem wurde auf der Website das alte Zertifikat angezeigt.
5. Den alten Apache-Pfad der acme.conf auf /etc/nginx/ gesetzt (Inhalt ist der Standard-Froxlor-nginx-Config-Code)
6. Die Einträge in /root/.acme.sh/ gelöscht und den Cronjob erneut manuell gestartet. Kein Erfolg, nach wie vor das alte Zertifikat auf der Website.
7. Die acme-challenge-Tokens in /var/www/froxlor/.well-known/acme-challenge gelöscht und Cronjob ausgeführt. Kein Erfolg.
8. Den nginx-Server restartet - dann hat es funktioniert, neues Zertifikat ist nun auf der Website sichtbar.

Vmtl. habe ich da was durcheinander gebracht. Jetzt ist kein Token mehr im Ordner /var/www/froxlor/.well-known/acme-challenge zu finden - ist das ein Problem? Ich glaube ich hab verstanden, dass NUR beim Einholen des Zertifikates diese Tokens zur Prüfung wichtig sind. Da das Zertifikat ja schon existiert ist der Token momentan nicht wichtig.

Wie kann ich diese Tokens wieder generieren? Werden die bei der automatischen Verlängerung neu generiert?

Wie kann ich sicher sein dass die automatische Verlängerung läuft?

Hast Du einen Tipp für mich?

 

Grüße aus Wien

 

 

[d00p]

Da ist mir zuviel durcheinander.

Wechsel des Webservers hat an sich nichts damit zu tun das das Zertifikat nicht verlängert wird ich tippe hier auf die Nummer mit der acme.conf, wenn deine Pfade nicht stimmen ist klar warum es nicht geht.

Und keine Panik mit dem token, das wird natürlich immer nur für den Validierungsprozess erstellt und danach wieder gelöscht. Das ist korrekt so, so funktioniert acme 

[chrisiwien]

Durcheinander: sorry, aber ich dachte wenn ich alle Schritte ins Posting schreibe ist es klarer...ich weiß, so sieht es nicht aus.

Ich war der Meinung dass die Ausführung des froxlor Master-Cronjobs auch den Webserver neu startet. Zumindest meine ich dass ich bei anderen Änderungen der Konfiguration den Cronjob manuell ausgeführt habe und es hat gepasst. Ich habe den Cronjob mehrere Male ausgeführt, erst "service ngnix restart" hat dann was gebracht.

Pfad zu acme.conf: Ok, d.h. wenn der Pfad falsch ist bindet nginx die Datei nicht richtig ein, korrekt? Die früheren Zertifikate wurden trotz falschen Pfades ausgestellt - die Tokens der früheren Zertifikate waren auch in /var/www/froxlor/.well-known/acme-challenge zu finden - , die Verlängerung hat halt nicht geklappt. Der Inhalt der acme.conf war trotz falschen Pfades die korrekte Froxlor-acme-Konfiguration in nginx-Notation.

Token: ok, das beruhigt mich.

Ich muss halt in 3 Monaten schauen ob es geht. Schön wäre es wenn es eine Liste mit Parametern gäbe wie das automatische Update garantiert funktioniert. Aber Server und immer gleichbleibende Parameter...man wird ja wohl noch träumen dürfen! 😉

 

Danke für die Rückmeldung.

 

[chrisiwien]

Lieber d00p!

Ich bin unglücklich. Ich habe jetzt die 3 Monate gewartet, heute war das Zertifikat wieder ungültig. Die automatische Erneuerung hat nicht funktioniert.

ich habe wieder die Einträge in /root/.acme.sh/ und /var/www/froxlor/.well-known/acme-challenge gelöscht, den froxlor Master-Cronjob laufen lassen und dann den Server mit service nginx restart neu gestartet, jetzt passt es wieder.

Wo kann ich weiter nachforschen warum die automatische Aktualisierung nicht hinhaut? Ev. wird der Master-Cronjob nicht richtig ausgeführt?

 

Help!

Schöne Grüße aus Wien

 

[d00p]

Das kann alles mögliche sein. Und warum es nach löschen und neu anlegen problemlos geht macht es jetzt nicht einfacher zumal du damit jetzt natürlich die Möglichkeit zum debuggen ausgelöscht hast

[chrisiwien]

"zumal du damit jetzt natürlich die Möglichkeit zum debuggen ausgelöscht hast" - echt? Ich hab ja nur die Zertifikatseinträge gelöscht. Ist halt blöd, meine Website rankt für meine Schlüsselwörter in Google recht gut, die will ich nicht ohne Zertifkat stehen lassen weil dann potentielle Kunden die Meckerei im Browser sehen.

Ok, kann ich mich so herantasten ob der Cronjob überhaupt automatisch ausgeführt wird? Wie kann ich das prüfen? Über die Server-Logs? Zudem bringt das manuelle Ausführen ja nix, erst das Löschen und Server-Restart...

Liegt das ev. an der nginx-Konfiguration? Soll ich diese posten?

Auf einem anderen Server den ich betreibe (Apache) steht im Ordner "var/www/froxlor/.well-known/acme-challenge" nur ein Eintrag a la "AdVu25vcdf9-orM5-LIFssjJx4G6JxgjAgzVR6OCzVfIM". Beim nginx-Server bleiben dort immer die alten Zertifkatseinträge stehen. Nachdem ich die lösche und den nginx-Server neu starte gehts.

[d00p]

9 hours ago, chrisiwien said:

Ok, kann ich mich so herantasten ob der Cronjob überhaupt automatisch ausgeführt wird? Wie kann ich das prüfen? Über die Server-Logs

jo sicher, ausgeführte cronjobs via cron-daemon tauchen in /var/log/syslog auf

9 hours ago, chrisiwien said:

Zudem bringt das manuelle Ausführen ja nix, erst das Löschen und Server-Restart..

Schon richtig, aber die entsprechenden Ausgaben des Cronjobs hätten vllt Aufschluss geben können wo das Problem liegt.

9 hours ago, chrisiwien said:

Liegt das ev. an der nginx-Konfiguration? Soll ich diese posten?

Wenn es die von froxlor automatisch generierten sind sollte das problemlos funktionieren

9 hours ago, chrisiwien said:

Auf einem anderen Server den ich betreibe (Apache) steht im Ordner "var/www/froxlor/.well-known/acme-challenge" nur ein Eintrag a la "AdVu25vcdf9-orM5-LIFssjJx4G6JxgjAgzVR6OCzVfIM". Beim nginx-Server bleiben dort immer die alten Zertifkatseinträge stehen. Nachdem ich die lösche und den nginx-Server neu starte gehts.

Also generell ist dieser Ordner leer. acme.sh generiert dort das Token hin, dass Let's Encrypt von außen via Zugriff auf http://domain.tld/.well-known/acme-challenge/[token] validiert und somit die Existenz der Domain bestätigt auf dem Server. Ich wüsste nicht das der Webserver da irgendwas "aufräumt" - würde jetzt eher Tippen das die beim nginx liegenbleiben, da es zu Fehlern kam

[chrisiwien]

Ok, danke für Rückmeldung.

Ich habe jetzt den Mastercronjob mit --letsencrypt --force --debug laufen lassen. Es erscheint eine Fehlermeldung "[error] could not find file 'domain.com.cer' in '/root/.acme.sh/domain.com'". Das selbe für die anderen Zertifikatsdateien (key, cer, csr).

Im Ordner '/root/.acme.sh/www.domain.com' sind Zertifikatsdateien.

Wohlgemerkt, ich leite www.domain.com via dem nginx-Configbefehl 'return 301 https://domain.com$request_uri;' (eingestellt in den vHost-Settings von www.domain.com) auf die non-www-Adresse um. Im Froxlor-Panel wird das Zertifikat sowohl für die www also auch für die non-www-Adresse angezeigt.

Im Browser erscheint domain.com mit gültigem Zertifikat. Mach ich mir ev. mit diesem nginx-Redirect einen Murks rein? Muss ich den Redirect von www auf non-www anders lösen?

[d00p]

39 minutes ago, chrisiwien said:

Wohlgemerkt, ich leite www.domain.com via dem nginx-Configbefehl 'return 301 https://domain.com$request_uri;' (eingestellt in den vHost-Settings von www.domain.com) auf die non-www-Adresse um.

für nen redirect richte doch einfach die subdomain www.domain.com ein und trag dort als documentroot die domain.com ein dann erstellt froxlor dir einen redirect und weiss auch davon - vllt hilft das

[chrisiwien]

Ok, das ist bereits so. Die documentroot ist für beide Domains /var/customers/webs/domain. D.h. ich brauche den nginx-Redirect gar nicht? Froxlor erstellt automatisch den Redirect von www auf non-www???

[d00p]

Nenene, du trägst bei der einen als document root die URL anstatt /var/customers/webs/domain/ ein, dann erstellt froxlor einen redirect

[chrisiwien]

aso

[chrisiwien]

Dadurch hab ich jetzt einen 502 Bad Gateway-Error...😕

Wenn ich domain.com in die DocumentRoot einfüge erscheint bei neuerlichen Aufruf "/domain.com/".

 

[d00p]

502 sagt wohl eher das fcgi nich gestartet ist

[chrisiwien]

Die FPM-Sockets sind alle da. Was tun?

[d00p]

Webserver error logs sagen was? 502 heisst er hat keine verbindung zu den sockets

[chrisiwien]

2020/12/16 22:06:12 [crit] 6725#6725: *3 connect() to unix:/var/lib/nginx/fastcgi/1-domain-domain.com-php-fpm.socket failed (13: Permission denied) while connecting to upstream, client: 80.109.49.138, server: domain.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/lib/nginx/fastcgi/1-domain-domain.com-php-fpm.socket:", host: "domain.com"

und für eine subdomain.domain.com (da liegt eine Testseite):

2020/12/16 22:06:10 [crit] 6725#6725: *1 stat() "/var/customers/webs/virtualbooth/index.php" failed (13: Permission denied), client: 80.109.49.138, server: virtual-booth.domain.com, request: "GET /favicon.ico HTTP/2.0", host: "virtual-booth.domain.com", referrer: "https://virtual-booth.domain.com/favicon-32x32.png"
 

Der Froxlor-Admin läuft zum Glück. Da ist plötzlich in den vHosts ein Hund drinnen.

 

[d00p]

Permission denied....libnss auch korrekt eingerichtet?

[chrisiwien]

Du, ich hab in dem Moment nur versucht die domain.com in die DocumentRoot einzutragen. Dann Cronjob ausgeführt und noch service nginx restart ausgeführt. An der Konfiguration habe ich nichts geändert...

[d00p]

naja, wenn du fpm nutzt musst du schon auch die db user aufs system mappen mittels libnss-extrausers

[chrisiwien]

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat extrausers
group:          compat extrausers
shadow:         compat extrausers
gshadow:        files

hosts:          files dns
networks:       files dns

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

 

Datei var/lib/extrausers/group:

domain:x:10000:domain,www-data,froxlorlocal
domain2:x:10001:domain2,www-data,froxlorlocal
domain3:x:10002:domain3,www-data,froxlorlocal

Ist das so richtig?

 

 

 

[d00p]

sieht alles ganz richtig aus ja. läuft denn nginx unter www-data?

[chrisiwien]

Im Froxlor-Panel unter Webserver-Einstellungen steht www-data bei Benutzername/Gruppenname.

[d00p]

ja und läuft der prozess auch unter dem user?

[chrisiwien]

ps -u www-data zeigt mir vier Einträge mit nginx.

[chrisiwien]

Folgendes Verhalten: bei der Hauptdomain domain.com kann ich nicht auf die PHP-Dateien zugreifen (502 Bad Gateway) aber auf die statischen Dateien (Texte, Bilder) schon.

Bei der Subdomain subdomain.domain.com leitet der Server ins Nirvana. Ohne Versuch gezielt eine Datei aufzurufen kommt ein 403er mit Dateiversuch ein 404er.

Und in den Error-Logs ist nach wie vor permission denied zu finden.