Activar HTTPS para el panel de ZimaOS no proporciona automáticamente a Jellyfin, Vaultwarden, Nginx Proxy Manager ni a ninguna otra aplicación de Docker una dirección HTTPS. Ese malentendido fue precisamente lo que dio inicio a este hilo de febrero de 2026. El usuario había activado HTTPS en los ajustes de ZimaOS, guardado el certificado generado para la interfaz de ZimaOS e intentado importarlo en Nginx Proxy Manager, pero Jellyfin y NPM seguían sin comportarse como esperaba.
El hilo finalmente llegó a una configuración funcional de la comunidad: usar Nginx Proxy Manager como punto de terminación TLS para aplicaciones individuales, alejar la puerta de enlace de ZimaOS de los puertos 80 y 443 si el proxy inverso necesitaba esos puertos, configurar un nombre de host mediante DuckDNS y emitir un certificado para ese nombre de host. Posteriormente, el usuario original publicó una captura de pantalla en la que se mostraban los hosts proxy en línea y resumió el resultado indicando que funcionaba.
Comprende las tres capas independientes de HTTPS
Hay tres elementos diferentes que se confunden fácilmente:
- HTTPS del panel de ZimaOS protege la propia interfaz de administración de ZimaOS.
- HTTP de la aplicación es el puerto interno normal que utiliza una aplicación como Jellyfin.
- HTTPS del proxy inverso es un nombre de host público o local que termina TLS y reenvía el tráfico al puerto HTTP interno de la aplicación.
Por lo tanto, el certificado generado para la interfaz de administración de ZimaOS no es un certificado universal para todas las aplicaciones. Un proxy inverso necesita un certificado cuyo nombre de host coincida con la dirección que los usuarios abren realmente en el navegador.
Usa Nginx Proxy Manager como puerta de entrada HTTPS
La parte más reutilizable de la solución de la comunidad es la arquitectura, no los números de puerto exactos de 2026. Nginx Proxy Manager recibe solicitudes HTTPS para nombres de host como jellyfin.example.net y las reenvía al servicio HTTP local de Jellyfin. Jellyfin puede seguir escuchando en su puerto interno habitual; no necesita administrar directamente el certificado público.
La versión actual de Nginx Proxy Manager mantiene este modelo: crea un host proxy, especifica el host y el puerto de destino, y después asocia un certificado SSL y, opcionalmente, fuerza SSL. Para una configuración nueva, sigue el flujo actual de Nginx Proxy Manager para hosts proxy y certificados en lugar de tratar una captura antigua como una descripción fija de la interfaz.
Resuelve los conflictos de los puertos 80 y 443 antes de emitir certificados
El usuario original descubrió que la puerta de enlace de ZimaOS ya utilizaba los puertos 80 y 443. Esto es importante porque normalmente un proxy inverso quiere escuchar en esos puertos estándar. Su solución fue cambiar los puertos de la puerta de enlace de ZimaOS en /etc/casaos/gateway.ini, trasladando el 80 al 85 y el 443 al 444, y después reiniciar el servicio de la puerta de enlace.
Esas modificaciones exactas procedían del usuario, no de una respuesta del soporte de IceWhale en este hilo. Deben considerarse una solución histórica de la comunidad, no una secuencia de comandos universal. Antes de cambiar los puertos del panel, anota la URL actual, asegúrate de saber cómo acceder a ZimaOS después del cambio y da prioridad a la interfaz actual de ZimaOS cuando ofrezca una forma compatible de cambiar el puerto de administración.
Por qué DuckDNS ayudó al usuario original
Una autoridad certificadora necesita un nombre de host que pueda validar. El usuario configuró DuckDNS y después utilizó ese nombre de host para solicitar un certificado mediante Nginx Proxy Manager. Esto resolvió un problema diferente de «¿cómo accedo a la aplicación?»: el DNS proporcionó el nombre, mientras que NPM proporcionó la terminación HTTPS y el reenvío.
El HTTPS solo local también necesita un DNS que resuelva localmente
La pregunta original se refería específicamente al HTTPS dentro de la red local, no al acceso remoto. Un nombre de dominio no obliga al tráfico a salir de casa. Puedes hacer que un nombre de host se resuelva en la dirección LAN de ZimaOS dentro de tu red mediante DNS local o DNS dividido, y después dejar que Nginx Proxy Manager proporcione un certificado de confianza para ese nombre de host.
Esto suele ser más limpio que navegar a una IP privada sin formato e intentar conseguir que un certificado público coincida con ella. El certificado se valida para el nombre de host; tu DNS local decide que el nombre de host debe resolverse en una dirección privada.
Un certificado autofirmado es otra opción, pero debes gestionar la confianza
Una respuesta de la comunidad sugirió generar un certificado con OpenSSL e importarlo en Nginx Proxy Manager. Esto puede funcionar para un uso exclusivamente local, pero los navegadores y dispositivos no confiarán automáticamente en un certificado autofirmado. Todos los clientes que deban mostrar una conexión HTTPS limpia necesitan confiar en el certificado emisor o en la CA local.
Para un hogar con muchos teléfonos, televisores, tabletas y aplicaciones, utilizar un certificado reconocido públicamente para un nombre de host suele ser más sencillo que instalar manualmente una CA local en todos los dispositivos.
Cloudflare es una arquitectura alternativa, no un requisito
Otro participante dijo que utilizaba Cloudflare tanto dentro como fuera de la red doméstica. Cloudflare puede ser útil si el mismo nombre de host debe funcionar de forma remota, pero la pregunta original no requería acceso público. No añadas un túnel simplemente porque quieras HTTPS en la LAN.
Verifica cada capa por separado
- Confirma que la aplicación se abre mediante su dirección HTTP local directa.
- Confirma que el nombre de host se resuelve en el proxy inverso previsto.
- Confirma que Nginx Proxy Manager puede comunicarse con el host y el puerto internos de la aplicación.
- Asocia el certificado solo después de que el enrutamiento proxy sin cifrado funcione.
- Después, fuerza HTTPS y prueba desde más de un cliente local.
Este orden evita confundir un problema del certificado con un problema de enrutamiento de Docker o un conflicto de puertos.
Preguntas frecuentes sobre el HTTPS local en ZimaOS
¿El interruptor de HTTPS de ZimaOS protege automáticamente Jellyfin?
No. Protege la interfaz de administración de ZimaOS, no todas las aplicaciones de Docker.
¿Necesito un dominio público para usar HTTPS solo en la LAN?
Necesitas un nombre de host que coincida con tu certificado. Ese nombre de host puede resolverse en una dirección privada de la LAN dentro de tu red.
¿Por qué el usuario original alejó ZimaOS de los puertos 80 y 443?
Nginx Proxy Manager necesitaba los puertos HTTP y HTTPS estándar. El cambio fue una solución de la comunidad para esa instalación.
¿Se confirmó que la configuración original funcionaba?
Sí. El autor original mostró los hosts de NPM en línea con certificados y dijo que la configuración funcionaba.
