Avatares, logotipos de site e erros de certificado

Aqui está um link para uma das instâncias:
https://discourse.mobiusnode.io

Ela está desligada. X-Forwarded-Proto está no meu bloco de servidor. Portanto, o único elemento(s) que não estou utilizando — com base nos links que todos vocês compartilharam — é este:

# modelos base utilizados; pode reduzir para incluir menos funcionalidade por modelos de container:
# - "templates/cron.template.yml" # cron agora está incluído na imagem base
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # remover - https será tratado pelo nginx externo
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- Adicionado
# quais portas expor?
# expose: comente toda a seção

Carreguei o site em 3 navegadores (Edge, Firefox e Chrome Mobile) e recebi um certificado perfeitamente válido como anônimo. Quais são os seus passos para reproduzir isso?

Cadastre-se como usuário. Após o cadastro e login, tudo desanda e aparecem os erros mencionados anteriormente.

Ok, vou me cadastrar como um usuário falso pelo Firefox agora mesmo.

Seus e-mails nunca chegam à minha caixa de entrada. Já tentei reenviar, mas sem sucesso. Vocês estão ativando as contas manualmente aqui?

Não. Provavelmente foram para a Lixeira ou Spam. Não houve reclamações de nenhum usuário sobre isso.

O inferno não se soltou aqui. Um problema potencial é que seus e-mails ainda contêm o link http://. No entanto, fui redirecionado corretamente para o site HTTPS para ativar minha conta e não vejo nenhum erro relacionado ao SSL aqui.

Então, sim, tenho 99% de certeza de que seu force_https não está ativado ou algo está muito, muito errado na sua instalação, causando isso.

Eu tenho um redirecionamento no meu bloco de servidor, então não importa qual link é mostrado lá. Ele sempre será redirecionado para https.

É aí que você está errado. Se o “force https” estiver habilitado, o Discourse deve enviar todos os links como https. Cada link relacionado ao fórum deve ser carregado via https. Se você ainda está fazendo coisas estranhas e não seguindo o método sugerido, está por conta própria. Não podemos ajudar além dos procedimentos padrão que funcionam.

Isso não faz muito sentido para mim. Se analisarmos logicamente, estou essencialmente fazendo exatamente o que o force-https é destinado a fazer, mas dentro do bloco do servidor.

Além disso, ao ativar force-https, meu site para de funcionar e os usuários não conseguem autenticar.

force_https não é apenas uma reescrita. Ele faz mais do que isso internamente. Se você deseja que seus problemas sejam resolvidos, uma solução já foi fornecida. Se você rejeitar a solução, sinta-se à vontade para assumir as próprias responsabilidades e explorar novas alternativas.

Isso ocorre por causa do seu proxy reverso instável. Você terá que descobrir o que está errado e fazer as coisas da maneira correta. Não podemos fornecer assistência com suas próprias soluções.

Todas as “soluções” apresentadas não se encaixam no meu caso de uso específico:

  • Servidor remoto (na mesma rede) — Acredito que todos os exemplos assumem que o Nginx está rodando no mesmo servidor que o Discourse. Estou usando proxy_pass para acessar outro IP interno.

Por que fiz isso? Maior segurança e dispersão de recursos. É a mesma razão pela qual dividi os serviços de duas formas: por container e por VM. A documentação sugerida parece favorecer um cenário em que todos os serviços estão rodando no mesmo servidor.

Imagino que as condições descritas acima sejam bastante comuns. Se alguma delas puder ser usada para acomodar uma configuração de proxy_pass, ficarei mais do que feliz em ajustar minhas configurações conforme necessário. Apenas sinto que fornecer uma declaração genérica do tipo “você está por sua conta” porque estou tentando evitar o cenário de “colocar todos os ovos na mesma cesta” é um pouco injustificado.

proxy_pass 192.168.20.10:8080

no Discourse, exponha 192.168.20.10:8080:80

remova o template socketed.

habilite o force_https

Pronto.

Isso tem um monte de implicações além do que você acabou de escrever, que terei que investigar — poderíamos ter começado por aí. :wink:

Perguntas imediatas:

  1. No app.yml, alterar a porta de escuta padrão para 8080?
  2. E quanto ao SSL 443? Manter a 443?
  3. Remover o redirecionamento na porta 80 do bloco de servidor do Nginx?
  4. O item #3 importa se eu estiver apenas alterando o proxy_pass no lado interno? Provavelmente não? Estou apenas reencaminhando para a porta 8080?
  5. A maior pergunta: por quê? Por que isso faria diferença, mudar de 80 para 8080?
  6. Manter todos os outros Templates ativos? Apenas comentar o socketed?

Obrigado pela sua ajuda e paciência.

Essa é a sua preferência; eu escrevi como um exemplo. Você também pode optar por expor a porta 80.

Não há benefício ou sentido em ativar o SSL em uma rede local.

Isso precisa existir.

server {
    listen 80;
    server_name discourse.example.com;
    return 301 https://example.com$request_uri;
}

É exatamente isso que está acontecendo. Você está encaminhando todas as requisições recebidas pelo seu proxy/ingress para um backend interno na porta 8080 (ou seja, o Discourse).

Respondido no ponto #1: foi uma preferência pessoal. Sinta-se à vontade para usar a porta que preferir.

Você especialmente não precisa de nada relacionado a sockets ou SSL no servidor interno. O SSL deve ser adequadamente terminado no proxy reverso.

Nota: a maior parte disso é uma preferência pessoal baseada na implantação para clientes.

Ok. Obrigado pelos comentários.

Aqui está meu bloco de servidor Nginx, só para informação:

server {
# ssl
listen 443 ssl http2;
listen [::]:443 ssl http2;

   server_name discourse.mobiusnode.io;

   location / {
           #tráfego http
           proxy_pass http://192.168.86.108;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header Host $http_host;
           proxy_http_version 1.1;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto https;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection "upgrade";

   }

ssl on;
ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # gerenciado pelo Certbot
ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # gerenciado pelo Certbot

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

add_header Strict-Transport-Security "max-age=63072000;";
ssl_stapling on;
ssl_stapling_verify on;

client_max_body_size 0;

}

server {
if ($host = discourse.mobiusnode.io) {
return 301 https://$host$request_uri;
} # gerenciado pelo Certbot

listen 80;
listen [::]:80;

server_name discourse.mobiusnode.io;
return 404; # gerenciado pelo Certbot

}

O comportamento que estou experimentando ocorre sob as condições acima.

O início do app.yml se parece com isto:

## este é o modelo de contêiner Docker Discourse tudo-em-um, autônomo
##
## Após fazer alterações neste arquivo, você DEVE reconstruir
## /var/discourse/launcher rebuild app
##
## TENHA *MUITO* CUIDADO AO EDITAR!
## ARQUIVOS YAML SÃO SUPER SUPER SENSÍVEIS A ERROS EM ESPAÇOS EM BRANCO OU ALINHAMENTO!
## visite http://www.yamllint.com/ para validar este arquivo conforme necessário

templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Descomente estas duas linhas se desejar adicionar Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

## quais portas TCP/IP este contêiner deve expor?
## Se você quiser que o Discourse compartilhe uma porta com outro servidor web como Apache ou nginx,
## consulte https://meta.discourse.org/t/17247 para detalhes
expose:
- "80:80" # http
- "443:443" # https

params:
db_default_text_search_config: "pg_catalog.english"

## Defina db_shared_buffers para no máximo 25% da memória total.
## será definido automaticamente pelo bootstrap com base na RAM detectada, ou você pode substituir
db_shared_buffers: "1024MB"

## pode melhorar o desempenho de classificação, mas aumenta o uso de memória por conexão
#db_work_mem: "40MB"

## Qual revisão do Git este contêiner deve usar? (padrão: tests-passed)
#version: tests-passed

Você está se conectando à porta 80 no segundo nginx, então ele acha que você está se conectando via HTTP e não HTTPS.

Tente encontrar o X-Forwarded-Proto no nginx interno e altere proxy_set_header X-Forwarded-Proto $thescheme; para proxy_set_header X-Forwarded-Proto https;

ou encaminhe seu tráfego para HTTPS proxy_pass https://192.168.86.108

Esta parte precisa ser alterada