Hallo.
Seit gestern taucht auf unserer Nextcloud 21.x mit dem Chrome-Browser jedoch nicht mit dem Firefox dieses Problem auf:
Dies ist keine sichere Verbindung
Hacker könnten versuchen, Ihre Daten von nextcloud.meine-domain.de zu stehlen, zum Beispiel Passwörter, Nachrichten oder Kreditkartendaten. Weitere Informationen
NET::ERR_CERT_DATE_INVALID
Wenn ich im Firefox das gleiche mache, erhalte ich das gültige LE-Zertifikat, das auch noch bis Ende Oktober gültig ist. Wir lassen die Zertifikate von der OPNSense (Version 21.1.x) holen und dann auf den Nextcloud-Server schieben. Daneben dient die OPNSense auch als RevProxy (HAProxy) für alle Zugriffe auf Port 80/443. Ein Update der Firewall wurde gestern nicht durchgeführt aber die LE-Zertifikate wurden am Monatsende automatisch erneuert.
Hat jemand einen Vorschlag, wo man hier am besten ansetzten soll? Ich habe natürlich schon versucht, die Zertfikate nochmal manuell neu zu erstellen und anschließend die NC neu gestartet -- der Effekt bleibt aber bestehen. Ach ja: Die Systemzeit habe ich sowohl auf der OPNSense als auch auf dem NC-Host verglichen. Die sind identisch und stimmen.
Wenn ich mir die Zertifikate direkt auf der Firewall ansehe, erhalte ich seltsamerweise:
/var/etc/acme-client/home/nextcloud.meine-domain.de # openssl verify ./fullchain.cer
O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 3 depth lookup: certificate has expired
Ebenso seltsam ist: Wenn ich das Zertifikat von außen prüfe, erhalte ich:
openssl s_client -connect nextcloud.meine-domain.de:443
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate
verify return:1
Aber wenn ich mich auf dem Nexcloud-Host selbst (also von "innen") verbinde, erhalte ich:
openssl s_client -connect nextcloud.meine-domain.de:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = nextcloud.meine-domain.de
verify return:1
... ich bin nicht sicher, wo ich nun weitersuchen soll?!? Ich bin auch nicht sicher, ob das nun mit der Firewall, mit dem Apache2 der Nexcloud oder mit der LE-Zertifikats-Erneuerung zu tun hat!?
Vielleicht hat jemand eine gute Idee?
Bei mir hat geholfen das veraltete X3 CA zu löschen und dann die Zertifikate neu auszustellen
Gesendet von meinem OnePlus 8t mit Tapatalk
Quote from: superwinni2 on October 02, 2021, 12:26:50 PM
Bei mir hat geholfen das veraltete X3 CA zu löschen und dann die Zertifikate neu auszustellen
Oh, das klingt gut! Also muss ich das doch auf der Firewall tun? Oder wie bist Du genau vorgegangen?
Genau.
Unter System Trust Authorities.
Im Normalfall sind dort nicht viele Einträge. Einfach anhand des Datums schauen welche nicht mehr aktuell sind und diese entsprechend löschen.
Danach erneut das LE Zertifikat ausstellen lassen und falls nötig die entsprechenden Dienste (nginx oder haproxy) Neustarten.
Gesendet von meinem OnePlus 8t mit Tapatalk
Es sieht alles danach aus, als wäre die Ursache gefunden ... :)
Mir ist aber noch nicht klar, warum da Einträge mehrfach auftauchen und unterschiedliche Ablaufdaten haben. Aber entscheidend scheint ja der vorletzte Eintrag unter R3 zu sein. Dort steht ja auch, dass am 29. September Schluss mit lustig war?!
Man kann den Eintrag ja auch editieren und das Zertifikat auf diese Weise ändern -- aber wie findet man heraus, welcher Eintrag da rein muss?
Das Thema wird ja hier auch heiß diskutiert ... habe ich erst gerade entdeckt:
https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190/261
Gibt es einen Fix via
opnsense-patch -c plugins .... ?
Hi
Bei mir half, unter System: Trust: Authorities alle LE R3 Zertifikate zu löschen, anschließend alle LE Zertifikate neu erstellen und neu zuweisen und alle betroffenen Dienste nochmals neu zu starten. Überall, wo in der OPNsense ein LE Zertifikat verwendet wird, mußt du überprüfen, denn durch das Löschen des LE R3 Zertifikats werden die erzeugten LE Zertifikate gelöscht.
Beim neu erstellen der Zertifikate wurde dann bei mir ein neues R3 (ACME Client) Zertifikat unter System: Trust: Authorities hinzugefügt.
Das ganze wird aber vermutlich nur dann funktionieren, wenn du auf OPNsense 21.7.3_3 aktualisierst. Denn das ACME Client Plugin 3.2 enthält einen Fix.
Gruß
KH
Sorry, wenn ich nochmal doof nachfrage bevor ich mich an die Sache heran machen:
Was meinst du mit "neu zuweisen" genau? Wo ist das überall der Fall?
Hi,
Ich habe ein LE Zertifikat für die WebGUI. Da zum Bespiel.
In den Public Services des HAproxy.
Im Nginx.
...
Da wo du halt die LE Zertifikate in der OPNsense verwendest. Wenn ich das richtig gesehen habe, dann hast du 12 Stück.
Gruß
KH
Genau deshalb meine Frage ... wenn man das Zertifikat im WebUI direkt editieren kann, dürfte es doch auch reichen, wenn man NUR dort die aktuelle Version per copy & paste einfügt, oder?
Wozu sonst gibt es die Funktion "editieren"?
Ich bin in Sachen Zertifikatsketten allerdings nicht fit genug, um entscheiden zu können, welchen Teil aus
"cat fullchain.pem" man da ggf verwenden müsste...?
Ok, ich bin jetzt dieser Anleitung gefolgt: https://forum.opnsense.org/index.php?topic=24950.msg119873#msg119873 - den alten Eintrag editiert, umbenannt und die beiden neuen Zertifikate eingefügt. Und siehe da: Gültig bis Mon, 15 Sep 2025 18:00 Uhr.
Danach das Nextcloud-LE-Zertifikat nochmal erneuert ...
blöderweise musste ich im Chrome nochmal den lokalen Cache löschen aber danach wurde die Seite wieder mit neuem und gültigem Zertifikat geladen :)
Hm -- leider zu früh gefreut. Ich habe seit der Erneuerung der LE-Zertifikate jetzt zwar gültige R3-Zertifikate (s. Attachment), doch wenn ich es so wie oben prüfe, erhalte ich auch weiterhin das gleiche Ergebnis:
von außen:
openssl s_client -connect nextcloud.meine-domain.de:443
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate
verify return:1
Aber wenn ich mich auf dem Nexcloud-Host selbst (also von "innen") verbinde, erhalte ich:
openssl s_client -connect nextcloud.meine-domain.de:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = nextcloud.meine-domain.de
verify return:1
Hi,
nachdem ich heute morgen einen Neustart durchführen musste (IPv6 Prefix war weg), dann hat bei mir das verifizieren von manchen LE Zertifikaten auch nicht mehr funktioniert (namentlich meine DoT Server).
Ich habe es erst lösen können, als ich die LE-CA Zertifikate nach der Anleitung von Felix https://forum.opnsense.org/index.php?topic=24950.msg119873#msg119873 (https://forum.opnsense.org/index.php?topic=24950.msg119873#msg119873) als neue Authority hinzugefügt habe. Danach waren meine LE-Zertifikate dieser Authority zugewiesen. Ich habe dann die Authority mit 0 Zertifikaten gelöscht. Danach ging alles wieder.
Lösche doch einfach die LE R3 Authority mit 0 Zertifikaten und schau ob es geht.
Gruß
KH
Hallo, ich habe das neue R3 Zertifikat ja bereits dort eingefügt und dann auch alle LE Zertifikate neu erstellen lassen. Das Problem besteht aber blöderweise weiterhin. Bei Zugriffen auf die Nextcloud, die hinter dem HA Proxy liegt, erscheint immernoch die Zertifikatswarnung.
Es wurde oben ja schon gesagt, dass es vermutlich erst mit 21.7 wieder rund läuft. Kann das jemand bestätigen?? Geht es mit 21.1 auf keinen Fall??
Na in der Changelog steht ja das es ordentliche Änderungen gab...
Zudem ist das Forum für die 21.7 Version...
Daher aktualisieren und dann weiter sehen
Gesendet von meinem OnePlus 8t mit Tapatalk
Nur um den Thread zu schließen: Mit dem Update auf 21.7.3 lief alles wieder.
Super
Danke für die Rückmeldung
Gesendet von meinem OnePlus 8t mit Tapatalk