[gelöst] IOB per https nicht erreichbar / Zertifikat def.
-
@schneidy76 sagte in Admin Webseite nicht mehr erreichbar:
aber es ist eben so....
Na, wenns so is, dann isses so.
Ich bin damit aber raus.
-
@bahnuhr sagte in Admin Webseite nicht mehr erreichbar:
Ich bin damit aber raus.
Ich auch.
Security sucks!
-
@bahnuhr Trotzdem Danke
-
@codierknecht ich habe den Betreff mal aktualisiert, vielleicht kann ja jemand helfen
-
@schneidy76 sagte in Admin Webseite nicht mehr erreichbar / SSL Keys defekt?:
bin den Weg über eine zusätzliche Admin Instance gegangen. Ohne SSL geht es. Sobald ich das aktiviere, bekomme ich den Adapter nicht mehr grün.
Wenn du jetzt eine weitere Admin-Instanz am Start hast, kannst du doch jetzt mal das Debug Log der Instanz "0" aktivieren, diese Instanz neu starten und das Log (nicht "iob diag"!) hier posten. Eine entsprechende Frage von @Thomas-Braun hattest du noch nicht beantwortet.
-
@marc-berg said in Admin Webseite nicht mehr erreichbar / SSL Keys defekt?:
Debug Log der Instanz "0" aktivieren
Hallo Marc,
stelle ich den Log auf Debug um und starte die Admin.0 Instance mit SSL Authentifizierung, bekomme ich trotz den nicht startenden Adapter keine Meldung ins Log.
Also zurück auf INFO? -
@schneidy76 sagte in Admin Webseite nicht mehr erreichbar / SSL Keys defekt?:
bekomme ich trotz den nicht startenden Adapter keine Meldung ins Log
Gegenprobe: bekommst du bei der Instanz.1 Meldungen im Log, wenn du auf "debug" schaltest?
-
@marc-berg
Gegenprobe 1: Admin.0 steht auf "Alles" und nichts kommt an
Gegenprobe 2: Admin.1 steht auf "Debug" Meldungen mit Level Debug kommen- Habe ein Update (Edit: auf Admin 6.12.0) angeboten bekommen und dieses ausgeführt. Augenscheinlich durchgelaufen, aber Fehler:
SyntaxError: Unexpected token '<', "<!doctype "... is not valid JSONim Dialogfenster.
Vg Torsten
-
Zwischenstand:
bin nun auf einen RP4 mit 8GB RAM umgestiegen.
Es gab einige Probleme beim Zurückspielen des Backups, die ich aber lösen konnte.
Jetzt läuft der ioBroker wieder stabil mit genügend Reserven.Ich habe derzeit (zum Testen) 2 Admin Instanzen laufen:
Admin.0 mit https und Authentifizierung Port 8081
Admin.1 ohne SSL Port 8089Instanz Admin.0 konnte ich starten, nachdem ich den Befehl:
iob cert creategefunden habe.
Ich kann aber noch nicht per https zugreifen. Die Browser melden zurück:
192.x.x.x erfüllt die Sicherheitsstandards nicht. ERR_SSL_SERVER_CERT_BAD_FORMATHat jemand ne Idee?
Danke und VG Torsten
-
@schneidy76 sagte in Admin per https nicht erreichbar / Zertifikatprobleme:
ERR_SSL_SERVER_CERT_BAD_FORMAT
Ich weiß ja nicht, welchen Browser du nutzt, normalerweise muss man ja das Verwenden von selbstsignierten Zertifikaten am Browser explizit bestätigen.
Ein weiterer Klassiker bei solchen Fehlern ist ein falsch eingestellte Zeitzone und/oder Zeit. Prüf das mal. -
@marc-berg
Hi Marc, den Firefox konnte ich überreden, die Website per https anzuzeigen.
Ich musste dazu den erweiterten Schutz deaktivieren und explizit bestätigen, dass ich mir dem Risiko bewusst bin.Google Chrom konnte ich noch nicht dazu bewegen - Safe Browsing habe ich dort nun ebenfalls deaktiviert. Trotzdem zeigt der mir die Seite nicht an...
Ich teste weiter...
-
Lösung:
So nun habe ich es endlich hinbekommen. Der Ausflug zu letsencrypt ging schief, nach einigen schlaflosen durchdachten Nächten, habe ich eine Lösung gefunden:-
Backup der bestehenden Installation erstellen und per WinSCP (o.ä.) auf dem PC sichern
-
iob stop -
ioBroker Installation per
sudo rm -r /opt/iobrokerplattmachen -
ioBroker nach der Anleitung: Klick mich neu installieren
-
Im Assistenten "Authentifizierung erforderlich" auswählen und Admin Password vergeben
-
Nach dem Abschluss die ioBroker Einstellungen öffnen und zum Reiter Zertifikate gehen
-
Beide Zertifikate einzeln komplett markieren und als "Nur Text" in einer separaten WordPad Datei speichern.
-
Backup mit WinSCP (o.ä.) zurückspielen und per
iob restore 0wiederherstellen -
iob rebuilddurchlaufen lassen und anschließend den ioBroker gestartet -
wieder in die Einstellungen des ioBroker gehen und in dem Reiter Zertifikate die bestehenden Zertifikate mit
Xlöschen -
die vorher gesicherten Zertifikate aus den Dateien ersetzen
-
Sichern und Schließen --> anschließend Instance "Admin" neu starten
-
FERTIG
-
-
@schneidy76 sagte in Admin per https nicht erreichbar / Zertifikatprobleme:
Rechte des Verzeichnisses /opt auf 777 setzen
per sudo rm -r /opt plattmachenWarum das? Hört sich komplett unnötig, gefährlich und planlos an.
-
@thomas-braun
leider alternativlos denn ich brauche dringend den Zugang über https für mein KNX Projekt:
Issues 251 GitHub -
Ich meine das grobschlächtige löschen von /opt.
Und warum setzt man das auf 'frei blasen für alle und jeden', wenn man das dann im nächsten Schritt ohnehin als root wegsenst? -
@thomas-braun jaa, vielleicht wäre das eleganter gegangen, aber Hauptsache alles ist erstmal wech und clean...
Bei der Installation werden die Rechte ohnehin wieder richtig vergeben - und zur Not gibt es ja noch den Fixer......
-
@schneidy76 sagte in [gelöst] IOB per https nicht erreichbar / Zertifikat def.:
aber Hauptsache alles ist erstmal wech und clean...
Das Problem ist, das /opt nicht exklusiv für den ioBroker da ist. Da wohnen unter Umständen auch noch andere Programme. Und deswegen kann man da nicht einfach so wüst drin rum löschen.
Und die Rechte sind und bleiben da auch falsch.
Das muss so aussehen, nix mit 777...drwxr-xr-x 5 root root 4096 Oct 26 2023 opt -
@thomas-braun
Du hast Recht. Bei mir wohnte da nur noch gpio, vom rp2 Adapter.
In dem Fall also egal.
Ich nehme deinen Rat aber gerne an und korrigiere mich oben entsprechend.
Das /opt Verzeichnis wurde übrigens mit den richtigen Rechten wieder bei der Installation neu erstellt. -
Das kannst du aber nicht auf andere Systeme übertragen.
echad@chet:/opt $ ls -l total 12 drwxrwxr-x+ 7 iobroker iobroker 4096 Aug 9 21:21 iobroker drwxr-xr-x 3 root root 4096 Oct 10 2023 pigpio drwxr-xr-x 3 root root 4096 Oct 26 2023 scripts echad@chet:/opt $Hier hättest du pigpio und scripts mit der Aktion weggegrätscht.
