Como você pode ver na captura de tela, consegui “instalar” o Discourse. Mas não consigo atribuir um certificado SSL válido.
Para constar, estou roteando isso através do meu Synology NAS com um proxy reverso elevando a porta 89 para 443 com websocket e as portas 89 e 449 (mapeadas para 80 e 443, respectivamente, em app.yml).
Pelo que pude apurar, fiz tudo o que deveria para configurar tudo. Tenho um certificado apontado para subdomain.domain.com, mas ele ainda resolve para domain.com.
Não entendo completamente sua situação atual, você está executando o Discourse atrás de um proxy? Se sim, provavelmente você só precisa expor a porta 80 e deixar seu servidor proxy lidar com https/ssl.
Isso significa que você está implantando o Discourse em nuvem privada/on-premise? Se a resposta for sim, então um problema comum é tentar acessar o site na LAN vs WAN, se esta for a sua causa e acessar o site de outra rede parecer normal ou seja, apenas tente acessar o site na sua rede móvel então verifique isto ref .
Como está configurado, pelo Discourse? Se não for pelo Discourse, então provavelmente você só precisa expor a porta 80.
Peço desculpas por não ter fornecido o esclarecimento necessário.
Estou usando um proxy reverso para rotear o endereço IP 192.168.1.XXX para um subdomínio, ou seja, discourse.mydomain.com, então, em resumo, sim, está on-premise.
Atualmente, está inacessível via LAN ou WAN (celular).
Após executar sudo netstat -tlnp | grep LISTEN, vejo as portas 89 e 449 listadas, mas acessar o IP local, por exemplo, 192.168.1.XXX:449 (ou 89), não funciona.
E, claro, o proxy reverso (do Synology NAS) não ajuda, então o subdomínio que configurei é um beco sem saída.
Para total clareza, a máquina em que estou tentando hospedar o Discourse é uma VM hospedada em uma máquina com XCPNG. O sistema operacional da VM é o Ubuntu Server mais recente (CLIN).
Hummm, se eu entendi corretamente, o 192.168.1.XXX é o seu endereço IP privado na LAN, e você provavelmente tem um endereço IP público, que seu provedor de internet lhe dá. Então, apenas para esclarecer, em seu registro DNS você deve ter seu endereço IP público configurado para apontar para seu subdomínio, não seu endereço IP privado (na LAN), e secundariamente seu roteador pode precisar ser configurado para permitir o tráfego de entrada e roteá-lo para seu IP privado 192.168.1.XXX. E seu provedor de internet deve permitir o tráfego de entrada
Alternativamente, você pode simplesmente tunelar seu tráfego local para um servidor remoto para que você não precise mexer nas configurações do seu roteador ou pensar se seu provedor de internet permite tráfego de entrada.
Então, qual é o seu caso, tunelar tráfego ou permitir tráfego de entrada via NAT ou DMZ?
