Rechercher

L’éditeur de macros est un graphe de nœuds visuel qui s’exécute sur le serveur. Un nœud Événement système se déclenche lorsque le moniteur de santé émet un événement correspondant — un certificat sur le point d’expirer, une forte occupation du disque ou du GPU, la batterie faible d’un appareil — et transmet le texte et la valeur de l’événement sur ses ports de sortie. Relié à un nœud Envoi Telegram, il publie un message via l’API des bots Telegram. Le graphe se vérifie avec Valider, peut être simulé et, lorsqu’il est actif, l’éditeur affiche les valeurs qui transitent par chaque nœud.

Le panneau d’administration web interroge le serveur sur son état TLS actuel et affiche quatre cartes : le transport utilisé (HTTPS avec TLS 1.2 ou 1.3), le certificat serveur et sa date d’expiration, le type et la taille de la clé du serveur, ainsi que le certificat chargé pour les navigateurs avec son empreinte SHA-256. Ces mêmes données d’expiration alimentent un service de surveillance en arrière-plan qui génère des événements pour le serveur, l’autorité de certification, les serveurs pairs et les caméras avant toute expiration ; les alertes peuvent ainsi être transmises à des macros, par e-mail ou sur Telegram.

Le serveur peut générer une autorité de certification ou en importer une existante. Le certificat de l’AC et sa clé privée sont stockés sur le serveur ; le fichier de clé n’est lisible que par le compte de service et peut être protégé par un mot de passe, et seuls les certificats signés quittent la machine. L’onglet permet aussi de télécharger le certificat de l’AC, de le sauvegarder et de le restaurer, de l’installer dans le magasin de confiance du système, de révoquer des certificats par numéro de série et de générer une liste de révocation (CRL). Un certificat de serveur RADIUS pour le 802.1X peut être émis par cette même AC.

Une nouvelle paire de clés est générée et un certificat est signé par l’AC enregistrée pour le nom et les entrées DNS et IP indiqués, avec la validité et le type de clé choisis. Le résultat est proposé au format PEM (certificat, clé et AC) ou sous forme de paquet PKCS#12. En cochant l’option serveur, le certificat est installé comme certificat propre du serveur, l’AC est approuvée pour le client de bureau, l’ancien certificat auto-signé est retiré et le service redémarre : les navigateurs cessent d’afficher des avertissements dès qu’ils font confiance à l’AC.

Vous saisissez les caméras à la main ou importez un CSV avec adresse, fabricant, identifiants et ports. Pour chaque ligne, le serveur émet un certificat d’appareil depuis l’autorité de certification (CA), transmet le certificat et la CA à la caméra via l’API web propre au fabricant, puis active HTTPS. Des actions permettent aussi de désactiver HTTPS et de le tester. Le serveur doit pouvoir joindre les caméras sur le réseau, et les identifiants ne servent que le temps de l’opération. Résultat : un seul passage au lieu de se connecter à chaque caméra.

Pour une caméra, le serveur signe un certificat d’appareil, le téléverse via l’API du fabricant et peut transmettre la CA, activer HTTPS, désactiver le HTTP non chiffré et tester la connexion sécurisée. La seconde section se connecte à un autre hôte PotoP via SSH, copie le certificat, la clé et le fichier CA dans le répertoire de destination et peut redémarrer un service. Les deux opérations s’exécutent sur le serveur : celui-ci doit pouvoir joindre la cible, et elles nécessitent des droits d’administrateur.

Le panneau affiche le certificat actuellement chargé pour le client web, avec son sujet, son émetteur, sa validité, le type et la taille de sa clé, l’algorithme de signature et l’empreinte SHA-256, et peut l’exporter au format PEM. La section mobile met le certificat de l’AC à disposition en téléchargement, ou sous forme de QR code qu’un téléphone ou une tablette peut scanner : l’appareil fait ainsi confiance au serveur une fois pour toutes et cesse d’afficher des avertissements. Des instructions et des scripts d’installation sont fournis pour Linux, macOS et Windows.

Avant l’envoi du mot de passe, la page de connexion contacte le serveur choisi en HTTPS et vérifie le certificat auprès du magasin de confiance du navigateur. Si la chaîne est valide et correspond, le message vert « Connexion sécurisée » apparaît ; sinon, l’utilisateur voit un avertissement. Cette vérification est effectuée par la pile TLS du navigateur lui-même : la page ne peut donc pas la falsifier. Les identifiants sont ensuite envoyés au serveur vérifié par la connexion chiffrée.

Le chat IA est intégré au client web et au client de bureau. La plupart des demandes sont comprises par un moteur de commandes à base de règles sur le serveur — signalées comme directes dans le chat — qui associe des formulations comme « lister les dispositions » aux mêmes fonctions que celles appelées par l’interface utilisateur. Le panneau d’aide liste des exemples de formulations par thème. Les actions qui modifient quelque chose, comme créer une autorité de certification ou déployer des certificats, posent leurs questions étape par étape et ne changent rien tant que vous n’avez pas confirmé. Les réponses volumineuses sont envoyées sur le tableau de résultats pour que la conversation reste lisible.

Tout composant de n’importe quel plan peut porter une date de fin de certificat, et cette page les rassemble toutes pour l’entreprise en une seule requête, triées par jours restants. Une tâche de fond vérifie les dates chaque jour et envoie des avertissements à six, trois, deux et un mois, puis à vingt, dix et un jour avant l’échéance, et une fois après l’expiration. Les avertissements partent par e-mail, par Telegram et dans la suite, vers les personnes autorisées à modifier les plans. Chaque étape d’avertissement est enregistrée sur l’élément lui-même : un redémarrage ou une seconde exécution ne la répète jamais.