Espero que alguém possa oferecer algum conselho; ficaria em dívida com você. Vou explicar a situação.
Configurei o Discourse várias vezes no meu domínio, hostballs[.]com. Cada vez que se acessa www[.]hostballs[.]com, ele redireciona corretamente para hostballs[.]com, pois o certificado do LetsEncrypt cobre tanto a versão com www quanto a sem. Esse é o comportamento padrão e comum que conheço do Discourse com sua implementação do LE.
Atualmente, minha nova instalação do Discourse está configurando o SSL apenas para o site sem www (conforme configurado na URL), mas não está cobrindo o www. Isso significa que qualquer pessoa que visite www[.]hostballs[.]com não será redirecionada, mas sim verá um erro de SSL. Considerando que sei que o comportamento padrão costuma ser diferente disso e que a instalação do Discourse é muito controlada para que eu queira simplesmente ir ao certbot e fazer tudo manualmente (isso não tornaria as atualizações regulares mais complicadas?), estou incerto sobre o melhor caminho a seguir.
Ao tentar resolver isso, comentei as seções ssl e LE, bem como o endereço de e-mail do LE, no app.yml. Em seguida, removi os diretórios letsencrypt e ssl de /shared/standalone. Recriei o site sem SSL, depois reativei essas opções no app.yml e recriei novamente para gerar novos certificados e configurações SSL. Embora isso tenha funcionado, o problema do www ainda não foi resolvido.
Alguém mais já lidou com uma situação semelhante e encontrou uma solução?
Se o conselho acima for intimidante, você também pode configurar um redirecionamento DNS simples. A maioria dos registradores oferece isso.
O Discourse não pode ser publicado em múltiplas URLs; o registro raiz (sem www) e o registro ‘A’ com www são endereços separados. Assim que você nomear um FQDN para seu site, qualquer endereço adicional precisará ser tratado com um redirecionamento.
Se você não gostar de nenhuma das sugestões já fornecidas, pode optar por usar www.example.com e utilizar http://forcewww.com/ para redirecionar ao site com www.
Obrigado, amigos. Deixe-me revisar alguns detalhes que podem ajudar alguém no futuro.
Isso começou porque um usuário me disse que visitar www não funcionava, gerando um erro de certificado. Ao acessar diretamente o link https que ele forneceu no tópico de relatórios, encontrei o mesmo problema. No passado, ao usar www, não enfrentei esse problema; em vez disso, era redirecionado para o domínio raiz sem complicações. Isso me levou à conclusão de que minha instalação, após uma migração recente, estava de alguma forma comprometida e não se comportava conforme as características padrão de uma nova instalação do Discourse.
Então, instalei uma cópia fresca do Discourse em um novo domínio para provar que www funcionava por padrão ao usar o domínio raiz. Acessei o domínio, editei o URL na barra de endereços e adicionei “www.” no início. Ele foi redirecionado para o domínio raiz sem problemas, como eu esperava. Depois, pensei em tentar mais uma coisa. Digitei manualmente “https://” antes dele. Então, falhou com o mesmo erro de certificado.
Portanto, o que pode ter me levado a assumir que a assinatura para www era o comportamento padrão na implementação do Let’s Encrypt do Discourse pode, na verdade, ter sido o meu navegador usando a porta 80 por padrão, enquanto ocultava a parte http/https do URL à medida que eu reescrevia o endereço na barra de endereços.
Essa é a minha melhor avaliação da situação, pelo menos.
A solução mais fácil para quem usa o domínio raiz e deseja que o www seja assinado pelo LE para um redirecionamento HTTPS adequado, sem complicar ou usar outro servidor web para gerenciar o redirecionamento:
É, não estou vendo uma maneira de fazer isso que não corra o risco de ser quebrada em atualizações. Isso parece ser o dilema de quem tem domínios dedicados para comunidades e não gosta de subdomínios desnecessários.
A menos, claro, que se execute outro servidor web em outro lugar.
Certo, já estou vendo uma tentativa que foi interrompida porque um arquivo mudou, quebrando a forma como eles estavam configurando a alteração no arquivo app.yml:
Seja editando um arquivo diretamente ou deixando o app.yml editá-lo depois, uma atualização tem o potencial de alterar esse arquivo e quebrar a maneira como você está editando, independentemente disso.
Meu ponto é que qualquer alteração nesse modelo vai quebrá-lo novamente. Apenas uma mudança quebrou o método PUPS/hooks nos últimos anos: a introdução do suporte a ECC.