Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Marc Berg]

@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.

[schneidy76]

@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?

[Marc Berg]

@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?

[schneidy76]

@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

3. 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 JSON

im Dialogfenster.

Vg Torsten

[schneidy76]

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 8089

Instanz Admin.0 konnte ich starten, nachdem ich den Befehl:

iob cert create

gefunden 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_FORMAT

Hat jemand ne Idee?

Danke und VG Torsten

[Marc Berg]

@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.

[schneidy76]

@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... :muscle:

[schneidy76]

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/iobroker plattmachen

• 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 0 wiederherstellen

• iob rebuild durchlaufen lassen und anschließend den ioBroker gestartet

• wieder in die Einstellungen des ioBroker gehen und in dem Reiter Zertifikate die bestehenden Zertifikate mit X löschen

• die vorher gesicherten Zertifikate aus den Dateien ersetzen

• Sichern und Schließen --> anschließend Instance "Admin" neu starten

• FERTIG

[Thomas Braun]

@schneidy76 sagte in Admin per https nicht erreichbar / Zertifikatprobleme:

Rechte des Verzeichnisses /opt auf 777 setzen
per sudo rm -r /opt plattmachen

Warum das? Hört sich komplett unnötig, gefährlich und planlos an.

[schneidy76]

@thomas-braun
leider alternativlos denn ich brauche dringend den Zugang über https für mein KNX Projekt:
Issues 251 GitHub

[Thomas Braun]

@schneidy76

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?

[schneidy76]

@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......:grin:

[Thomas Braun]

@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

[schneidy76]

@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.

[Thomas Braun]

@schneidy76

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.