Facebook-Login als nicht konform von Facebook nach Umstellung auf Let's Encrypt-Zertifikatssystem markiert

[Paul_King]

Seit ungefähr dem 30. September 2021 (soweit ich das beurteilen kann) wirft meine Seite Zertifikatsfehler auf:

Ihre Verbindung ist nicht privat
Sicherheitswarnung „NET::ERR_CERT_COMMON_NAME_INVALID“.

Dieser Server konnte nicht nachweisen, dass es sich um www.nzarchitecture.net.nz handelt; sein Sicherheitszertifikat stammt von nzarchitecture.net.nz. Dies kann auf eine Fehlkonfiguration oder einen Angreifer zurückzuführen sein, der Ihre Verbindung abfängt.

Dieses Problem könnte mit den an diesem Datum eingeführten Änderungen bei Let’s Encrypt zusammenhängen.
Der Fehler tritt auf, wenn die URL https://www.nzarchitecture.net.nz verwendet wird, nicht jedoch bei https://nzarchitecture.net.nz.

Das Problem besteht weiterhin, auch nachdem auf Version 2.8.0 Beta 7 aktualisiert und ein vollständiger Neuaufbau durchgeführt wurde.

Eine Folge des Auftretens dieser Fehlermeldung auf meiner Startseite ist, dass die Website als nicht mehr konform mit den Anforderungen von Facebook gekennzeichnet wurde, wodurch die Facebook-Anmeldung von Facebook deaktiviert wurde.

[IAmGav (Gavin Perch)]

Das ist ein Problem von Facebook, das sie beheben müssen.

Das Zertifikat ist zu 100 % legitim.

SSL Checker

[anon73664359]

Das scheint ähnlich zu sein wie…
https://meta.discourse.org/t/configuring-google-login-for-discourse/15858/239

[Paul_King]

Die Sache ist die: Selbst ich sehe diese Fehler, wenn ich „www" in die URL einfüge oder eingebe, die ich in den Browser kopiere. Obwohl also kein tatsächliches Risiko besteht, werden Nutzer mit beunruhigenden Warnungen konfrontiert – unabhängig vom Facebook-Compliance-Problem.

Facebook wiederum weigert sich, den Fall zu prüfen, bis der Fehler behoben ist.

[IAmGav (Gavin Perch)]

in deiner Konfigurationsdatei

/var/discourse/containers/app.yml

worauf ist dein DISCOURSE_HOSTNAME: gesetzt?

[Falco]

@Paul_King

Das Problem tritt auf, wenn die URL https://www.nzarchitecture.net.nz verwendet wird, nicht jedoch bei https://nzarchitecture.net.nz.

Wenn Ihre echte Website unter der Domain ohne „www" läuft, müssen Sie diese Domain im Facebook-System registrieren. Eine Mischung ist nicht möglich.

[Paul_King]

app.yml zeigt

DISCOURSE_HOSTNAME: nzarchitecture.net.nz

[Paul_King]

@Falco

Wenn deine echte Website unter der Nicht-www-Domain läuft, musst du die Nicht-www-Domain im Facebook-System registrieren. Das lässt sich nicht miteinander vermischen.

OK, das ergibt wohl Sinn – aber aus DNS-Sicht ist das eine ein Alias des anderen (oder so dachte ich zumindest). Es wird schwierig sein, dem durchschnittlichen Benutzer zu erklären, dass er „www" nicht verwenden kann – besonders dann, wenn er sich einloggen muss, um eine entsprechende Warnung zu sehen.

[Falco]

Es ist eigentlich kein „Alias", sondern eine Weiterleitung. Und Sie müssen eine Weiterleitung korrekt einrichten, was bedeutet, dass für die Seite, auf der die Weiterleitung stattfindet, ein Zertifikat vorhanden sein muss.

Unsere Partner bei communiteq bieten beispielsweise einen entsprechenden Dienst unter https://www.forcewww.com/ an.

[Paul_King]

@Falco

Es ist nicht wirklich ein „Alias", sondern eine Weiterleitung. Und Sie müssen eine Weiterleitung ordnungsgemäß konfigurieren, was bedeutet, dass ein Zertifikat für den Ort, an dem die Weiterleitung stattfindet, vorhanden sein muss.

Bis vor kurzem war dies noch nie ein Problem – keine Warnung von Facebook und keine Zertifikatswarnungen, egal ob mit oder ohne „www".

Gibt es eine Möglichkeit, dass das standardmäßige kostenlose Let’s Encrypt-Zertifikat beide Optionen abdeckt? Ich möchte die Dinge nicht durch zusätzliche zu verwaltende Zertifikate und zusätzliche Kosten komplizieren.

Es gibt viele E-Mails mit Links zur Website, die das „www" enthalten.

Meinen Sie mit „dem Ort, an dem die Weiterleitung stattfindet" in diesem Fall Digital Ocean? (Mein Hosting-Anbieter, von dem aus auch die DNS-Einstellungen verwaltet werden.)

[JammyDodger]

@Paul_King

Gibt es eine Möglichkeit, das Standard-zertifizierte kostenlose Let’s Encrypt-Zertifikat für beide Optionen zu verwenden? Ich möchte die Dinge nicht durch zusätzliche zu verwaltende Zertifikate und zusätzliche Kosten komplizieren.

Du kannst deinem app.yml eine oder zwei zusätzliche Zeilen hinzufügen. Das hat bei mir funktioniert, als ich Probleme hatte:

Set up Let’s Encrypt with multiple domains / redirects

NOTE: @pfaffman says: This page needs to be cleaned up. There is now a new ENV setting that will let you add more hostnames. In your app.yml under your DISCOURSE_HOSTNAME line (it can go many places but that one makes sense), add DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com and early reports suggest that you’ll get valid certs for those domains and that accessing https://domain.com will properly redirect you to your DISCOURSE_HOSTNAME without a certificate error. If you do that an…

[Paul_King]

Danke – das klingt vielversprechend.

In meinem Fall, wenn https://nzarchitecture.net die Basis-Domain ist, wären die richtigen Zeilen zum Hinzufügen dann wie folgt?

after_ssl:
- replace:
filename: “/etc/runit/1.d/letsencrypt”
from: /–keylength/
to: “-d www.nzarchitecture.net.nz --keylength”

Und muss ich Discourse neu erstellen, damit dies wirksam wird?

[Simon_Manning]

Der Inhalt ist korrekt, aber die Einrückung ist in der YML-Datei wichtig, sodass dies korrigiert werden muss:

  after_ssl:
    - replace:
        filename: “/etc/runit/1.d/letsencrypt”
        from: /--keylength/
        to: “-d www.nzarchitecture.net.nz --keylength”

Sie müssen das System neu erstellen, damit die Änderung wirksam wird.

Edit: Tatsächlich scheint die Verwendung von --keylength durch -k ersetzt worden zu sein, sodass Sie stattdessen Folgendes benötigen:
Entschuldigung, meine GitHub-Suche hat mich ohne mein Wissen zu einem alten Fork geführt. --keylength ist korrekt.

[Paul_King]

Fantastisch! Vielen Dank für eure Hilfe, @Simon_Manning und alle anderen – diese Weiterleitung über app.yml hat perfekt funktioniert.