Não existe um switch HTTPS global confirmado para todas as aplicações
O tópico da comunidade não identificou nenhum botão no ZimaOS que forneça automaticamente um endpoint HTTPS válido a todas as aplicações instaladas. Cada aplicação pode escutar numa porta diferente, utilizar funcionalidades Web distintas e exigir regras de encaminhamento próprias.
O utilizador acedia ao armazenamento através de um domínio e de um IP público estático, mas continuava a receber um aviso de ligação insegura. Um nome de domínio, por si só, não cria TLS. O navegador tem de chegar a um endpoint que apresente um certificado válido para esse nome de anfitrião.
Comece por listar cada aplicação, a respetiva porta interna, o nome de anfitrião que pretende utilizar e se o acesso será apenas local, remoto privado ou através da Internet pública. Esse âmbito determina o desenho de entrada adequado.
Escolha um modelo de entrada para o objetivo de acesso real
Um proxy inverso pode terminar o TLS na porta 443 e encaminhar diferentes nomes de anfitrião para portas internas distintas das aplicações. Isto é adequado a um desenho baseado em domínios, no qual uma única interface controlada disponibiliza várias aplicações.
Um túnel gerido pode fornecer um ponto de entrada HTTPS sem encaminhar diretamente todas as portas das aplicações a partir do router. Uma rede privada sobreposta, como o Tailscale, resolve um problema diferente: os dispositivos autenticados entram numa rede privada e podem aceder aos serviços sem os tornar geralmente públicos.
Escolha um modelo antes de configurar os certificados. Combinar encaminhamento direto de portas, um túnel e uma rede sobreposta sem uma razão definida aumenta o número de caminhos que têm de ser protegidos e depurados.
Os certificados pertencem ao ponto de terminação TLS
Um certificado Let's Encrypt pode ser utilizado por um proxy inverso ou por outro serviço que controle a ligação HTTPS. Não é instalado “no domínio”, e obtê-lo não ensina automaticamente todas as aplicações de backend a utilizá-lo.
Aponte um nome de anfitrião para o proxy ou túnel escolhido, emita ou associe aí o certificado e encaminhe esse nome de anfitrião para uma aplicação interna. Mantenha a porta de backend privada, salvo se a arquitetura exigir especificamente acesso direto.
Se o navegador apresentar um aviso, verifique o nome de anfitrião no certificado, o destino DNS, a cadeia de certificados e o componente que está efetivamente a responder na porta 443. Não ignore o aviso como solução permanente.
Valide uma aplicação antes de repetir o padrão
Teste o início de sessão, os carregamentos, as transferências, as atualizações em tempo real e todas as funcionalidades que dependam de WebSockets através do nome de anfitrião HTTPS. Uma página que carrega, mas não consegue carregar ficheiros ou manter uma sessão, não está totalmente configurada.
Reinicie o proxy ou túnel e a aplicação de destino e, em seguida, repita o mesmo fluxo de trabalho. Confirme que o HTTP é redirecionado apenas quando pretendido e que as portas de backend diretas não estão inadvertidamente expostas à Internet.
Quando uma aplicação funcionar, repita o mapeamento entre o nome de anfitrião e o backend para a aplicação seguinte. Se um serviço tiver requisitos especiais de proxy, reverta apenas a rota com problemas, em vez de desmontar os endpoints HTTPS que já funcionam.
O HTTPS remoto não substitui o controlo de acesso
O TLS cifra o tráfego e autentica o nome de anfitrião, mas não decide quem deve utilizar a aplicação. Mantenha uma autenticação forte nas aplicações, uma exposição limitada, as atualizações e os registos de auditoria.
O tópico recomenda pesquisar o Cloudflare Tunnels, o Tailscale ou um proxy inverso como o Caddy, mas não documenta uma implementação concluída. Estas são orientações de arquitetura, não uma receita passo a passo do ZimaOS confirmada pela fonte.
Pare antes de expor o serviço publicamente se o método escolhido, a gestão do certificado ou o limite de autenticação não forem claros. Valide primeiro num serviço não crítico ou utilize acesso remoto privado enquanto desenha o percurso público.
Perguntas frequentes
Um único certificado pode proteger automaticamente todas as aplicações do ZimaOS?
Não, por si só. Um proxy ou outro endpoint TLS continua a precisar de um nome de anfitrião e de uma regra de encaminhamento para cada serviço de backend.
Tenho de expor a porta de cada aplicação para utilizar HTTPS remotamente?
Não necessariamente. Os proxies inversos e os túneis geridos foram concebidos para centralizar a entrada, enquanto as redes sobrepostas privadas evitam a exposição pública geral.
O Tailscale é o mesmo que um proxy inverso?
Não. O Tailscale cria conectividade de rede privada entre dispositivos autorizados; um proxy inverso aceita pedidos Web e encaminha os nomes de anfitrião para os serviços de backend.
