NextcloudPI neu mit veralteten Letsencrypt-Daten?

Hallo,

ich bin noch recht neu hier im Forum.
In den letzten Wochen habe ich mich an verschiedenen NextcloudPi Installationen ausgetobt und hatte bei einer älteren, mittlerweile nicht mehr vorhandenen Installation über dyn6.com in Verbindung mit FritzBox eine Domain für den Fernzugriff eingerichtet, das ganze dann mit Letsencrypt zu dieser Domain abgesichert. Nun bekomme ich natürlich Meldungen von Letsencrypt, dass das Zertifikat abläuft und erneuert werden muss.
Verstehe ich dass richtig, dass das Zertifikat an die ursprüngliche ncPi-Installation und Domain gebunden ist? Gehe ich über ncPi- Admin und versuche mit der Domain und der EMail-Adresse das Zertifikat wieder einzubinden, bekomme ich nur Fehlermeldungen.
Weil ich die Domain gerne weiter benutzen würde, gibt es einen Weg (bzw. Doku), wie ich bei Letsencrypt das Zertifikat zu Domain und EMail- Adresse löschen und mit der gegenwärtigen ncPi Installation wieder neu aufsetzen kann?

Ich bin dankbar für jeden Tip!
Viele Grüße

Gehe ich über ncPi- Admin und versuche mit der Domain und der EMail-Adresse das Zertifikat wieder einzubinden, bekomme ich nur Fehlermeldungen.

Es wäre hilfreich wenn du die Fehlermeldungen hier posten könntest.

Ist der DynDNS Name beim Anbieter des Dienstes noch aktiv und verweist er auch auf deine aktuelle externe IP, sprich erreichst du deine Nextcloud damit von extern?

Hallo bb77,

Sorry für meine verspätete Antwort, ich hatte selber erst noch ein paar Schritte versucht. Aus einer früheren ncpi Installation hatte ich via Terminal den “letsencrypt” Ordner nach /etc kopiert.
Leider ist die Fehlermeldung dieselbe geblieben (siehe Anhang) - da es verschiedene Installationen waren, könnte allerdings einfach auch die richtige noch nicht dabei gewesen sein.

Aus der Fehlermeldung: mit dem “A” und “AAAA” Einträgen habe ich bei Erstellung und Nutzung der Zertifikate nie Probleme gehabt, diese Parameter hatte ich nie eingetragen gehabt.
Wenn ich das richtig gesehen habe, ändern diese sich ja auch einmal am Tag (oder bin ich da verkehrt drauf?)

Rufe ich via Internet die Domain über .dynv6.net auf, bekomme ich nur noch “nicht erreichbar” Meldungen

Grundsätzlich muss dein Nextcloud Server über Port80 und 443 mit dem entsprechenden Domainnamen vom Internet aus erreichbar sein, damit die Zertifikate für diesen Domainnamen erneuert werden können. Das scheint hier nicht mehr der Fall zu sein.

An einem normalen Heim-Internetanschluss hast du normalweise dynamische IP-Adressen. Wie häufig diese ändern, hängt von deinem Provider ab. Genau hier kommen nun Dienste wie dyn9.com ins Spiel. Damit deine dyn9.com Adresse immer auf die jeweils aktuelle IP deines Internetanschlusses zeigt, müssen diese A und AAAA-Einträge jeweils aktualisiert werden, wenn sich deine IP ändert. Dieser Vorgang muss von deinem Internetanschluss aus, sprich von einem Gerät in deinem Netzwerk initiert werden.

Normalerweise, wird dieser Vorgang durch ein Script auf einem PC oder Server in deinem lokalen Netzwerk, oder direkt auf deinem Router erledigt. Dieses Script meldet dem DynDNS-Anbieter dann im Idealfall automatisiert deine aktuelle IP. Viele Router haben da schon Scripte von den gängigen DynDNS-Anbietern hinterlegt, und du musst nur noch diene Zugangsdaten eingeben. Falls dein Router oder NCP keine Einstellungen anbieten für dyn9.com, müsstest du mal auf deren Website schauen, was du sonst noch für Möglichkeiten hast, die Aktualisierung automatisiert auszuführen. Am einfachsten ist es aber, wenn du einen DynDNS-Anbieter wählst, der direkt von deinem Router oder von NCP unterstützt wird.

Grundsätzlich muss dein Nextcloud Server über Port80 und 443 mit dem entsprechenden Domainnamen vom Internet aus erreichbar sein, damit die Zertifikate für diesen Domainnamen erneuert werden können. Das scheint hier nicht mehr der Fall zu sein.

ist er, Ports 80 und 443 sind auf der FritzBox über https - tcp freigegeben für den Raspi
woraus im Fehlerlog hattest du diese Info her bezogen?

dynv6.net:
hält eine sehr detailreiche Anleitung speziell für verschiedene Router-Typen / -Modelle vor, diese habe ich 1:1 umgesetzt. Die Weiterleitung lief ja auch bis zuletzt störungsfrei, erst als der Expirybot von Letsencrypt sich meldete, bin ich tätig geworden. Dabei hat mich am meisten verwundert, das im Adminpanel von ncpi in den Zeilen darüber immer “wird automatisch erneuert” steht.

Bitte nochmal zu meinem Verständnis:
Zertifikate “leben” doch immer von einem öffentlichen und privaten Teil. Habe ich durch das Neuaufsetzen des Systems diesen Kommunikationsprozess mit den Servern von Letsencrypt möglw. selber unterbrochen, da der benötigte Teil des Zertifikats nunmehr nicht mehr auf meinem Raspi vorhanden ist - und hilft mir möglw. ein Reinkopieren aus alten Installationen?

Danke übrigens mal für Deine Hilfe !

woraus im Fehlerlog hattest du diese Info her bezogen?

“The Server could not connect to the client to verify the domain”

Mit Server ist in diesem Fall der Let’s Encrypt-Server gemeint. Mit Client dein Raspi.

Und du schreibst ja selbst, dass, wenn du die Domain über das Internet aufrufst, den Raspi nicht mehr erreichst. Wäre er noch erreichbar, käme bei einem abgelaufenen/ungültigen Zertifikat irgendeine Zertifikatsfehlermeldung und nicht “nicht erreichbar”

Bitte nochmal zu meinem Verständnis:
Zertifikate “leben” doch immer von einem öffentlichen und privaten Teil. Habe ich durch das Neuaufsetzen des Systems diesen Kommunikationsprozess mit den Servern von Letsencrypt möglw. selber unterbrochen, da der benötigte Teil des Zertifikats nunmehr nicht mehr auf meinem Raspi vorhanden ist - und hilft mir möglw. ein Reinkopieren aus alten Installationen?

Vielleicht würde das mit dem rein kopieren sogar funktionieren, wenn das Zertifikat noch gültig ist. Aber spätenstens, wenn es wieder erneuert werden soll, hättest du wieder das gleiche Problem.

Ich kenne leider den Anbieter dyn6.com überhaupt nicht, darum wiederhole ich mich teilweise noch mal und kann dir nur relativ allgemeine Tipps geben.

Damit es funktioniert müssen die folgenden zwei Punkte erfüllt sein:

  1. Im Router müssen via Port-Forwarding Port 80 und 443 auf deinen Raspi weitergeleitet werden.
  2. Dein Dyn6-Domainname muss auf deine aktuelle externe IP-Adresse zeigen.

Eines von beidem oder beides ist hier nicht der Fall.

zertifkate enthalten die url des browsers. damit jetzt nicht jeder zertifikate für www.google.com ausstellen kann, was man leicht mit openssl auf der kommandoazeile kann, werden zertifikate von vertrauensvollen stellen unterschrieben.

also du gibt’s bei einer solchen stelle dein selbst erstelltes zertifkat ab und erhälst es unterschrieben zurück. unterschrieben heißt hier “nochmal” verschlüsseln mit dem privaten teil des schlüssels der vertauensvollen stelle. der öffentliche teil dieses schlüssels ist in deinem browser.

letsencrypt ist eine solche vertrauensvolle stelle. deren öffentlicher schlüssel ist in deinem browser.

jetzt kommt der punkt mit dem vertrauen. letsencrypt möchte gerne wissen, ob dir denn auch die domain www.google.com gehört. also schicken sie dir als gegenzug zu deinem “signing request” einen “challenge” zu, mit der bitte den auf deiner web-seite zur verfügung zu stellen. der letsencrypt client (certbot, acme.sh, andere) stellt dieses challenge über einen webserver zur verfügung und letsencrypt ruft den ab. für deine domain kein problem. falls du das mit www.google.com versuchst, wird’s schwierig. ist der abruf erfolgreich, bekommst du ein unterschriebenes zertifkat turück. und dein browser bestätigt dir mit dem schloß, dass du mit deiner seite verbunden bist.

nö. immer wenn du einen letencrypt client beauftragst ein zertifkat zu erstellen/erneuern, wird immer ein neues erstellt und zum unterschreiben geschickt.

p.s.: das mit öffentlichen und privaten teil bezieht sich eher auf asymmetrische kryptographie, wo man öffentliche und private schüssel benutzt. den öffentlichen kann man gefahrlos über unsichere kanäle schicken. der dient aber nur zum verschlüsseln der nachricht. deshalb kann den jeder haben.

p.p.s.: das mit dem challenge über web ist nur eine methode zu prüfen, ob dir die domain gehört. alternativ kann man auch txt einträge im dns vornehmen. die ruft letsencrypt dann mittels “nslookup” ab.

p.p.p.s: ruf mal mit `curl -v https://www.google.com/ die seite auf der commando zeile auf. dann findest oben im header den “inhalt” des zertifikates.

* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com
*  start date: Jan  5 12:13:00 2021 GMT
*  expire date: Mar 30 12:12:59 2021 GMT
*  subjectAltName: host "www.google.com" matched cert's "www.google.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.

Hallo,
ich habe mich die letzten Tage mit Euren Tipps und Rückmeldungen noch einmal intensiv an meiner NextcloudPi und den Zertifikaten sowie meinen Router-Einstellungen (FritzBox 7410) ausgetobt.

Mehr oder weniger per Zufall fiel dabei ins Auge, dass auf dem Router die CheckBox für “Zertifikat von letsencrypt verwenden” deaktiviert war - wieso & warum ? - keine Ahnung ! Ich hatte irgendwann Anfang letzten Jahres diesen Dienst auf meinem Router aktiviert. Nachdem ich diese CheckBox erneut aktiviert hatte, ging auch der Verbindungsaufbau über die Domain zur heimischen NCPi via Internet wieder, nur leider ohne “https”.

Weiterhin hatte ich die Freigabe für Ports 80 und 443 gelöscht und einfach mal neu angelegt. Leider so auch ohne erkennbaren Erfolg, sodass auch weiterhin beim Versuch das Zertifikat über das NCPi Admin-Panel zu erneuern die bereits bekannte Fehlermeldung auftritt.

@ Reiner Nippes: vielen Dank für die detaillierte Ausführung, konnte ich trotz der Komplexität recht gut verstehen!

Hmm. Soviel ich weiss geht es bei dieser Checkbox darum ein Let’s Encrypt Zertifikat für die Weboberfläche der Fritzbox zu beziehen. Und wie man verschiedenen Berichten entnehmen kann, ist dann offenbar die Weboberfläche der FritzBox von aussen erreichbar, was ich a) nicht unbedingt empfehlen würde und b) sich allenfalls mit der Portweiterleitung auf deinen NCP-Server beissen könnte. Ich habe aber selbst keine Fritzbox und kann nicht aus eigener Erfahrung sprechen. Habe u.a. das dazu gefunden…

https://www.golem.de/news/https-fritzbox-bekommt-let-s-encrypt-support-und-verraet-hostnamen-1712-131705.html

Was dein eigentliches Problem betrifft, bin ich ehrlich gesagt etwas ratlos… Kommt immer noch die exakt gleiche Fehlermeldung, wenn du versuchst das Zertifikat zu erneuern?

Wird wirklich deine externe IP-Adresse aufgelöst, wenn du aus dem Internet deinen dyn6 -Domainnamen aufrufst? Du kannst das z.B. mit diesem Online-Tool überprüfen…

https://mxtoolbox.com/DnsLookup.aspx

Generell ist es Letsenrypt egal, ob das aktuelle Zertifikat des Webserver noch gültig oder abgelaufen ist, wenn man es erneuert. Ich habe eine Maschine, die auch nur einmal im Jahr für ein paar Wochen hochgefahren wird. Da ist das Zertifikat am Anfang auch immer hoffnungslos abglaufen.

Die Fehlermeldung aus deinem Screenshot ist übrigens der Fall, dass der Server, der die Zertifikate ausstellt, sich bei dir die Datei mit dem Geheimnis nicht abholen kann.

Normalerweise schickt der Client von Letsencrypt an deren Server eine Nachricht, dass er unter einer bestimmten URL mit diesem .well-known eine Datei als Geheimnis findet, die einen zufälligen Inhalt wie XYZ123 hat.
Dann versucht der Server irgendwie über Port 80 oder 443 diese Datei runterzuladen. Ob es da nur http oder vielleicht auch https mit einem beliebigen Zertifikat (gültig, abgelaufen oder selbstsigniert ist egal) gibt, stört ihn nicht. Da frisst er alles.
Findet er das Geheimnis wie angekündigt unter der Adresse mit XYZ123 als Inhalt, erstellt er dir ein neues Zertifikat. Das lädt der Client dann runter und tauscht es dann aus, wenn es schon eins gab, oder passt die Config von deinem Webserver beim ersten Lauf an.

Kannst du mal von einem anderen Internetanschluss schauen, ob du bei deiner aktuellen externen IPv4 überhaupt wenigstens eine Antwort auf Port 80 bekommst?

Hallo,
ich konnte die Störung auflösen und jetzt wieder Zertifikate in NCPi erhalten, bzw. erneuern. Durch Eure Beiträge und viel Recherche im Internet konnte ich einige Fehler letztenendes ausschließen, z.B. Störung durch die Firewall/Virensoftware des PCs, grundsätzlicher Fehler beim Verbindungsaufbau zw dem PI und dem Letsencrypt Server, Fehler in den A und AAAA Record Einstellungen bei dynv6.com, usw.
Das brachte mich schließlich dazu, mir die Einstellungen meines Routers (FB7490) näher anzuschauen; Fehler in den Filterlisten, Portforwarding, bzw -freigaben konnte ich ausschließen. Obwohl im Internet mehrere Post zu finden waren, bei denen im Zusammenhang mit IPv6 und dynv6.com auf die vom Router eingerichtete Verbindungsart verwiesen und empfohlen wurde, konnte ich den Zertifierungsvorgang schließlich dadurch wieder aktivieren, dass ich auf IPv6 Tunnelprotokoll und “6to4” umgestellt habe - dann ist der Vorgang sofort problemlos durchgelaufen.

Vielen Dank für Eure Hilfe
& alles Gute !

1 Like