HTTPS y certificados

Cuando una app en un dispositivo conectado expone una interfaz web, el appliance la hace alcanzable a través de su túnel integrado. Tú eliges cómo llegan los navegadores al appliance — hay tres modos, desde cero configuración hasta totalmente firmado por la empresa. Elige uno y sigue sus pasos.

No es lo mismo que Detrás de un proxy corporativo. Esa página trata sobre que el appliance confíe en tu CA corporativa para el tráfico saliente (appliance → nube, a través de un proxy que intercepta TLS). Esta página es la dirección opuesta — tráfico entrante desde los navegadores de tu red que alcanzan el appliance. Las dos son independientes.

Modo 1 — HTTP simple (predeterminado)

Qué obtienes. Todo por HTTP simple en la dirección del appliance:

Cada UI de app se publica en su propio puerto asignado automáticamente; la UI de IronFlock muestra el enlace exacto de cada una. Las UI de las apps permanecen detrás del inicio de sesión del appliance — abrir una redirige al inicio de sesión a menos que hayas iniciado sesión y estés autorizado para ese dispositivo (un puerto puede marcarse como público por app cuando quieras dejarlo abierto).

Qué tienes que hacer. Nada. Este es el modo predeterminado — solo usa la IP o el nombre de host del appliance en tu red local. Sin DNS, sin certificado, sin intervención de IT corporativo.

Cuándo usarlo. Un appliance en una red segmentada y de confianza — un armario de control en una VLAN de máquina/OT — donde el HTTP simple es la norma y el acceso se controla mediante segmentación de red y seguridad física.

Modo 2 — HTTPS con una CA autoemitida

Qué obtienes. El appliance activa su ingress HTTPS integrado y sirve todo por HTTPS bajo tu dominio — usando un certificado que genera él mismo. No hay ningún proxy inverso que ejecutar ni URL que reconfigurar; el instalador lo conecta todo.

Qué tienes que hacer.

1. Elige un dominio que resuelva al appliance para cada navegador y dispositivo que vaya a usarlo, y establece tanto APPLIANCE_HOST como APPLIANCE_DOMAIN con ese valor. Como el appliance emite el certificado él mismo, cualquier nombre sirve — el único requisito es que resuelva. Para cualquier uso más allá de una prueba rápida usa un dominio interno que controles (por ejemplo, appliance.corp.example.com) con un registro comodín en tu propio DNS: una red de appliance aislada o restringida por DNS normalmente no puede alcanzar el servicio público nip.io del que depende el nombre predeterminado <host-ip>.nip.io. (Ese predeterminado sí funciona cuando la red puede alcanzar internet — por eso funciona en una máquina de desarrollo).

2. Añade DNS comodín para el dominio, con ambos registros apuntando a la IP del host del appliance:

   • *.<APPLIANCE_DOMAIN> — cubre las UI de las apps y cada subdominio de servicio.
   • <APPLIANCE_DOMAIN> (ápice) — la UI principal por su nombre.

   (Un servicio de DNS comodín como nip.io ya resuelve esto automáticamente, así que no hay registros que añadir — pero depende de que ese servicio externo sea alcanzable).

3. Instala con --tls:

   curl -fsSL https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
     | sudo bash -s -- <your-instance-key> --interactive --tls

   --interactive solicita APPLIANCE_HOST / APPLIANCE_DOMAIN (o define IRONFLOCK_APPLIANCE_HOST / IRONFLOCK_APPLIANCE_DOMAIN para una instalación desatendida). El appliance genera una CA local en /opt/ironflock/certs/ca/rootCA.crt y un certificado comodín firmado por ella.

4. Distribuye la raíz de CA a las máquinas cliente. Envía rootCA.crt a través de tu MDM, o añádelo al almacén de confianza del sistema operativo/navegador de cada máquina. Hasta que una máquina confíe en ella, su navegador avisará.

5. Renueva antes de un año. El certificado del servidor está limitado a ~1 año — los navegadores rechazan los de vida más larga. Para renovar, elimina tls.crt/tls.key en el directorio del certificado y vuelve a ejecutar el instalador; vuelve a firmar un certificado nuevo contra la misma CA, de modo que la confianza que distribuiste sigue funcionando.

Los dispositivos permanecen en la ruta de IP simple. Solo el lado del navegador pasa a HTTPS. Los dispositivos conectados siguen alcanzando el appliance por su IP, así que no tienes que instalar la CA en cada dispositivo.

Cuándo usarlo. Quieres HTTPS en una red compartida pero no tienes (o no quieres esperar) un certificado de IT corporativo, y puedes distribuir una CA raíz a las máquinas que abrirán la UI.

Modo 3 — HTTPS con tu certificado corporativo

Qué obtienes. El mismo HTTPS de appliance completo que el Modo 2 — pero el certificado proviene de la CA de tu organización, cuya raíz ya es de confianza en cada máquina gestionada. Sin avisos del navegador, nada que distribuir. Los dispositivos también pasan al dominio.

Qué tienes que hacer.

1. Elige un dominio interno que controles y establece APPLIANCE_HOST y APPLIANCE_DOMAIN con ese valor (por ejemplo, appliance.corp.example.com). Aquí debe ser tu propio dominio — una CA solo emite certificados para dominios que posees, así que un nombre nip.io no funcionará en este modo.
2. Añade DNS comodín — *.<APPLIANCE_DOMAIN> y el ápice, apuntando a la IP del host del appliance — como en el Modo 2, paso 2.
3. Obtén un certificado comodín para *.<APPLIANCE_DOMAIN> de tu CA interna, como dos archivos PEM: tls.crt (idealmente con cadena completa) y una tls.key sin cifrar.
4. Instala con tu certificado:

   curl -fsSL https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
     | sudo bash -s -- <your-instance-key> --interactive \
         --tls-cert /path/to/wildcard.crt \
         --tls-key  /path/to/wildcard.key

   --tls-cert implica --tls. Variables de entorno equivalentes: IRONFLOCK_TLS_CERT / IRONFLOCK_TLS_KEY.
5. Rota según el calendario de tu CA. Coloca los nuevos archivos PEM en el directorio del certificado y reinicia:

   sudo cp wildcard.crt /opt/ironflock/certs/tls.crt
   sudo cp wildcard.key /opt/ironflock/certs/tls.key
   sudo chmod 0600 /opt/ironflock/certs/tls.key
   sudo systemctl restart ironflock.service

   El appliance recarga el certificado automáticamente cuando el archivo cambia; el reinicio solo lo aplica de inmediato. Volver a ejecutar el instalador nunca sobrescribe un certificado existente a menos que pases --tls-cert.

Los dispositivos también pasan al dominio. Como el certificado es de confianza en toda la flota, el tráfico de los dispositivos — el enlace del dispositivo y las descargas de imágenes de contenedor — también se ejecuta sobre el dominio vía TLS, y ya no se necesita el rodeo de insecure-registries.

Cuándo usarlo. La ruta corporativa on-prem estándar: tu organización ya opera una CA interna, así que se emite un certificado comodín una vez y es de confianza en todas partes sin configuración por máquina.

Resolución de problemas

Un enlace de UI de app no se abre / conexión rechazada. En modo simple las UI de las apps están en http://<host>:<port> — asegúrate de usar el enlace exacto que se muestra en la UI de IronFlock (el puerto se asigna por app), y de que nada en la red bloquee ese puerto.

El navegador avisa de que el certificado no es de confianza (tras --tls). El cliente aún no confía en la CA del certificado. En el Modo 2, despliega la CA generada por el appliance (/opt/ironflock/certs/ca/rootCA.crt) en el cliente. En el Modo 3, asegúrate de que el cliente confíe en la raíz de tu CA interna.

Certificado caducado (autoemitido). Un certificado de servidor autoemitido es válido durante aproximadamente un año (los navegadores rechazan los de vida más larga). Renuévalo: elimina tls.crt/tls.key en el directorio del certificado y vuelve a ejecutar el instalador para volver a firmar contra la misma CA, aún de confianza — o cambia a un --tls-cert de tu propia CA.

Discrepancia en el nombre del certificado. El certificado no es un comodín para el dominio en uso. Debe cubrir *.<APPLIANCE_DOMAIN>, y el dominio de la URL debe coincidir con APPLIANCE_DOMAIN.

Un subdominio no resuelve (tras --tls). Falta el DNS comodín. Añade un registro A *.<APPLIANCE_DOMAIN> que apunte al host del appliance — cubre las UI de las apps y cada subdominio de servicio.