Facebook login segnalato come non conforme da Facebook dopo la modifica al sistema di certificati Let's Encrypt

[Paul_King]

Dal 30 settembre 2021 circa (per quanto riesco a capire), il mio sito genera errori relativi ai certificati:

La tua connessione non è privata
Avviso di sicurezza “NET::ERR_CERT_COMMON_NAME_INVALID”.

Questo server non è riuscito a dimostrare di essere www.nzarchitecture.net.nz; il suo certificato di sicurezza appartiene a nzarchitecture.net.nz. Ciò potrebbe essere causato da una configurazione errata o da un attaccante che intercetta la tua connessione.

Questo problema potrebbe essere correlato alle modifiche implementate da Let’s Encrypt in quella data.
Il problema si verifica quando viene utilizzato l’URL https://www.nzarchitecture.net.nz, ma non quando si usa https://nzarchitecture.net.nz.

Il problema persiste anche dopo l’aggiornamento alla versione 2.8.0 beta 7 e l’esecuzione di una ricostruzione completa.

Una conseguenza dell’errore visualizzato sulla pagina di destinazione è che il sito è stato segnalato come non più conforme ai requisiti di Facebook, il che ha portato alla disattivazione dell’accesso tramite Facebook.

[IAmGav (Gavin Perch)]

È un problema di Facebook che devono risolvere.

Il certificato è al 100% legittimo.

SSL Checker

[anon73664359]

Questo sembra simile a…
https://meta.discourse.org/t/configuring-google-login-for-discourse/15858/239

[Paul_King]

Il fatto è che persino io vedo questi errori quando includo ‘www’ nell’URL che incollo o digito nel browser. Quindi, anche se non c’è un reale rischio, gli utenti ricevono avvisi preoccupanti, con o senza il problema di conformità a Facebook.

Nel frattempo, Facebook si rifiuta di esaminare la questione finché l’errore non scompare.

[IAmGav (Gavin Perch)]

Nel tuo file di configurazione

/var/discourse/containers/app.yml

a cosa è impostato DISCOURSE_HOSTNAME:?

[Falco]

@Paul_King

Il problema si verifica quando viene utilizzato l’URL https://www.nzarchitecture.net.nz, ma non quando si utilizza https://nzarchitecture.net.nz

Se il tuo sito reale si trova sotto il dominio non-www, devi registrare il dominio non-www nel sistema di Facebook. Non è possibile mescolarli.

[Paul_King]

app.yml mostra

DISCOURSE_HOSTNAME: nzarchitecture.net.nz

[Paul_King]

@Falco

Se il tuo sito reale è sotto il dominio non-www, devi registrare il dominio non-www nel sistema di Facebook. Non puoi mescolarli.

Ok, suppongo che abbia senso, ma dal punto di vista DNS uno è un alias dell’altro (o almeno credevo) e sarà difficile spiegare all’utente medio che non può usare ‘www’, specialmente se deve accedere per vedere un avviso del genere…

[Falco]

Non è propriamente un “alias”, ma un reindirizzamento. È necessario configurare correttamente un reindirizzamento, il che include la presenza di un certificato valido per il sito su cui risiede il reindirizzamento.

Ad esempio, i nostri partner di communiteq offrono un servizio a tal proposito su https://www.forcewww.com/

[Paul_King]

@Falco

Non è propriamente un “alias”, ma un reindirizzamento. E devi configurare correttamente il reindirizzamento, il che include avere un certificato in vigore per il luogo in cui risiede il reindirizzamento.

Fino a poco tempo fa, questo non è mai stato un problema: nessun avviso da Facebook e nessun avviso relativo ai certificati, con o senza www.

Esiste un modo per ottenere che il certificato gratuito predefinito di Let’s Encrypt certifichi entrambe le opzioni? Preferirei non complicare le cose con certificati aggiuntivi da gestire e costi extra.

Ci sono molte email in circolazione con link al sito che includono il www.

Con “il luogo in cui risiede il reindirizzamento” intendi in questo caso Digital Ocean? (il mio hosting, da cui vengono gestite le impostazioni DNS)

[JammyDodger]

@Paul_King

Esiste un modo per ottenere il certificato gratuito predefinito di Let’s Encrypt che certifichi entrambe le opzioni? Vorrei evitare di complicare le cose con certificati aggiuntivi da gestire e costi extra.

Puoi aggiungere una o due righe al tuo file app.yml. Questo ha funzionato per me quando ho avuto problemi:

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]

Grazie - sembra promettente

Nel mio caso, se https://nzarchitecture.net è il dominio base, le righe corrette da aggiungere sarebbero quelle qui sotto?

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

Devo ricostruire Discourse perché queste modifiche abbiano effetto?

[Simon_Manning]

Il contenuto è corretto, ma l’indentazione nel file YAML è importante, quindi va corretta:

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

Dovrai ricompilare affinché le modifiche abbiano effetto.

Modifica: In realtà sembra che l’uso di --keylength sia stato sostituito da -k, quindi dovrai utilizzare invece quanto segue:
Scusa, la mia ricerca su GitHub mi ha portato a un vecchio fork senza che me ne accorgessi. --keylength è corretto.

[Paul_King]

Fantastico! Grazie mille per il tuo aiuto @Simon_Manning e a tutti quanti: quel reindirizzamento tramite app.yml ha funzionato alla perfezione.