Mais, en fait, le titre de ce bug est un peu incorrect, et la proposition de mortheres ne répond pas au vrai problème que l'on suppose.
En fait, on pense que, dans notre cas, l'agent ocsi ne devrait pas avoir besoin d'une copie du certificat du serveur car notre serveur utilise un certificat signé par TERENA (et UTN-USERFirst-Hardware encore au-dessus) et qu'il est configuré pour envoyer toute la chaine certifiante aux clients lors de leurs connexions (option SSLCertificateChainFile du serveur Apache).
Avec, cette config, l'agent est censé récupérer le certificat du serveur ainsi que toute la chaine certifiante (jusqu'à UTN-USERFirst-Hardware) à chaque connexion, et est donc capable de valider l'identité du serveur sans en avoir une copie en local.
Ce semble bien être le cas pour la partie inventaire de l'agent mais pas pour la partie download.
Hello,
Merci pour ton suivi.
Mais, en fait, le titre de ce bug est un peu incorrect, et la proposition de mortheres ne répond pas au vrai problème que l'on suppose.
En fait, on pense que, dans notre cas, l'agent ocsi ne devrait pas avoir besoin d'une copie du certificat du serveur car notre serveur utilise un certificat signé par TERENA (et UTN-USERFirst- Hardware encore au-dessus) et qu'il est configuré pour envoyer toute la chaine certifiante aux clients lors de leurs connexions (option SSLCertificateC hainFile du serveur Apache).
Avec, cette config, l'agent est censé récupérer le certificat du serveur ainsi que toute la chaine certifiante (jusqu'à UTN-USERFirst- Hardware) à chaque connexion, et est donc capable de valider l'identité du serveur sans en avoir une copie en local.
Ce semble bien être le cas pour la partie inventaire de l'agent mais pas pour la partie download.
Bien à toi,
Cyrille