Zertifikatsprobleme

Seit heute behauptet mein Browser, dass die verbindung zum Forum nicht mehr sicher ist. Liegt das am Server oder an mir?

Du könntest mal alle Cookies und den Verlauf löschen.
Vielleicht hat dein Browser ein veraltetes Zertifikat.
Bei mir passt alles (Chrome mobile).

Hm, scheint ein Firefox-Problem zu sein. Sowohl mobil wie am Computer.
Mit edge auf dem androidgerät wird die Verbindung als sicher bezeichnet.

Anscheinend wird COntent (vermutlich Bilder) von außerhalb der URL geladen, und diese sind unverschlüsselt:

Das scheint das Problem zu sein.

@vieuxrenard : ich denke, das Problem ist, dass das Lage-der-Nation Logo oben links von

http://talk.lagedernation.org/uploads/default/original/1X/8765aa7253df62395269d9d1f828d43c0f1d85d1.svg

geladen wird, also ohne https. Könntest du das auf https umstellen?

Gibts hier nochmal ein feedback? Und sei es wont fix.

1 „Gefällt mir“

Lässt sich leider von unserer Seite aus nicht fixen, ist ein Bug in Discourse. Auch frisch hochgeladene Bilder werden wieder als http eingebunden.

Habe das gleiche Problem.

Wie ärgerlich.
Danke fürs Reinschauen!

Da fällt mir ein: Würdest du nen Issue bei Discourse aufmachen? Ich habe mich selbst daran versucht, aber da ich außer als Konsument keine Ahnung davon habe, könnte ich außer „is kaputt“ wenig da hineinschreiben.

Ich habe gerade recherchiert, auf Seiten von Discourse scheint da kein offener Bug vorzuliegen.

Da ihr das Discourse (so wie es anständig ist) offenbar via Nginx reverse-proxied, ist anzunehmen, dass Discourse von Nginx via http (nicht https) angesprochen wird (sowas wie http://127.0.0.1:[discourse-port]).

Daher ist Discourse vermutlich nicht bekannt, dass der Nginx vor ihm eine TLS-Verbindung bedient.

Es scheint für Discourse die Konfigurationsoption force_https zu geben, welche Discourse offenbar zwingt davon auszugehen, dass es per HTTPS aufgerufen wird (und das entsprechend auch bei der Referenzierung von Resourcen beachtet).

Der saubere Weg ist vermutlich, Nginx so zu konfigurieren dass es in Richtung Discourse den X-Forwarded-Proto (X-Forwarded-Proto - HTTP | MDN) Header setzt. Wenn Discourse diesen Header auswertet (was gute Software üblicherweise tut), sollte sich das Problem damit gegessen haben, wenn nicht würde ich den Weg über force_https in der Discourse-Konfiguration wählen.

Cheers
Thomas

1 „Gefällt mir“

Vielen Dank für deine Mühe, Thomas!

Wir setzen „leider“ auf den offiziellen Docker-Container von Discourse, d.h. es ist nicht so einfach, an die Konfiguration heranzukommen … aber ich schau mal, man kann dem Container sicher irgendwie auch Parameter mitgeben.

2 „Gefällt mir“

Doch noch was gefunden: Site logos and https with proxy - #2 by codinghorror - support - Discourse Meta

Der Co-Founder von Discourse sagt dort:

Running https without “force https” set isn’t supported – and never has been.

Cheers
Thomas

Wunderbar, nur wie kommt der Parameter jetzt in den Container?

Völlig überraschend erhöht Containerisierung die Kmomplexität und führt zu neuen Problem, die man vorher nicht gehabt hat.

In dem verlinkten Post ist an einer Stelle ein Screenshot, in dem es so aussieht als sei das eine klickbare Option im Admin Interface.

Sollte es das nicht sein, so gehe ich davon aus, dass die Discourse Config-Datei Teil des wie auch immer gearteten Datenverzeichnisses ist, welches in den Container gemountet wird. Hier fehlt mir aber ehrlich gesagt die Kenntnis des Aufbaus des Docker-Containers von Discourse und Erfahrung mit Discourse selbst (habe nie eins betrieben, sorry)

@WilliWuff

Völlig überraschend erhöht Containerisierung die Kmomplexität und führt zu neuen Problem, die man vorher nicht gehabt hat.

Glaube nicht, dass das hier und jetzt der Ort oder die Zeit ist über das Für und Wider von Docker zu sprechen :wink:

Cheers
Thomas

1 „Gefällt mir“

Völlig richtig… ohne den Docker-Container gäbe es dieses Forum vielleicht gar nicht. Dann hätte auch niemand Probleme damit.
Wahrscheinlich hast du nen Punkt, aber ich finde ihn unter der Überheblichkeit nicht.

Wenn du ganz ernsthaft der Lage der Nation von der Verwendung des Containers abraten willst, empfehle ich, die Nachteile aufzuzeigen und eine bessere Alternative zu beschreiben.

Ich habe mal gesucht, hier in dem Threat beschreibt jemand das Problem, und der letzte Post beschreibt wie man ihn behebt:

After a lot of digging around a days of trial and error, I finally found this command line setting:

cd /var/discourse
./launcher enter socket-only
rails c
SiteSetting.force_https = true

and verified:

postgres=# \c discourse
You are now connected to database "discourse" as user "postgres".
discourse=# select * from site_settings where name like '%http%';
 id |    name     | data_type | value |         created_at         |         updated_at         
----+-------------+-----------+-------+----------------------------+----------------------------
 79 | force_https |         5 | t     | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)

discourse=# \q

Then, I restarted:

./launcher restart socket-only

BOOM.

Man kann Discourse wohl auch ohne Docker installieren, das hat aber wohl tatsächlich deutlich Mehraufwand zur Folge. Kann ich also einsehen. Aber man erkauft sich diese Vereinfachung eben auch immer mit Abhängigkeiten vom Distributor. Ist also eine Abwägung.

2 „Gefällt mir“

Moin, ich habe das Setting über die Suche in den Admin-Einstellungen gefunden - es gibt dort tatsächlich eine Option via UI. Nun sollte alles klappen.

Danke für eure Mithilfe!

3 „Gefällt mir“

Ja, die Warnung ist weg. Prima.

1 „Gefällt mir“