Certificats
Une identité propre à chaque équipement, compatible avec votre PKI
Le hub reconnaît à une identité cryptographique les agents autorisés à rejoindre votre parc. Chaque machine s'authentifie par un certificat dont la clé privée ne quitte jamais l'appareil. Ce sur quoi ce certificat s'appuie, en revanche, se choisit : une ancre épinglée par parc, sans racine commune, qui fait échouer la vérification d'un parc à l'autre ; ou la chaîne de confiance que votre organisation tient déjà.
Prise 9
Ce que cela apporte, en clair
Seuls les appareils que vous avez reconnus établissent une relation avec le hub, et votre organisation garde le choix du modèle de confiance qui convient à ses contraintes. Une identité volée sur une machine ne vaut rien sur une autre, ni dans un autre parc.
Ce qu'est l'identité d'un agent
Un agent ne s'authentifie pas par un jeton posé dans un fichier de configuration, mais par un certificat client, présenté dans la poignée de main TLS. Sa clé privée est engendrée sur la machine et n'en sort jamais : elle n'est ni transmise, ni sauvegardée, ni recopiable.
Reste à savoir sur quoi ce certificat s'appuie. Deux modèles, choisis parc par parc, et le choix ne change pas le prix de votre licence.
Deux modèles, et non deux fournisseurs
La différence entre les deux ne tient pas à qui signe, mais à la forme de la confiance. L'un épingle une ancre par parc et ne connaît aucune racine commune ; l'autre est une PKI classique, avec sa chaîne qui remonte à votre racine.
Le premier segmente mieux, le second s'intègre mieux. C'est tout l'arbitrage, et il se fait parc par parc.
Dans les deux cas, l'autorité est la vôtre. Le hub tourne sur vos machines : celle qu'il engendre naît chez vous et n'en sort pas, celle que vous lui confiez était déjà la vôtre. Nous ne tenons aucune autorité, nous n'en signons aucune, et il n'existe nulle part une racine qui nous permettrait d'entrer dans un parc.
Une ancre épinglée par parc
C'est le mode par défaut, et ce n'est pas une PKI au sens habituel : il n'y a aucune racine commune. Chaque parc porte sa propre autorité, auto-signée, que le hub épingle ; il n'existe rien au-dessus d'elles pour les relier.
C'est l'absence de racine commune qui segmente
Le hub ne fait pas confiance à « une autorité » : il fait confiance à cette ancre-ci, pour ce parc-là, et il sait laquelle a signé le certificat qu'on lui présente. Une identité valide dans un parc ne se vérifie pas dans un autre - la validation échoue, il n'y a rien à filtrer ensuite.
L'autorité porte en outre une contrainte de nom : elle ne peut signer que sous son propre sous-arbre, ce que la bibliothèque de vérification fait respecter avant tout contrôle applicatif. Et elle ne peut pas engendrer d'autorité subordonnée : ce qu'elle signe est une feuille, et rien d'autre.
Déplacer une machine d'un parc à l'autre lui réémet donc son identité. C'est la conséquence voulue, et non un effet de bord : son ancienne identité n'aurait de sens nulle part ailleurs.
Rien à faire : elle se crée toute seule
Vous ne la demandez pas et vous ne la posez pas. Le hub l'engendre en même temps que le parc, et signe les identités à mesure que les machines s'enrôlent et se renouvellent.
Le hub écrit le nom, il ne le lit pas
Une demande de signature est rédigée par celui qui la présente. Le laisser choisir son propre nom reviendrait à le laisser choisir son identité, et c'est le défaut classique des PKI internes - silencieux, parce que tout le reste de la demande est parfaitement valide.
Deux choses seulement sont retenues de la demande : la clé publique, et la preuve que le demandeur détient la clé privée correspondante. Tout le reste est écrit par le hub.
Pas de liste de révocation, et c'est délibéré
Une feuille vit quatre-vingt-dix jours. Un certificat qu'on a manqué de révoquer expire de lui-même avant que la discussion sur sa révocation ne soit terminée. Il n'y a pas de longue traîne de machines que personne ne met à jour : le parc est maintenu avec son hub.
Une chaîne de confiance, si vous en avez déjà une
C'est le modèle classique. Si votre organisation tient déjà une autorité de certification, le hub s'y raccorde plutôt que d'en créer une de plus : vous lui donnez le certificat public de votre autorité, parc par parc. C'est tout.
Il porte l'ancre, il ne porte pas la clé
Le hub garde ce certificat comme ancre de confiance : ce contre quoi il vérifie ce qu'un agent présente. La clé qui signe ne lui est jamais remise, et il n'émet donc aucune identité pour ce parc - c'est votre PKI qui délivre les certificats de vos machines, selon vos propres procédures.
Changer l'ancre d'un parc est l'opération la plus lourde de ce montage : elle réémet toutes ses identités. Le hub garde donc quand elle a été posée et par qui.
Un gabarit dit comment lire vos noms
Votre PKI émet machine123.corp.example.com, pas la forme que le hub écrit pour
ses propres feuilles. Vous lui donnez donc un gabarit,
{agent}.corp.example.com, où {agent} marque l'endroit où se
trouve l'identifiant.
Un gabarit, et non une expression régulière. Une expression régulière donnerait plus de pouvoir que nécessaire à un champ qu'un administrateur remplit, et « plus de pouvoir que nécessaire » sur une décision de confiance est très exactement la façon dont on écrit un motif qui finit par tout accepter.
Il est ancré aux deux bouts : {agent}.corp.example.com ne peut pas être
satisfait par attaquant.corp.example.com.ailleurs.net. Et un identifiant vide,
ou qui déborde sur une étiquette de plus, n'en est pas un - sans ce contrôle, deux machines
se retrouveraient sous un même nom.
Une file pour ce qui frappe à la porte
Une machine que le hub ne connaît pas encore, mais dont le certificat est valide, entre en file d'attente si le parc l'accepte. Elle ne joint toujours rien ; l'exploitant la voit arriver, et la rattache ou la rejette.
Sans cela, une PKI d'entreprise n'aurait aucun chemin d'entrée : ses certificats sont valides et ne nomment rien que le hub connaisse.
Dites-nous quels équipements, derrière quels réseaux. On vous montre la console dessus.
Parc par parc, et pas d'un seul coup
Le modèle se choisit pour chaque parc séparément. Un parc peut vivre sur son ancre épinglée pendant qu'un autre est raccordé à votre chaîne. C'est ce qui permet d'introduire l'authentification par certificat progressivement, sur un parc pilote d'abord, au lieu de basculer une flotte entière un matin.
Ce que chaque mode vous fait porter
Avec l'ancre épinglée, la clé qui signe vit dans le hub, et elle y reste en ligne par nécessité : une identité se signe à l'enrôlement et à chaque renouvellement, sans personne devant l'écran. La mettre sous cloche demanderait une cérémonie tous les soixante jours et par machine.
Ce n'est pas une faiblesse du montage, c'est sa forme : le certificat client protège contre un secret volé sur le terrain, pas contre un hub retourné. Qui tient votre hub tient déjà vos sessions ; qu'il puisse aussi émettre une identité ne change pas grand-chose à sa position.
Avec votre chaîne, le hub ne détient aucune clé et ne peut donc rien émettre. C'est ce que vous gagnez.
Ce que vous perdez est la segmentation par l'ancre. Votre racine est commune à ce qu'elle signe : une feuille émise pour un parc reste cryptographiquement valide sous cette racine, et ce sont alors le gabarit et le contrôle applicatif du hub qui la retiennent - non plus l'échec de la vérification elle-même.
Si vous tenez plusieurs parcs strictement cloisonnés, cela mérite d'être pesé. Pour un parc unique, la question ne se pose pas.
Où vit la clé privée, appareil par appareil
« Ne quitte jamais l'appareil » se vérifie différemment selon l'appareil, et il vaut mieux le dire que le laisser deviner. Sur chacun, la clé est engendrée sur place, le hub n'en reçoit que la moitié publique, et le meilleur abri que la machine offre est pris en premier, le suivant seulement s'il manque - en le disant à l'écran.
| Appareil | Où est la clé | À défaut |
|---|---|---|
| PipeLinker Desktop, Windows | Dans le TPM, par le magasin de clés du système : la clé n'existe jamais sous forme d'octets, même pour le programme qui s'en sert. | Le magasin de clés logiciel, non exportable, chiffré pour le compte ; puis un fichier scellé par DPAPI, lisible par ce compte sur cette machine et par personne d'autre. |
| PipeLinker Desktop, Linux | Dans le TPM (/dev/tpmrm0) : la puce rend la clé enveloppée par sa propre graine, chargeable là et nulle part ailleurs. Copier le fichier ne donne rien. |
Un fichier lisible par ce compte seul. |
| PipeLinker Mobile, Android | Dans le Keystore Android, adossé au matériel quand l'appareil en a, et liée au déverrouillage : la clé ne signe rien tant que le téléphone est verrouillé. | - |
| Agent Linux et Windows | Un fichier à côté du certificat, créé avec ses droits restreints dès l'écriture - pas posés après coup -, lisible par le compte de l'agent seul. | - |
| Agent Android | Dans le Keystore Android, adossé au matériel quand l'appareil en a : l'agent peut signer avec, il ne peut pas la lire. | - |
Dans tous les cas, une sauvegarde restaurée ailleurs, un disque cloné ou un appareil remplacé ne transportent aucune identité : c'est un nouvel enrôlement, depuis la console, et l'ancien certificat se révoque en un geste.
À ne pas confondre : le certificat du hub lui-même
Tout ce qui précède concerne l'identité des agents. Le certificat que le hub présente à un navigateur est un autre sujet, et il est simple : le hub lit deux fichiers dans un dossier, et ce qui les y dépose ne le regarde pas - certbot, acme.sh, une PKI d'entreprise, ou un certificat posé à la main.
Un mandataire qui termine le TLS efface le certificat client
C'est la principale chose à savoir avant de placer le hub dans une infrastructure existante. Un certificat client n'existe que dans la poignée de main TLS : un mandataire inverse (reverse proxy) qui la termine le supprime, et plus aucun agent ne se connecte.
Le nom de la console, lui, se met derrière un mandataire comme n'importe quel site. C'est le nom que les agents joignent qui doit arriver jusqu'au hub sans être terminé en route.
Le prix ne dépend pas de ce choix
Interne ou d'entreprise, c'est une décision d'architecture, pas une option commerciale. La licence ne compte ni les autorités ni les certificats : elle ne connaît que la taille de ce que vous exploitez - vos machines, vos comptes, vos parcs. Cloisonner proprement ne doit jamais avoir de prix. Les tarifs, et ce qu'est un parc
Page mise à jour le 22 septembre 2026. Page technique, tenue par l'équipe PipeLinker de LOOTUS SECURITY, éditeur du produit. La date vient du dépôt, pas d'une saisie.