Welcome to OCS Inventory NG community support, where you can ask questions and receive answers from other members of the community.

Please ask questions only in English or French.

Release 2.11.1 available

The official documentation can be found on http://wiki.ocsinventory-ng.org. Read it before asking your question.

Déploiement Nouveau Certificat

Bonjour,

Je suis administrateur d'un serveur OCS dont les agents sont déployés chez nos clients par une installation manuelle au moment de la mise en place du PC.

Notre package OCS déploie l'agent et son certificat pour une communication en SSL avec notre serveur se trouvant derrière un nom de domaine.

Ce certificat est un autosigné qui a été généré il y a plus de 5 ans en 1024 bits.

La machine hôte de OCS a été upgradée en Ubuntu 20.04 LTS et nous souhaiterions déployer un nouveau certificat plus fort et autosigné.

Existe-t-il une méthode simple pour un déploiement automatique du nouveau certificat sur tout notre parc client car nous ne pouvons pas repasser manuellement sur toutes les machines ?

En vous remerciant par avance pour votre aide.
in OCS Inventory NG server for Unix by (120 points)

3 Answers

0 votes

Pour l'url /ocsinventory, on est, bien sûr, tenté par la 'sécurisation' : https + certificat + SSL=1. Toutefois, il y a le problème de la péremption et du changement du certificat.

Il est possible de créer 1 package de déploiement (1 pour les agents Windows et 1 pour les agents Linux) pour installer un nouveau certificat : on déploie le nouveau certificat sur toutes les machines puis on change le certificat sur le serveur.

Bien noter qu'il NE FAUT PAS changer le certificat sur le serveur AVANT de le changer sur les agents : dès le changement sur le serveur, les agents qui ont encore l'ancien certificat ne peuvent plus communiquer avec le serveur !!

Bien noter que, dès qu'un agent change son certificat, il ne peut plus communiquer avec le serveur tant que celui-ci n'a pas fait le changement !!

C'est inextricable, et forcément il y aura perte de communication durant le temps entre le déploiement et le changement sur le serveur. En outre, tous les agents n'auront pas exécuté le déploiement (ordi arrêté ou ne fonctionnant plus, ...)

Il y aurait bien une solution : créer une petite tâche qui récupère le certificat du serveur et l'installe à la bonne place dans le dossier de l'agent. (Cela en dit long sur la 'sécurité' : tous les X jours on va chercher le certificat existant et l'installer à la bonne place !). (Sous Linux : echo -n | openssl s_client -connect $HOST:443 -servername $SERVERNAME | openssl x509 > /tmp/$SERVERNAME.cert ) (Idéalement, il faudrait que les agents informent qu'ils ont récupéré le certificat ...)

NB : les navigateurs modernes refusent, de plus en plus, un certificat autosigné, donc pour /ocsreports il vaut mieux avoir un certificat Let's Encrypt = sur un autre nom dns de serveur !

Meilleure préconisation :

il faut créer plusieurs couples url/certificat : procéder avec plusieurs noms de dns et plusieurs virtualhost sur le serveur. Vous pouvez alors faire un package de déploiement qui change ET la config server= ET le certificat : les machines qui exécutent le package vont changer d'url/certificat ... mais sans perdre celles qui n'ont pas exécuté le package ....

by (18.9k points)
edited by
0 votes

Bonjour,

il est aussi possible d'embarquer l'ancien ET le nouveau certificat dans la clé publique.

Ainsi, vous envoyez le nouveau fichier cacert.pem à la place de l'ancien et votre agent peut communiquer à la fois avec les 2 serveurs / configs (ou davantage).

Par ex., contenu de cacert.pem :

# Serveur 1 / config 1

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

# Serveur 2 / config 2

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

 Toutefois, ça ne gère pas le cas où l'adresse du serveur a changé entre temps (server=... dans ocsinventory.ini), d'où l'intérêt d'un DNS plutôt qu'une adresse IP...

by (32.6k points)
0 votes
C'est intéressant à savoir : il est possible de coller plusieurs certificats dans le même fichier.

Il est notable, en effet, que l'adresse ip ne soit pas utilisée (et c'est très certainement le cas de SpongeBob).

J'insiste un peu sur la multiplication des couples url/certificat avec autant de virtualhost sur le (même) serveur : je le fais pour chaque version d'agent :

- url http://ocsinventory.xxxxx.com/ocsinventory (pour agent initial 2.0.5)

- url https://ocsinv-24.xxxxx.com/ocsinventory (pour agent 2.4)

- url https://ocsinv-26.xxxxx.com/ocsinventory (pour agent 2.6)

et les virtualhost ocsinv-24/ocsinv-26 font 'proxypass' vers la première url. (De surcroit, j'ai un autre nom dns pour /ocsreports et je fais en sorte que le nom dns pour ocsreports ne servent pas à remonter l'inventaire et reciproquement.)

Cela assure que tant les nouvelles config fonctionnent que les anciennes.

(On a tendance à considérer qu'il ne faut pas changer l'url et on risque de scier la branche sur laquelle on est assis !)
by (18.9k points)
 
Powered by Question2Answer
...