HTTPS e certificados

Quando um app em um dispositivo conectado expõe uma interface web, o appliance a torna acessível através do seu túnel embutido. Você escolhe como os navegadores alcançam o appliance — há três modos, do zero de configuração ao totalmente assinado pela empresa. Escolha um e siga seus passos.

Não é o mesmo que Atrás de um Proxy Corporativo. Aquela página trata do appliance confiando na sua CA corporativa para o tráfego de saída (appliance → nuvem, através de um proxy que intercepta TLS). Esta página é a direção oposta — tráfego de entrada de navegadores na sua rede alcançando o appliance. Os dois são independentes.

Modo 1 — HTTP simples (padrão)

O que você obtém. Tudo sobre HTTP simples no endereço do appliance:

Cada UI de app é publicada em sua própria porta atribuída automaticamente; a interface do IronFlock mostra o link exato de cada uma. As UIs dos apps permanecem atrás do login do appliance — abrir uma redireciona para o login, a menos que você esteja autenticado e autorizado para aquele dispositivo (uma porta pode ser marcada como pública por app, onde você quiser deixá-la aberta).

O que você precisa fazer. Nada. Este é o padrão — apenas use o IP ou o hostname do appliance na sua rede local. Sem DNS, sem certificado, sem envolvimento da TI corporativa.

Quando usar. Um appliance em uma rede confiável e segmentada — um painel de controle em uma VLAN de máquina/OT — onde o HTTP simples é a norma e o acesso é controlado por segmentação de rede e segurança física.

Modo 2 — HTTPS com uma CA autoassinada

O que você obtém. O appliance ativa seu ingress HTTPS embutido e serve tudo sobre HTTPS sob o seu domínio — usando um certificado que ele mesmo gera. Não há proxy reverso para executar e nenhuma URL para reconfigurar; o instalador cuida de tudo.

O que você precisa fazer.

1. Escolha um domínio que resolva para o appliance em cada navegador e dispositivo que o usará, e defina tanto APPLIANCE_HOST quanto APPLIANCE_DOMAIN para ele. Como o appliance emite o certificado ele mesmo, qualquer nome funciona — o único requisito é que ele resolva. Para qualquer coisa além de um teste rápido, use um domínio interno que você controla (por exemplo, appliance.corp.example.com) com um registro wildcard no seu próprio DNS: uma rede de appliance isolada ou com DNS restrito geralmente não consegue alcançar o serviço público nip.io do qual depende o nome padrão <host-ip>.nip.io. (Esse padrão funciona onde a rede consegue alcançar a internet — que é por isso que funciona em uma máquina de desenvolvimento.)

2. Adicione DNS wildcard para o domínio, ambos os registros apontando para o IP do host do appliance:

   • *.<APPLIANCE_DOMAIN> — cobre as UIs dos apps e cada subdomínio de serviço.
   • <APPLIANCE_DOMAIN> (apex) — a UI principal pelo nome.

   (Um serviço de DNS wildcard como nip.io já resolve esses registros automaticamente, então não há registros a adicionar — mas depende de esse serviço externo estar acessível.)

3. Instale com --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 (ou defina IRONFLOCK_APPLIANCE_HOST / IRONFLOCK_APPLIANCE_DOMAIN para uma instalação não assistida). O appliance gera uma CA local em /opt/ironflock/certs/ca/rootCA.crt e um certificado wildcard assinado por ela.

4. Distribua a raiz da CA para as máquinas cliente. Envie o rootCA.crt via seu MDM, ou adicione-o ao armazenamento de confiança do SO/navegador de cada máquina. Até que uma máquina confie nele, seu navegador exibe avisos.

5. Renove dentro de um ano. O certificado do servidor é limitado a ~1 ano — os navegadores rejeitam certificados de vida mais longa. Para renovar, exclua o tls.crt/tls.key no diretório de certificados e execute o instalador novamente; ele re-assina um certificado novo contra a mesma CA, então a confiança que você distribuiu continua funcionando.

Os dispositivos permanecem no caminho do IP simples. Apenas o lado do navegador muda para HTTPS. Os dispositivos conectados continuam alcançando o appliance pelo seu IP, então você não precisa instalar a CA em cada dispositivo.

Quando usar. Você quer HTTPS em uma rede compartilhada, mas não tem (ou não quer esperar por) um certificado da TI corporativa, e você consegue distribuir uma raiz de CA para as máquinas que abrirão a interface.

Modo 3 — HTTPS com o seu certificado corporativo

O que você obtém. O mesmo HTTPS completo do appliance que o Modo 2 — mas o certificado vem da CA da sua organização, cuja raiz já é confiável em cada máquina gerenciada. Sem avisos do navegador, nada a distribuir. Os dispositivos também passam para o domínio.

O que você precisa fazer.

1. Escolha um domínio interno que você controla e defina APPLIANCE_HOST e APPLIANCE_DOMAIN para ele (por exemplo, appliance.corp.example.com). Aqui ele precisa ser o seu próprio domínio — uma CA só emite certificados para domínios que você possui, então um nome nip.io não funciona neste modo.
2. Adicione DNS wildcard — *.<APPLIANCE_DOMAIN> e o apex, apontando para o IP do host do appliance — como no Modo 2, passo 2.
3. Obtenha um certificado wildcard para *.<APPLIANCE_DOMAIN> da sua CA interna, como dois arquivos PEM: tls.crt (idealmente com a cadeia completa) e um tls.key não criptografado.
4. Instale com o seu 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. Variáveis de ambiente equivalentes: IRONFLOCK_TLS_CERT / IRONFLOCK_TLS_KEY.
5. Rotacione no cronograma da sua CA. Coloque os novos arquivos PEM no diretório de certificados e reinicie:

   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

   O appliance recarrega o certificado automaticamente quando o arquivo muda; o restart apenas o aplica imediatamente. Executar o instalador novamente nunca sobrescreve um certificado existente, a menos que você passe --tls-cert.

Os dispositivos também passam para o domínio. Como o certificado é confiável em toda a frota, o tráfego dos dispositivos — o link do dispositivo e os downloads de imagens de contêiner — também roda sobre o domínio via TLS, e a solução alternativa insecure-registries deixa de ser necessária.

Quando usar. O caminho corporativo on-prem padrão: sua organização já opera uma CA interna, então um certificado wildcard é emitido uma vez e confiável em todos os lugares, sem configuração por máquina.

Solução de problemas

Um link de UI de app não abre / conexão recusada. No modo simples, as UIs dos apps ficam em http://<host>:<port> — certifique-se de estar usando o link exato mostrado na interface do IronFlock (a porta é atribuída por app) e de que nada na rede bloqueia aquela porta.

O navegador avisa que o certificado não é confiável (após --tls). O cliente ainda não confia na CA do certificado. No Modo 2, implante a CA gerada pelo appliance (/opt/ironflock/certs/ca/rootCA.crt) no cliente. No Modo 3, certifique-se de que o cliente confia na raiz da sua CA interna.

Certificado expirado (autoassinado). Um certificado de servidor autoassinado é válido por cerca de um ano (os navegadores rejeitam certificados de vida mais longa). Renove-o: exclua o tls.crt/tls.key no diretório de certificados e execute o instalador novamente para re-assinar contra a mesma CA, ainda confiável — ou mude para um --tls-cert da sua própria CA.

Incompatibilidade de nome do certificado. O certificado não é um wildcard para o domínio em uso. Ele precisa cobrir *.<APPLIANCE_DOMAIN>, e o domínio da URL precisa corresponder a APPLIANCE_DOMAIN.

Um subdomínio não resolve (após --tls). Falta o DNS wildcard. Adicione um registro A *.<APPLIANCE_DOMAIN> apontando para o host do appliance — ele cobre as UIs dos apps e cada subdomínio de serviço.