Espere… acho que entendi… desativei o proxy e reconstruí sem o modelo do Cloudflare. Ativei o proxy novamente depois e consigo acessar o WordPress e o fórum com SSL estrito!
Você seria limitado por taxa muito facilmente se escolhesse não usar o modelo do Cloudflare…
O Discourse achará que muitas pessoas estão se registrando pelo mesmo IP (proxy do Cloudflare) e começará a limitar a taxa deles.
Hmm… então é melhor fazer de novo sem o e-mail do Let’s Encrypt, mas com o modelo do Cloudflare… você sabe se devo deixar o proxy ativado ao reconstruir com o modelo do Cloudflare?
Muito obrigado por toda a ajuda… eu sou realmente mais da área criativa.
É o meu registrador, não apenas o DNS… e não posso pagar a quantia enorme que eles exigem para que eu use um DNS diferente. Então, opa.
A configuração do Discourse não exige mais um e-mail para inscrever certificados, e não exige há algum tempo. A menos que você altere o arquivo yml para desabilitar o SSL, ele sempre usará HTTPS por padrão.
Usar o Cloudflare para DNS e ativar a nuvem laranja são coisas totalmente diferentes. Usar o Cloudflare no contexto acima refere-se ao proxy e às otimizações deles, que já causaram problemas no passado. O DNS deles é bom, até excelente.
Sua instalação do Discourse não precisa mudar; você já tem o HTTPS funcionando e tudo está correto. Se o SSL funciona e o modelo do CloudFlare está ativado, não mexa nele.
Parece que o problema agora está no WordPress. Como você o instalou? É apenas um VPS ou você está em algum tipo de hospedagem WordPress?
Essa é uma configuração muito comum; tenho bastante certeza de que é um reparo simples.
Essa é uma Very Bad Idea (Muito Má Ideia). Uma vez que o Discourse tenha inscrito o certificado no Let’s Encrypt, as renovações serão bem-sucedidas, pois ocorrem por meio de um mecanismo diferente. Não há necessidade de desabilitar o TLS entre o servidor e a CDN.
Por que fazer isso, considerando o que foi dito acima? Além de criar uma carga adicional de processamento local com regras do UFW para todo o tráfego, você corre o risco de que suas regras fiquem desatualizadas; é uma maneira rápida de gerar vários erros de rede. O Cloudflare periodicamente traz novos intervalos de IP online; a primeira coisa que você saberá será quando seus usuários não conseguirem acessar o site. Deixe o certificado ser inscrito e, se quiser usar o CloudFlare, ajuste uma regra de página de acordo.
Eu uso o Cloudflare no modo apenas DNS, é muito simples. Basta clicar e desativar a “nuvem laranja” no seu painel de controle do DNS, para que a nuvem fique cinza em vez disso. Isso é tudo o que você precisa fazer.
Isso não funciona mais como antes. Se você não quiser usar o Let’s Encrypt, precisará configurar manualmente em vez de usar o discourse-setup.
Então, qual certificado o Discourse receberia na ausência de um e-mail do Let’s Encrypt? Um gerado automaticamente ou um certificado emitido com um e-mail arbitrário?
Em qualquer dos casos, ainda deve funcionar perfeitamente com o SSL do Cloudflare, pois eles permitem hosts com certificado válido em sua configuração SSL completa e superior.
Você precisará verificar o código-fonte, pois não me lembro exatamente. Acredito que ele use o e-mail de administrador. Se a verificação de disponibilidade do servidor na porta 443 falhar, ele se recusará a instalar.
Posso estar completamente errado aqui, mas pelo que vejo no código:
read_config "LETSENCRYPT_ACCOUNT_EMAIL"
local letsencrypt_account_email=$read_config_result
if [ -z $letsencrypt_account_email ]
then
letsencrypt_account_email="me@example.com"
fi
if [ "$letsencrypt_account_email" = "me@example.com" ]
then
local letsencrypt_status="ENTER para pular"
else
local letsencrypt_status="Digite 'OFF' para desativar."
fi
Parece que a verificação da configuração padrão deveria oferecer a opção de digitar “OFF” para desativar o Let’s Encrypt? Talvez eu esteja totalmente errado e olhando para o lugar errado?
Desativar o Let’s Encrypt não é a solução.
Em uma instalação padrão, não é.
Em uma instalação avançada (por exemplo, alguém usando um proxy reverso), é totalmente uma resposta.
Você poderia elaborar o motivo?
É fácil fazer o cenário de certificado funcionar. Mesmo que você opere um segundo servidor web no mesmo servidor e faça o proxy localmente, é fácil fazer o certificado funcionar, então por que não faria isso?
Por que eu solicitaria múltiplos certificados?
Quando posso simplesmente solicitar um único certificado (unificado) do Let’s Encrypt através do proxy reverso (por exemplo, nginx/caddy), por que eu desejaria um segundo certificado dentro do contêiner do Discourse, se ele nem será usado por nada?
Acho que a resposta geral é evitar completamente a complexidade do proxy, se possível 
Mas isso é inevitável assim que você começa a analisar uma implantação além da configuração padrão de um ou dois contêineres.
Seu fórum precisa ficar realmente muito grande para precisar de algo como o proxy da Cloudflare. É algo a considerar quando seu fórum começar a ficar sobrecarregado. A menos que você esteja migrando um fórum grande para o Discourse, ninguém que está instalando o Discourse deve pensar nisso.
Eu realmente não concordo, configurar o HTTPS corretamente é simples. Neste caso, o usuário tem dois sites em dois servidores diferentes sob um único domínio.
Não há nenhuma razão técnica que impeça ambos os sites de servirem conteúdo via HTTPS, independentemente de o CloudFlare estar ativado ou não. É fácil fazer assim que você entender o método de emissão de certificados usado pelo Let’s Encrypt e como configurar o CloudFlare para o Discourse. O CloudFlare possui um modo HTTPS completo, criado exatamente para este cenário: TLS do servidor até a rede deles, TLS da rede deles até os clientes, com decodificação no meio para que possam fazer cache e ‘otimizar’, embora, no caso do Discourse, saibamos que essa última parte não funcione tão bem.
Principalmente isso, embora haja definitivamente benefício em ter uma regra de página fazendo cache de /uploads/ — isso ajudará a aliviar a carga por um tempo e fará um VPS de baixo desempenho durar um pouco mais.