Pb depuis exp du certificat racine Let'Encrypt

Question

Bonjour à tous,

Je travaille dans une petite société de service et nous utilisons OCS depuis bientôt 2 ans sans souci.

Depuis le 1er Octobre, nous n'avons plus aucune remontée de nos machines, cela coincide avec l'expiration du certificat racine "IdentTrust DST Root CA X3" de Let's Encrypt (que nous utilisons pour la connexion SSL.

L'accès web fonctionne normalement et aucune erreur n'apparait sur le certificat mais dans les log des agents Windows nous avons ce message:

AGENT => Sending Prolog

ERROR *** AGENT => Failed to send Prolog <SSL peer certificate or SSH remote key was not OK>

AGENT => Unloading communication provider

Y a t-il un moyen de régler cela sans repasser sur tous les postes clients ?

Si ce n'est pas le cas, pouvons-nous autoriser (c'est pas bien je sais) la communication avec un certificat non valide ?

Merci de vos retours et bonne journée.

David

Answer 1

C'est une question intéressante.
Je livre ma réflexion personnelle :
(j'écris HTP et HTPS au lieu des protocoles connus ... pour contourner une limitation de l'éditeur : il compte le nombre de ces 2 mots !)

Il y a l'agent qui accède à

- /ocsinventory pour remonter l'inventaire en HTP ou HTPS selon la ligne 'Server=', avec ou sans vérification (SSL=1 ou 0),

- /download pour récupérer les paquets, en HTP pour les fragments et en HTPS pour le fichier 'infos', (sans vérification ?) (a évolué pour 2.8/2.9 ?)

Il y a l'administrateur qui accède à /ocsreports interface d'administration.

Ma vision : utiliser 2 noms distincts et donc 2 virtualhost (exemple ocsadm.xxx et ocsinv.xxx)

- pour l'admin : en HTPS avec certificat let's encrypt + renouvellement auto

- pour l'agent : en HTPS avec certificat autosigné 10 ans, avec ou sans vérification SSL=1 ou 0

En fait, en HTPS, le certificat est un vrai problème !

S'il n'est pas vérifié (SSL=0), il ne sert à rien, et tout est plus facile.

S'il est vérifié (SSL=1) : il faut le générer puis le télé-déployer AVANT qu'il ne soit mis en place sur le serveur, les agents ne remontent plus rien dans l'intervalle, ni ne peuvent recevoir un télé-déploiement ! Il ne peut être question d'un certificat 'court' ! Et s'il est expiré, impossible de télé-déployer quoi que ce soit : on est bon pour 'psexec' ...

A l'install d'OCS, on (je) n'a pas conscience des problèmes que l'on va rencontrer à l'upgrade serveur, upgrade agent, péremption du certificat. La conception d'OCS est restée à l'état de l'art du moment, et la sécurisation avec https a beaucoup évolué dans le même temps (sslv3, tls1.0, tls1.1, longueur de clé de certificat : un certificat créé en 2007 est 'key too small' pour un Apache Debian Buster !). Si un 'joueur' veut 'pourrir' votre serveur, c'est assez facile ...

Enfin c'est juste ma réflexion ...

Answer 2

Ce qui résout immédiatement votre pb est de passer à SSL=0.

Sur un pc Windows, pour tester

- arrêter le service : sc stop "OCS Inventory Service"

- modifier le fichier de conf : notepad "%programdata%\OCS Inventory NG\Agent\ocsinventory.ini"

- redémarrer le service : sc start "OCS Inventory Service"

- lancer un inventaire par OCS Systray

Ensuite, vous pouvez utiliser 'psexec' pour copier ce fichier vers chaque pc (Windows). Sous Linux, ssh + script ...

Où alors, vous êtes déjà en SSL=0 et c'est un nouveau certificat qu'il faut copier !

-------------
Néanmoins, je suis sceptique que vous ayez pu utiliser un certificat Let's Encrypt pour l'Agent : normalement ils durent 90 jours ! Il vaut mieux un certificat à durée longue, à cause des difficultés à le changer, et donc ce sera plus simple d'utiliser un certificat autosigné : l'agent ne vérifie rien avec un certificat autosigné (qui provoquerait une alerte sur un navigateur récent).

Answer 3

Bonjour, merci pour votre retour.

La solution de se passer du SSL a effectivement été évoquée mais cela implique de repasser sur l'ensemble des postes de nos différents clients, cela est compliqué.

Pour le certificat, nous étions passé par Cerbot qui fonctionne avec Let's Encrypt.

Answer 4

Après avoir créé le serveur OCS, il faut déployer l'agent.

Il y a plusieurs méthodes plus ou moins facile : la plus efficace AMHA est de passer sur chaque micro (Windows) et d'exécuter un script .cmd, en tant qu'admin, qui exécute le pgm d'install de l'agent avec les /options qui vont bien. (Evidemment avec 5000 machines ...)
(pour moi : /S /NOSPLASH /NO_SYSTRAY /TAG= /SERVER= /SSL= /CA= /NOW). (Quand vous voudrez upgrader l'agent vous ajouterez /UPGRADE.)

En alternative, il y a 'psexec' qui permet d'avoir une ligne de commande en admin sur chaque pc allumé. (Usuellement vous lancerez juste le script présent sur un partage Windows accessible.)

Je vous conseille de regarder cette commande 'psexec' : https://docs.microsoft.com/en-us/sysinternals/downloads/psexec : c'est en gros, pour les PC windows d'un domaine,  l'équivalent de ssh sous Linux. Vous verrez c'est facile .... Et ça fonctionne pour 5000 machines ...

Avec 'psexec', vous pouvez arrêter le service, copier le cacert.pem et le fichier de conf puis redémarrer le service sur n'importe quel PC Windows allumé de votre parc/domaine, sans quitter votre chaise :
psexec \\MACHINE -u DOMAINE\Administrateur -p pwd call \\SRV\PARTAGE\script.cmd

Answer 5

Il y a un élément que je n'ai pas pris en compte : vous réalisez l'inventaire des parcs de vos clients. De facto, ces matériels ne sont pas chez vous !

Dans un tel contexte, il y a 2 schémas :

- un serveur commun pour tous vos clients, avec trafic agents -> serveur via Internet,

- un serveur dédié chez chaque client ou pour chaque client.

Dans le cas 1, le trafic ne peut être sérieusement qu'en HTPS et un certificat autosigné reste acceptable AMHA, mais il faut bien proposer 2 virtualhost pour avoir un certificat Let's Encrypt sur la partie Administration. AMHA je mettrais une protection d'accès par user/mdp et .htpasswd (avec 1 couple user/mdp par client).

Dans le cas 2, c'est un serveur interne managé par vous, et c'est plus facile.

Dans tous les cas, le certificat étant expiré, c'est mort : il vous faudra modifier pc par pc la config : là, il faut anticiper, pour ne pas avoir à y revenir ...

-----------------------

J'ai du mal à voir la mutualisation de l'outil :
- si le client a un accès, comment lui limiter, de façon certaine, la consultation à son seul parc ?

- quid des télé-déploiements, comment être certain de ne pas télé-déployer un paquet destiné à un client sur les matériels d'un autre client ?

Ou alors, il faut chez vous 1 serveur par Client : avec un reverse proxy, pas de problème même avec une seule ip.

(Il y a l'idée de 'OCSPro' sur marketplace OVH par l'éditeur d'OCS FactorFX : 1 VM publique = 1 client = facturation par palier de nb de machine.)

Answer 6

Bonjour,

Merci encore pour vos réponses.

Oui nous sommes bien dans le cas numéro 1.

Nous hébergeons le serveur OCS dans nos locaux et nous faisons remonter les agents sur le même serveur avec des Tags différents par clients.

Quand les clients souhaitent avoir accès à leurs machines, nous leur créons un compte et filtrons sur le Tag.

Le certificat Let'sEncrypt a certe une durée courte, mais le fait de passer par Cerbot, celui-ci est renouvelé automatiquement (fonctionne comme ca depuis pratiquement deux ans) là il semble que ce soir l'expiration du certificat racine qui pose problème...

Answer 7

Le tag associé au compte utilisateur permet de limiter les listes de matériels à un groupe donné, c'est connu et fait pour. Mais est-ce bien 'solide' ? Je n'en suis pas certain ...

Néanmoins l'idée de séparer, par dns distincts, administration (/ocsreports) et inventaire (/ocsinventory) reste une bonne idée, car, pour le premier vhost, un certificat Let'sEncrypt fait parfaitement l'affaire alors que le certificat autosigné longue durée est bien adapté au second vhost. Toutefois SSL=0 permet de faire du HTPS sans vérif de certificat.

Allons même plus loin : les 2 vhosts pourraient/devraient être limités aux ip publiques des différents clients, avec un 'Allow from', pour bien les limiter aux clients. Voire pour chaque client un dns spécifique au client les limitera encore plus ...

Concernant le certificat cacert.pem, comme celui-ci est juste le certificat présenté par le serveur web, une tâche de récupération auto permettrait de la mettre à jour à 'tout coup' : sous Linux, 'echo -n | openssl s_client -connect host:443 | openssl x509 >cacert.pem', je n'ai pas trouvé d'équivalent simple sous Windows ... Mais là on change l'utilisation ...