Lets encrypt Zertifikat erneuert sich nicht

[heisenberg]

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

Man kann da bei der Weiterleitung für die Umleitung http -> https eine Ausnahme für die LetsEncrypt-Requests setzen. Dann funktioniert das in Zukunft. Bei Apache sieht das so aus:

Code: Alles auswählen

RewriteEngine On
RewriteCond "%{REQUEST_URI}" !/.well-known/acme-challenge/
RewriteRule  ^.*$ https://%{HTTP_HOST}

...und noch den include für die Umleitung des Requests für alle VHosts:

viewtopic.php?t=168482

Andere Variante ist, da certbot einzusetzen, der seinen eigenen Webserver für die Validierung starten kann - da muss der andere Webserver natürlich vorher abgeschaltet werden. Das wäre mir aber zu umständlich.

[tim11]

Nach einer Woche Pause die nächste Frage

Die Konfiguration habe ich geändert, Zugriff auf Port 80 ist nun wieder möglich.

Nun funktioniert acme.sh --renew -d ****.****.de, das Zertifikat wird erneuert, Datum zeigt dass die Daten verändert wurden und ein erneutes Erneuern zeigt ebenfalls die Gültigkeit.

-rwxrwx--- 1 www-data www-data 2,2K 1. Jul 12:42 cert.pem
-rwxrwx--- 1 www-data www-data 3,7K 1. Jul 12:42 chain.pem
-rwxrwx--- 1 www-data www-data 5,9K 1. Jul 12:42 fullchain.pem
-rwxrwx--- 1 www-data www-data 3,2K 1. Jul 12:42 privkey.pem

Sa 2. Jul 08:06:03 CEST 2022] Skip, Next renewal time is: Di 30. Aug 10:42:16 UTC 2022

Allerdings wird dies im Browser beim Aufrufen der Seite nicht beachtet:

Gültigkeit
Beginn
Sun, 02 Jan 2022 08:35:46 GMT
Ende
Sat, 02 Apr 2022 08:35:45 GMT

Restart von Webserver und Reboot haben keine Veränderung. Muss ich noch irgendwas manuell anstoßen?

[heisenberg]

Welche Zertifikatspfade sind im Webserver gesetzt?

[tim11]

nginx:

ssl_certificate /etc/letsencrypt/rsa-certs/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/rsa-certs/privkey.pem;

root@****:/etc/letsencrypt/rsa-certs# ls -lha
insgesamt 28K
drwxrwx--- 2 www-data www-data 4,0K 19. Jan 09:30 .
drwxrwx--- 4 www-data www-data 4,0K 2. Jan 10:01 ..
-rwxrwx--- 1 www-data www-data 2,2K 1. Jul 12:42 cert.pem
-rwxrwx--- 1 www-data www-data 3,7K 1. Jul 12:42 chain.pem
-rwxrwx--- 1 www-data www-data 5,9K 1. Jul 12:42 fullchain.pem
-rwxrwx--- 1 www-data www-data 3,2K 1. Jul 12:42 privkey.pem

[heisenberg]

nginx:

Code: Alles auswählen

ssl_certificate /etc/letsencrypt/rsa-certs/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/rsa-certs/privkey.pem;

a) Sicherheitshalber würde ich nochmal nginx durchstarten. (Gibt's dabei irgendwelche Aufälligkeiten im nginx log?)
b) Nochmal den Gültigkeitszeitraum der Zertifikate auf der Shell testen.(Das müsste: openssl x509 -in /etc/letsencrypt/rsa-certs/cert.pem -noout -dates sein bzw. statt cert.pem auch noch mal fullchain.pem testen)
c) Wenn Dir Dir der Browser einen abweichenden Gültigkeitszeitraum angibt, dann müssen das Zertifikate sein, die bei dir auch noch irgendwo rumliegen und konfiguriert sind. D. h. evtl. ein anderer VHost im nginx, der aufgrund von Fehlkonfiguration aktiv ist. Empfehlung deine Nginx-Konfig und die zugehörigen Zertifikate zu überprüfen.

[tim11]

Die Zertifikate passen:

notBefore=Jul 1 09:42:14 2022 GMT
notAfter=Sep 29 09:42:13 2022 GMT

Reboot bringt nichts, der Proxy geht per Cron eh jeden Tag ab 23:00 schlafen und weckt sich morgens um 07:00 wieder. Die conf ist seit dem letzten Zertifikat nicht geändert worden.

im Konqueror geht auch nichts

ERR_CERT_DATE_INVALID

Komisch dass er das alte Datum noch erkennt laut Zertifikat, wenn es ein falscher Pfad wäre, dürfte er eigentlich überhaupt keins erkennen.

[heisenberg]

der Proxy geht per Cron eh jeden Tag ab 23:00 schlafen und weckt sich morgens um 07:00 wieder.

Sich schlafen legen heisst jetzt aber schon SHUTDOWN und keinesfalls SUSPEND?( Bei letzterem würde der nginx vermutlich nicht neu gestartet und verwendet die alten Zertifikate).

Insofern:

a) Sicherheitshalber würde ich nochmal nginx durchstarten. (Gibt's dabei irgendwelche Aufälligkeiten im nginx log?)

Und Du hast keine weiteren Zertifikate rumliegen?

Du hast ansonsten keine weiteren vhosts mit Zertifikaten definiert?

Ansonsten würde ich mir als nächstes mal lokal am proxy mittels openssl anschauen, ob der das richtige Zertifikat zumindest lokal verwendet:

Code: Alles auswählen

you@proxy $ openssl s_client -connect nginx_ip:443 -servername dein.nxcloud.dnsname \
   | openssl x509 -noout -dates -text

In der Ausgabe sind 2 Dinge zu prüfen:

a) Die Zeile "Subject: CN = ..." sollte Deinen korrekten Zertifikats-CN enthalten.
b) Anfang- und End- Datum des Zertifikates sollten Deinem auf der Platte liegenden Zertifikat entsprechen.

[tim11]

Ausgabe:

root@***:/etc/nginx/conf.d# openssl s_client -connect nginx_ip:443 -***.**.de https://***.***.de | openssl x509 -noout -dates -text
s_client: Option unknown option -***.***.de
s_client: Use -help for summary.
unable to load certificate
139978595669312:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE

Servername laut conf nginx ist identisch mit der DNS.

Könnte ich die Zertifikate einfach löschen und nochmal neu beantragen?

[heisenberg]

Code: Alles auswählen

openssl s_client -connect nginx_ip:443 -***.**.de https://***.***.de \
      | openssl x509 -noout -dates -text

Der Befehl enthält mehrere Fehler:

• Für nginx_ip musst Du natürlich die IP-Adresse einsetzen, auf der der VHost lokal läuft.
• https://***.***.de ist falsch. Da muss stehen: -servername ***.***.de (ohne "https")
• Das gehört da auch so nicht hin: -***.**.de

Nimm Dir mal 5 Minuten Zeit, atme tief durch und schaue Dir den Befehl, den ich oben geschrieben habe genau an und setze Ihn dann richtig mit Deinen Werten um.

Könnte ich die Zertifikate einfach löschen und nochmal neu beantragen?

Du hast afaiu einwandfreie Zertifikate lokal vorliegen. Du kannst natürlich die Zertifikate nochmal neu registrieren. Das löst nur Dein Problem nicht.

[tim11]

Ah, ok, ich dachte dass ich den -servername mit meinem Servernamen ersetzen muss, my bad

Subject passt, Servername laut conf, aber Datum passt nicht:

Validity
Not Before: Jan 2 08:35:46 2022 GMT
Not After : Apr 2 08:35:45 2022 GMT

[heisenberg]

Ok. Und Du hast den NGINX durchgestartet? Und danach mit dem Befehl nochmal geprüft?

[tim11]

Ganz vergessen Deine Frage zu beantworten, es erfolgt jede Nacht ein shutdown mittels skript, das je nach Wochentag definiert ist, zum Beispiel

#!/bin/sh
rtcwake -m no -s 57600 && poweroff

nginx habe ich neu gestartet, aber es zeigt im Konqueror und Firefox immer noch das alte Datum an, auch in der Ausgabe von openssl keine Änderung

[heisenberg]

Subject passt, Servername laut conf, aber Datum passt nicht:

Validity
Not Before: Jan 2 08:35:46 2022 GMT
Not After : Apr 2 08:35:45 2022 GMT

Ok. Dann liefert also der lokale NGINX auf dem Reverse Proxy tatsächlich nicht das korrekte Zertifikat aus. NGINX wird tatsächlich auch täglich neu gestartet. D. h. eine neue Konfiguration wird tatsächlich aktiv. D. h. die Konfiguration muss immer noch falsch sein und verweist vermutlich auf falsche Zertifikate.

nginx habe ich neu gestartet, aber es zeigt im Konqueror und Firefox immer noch das alte Datum an, auch in der Ausgabe von openssl keine Änderung

Testen am besten immer mit openssl bzw. wget auf der Konsole. Browser bringen zusätzlich mögliche Fehlerquellen mit rein.

Dann nochmal zu:

c) Wenn Dir Dir der Browser einen abweichenden Gültigkeitszeitraum angibt, dann müssen das Zertifikate sein, die bei dir auch noch irgendwo rumliegen und konfiguriert sind. D. h. evtl. ein anderer VHost im nginx, der aufgrund von Fehlkonfiguration aktiv ist. Empfehlung deine Nginx-Konfig und die zugehörigen Zertifikate zu überprüfen.

Was ist die Ausgabe am Proxy von ...

• fgrep -R ssl_certificate /etc/nginx
• netststat -ntlp bzw. ss -nltp
• nginx -T (am bestens ins NoPaste und davor anonymisieren, aber bitte so, dass die Struktur erhalten bleibt. Deine lokalen IPv4-Adressen brauchst Du nicht anonymisieren).

[tim11]

Habe ich mich eigentlich schon für Deine tolle und geduldige Hilfe bedankt?

root@***:/home/***# fgrep -R ssl_certificate /etc/nginx
/etc/nginx/conf.d/nextcloud.conf:ssl_certificate /etc/letsencrypt/rsa-certs/fullchain.pem;
/etc/nginx/conf.d/nextcloud.conf:ssl_certificate_key /etc/letsencrypt/rsa-certs/privkey.pem;
/etc/nginx/conf.d/nextcloud.conf:ssl_certificate /etc/letsencrypt/ecc-certs/fullchain.pem;
/etc/nginx/conf.d/nextcloud.conf:ssl_certificate_key /etc/letsencrypt/ecc-certs/privkey.pem;
/etc/nginx/conf.d/http.conf:ssl_certificate /etc/letsencrypt/rsa-certs/fullchain.pem;
/etc/nginx/conf.d/http.conf:ssl_certificate_key /etc/letsencrypt/rsa-certs/privkey.pem;
/etc/nginx/conf.d/http.conf:ssl_certificate /etc/letsencrypt/ecc-certs/fullchain.pem;
/etc/nginx/conf.d/http.conf:ssl_certificate_key /etc/letsencrypt/ecc-certs/privkey.pem;

root@***:/home/***# netstat -ntlp bzw. ss -nltp
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:*** 0.0.0.0:* LISTEN 645/mariadbd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 552/nginx: master p
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 1515/master
tcp 0 0 0.0.0.0:*** 0.0.0.0:* LISTEN 576/sshd: /usr/sbin
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 552/nginx: master p
tcp6 0 0 :::80 :::* LISTEN 552/nginx: master p
tcp6 0 0 :::25 :::* LISTEN 1515/master
tcp6 0 0 :::*** :::* LISTEN 576/sshd: /usr/sbin
tcp6 0 0 :::443 :::* LISTEN 552/nginx: master p
tcp6 0 0 :::*** :::* LISTEN 559/vsftpd

https://nopaste.debianforum.de/41780

[heisenberg]

Bin jetzt erst mal weg (Urlaub).

In der Ausgabe sind mehrere Zertifikate. Bei denen kannst Du jetzt prüfen, welches Darum exakt mit dem falschen von oben überein stimmt und dementsprechend Deine nginx Konfiguration anpassen.

[tim11]

Die eigentlich Homepage geht auf die Nextcloud.conf. Die Zertifikate, die in der http.conf aufgeführt sind, haben den gleichen Pfad und wurden erst vor ein paar Tagen in die conf eingeführt, weil ich eine Subdomain mit dieser Conf integrieren will. Aber es gibt in der Tat 2 Zertifikate. Die rsa haben das neue Datum,

root@***:/etc/letsencrypt/rsa-certs# ls -lha
insgesamt 28K
drwxrwx--- 2 www-data www-data 4,0K 19. Jan 09:30 .
drwxrwx--- 4 www-data www-data 4,0K 2. Jan 2022 ..
-rwxrwx--- 1 www-data www-data 2,2K 1. Jul 12:42 cert.pem
-rwxrwx--- 1 www-data www-data 3,7K 1. Jul 12:42 chain.pem
-rwxrwx--- 1 www-data www-data 5,9K 1. Jul 12:42 fullchain.pem
-rwxrwx--- 1 www-data www-data 3,2K 1. Jul 12:42 privkey.pem

die ecc noch das alte

root@***:/etc/letsencrypt/ecc-certs# ls -lha
insgesamt 28K
drwxrwx--- 2 www-data www-data 4,0K 2. Jan 2022 .
drwxrwx--- 4 www-data www-data 4,0K 2. Jan 2022 ..
-rwxrwx--- 1 www-data www-data 1,6K 2. Jan 2022 cert.pem
-rwxrwx--- 1 www-data www-data 3,7K 2. Jan 2022 chain.pem
-rwxrwx--- 1 www-data www-data 5,3K 2. Jan 2022 fullchain.pem
-rwxrwx--- 1 www-data www-data 288 2. Jan 2022 privkey.pem

Und den Urlaub hast Du Dir aus meiner Sicht redlich verdient

[tim11]

So, nach meinem Urlaub kann ich den Rest nachliefern. Die nextcloud.conf hat beide Zertifikate aufgeführt:

server_name ***.de;
ssl_certificate /etc/letsencrypt/rsa-certs/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/rsa-certs/privkey.pem;
ssl_certificate /etc/letsencrypt/ecc-certs/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/ecc-certs/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/ecc-certs/chain.pem;

unter trusted_certificate ist nur das ecc pem gelistet, und die ecc sind noch Stand Januar. Hier hört leider mein Wissen auf. Habe einfach mal getestet, den Pfad des trusted_certificate von ecc auf rsa geändert, nginx neu gestartet, aber es hatte keine Auswirkung. Somit scheint der Fehler darin zu liegen, dass der Browser das - nicht erneuerte - ecc Zertifikat anfordert und nicht das - erneuerte - rsa Zertifikat. Somit muss ich entweder das ecc erneuern oder die Config so anpassen dass das rsa angefordert wird. Oder es gibt einen dritten Weg, den ich mir aktuell nicht vorstellen kann

[bluestar]

Wie sieht die komplette nginx Konfiguration an:

Code: Alles auswählen

nginx -T

[tim11]

Wie sieht die komplette nginx Konfiguration an:

Code: Alles auswählen

nginx -T

https://nopaste.debianforum.de/41780

[bluestar]

Kommentiere einfach mal die abgelaufenen ECC Zertifikate aus, dann sollte das ganze funktionieren.

[tim11]

Kommentiere einfach mal die abgelaufenen ECC Zertifikate aus, dann sollte das ganze funktionieren.

Hat funktioniert:

Ende
Thu, 29 Sep 2022 09:42:13 GMT

Ich bedanke mich bei Euch für die tolle und geduldige Hilfe