Se o seu navegador avisar que o painel do ZimaOS ou as aplicações estão “Não seguro”, comece por separar o painel principal do ZimaOS das aplicações executadas nas respetivas portas. A discussão de origem acabou por estabelecer que se trata de dois problemas HTTPS diferentes.
O ZimaOS pode gerar um certificado local para https://zimaos.local. Confiar nesse certificado pode remover o aviso do navegador relativo ao painel do ZimaOS. Isto não fornece automaticamente HTTPS ao Plex, Jellyfin, Emby, AdGuard ou a outras aplicações Docker, porque são serviços HTTP separados. Para colocar várias aplicações por trás de nomes HTTPS fidedignos, utilize um proxy inverso, como o Nginx Proxy Manager ou o Caddy, com certificados adequados.
O aviso original do navegador
Opção 1: Desativar o HTTPS do painel local do ZimaOS
Zima-Giorgio respondeu que o HTTPS podia ser desativado no painel Definições do ZimaOS. Numa LAN privada de confiança, o HTTP simples pode eliminar o incómodo dos avisos de certificado, mas também remove a encriptação do transporte entre o navegador e o painel.
Para computadores portáteis ou dispositivos que mudam de rede, confiar no certificado do ZimaOS é geralmente preferível a enfraquecer globalmente a segurança do navegador.
Opção 2: Descarregar e confiar no certificado local do ZimaOS
A resposta oficial recomendou descarregar o ficheiro CRT gerado e confiar nele no cliente. Depois de configurar a confiança, utilize:
https://zimaos.local
Confie no CRT do ZimaOS no Windows
A resposta original indicou este processo para Windows:
- Prima
Win + R. - Execute
certmgr.msc. - Abra Autoridades de certificação de raiz fidedignas → Certificados.
- Escolha Todas as tarefas → Importar.
- Selecione o CRT descarregado do seu próprio sistema ZimaOS.
- Coloque-o em Autoridades de certificação de raiz fidedignas.
- Reinicie o navegador.
Confie apenas num certificado obtido a partir da sua própria instância ZimaOS conhecida. Instalar um certificado raiz significa confiar nele para validar ligações nesse cliente.
Porque é que o certificado do ZimaOS não protege o Jellyfin, o Plex ou o Emby
Mais tarde, o autor original importou o certificado com sucesso no Pop!_OS e confirmou que zimaos.local funcionou, mas o Plex, o Emby e o Jellyfin continuavam a aparecer como não seguros.
Uma resposta de 2026 explicou porquê: essas aplicações escutam em serviços e portas separados. Os exemplos incluem:
Jellyfin: http://ZIMAOS_IP:8096
Plex: http://ZIMAOS_IP:32400
Não herdam automaticamente o certificado do painel do ZimaOS. Esse comportamento é esperado e não é prova de que a importação do CRT tenha falhado.
Utilize um proxy inverso para HTTPS em várias aplicações
Para dar às aplicações nomes como:
https://jellyfin.example.com
https://emby.example.com
https://adguard.example.com
colocar um proxy inverso à frente delas. O proxy trata dos certificados TLS e, em seguida, encaminha cada pedido para a porta HTTP interna da aplicação.
O Nginx Proxy Manager está atualmente disponível na loja de aplicações do ZimaOS:
Nginx Proxy Manager para ZimaOS
Porque é que o Nginx Proxy Manager indica que as portas 80 ou 443 já estão a ser utilizadas
O autor da fonte tentou instalar um proxy e deparou-se imediatamente com um conflito de portas. A documentação atual do Nginx Proxy Manager prevê estas portas padrão:
80 → HTTP público
443 → HTTPS público
81 → interface de administração do NPM
Se o ZimaOS já possuir as portas 80 ou 443 do anfitrião, o NPM não pode associar-se simultaneamente à mesma porta do anfitrião.
Configuração oficial do Nginx Proxy Manager
A porta 81 não é o destino HTTPS público
Mais tarde, outro utilizador no mesmo tópico encaminhou as portas 80 e 443 do router para a porta interna 81. A comunidade corrigiu-o:
Router 80 → porta 80 do NPM
Router 443 → porta 443 do NPM
Porta 81 é a interface de administração do NPM. Não deve receber tráfego normal de sites públicos.
Desafio HTTP vs. desafio DNS
O tópico também distinguiu dois métodos de validação do Let's Encrypt:
- Desafio HTTP: normalmente requer que a autoridade de certificação consiga aceder ao proxy através da porta 80.
- Desafio DNS: valida o controlo do domínio através dos registos da API do fornecedor de DNS e pode evitar a validação através da porta de entrada 80.
Escolha deliberadamente um método. Não combine definições das duas abordagens sem compreender qual o processo de validação que o NPM está a utilizar.
Precisa do MySQL apenas para executar o Nginx Proxy Manager?
Não. A configuração atual do Nginx Proxy Manager suporta SQLite para uma instalação simples num único contentor. Uma base de dados externa MySQL/MariaDB/PostgreSQL é opcional.
Isso corrige outra preocupação levantada no tópico original: um principiante não precisa de implementar o MySQL apenas para começar a encaminhar alguns serviços domésticos através de um proxy inverso.
Alterar a porta Web do ZimaOS tem uma contrapartida
Mais tarde no tópico, um utilizador afastou o ZimaOS da porta 80 e conseguiu então instalar o Nginx Proxy Manager. No entanto, relatórios comunitários separados de 2026 indicam que alterar a porta do painel do ZimaOS pode interferir com o comportamento do cliente de computador/telemóvel do Zima.
Por isso, “mover o ZimaOS para fora da porta 80” não é uma solução universal isenta de riscos. Antes de a alterar, decida o que é mais importante no seu ambiente:
- posse padrão das portas 80/443 por um proxy inverso;
- ou preservar o comportamento predefinido do cliente/descoberta do ZimaOS.
HTTPS apenas local vs. HTTPS público
Se apenas utiliza aplicações dentro de casa:
- pode manter HTTP direto numa LAN de confiança;
- utilize certificados considerados fidedignos localmente;
- ou execute um proxy inverso interno e DNS interno.
Se quiser HTTPS acessível a partir da Internet, utilize um domínio, autenticação forte, certificados emitidos corretamente e um plano deliberado de acesso remoto e segurança. Não exponha portas de administração de aplicações nem a interface de administração do NPM apenas para fazer aparecer o cadeado do navegador.
Lista de verificação do HTTPS do ZimaOS
- Determine se o aviso diz respeito a
zimaos.localou uma aplicação separada. - Para o painel do ZimaOS, transfira e considere fidedigno o CRT gerado se quiser HTTPS local sem avisos.
- Utilize
https://zimaos.localdepois de o certificado ser considerado fidedigno. - Não espere que o CRT do ZimaOS proteja portas de aplicações separadas.
- Utilize um proxy inverso para nomes de anfitrião HTTPS em várias aplicações.
- Confirme que serviço é proprietário das portas 80 e 443 antes de instalar o NPM.
- Mantenha a porta 81 do NPM para administração, não para encaminhar sites públicos.
- Escolha a validação de certificados por HTTP ou por DNS, de acordo com a sua rede.
- Não exponha serviços de administração desnecessários à Internet pública.
Perguntas frequentes sobre HTTPS do ZimaOS
Porque é que zimaos.local é seguro, mas o Jellyfin continua em HTTP?
Porque o certificado do ZimaOS se aplica ao nome de anfitrião do painel. O Jellyfin é um serviço separado que escuta na sua própria porta.
Um único proxy inverso pode proteger todas as minhas aplicações ZimaOS?
Pode terminar HTTPS para vários serviços HTTP, desde que cada anfitrião proxy esteja configurado corretamente e o proxy consiga alcançar a aplicação de destino.
Porque é que o Nginx Proxy Manager não consegue iniciar na porta 443?
Outro serviço já está associado a essa porta do anfitrião. O tópico de origem deparou-se com isto quando o ZimaOS e o NPM competiam pelas portas Web padrão.
É na porta 81 que devo encaminhar tráfego HTTPS público?
Não. A porta 81 é a interface de administração do NPM. O tráfego público normal deve chegar às portas 80 e 443.
