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 et les récupérations d’images de conteneurs — s’exécute lui aussi sur le domaine via TLS, et le contournement insecure-registries n’est plus nécessaire.

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.