Test für gültiges Zertifikat zur Aktivierung von force_https ist fehlerhaft, es bleibt deaktiviert, obwohl es aktiviert sein sollte

Beitragen Fehler
1

Edit: Ich ändere dies in einen Fehler. Force_https ist nun auf Seiten deaktiviert, auf denen es zuvor aktiviert war, was Probleme verursacht.

Ich habe eine Weile an einer Website geforscht, bei der „Uploads nicht funktionieren". Nachdem ich eine Reihe offensichtlicher Dinge durchgegangen war (Neuaufbau, Abgesicherter Modus, nicht-standardmäßige Plugins in Betracht ziehen), fiel mir schließlich eine Warnung wegen gemischtem Inhalt auf, und ich aktivierte force_https. Jetzt läuft alles wieder.

Ich dachte, dass vor ein oder zwei Jahren force_https standardmäßig aktiviert war, aber in letzter Zeit habe ich mehrfach gehört (oder vielleicht gesehen), dass Dinge nicht funktionierten, weil force_https nicht aktiviert war.

Gibt es einen Grund, es nicht standardmäßig zu aktivieren?
[/quote]

Ich habe eine Weile an einer Website geforscht, bei der „Uploads nicht funktionieren". Nachdem ich eine Reihe offensichtlicher Dinge durchgegangen war (Neuaufbau, Abgesicherter Modus, nicht-standardmäßige Plugins in Betracht ziehen), fiel mir schließlich eine Warnung wegen gemischtem Inhalt auf, und ich aktivierte force_https. Jetzt läuft alles wieder.

Ich dachte, dass vor ein oder zwei Jahren force_https standardmäßig aktiviert war, aber in letzter Zeit habe ich mehrfach gehört (oder vielleicht gesehen), dass Dinge nicht funktionierten, weil force_https nicht aktiviert war.

Gibt es einen Grund, es nicht standardmäßig zu aktivieren?

1 „Gefällt mir“
Image upload stuck with "Processing" message
2

Es ist in der discourse.conf automatisch aktiviert, wenn ein gültiges Zertifikat vorhanden ist.
Das ist tatsächlich seit ein oder zwei Jahren so.

grep -q 'force_https' "/var/www/discourse/config/discourse.conf" || echo "force_https = 'true'" >> "/var/www/discourse/config/discourse.conf"

1 „Gefällt mir“
3

Aha! Danke, Richard.

Also werde ich nicht verrückt.

Das Problem ist, dass der Test für ein gültiges Zertifikat fehlschlägt:

# openssl verify -CAfile ca.cer fullchain.cer 
O = Digital Signature Trust Co., CN = DST Root CA X3
error 10 at 3 depth lookup: certificate has expired
error fullchain.cer: verification failed

Wenn ich dann mozilla/DST_Root_CA_X3.crt aus /etc/ca-certificates.conf entferne und update-ca-certificates ausführe, erhalte ich Folgendes:

C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 2 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed

Im Browser wird es jedoch korrekt angezeigt. Ich habe diesen Container heute neu erstellt (er sollte also über die aktualisierten Root-Zertifikate verfügen).

Ich weiß nicht genug über Zertifikate, um zu sagen, was genau hier los ist. Ich kann von innerhalb des Containers ein Let’s Encrypt-Zertifikat mit curl abrufen (ein Test, der letzte Woche bei einem WordPress-Container, an dem ich gearbeitet habe, fehlschlug).

Und diesmal bin ich nicht der Einzige: Es gab einige Leute, die kürzlich Dinge repariert haben, indem sie force_https aktiviert haben.

1 „Gefällt mir“
4

Ja, das klingt im Zusammenhang mit dem Ablauf des LetsEncrypt-Root-Zertifikats, insbesondere/allein, wenn dies erst seit vergangenen Freitag aufgetreten ist.

Was sagt openssl version (innerhalb des Docker-Containers)? (Aufgrund dieser Änderungen).

2 „Gefällt mir“
5 
OpenSSL 1.1.1d  10. Sep 2019

Vielleicht wird also „ISRG Root X1 im Trust Store" benötigt? Aber ich sehe mozilla/ISRG_Root_X1.crt in ca-certificates.conf.

1 „Gefällt mir“
6

OMG. Und ich habe zwei Tage lang an einem Problem geforscht, von dem ich dachte, es liege an einer komplexen Interaktion zwischen Rails, Ansible und Python, aber es stellte sich heraus, dass mein Server, auf dem früher force_https aktiviert war, das jetzt nicht mehr ist, und eine Reihe von Anfragen an http://myserver statt an https://myserver gestellt wurden.

Das scheint tatsächlich ein Bug zu sein.

2 „Gefällt mir“
7

Ja, das ist tatsächlich ein Fehler.

Letzte Woche haben wir ein Forum auf einen anderen Server verlegt und sind dabei auf das LetsEncrypt-Wiederherstellungslimit gestoßen (maximal 5 pro Woche für denselben Hostnamen). Anfangs wussten wir nicht, was das Problem war, aber dieser Fehler führte dazu, dass das Zertifikat bei jedem Build neu ausgestellt wurde. Nach fünf Versuchen stießen wir auf das Ratenlimit. Das löste keine Alarme aus, da das vorherige Zertifikat noch auf dem Server vorhanden war.

Erst als wir das Forum auf einen neuen Server verlegten, bekamen wir kein frisches Zertifikat. Wir hätten es zwar vom alten Server kopieren können, aber uns war nie klar, was die Ursache war.

acme.sh ist auf Version 2.9.0 festgelegt, während der Master-Zweig bei 3.0.1 liegt und über eine Funktion zum Festlegen einer Standard-Kette verfügt, was meiner Vermutung nach damit zusammenhängen könnte.

3 „Gefällt mir“
9

Hey @Falco. Möchtest du dir das mal ansehen? Du scheinst dich in diesen Angelegenheiten gut auszukennen. Ich habe das in den letzten ein oder zwei Wochen mehrere Stunden lang untersucht und verstehe immer noch nicht, was vor sich geht.

1 „Gefällt mir“
10

Ja, ich habe es mir am Wochenende selbst zugewiesen. Hier ist ein verlängertes Feiertagswochenende, aber ich werde mich diese Woche so schnell wie möglich darum kümmern.

2 „Gefällt mir“
11

Aha. Das ist der Teil, den ich übersehen habe. Entschuldige bitte, dass ich dich belästigt habe.

Unser verlängertes Feiertagswochenende ist gerade zu Ende gegangen, und der Tag Unserer Lieben Frau von Aparecida stand nicht in meinem Kalender. Aber jetzt weiß ich es.

Danke.

2 „Gefällt mir“
12

Dies wurde behoben durch

5 „Gefällt mir“
13

Danke @Falco für deine harte Arbeit daran :slight_smile:

2 „Gefällt mir“