Login do Facebook sinalizado como não compatível pelo Facebook após mudança para o sistema de certificados Let's Encrypt

[Paul_King]

Desde por volta de 30 de setembro de 2021 (até onde pude constatar), meu site tem gerado erros de certificado:

Sua conexão não é privada
Aviso de segurança “NET::ERR_CERT_COMMON_NAME_INVALID”.

Este servidor não pôde provar que é www.nzarchitecture.net.nz; seu certificado de segurança é de nzarchitecture.net.nz. Isso pode ser causado por uma configuração incorreta ou por um invasor interceptando sua conexão.

Esse problema pode estar relacionado às alterações implementadas pela Let’s Encrypt naquela data.
O erro ocorre ao acessar a URL https://www.nzarchitecture.net.nz, mas não ao acessar https://nzarchitecture.net.nz.

O problema persiste mesmo após a atualização para a versão 2.8.0 beta 7 e a reconstrução completa do site.

Uma consequência da exibição dessa mensagem de erro na página inicial é que o site passou a ser sinalizado como não atendendo mais aos requisitos do Facebook, o que resultou na desativação do login via Facebook pela própria plataforma.

[IAmGav (Gavin Perch)]

É um problema do Facebook que eles precisam resolver.

O certificado é 100% legítimo.

SSL Checker

[anon73664359]

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

[Paul_King]

O problema é que, mesmo eu, vejo esses erros ao incluir ‘www’ na URL que colo/digito no navegador. Portanto, embora não haja risco real, os usuários estão recebendo avisos preocupantes, com ou sem a questão de conformidade do Facebook.

Enquanto isso, o Facebook se recusa a revisar o assunto até que o erro desapareça.

[IAmGav (Gavin Perch)]

no seu arquivo de configuração

/var/discourse/containers/app.yml

para que valor está definido o DISCOURSE_HOSTNAME:?

[Falco]

@Paul_King

O problema é acionado quando a URL https://www.nzarchitecture.net.nz é usada, mas não quando https://nzarchitecture.net.nz é usada.

Se o seu site real estiver no domínio sem “www”, você deve registrar o domínio sem “www” no sistema do Facebook. Não é possível misturar os dois.

[Paul_King]

app.yml mostra

DISCOURSE_HOSTNAME: nzarchitecture.net.nz

[Paul_King]

@Falco

Se o seu site real estiver no domínio sem o www, você deve registrar o domínio sem o www no sistema do Facebook. Não é possível misturar os dois.

Ok, suponho que isso faça sentido — mas, do ponto de vista do DNS, um é um alias do outro (ou pelo menos era o que eu acreditava). Além disso, será difícil explicar ao usuário comum que ele não pode usar o ‘www’, especialmente se ele precisar fazer login para ver algum aviso nesse sentido…

[Falco]

Não é exatamente um “alias”, mas sim um redirecionamento. E você precisa configurar corretamente um redirecionamento, o que inclui ter um certificado válido para o local onde o redirecionamento está hospedado.

Por exemplo, nossos parceiros da communiteq oferecem um serviço para isso em https://www.forcewww.com/

[Paul_King]

@Falco

Não é exatamente um “alias”, mas sim um redirecionamento. E você precisa configurar corretamente o redirecionamento, o que inclui ter um certificado válido para o local onde o redirecionamento ocorre.

Até recentemente, isso nunca foi um problema — nenhum aviso do Facebook e nenhum aviso de certificado, com ou sem o www.

Existe alguma maneira de fazer o certificado gratuito padrão do Let’s Encrypt abranger ambas as opções? Estou muito interessado em não complicar as coisas com certificados extras para gerenciar e custos adicionais.

Há muitos e-mails por aí com links para o site que incluem o www.

Ao dizer “o local onde o redirecionamento ocorre”, você está se referindo ao Digital Ocean neste caso? (meu provedor de hospedagem, e onde as configurações de DNS são gerenciadas)

[JammyDodger]

@Paul_King

Existe alguma maneira de obter o certificado gratuito padrão do Let’s Encrypt para certificar ambas as opções? Estou bastante interessado em não complicar as coisas com certificados extras para gerenciar e custos adicionais.

Você pode adicionar uma ou duas linhas extras ao seu app.yml. Isso funcionou para mim quando eu estava tendo 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]

Obrigado – isso parece promissor

No meu caso, se https://nzarchitecture.net for o domínio base, seriam as linhas corretas a adicionar as abaixo?

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

E preciso reconstruir o Discourse para que isso surta efeito?

[Simon_Manning]

O conteúdo está correto, mas a indentação é importante no arquivo yml, então isso precisa ser corrigido:

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

Você precisará reconstruir para que as alterações surtam efeito.

Edição: Na verdade, parece que o uso de --keylength foi substituído por -k, então você precisará do seguinte em vez disso:
Peço desculpas; minha pesquisa no Github me levou a um fork antigo sem que eu percebesse. --keylength está correto.

[Paul_King]

Fantástico! Muito obrigado pela sua ajuda, @Simon_Manning, e a todos — esse redirecionamento via app.yml funcionou perfeitamente.