El inicio de sesión de Facebook fue marcado como no conforme por Facebook después del cambio al sistema de certificados Let's Encrypt

[Paul_King]

Desde aproximadamente el 30 de septiembre de 2021 (según mi conocimiento), mi sitio ha estado generando errores de certificado:

\u003e su conexión no es privada
\u003e advertencia de seguridad ‘NET::ERR_CERT_COMMON_NAME_INVALID’.
\u003e
\u003e Este servidor no pudo probar que es www.nzarchitecture.net.nz; su certificado de seguridad es de nzarchitecture.net.nz. Esto puede ser causado por una mala configuración o por un atacante que intercepta su conexión.

Este problema podría estar relacionado con los cambios implementados por Let’s Encrypt en esa fecha.
El problema se activa cuando se utiliza la URL https://www.nzarchitecture.net.nz, pero no cuando se utiliza https://nzarchitecture.net.nz.

El problema persiste incluso después de actualizar a la versión 2.8.0 beta 7 y realizar una reconstrucción completa.

Una consecuencia de que aparezca el mensaje de error en mi página de inicio es que el sitio ha sido marcado como que ya no cumple con los requisitos de Facebook, lo que significa que Facebook ha desactivado el inicio de sesión de Facebook.

[IAmGav (Gavin Perch)]

es un problema de Facebook que ellos necesitan solucionar.

el certificado es 100% legítimo

SSL Checker

[anon73664359]

Eso parece similar a…
https://meta.discourse.org/t/configuring-google-login-for-discourse/15858/239

[Paul_King]

El problema es que incluso yo veo estos errores al incluir ‘www’ en la URL que pego o escribo en el navegador; por lo tanto, aunque no exista un riesgo real, los usuarios se encuentran con advertencias preocupantes, con o sin el problema de cumplimiento de Facebook.

Mientras tanto, Facebook se niega a revisar el asunto hasta que el error desaparezca.

[IAmGav (Gavin Perch)]

en tu archivo de configuración

/var/discourse/containers/app.yml

¿a qué está configurado tu DISCOURSE_HOSTNAME:?

[Falco]

@Paul_King

El problema se activa cuando se usa la URL https://www.nzarchitecture.net.nz, pero no cuando se usa https://nzarchitecture.net.nz

Si tu sitio real está bajo el dominio sin www, debes registrar el dominio sin www en el sistema de Facebook. No se pueden mezclar.

[Paul_King]

app.yml muestra

DISCOURSE_HOSTNAME: nzarchitecture.net.nz

[Paul_King]

@Falco

Si tu sitio real está bajo el dominio sin www, debes registrar el dominio sin www en el sistema de Facebook. No se pueden mezclar.

Vale, supongo que tiene sentido, pero desde el punto de vista de DNS, uno es un alias del otro (o al menos eso creía) y va a ser difícil decirle al usuario promedio que no puede usar ‘www’, especialmente si necesita iniciar sesión para ver alguna advertencia al respecto…

[Falco]

No es realmente un “alias”, sino una redirección. Y necesitas configurar correctamente una redirección, lo que incluye tener un certificado en vigor para el lugar donde reside la redirección.

Por ejemplo, nuestros socios en communiteq ofrecen un servicio para ello en https://www.forcewww.com/

[Paul_King]

@Falco

En realidad no es un “alias”, sino una redirección. Y necesitas configurar correctamente una redirección, lo cual incluye tener un certificado en vigor para el lugar donde reside la redirección.

Hasta hace poco, esto nunca había sido un problema: no había advertencia de Facebook ni advertencias de certificado, tanto con como sin www.

¿Existe alguna forma de que el certificado gratuito predeterminado de Let’s Encrypt certifique ambas opciones? No quiero complicar las cosas gestionando certificados adicionales ni incurriendo en costos extra.

Hay muchos correos electrónicos con enlaces al sitio que incluyen el www.

¿Al decir “el lugar donde reside la redirección” te refieres a Digital Ocean en este caso? (mi proveedor de alojamiento y desde donde se gestionan la configuración de DNS).

[JammyDodger]

@Paul_King

¿Hay alguna manera de que el certificado gratuito predeterminado de Let’s Encrypt certifique ambas opciones? No quiero complicar las cosas con certificados adicionales que gestionar ni con costos extra.

Puedes agregar una o dos líneas adicionales a tu archivo app.yml. Esto funcionó para mí cuando tenía problemas:

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]

Gracias, eso parece prometedor.

En mi caso, si https://nzarchitecture.net es el dominio base, ¿serían correctas las siguientes líneas para agregar?

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

¿Y tengo que reconstruir Discourse para que esto surta efecto?

[Simon_Manning]

El contenido es correcto, pero la sangría es importante en el archivo yml, por lo que debe corregirse:

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

Deberás reconstruir para que los cambios surtan efecto.

Edición: En realidad, parece que el uso de --keylength ha sido reemplazado por -k, por lo que necesitarás lo siguiente en su lugar:
Disculpas, mi búsqueda en Github me llevó a un fork antiguo sin que yo me diera cuenta. --keylength es correcto.

[Paul_King]

¡Fantástico! Muchas gracias por tu ayuda @Simon_Manning y a todos; ese redireccionamiento a través de app.yml funcionó de maravilla.