HTTPS et certificats

Lorsqu’une app sur un appareil connecté expose une interface web, l’appliance la rend accessible à travers son tunnel intégré. Vous choisissez comment les navigateurs atteignent l’appliance — il existe trois modes, de la configuration nulle au tout signé par l’entreprise. Choisissez-en un et suivez ses étapes.

À ne pas confondre avec Derrière un proxy d’entreprise. Cette page-là concerne l’appliance qui fait confiance à votre CA d’entreprise pour le trafic sortant (appliance → cloud, à travers un proxy interceptant le TLS). La présente page traite du sens inverse — le trafic entrant depuis les navigateurs de votre réseau atteignant l’appliance. Les deux sont indépendants.

Mode 1 — HTTP en clair (par défaut)

Ce que vous obtenez. Tout en HTTP en clair sur l’adresse de l’appliance :

Chaque interface d’app est publiée sur son propre port attribué automatiquement ; l’interface IronFlock affiche le lien exact pour chacune. Les interfaces des apps restent derrière la connexion de l’appliance — en ouvrir une redirige vers la connexion à moins que vous ne soyez identifié et autorisé pour cet appareil (un port peut être marqué public par app là où vous souhaitez le laisser ouvert).

Ce que vous devez faire. Rien. C’est le comportement par défaut — utilisez simplement l’IP ou le nom d’hôte de l’appliance sur votre réseau local. Aucun DNS, aucun certificat, aucune intervention de l’informatique d’entreprise.

Quand l’utiliser. Une appliance sur un réseau de confiance, segmenté — une armoire de commande sur un VLAN machine/OT — où l’HTTP en clair est la norme et où l’accès est contrôlé par la segmentation réseau et la sécurité physique.

Mode 2 — HTTPS avec une CA auto-émise

Ce que vous obtenez. L’appliance active son ingress HTTPS intégré et sert tout en HTTPS sous votre domaine — en utilisant un certificat qu’elle génère elle-même. Il n’y a aucun reverse proxy à exécuter ni aucune URL à recâbler ; l’installateur relie le tout.

Ce que vous devez faire.

1. Choisissez un domaine qui résout vers l’appliance pour chaque navigateur et appareil qui l’utilisera, et définissez à la fois APPLIANCE_HOST et APPLIANCE_DOMAIN sur celui-ci. Comme l’appliance émet le certificat elle-même, n’importe quel nom fonctionne — la seule exigence est qu’il résolve. Pour tout ce qui va au-delà d’un test rapide, utilisez un domaine interne que vous contrôlez (par exemple appliance.corp.example.com) avec un enregistrement générique dans votre propre DNS : un réseau d’appliance isolé ou restreint au niveau du DNS ne peut généralement pas atteindre le service public nip.io sur lequel repose le nom par défaut <host-ip>.nip.io. (Ce nom par défaut fonctionne bien là où le réseau peut atteindre internet — c’est pourquoi il fonctionne sur une machine de développement.)

2. Ajoutez un DNS générique pour le domaine, les deux enregistrements pointant vers l’IP de l’hôte de l’appliance :

   • *.<APPLIANCE_DOMAIN> — couvre les interfaces des apps et chaque sous-domaine de service.
   • <APPLIANCE_DOMAIN> (apex) — l’interface principale par son nom.

   (Un service de DNS générique comme nip.io résout déjà ces noms automatiquement, il n’y a donc aucun enregistrement à ajouter — mais cela dépend de l’accessibilité de ce service externe.)

3. Installez avec --tls :

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

   --interactive demande APPLIANCE_HOST / APPLIANCE_DOMAIN (ou définissez IRONFLOCK_APPLIANCE_HOST / IRONFLOCK_APPLIANCE_DOMAIN pour une installation sans surveillance). L’appliance génère une CA locale dans /opt/ironflock/certs/ca/rootCA.crt et un certificat générique signé par celle-ci.

4. Distribuez la racine de la CA aux machines clientes. Poussez rootCA.crt via votre MDM, ou ajoutez-le au magasin de confiance de l’OS/du navigateur de chaque machine. Tant qu’une machine ne lui fait pas confiance, son navigateur affiche un avertissement.

5. Renouvelez dans l’année. Le certificat du serveur est plafonné à environ 1 an — les navigateurs rejettent ceux dont la durée de vie est plus longue. Pour renouveler, supprimez tls.crt/tls.key dans le répertoire des certificats et relancez l’installateur ; il re-signe un certificat frais avec la même CA, de sorte que la confiance que vous avez distribuée continue de fonctionner.

Les appareils restent sur le chemin de l’IP en clair. Seul le côté navigateur passe à HTTPS. Les appareils connectés continuent d’atteindre l’appliance par son IP, vous n’avez donc pas à installer la CA sur chaque appareil.

Quand l’utiliser. Vous voulez du HTTPS sur un réseau partagé mais vous n’avez pas (ou ne voulez pas attendre) un certificat de l’informatique d’entreprise, et vous pouvez pousser une racine de CA vers les machines qui ouvriront l’interface.

Mode 3 — HTTPS avec votre certificat d’entreprise

Ce que vous obtenez. Le même HTTPS complet sur toute l’appliance que le Mode 2 — mais le certificat provient de la CA de votre organisation, dont la racine est déjà de confiance sur chaque machine gérée. Aucun avertissement de navigateur, rien à distribuer. Les appareils passent eux aussi sur le domaine.

Ce que vous devez faire.

1. Choisissez un domaine interne que vous contrôlez et définissez APPLIANCE_HOST et APPLIANCE_DOMAIN sur celui-ci (par exemple appliance.corp.example.com). Ici, il doit s’agir de votre propre domaine — une CA n’émet des certificats que pour des domaines que vous possédez, donc un nom nip.io ne fonctionnera pas dans ce mode.
2. Ajoutez un DNS générique — *.<APPLIANCE_DOMAIN> et l’apex, pointant vers l’IP de l’hôte de l’appliance — comme au Mode 2, étape 2.
3. Obtenez un certificat générique pour *.<APPLIANCE_DOMAIN> de votre CA interne, sous forme de deux fichiers PEM : tls.crt (idéalement la chaîne complète) et un tls.key non chiffré.
4. Installez avec votre certificat :

   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 implique --tls. Variables d’environnement équivalentes : IRONFLOCK_TLS_CERT / IRONFLOCK_TLS_KEY.
5. Effectuez la rotation selon le calendrier de votre CA. Déposez les nouveaux fichiers PEM dans le répertoire des certificats et redémarrez :

   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

   L’appliance recharge le certificat automatiquement lorsque le fichier change ; le redémarrage ne fait que l’appliquer immédiatement. Relancer l’installateur n’écrase jamais un certificat existant à moins que vous ne passiez --tls-cert.

Les appareils passent eux aussi sur le domaine. Comme le certificat est de confiance à l’échelle de la flotte, le trafic des appareils — le lien de l’appareil, les récupérations d’images de conteneurs et les mises à jour de l’agent d’appareil — s’exécute lui aussi sur le domaine via TLS, et le contournement insecure-registries n’est plus nécessaire. Cela s’applique aux images d’app construites après le basculement ; les apps installées avant conservent l’adresse de registre contre laquelle elles ont été construites, que l’agent 0.21.3 et plus récent résolvent d’eux-mêmes — voir l’exigence 4 ci-dessous.

Ce dont les appareils connectés ont besoin dans ce mode

Chaque appareil edge qui se connecte à l’appliance doit :

1. Résoudre le domaine. <APPLIANCE_DOMAIN> et ses sous-domaines (l’enregistrement générique) doivent résoudre vers l’IP de l’appliance depuis le réseau de l’appareil — les mêmes enregistrements DNS que ceux servis aux navigateurs.
2. Joindre l’appliance sur le port 443 — le seul port dont les appareils ont besoin pour la connexion à la plateforme, pour les mises à jour de l’agent d’appareil (servies depuis https://registry.<APPLIANCE_DOMAIN>/dl — le port 15002 n’est pas nécessaire dans ce mode) et pour les images d’app construites après le basculement (les apps installées avant relèvent de l’exigence 4). C’est ce qui fait du mode 3 le bon choix pour des appareils sur des réseaux verrouillés : le 443 sortant est autorisé à peu près partout, et la connexion fonctionne aussi à travers un proxy HTTP d’entreprise (donnez le proxy à l’agent comme décrit dans Derrière un proxy d’entreprise → Appareils Edge). En mode simple, à l’inverse, les appareils ont besoin d’un accès direct à plusieurs ports de service de l’appliance que les pare-feux et proxys d’entreprise bloquent couramment — voir Connectivité des appareils.
3. Faire confiance à votre CA racine d’entreprise. L’agent et Docker valident le certificat de l’appliance contre le magasin de confiance du système d’exploitation de l’appareil :
   • Machines gérées (Windows joint au domaine, Linux géré par MDM) font généralement déjà confiance à votre racine d’entreprise — rien à faire.
   • Windows non géré : installez la CA racine dans le magasin de l’ordinateur depuis une invite avec privilèges élevés — certutil -addstore -f Root corporate-root-ca.crt — puis redémarrez Docker Desktop (il importe les racines de confiance depuis le magasin Windows au démarrage) et le service de l’agent (Restart-Service reagent).
   • Linux : sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates, puis redémarrez Docker (sudo systemctl restart docker) et l’agent.
   • Les conteneurs d’apps héritent automatiquement de cette confiance (agent 0.21.3 et versions ultérieures). Un conteneur ne transporte que le bundle de CA de son image de base, et aucune image de base ne contient de racine interne : une app qui se connecte à l’appliance en TLS ne pouvait donc pas la vérifier. L’agent monte désormais le magasin de confiance de l’appareil en lecture seule dans chaque conteneur d’app, sous /etc/ironflock/certs/ca-bundle.crt, et y dirige les environnements d’exécution habituels (SSL_CERT_FILE, REQUESTS_CA_BUNDLE, NODE_EXTRA_CA_CERTS). Rien à configurer — mais l’appareil lui-même doit faire confiance à la racine, car c’est précisément cette confiance que l’agent transmet. Une app qui définit son propre SSL_CERT_FILE le conserve.
4. Mettre à jour l’agent d’appareil vers 0.21.3 ou plus récent — ou republier les apps installées avant le basculement. Le fichier compose stocké d’une app porte des références d’image pleinement qualifiées — <APPLIANCE_IP>:15001/apps/… — figées lors de la construction de l’app. Ces références sont des données : faire passer l’appliance sur un domaine ne réécrit aucun fichier compose. L’agent 0.21.3 et plus récent résolvent une telle référence vers le registre pour lequel l’appareil lui-même est configuré : une app installée avant le basculement continue donc de fonctionner sur le domaine sans rien faire, et le premier démarrage après la mise à jour télécharge chaque image une fois sous son nouveau nom. Un agent plus ancien utilise la référence telle quelle et continue de composer l’ancienne IP et l’ancien port : son appareil a encore besoin que le port du registre (15001) soit joignable sur le réseau local, et le port 443 seul ne lui suffit pas, jusqu’à ce que l’app soit reconstruite et republiée contre registry.<APPLIANCE_DOMAIN>. L’appliance gère son propre côté automatiquement : tant que son propre agent est antérieur à 0.21.3 et qu’une telle référence existe, elle garde le registre joignable sur le LAN et liste les fichiers compose concernés dans la sortie de l’installateur. Une fois l’agent à jour — ou ces apps republiées — le sudo ironflock-update suivant ne trouve plus rien à attendre et sort le registre du LAN de lui-même.

Quand l’utiliser. La voie standard on-prem d’entreprise : votre organisation exploite déjà une CA interne, un certificat générique est donc émis une fois et de confiance partout, sans aucune configuration par machine.

Dépannage

Un lien d’interface d’app ne s’ouvre pas / connexion refusée. En mode clair, les interfaces des apps sont à http://<host>:<port> — assurez-vous d’utiliser le lien exact affiché dans l’interface IronFlock (le port est attribué par app), et que rien sur le réseau ne bloque ce port.

Le navigateur avertit que le certificat n’est pas de confiance (après --tls). Le client ne fait pas encore confiance à la CA du certificat. En Mode 2, déployez la CA générée par l’appliance (/opt/ironflock/certs/ca/rootCA.crt) sur le client. En Mode 3, assurez-vous que le client fait confiance à la racine de votre CA interne.

Certificat expiré (auto-émis). Un certificat de serveur auto-émis est valide pendant environ un an (les navigateurs rejettent ceux dont la durée de vie est plus longue). Renouvelez-le : supprimez tls.crt/tls.key dans le répertoire des certificats et relancez l’installateur pour re-signer avec la même CA, toujours de confiance — ou passez à un --tls-cert de votre propre CA.

Non-correspondance du nom du certificat. Le certificat n’est pas un certificat générique pour le domaine utilisé. Il doit couvrir *.<APPLIANCE_DOMAIN>, et le domaine de l’URL doit correspondre à APPLIANCE_DOMAIN.

Un sous-domaine ne résout pas (après --tls). Le DNS générique est manquant. Ajoutez un enregistrement A *.<APPLIANCE_DOMAIN> pointant vers l’hôte de l’appliance — il couvre les interfaces des apps et chaque sous-domaine de service.

Une app ne démarre pas ou ne télécharge pas son image après le passage au mode 3 — « connection refused » sur le port 15001. Le fichier compose de l’app référence encore le registre par l’adresse IP de l’appliance, parce que c’est contre elle qu’elle a été construite, et l’agent de l’appareil est antérieur à 0.21.3 — à partir de cette version, l’agent résout lui-même une telle référence vers son propre registre. Mettez à jour l’agent d’appareil, ou reconstruisez et republiez l’app pour que son image se résolve via registry.<APPLIANCE_DOMAIN>. En attendant, le registre doit rester joignable sur le réseau local, ce dont l’appliance se charge d’elle-même — un simple sudo ironflock-update restaure la liaison au LAN et nomme les fichiers compose qui contiennent encore une ancienne référence.

Une app tourne mais ne se connecte jamais, et son journal répète la même tentative de connexion toutes les quelques secondes. Le conteneur de l’app ne peut pas vérifier le certificat de l’appliance : la poignée de main TLS est abandonnée juste après le certificat du serveur et le SDK réessaie indéfiniment, alors que l’appareil reste en ligne parce que l’agent utilise le magasin de confiance du système d’exploitation et pas le conteneur. Mettez à jour l’agent de l’appareil vers 0.21.3 ou une version ultérieure, qui transmet le magasin de confiance de l’appareil aux conteneurs d’apps, et vérifiez que l’appareil fait confiance à votre racine d’entreprise (exigence 3 ci-dessus). docker logs <conteneur> sur l’appareil affiche l’erreur de vérification du certificat. Avec un agent plus ancien, la solution se fait app par app : ajoutez la CA racine à l’image, ou montez-la et définissez SSL_CERT_FILE dans le fichier compose de l’app.

Un appareil ne se connecte pas après le passage au mode 3. Reprenez les quatre exigences d’appareil ci-dessus : le domaine doit résoudre depuis le réseau de l’appareil, le port 443 de l’appliance doit être joignable (directement ou via le proxy de l’appareil), l’appareil doit faire confiance à votre CA racine d’entreprise, et les apps installées avant le basculement ont besoin de l’agent 0.21.3 ou d’une republication avant de cesser d’avoir besoin du port du registre. Sous Windows, le journal de l’agent dans C:\ProgramData\IronFlock\Reagent\reagent.log (sous Linux /var/log/reagent.log) montre l’erreur de connexion exacte — un échec DNS, un délai dépassé ou une erreur de vérification de certificat pointent chacun vers l’une des trois premières.