Scénario #27453
diagnose des certificats doit prendre en compte les CA natives si on ne spécifie pas de CAFILE ($4)
Description
Dans /usr/share/eole/diagnose/05-common il y a "TestCerts $server_cert 10 "certificat expiré"".
Dans la fonction TestCerts il y a :
if [ -z "$4" ]; then
echo "$CERTFILE" | grep -q '^/etc/ipsec.d/'
[ $? = 0 ] && CAFILE=/etc/ipsec.d/cacerts/CertifCa.pem || CAFILE=/etc/ssl/certs/ca.crt
On est bien dans ce cas puisque $4 n'est pas défini. Donc CAFILE est /etc/ssl/certs/ca.crt.
On a ensuite :
if [[ -d ${CAFILE} ]]
then
cat ${CAFILE}/* > ${TMPFILE}
CAFILE=${TMPFILE}
fi
Je vois pas bien pourquoi un fichier CAFILE deviendrait tout d'un coup un répertoire mais admettons.
Après nous avons :
ssl_cmd="/usr/bin/openssl verify -CAfile $CAFILE -CApath $FAKE_CAPATH -purpose any $CERTFILE"Donc le certificat n'est validé que sur la CA généré localement pour les certificats auto signés :
. cadoles.crt => Erreur : self signed certificate
Si je lis la documentation :
Après génération de la CA locale, un fichier /etc/ssl/certs/ca.crt est créé qui regroupe les certificats suivants :
ca_local.crt ;
ACInfraEducation.pem ;
tout certificat présent dans le répertoire /etc/ssl/local_ca/
Le problème c'est que mon certificat est signé pour une CA nativement reconnu sur Ubuntu (donc n'est pas dans local_ca).
Solutions à mettre en œuvre¶
- prendre en compte les CA local lors du test du certificat (ca me semble mieux).
- Corriger le test diagnose pour qu'il soit fonctionnel dans tous les cas
Critères d'acceptation¶
- diagnose correct
Subtasks
Related issues
History
#1 Updated by Fabrice Barconnière over 4 years ago
- Tracker changed from Demande to Scénario
- Subject changed from diagnose des certificats étrange to diagnose des certificats doit prendre en compte les CA natives si on ne spécifie pas de CAFILE ($4)
- Start date deleted (
03/28/2019) - Release set to EOLE 2.6.2.2
- Story points set to 1.0
#2 Updated by Gilles Grandgérard about 4 years ago
- Due date set to 09/20/2019
- Target version set to sprint 2019 36-38 Equipe MENSR
- Start date set to 08/20/2019
#3 Updated by Joël Cuissinat about 4 years ago
- Due date deleted (
09/20/2019) - Target version deleted (
sprint 2019 36-38 Equipe MENSR) - Start date deleted (
08/20/2019) - Release changed from EOLE 2.6.2.2 to Carnet de produit (Cadoles)
#4 Updated by Joël Cuissinat about 4 years ago
- Description updated (diff)
#5 Updated by Gilles Grandgérard about 4 years ago
- Description updated (diff)
#6 Updated by Joël Cuissinat about 4 years ago
- Related to Tâche #23543: Let's Encrypt et diagnose added
#7 Updated by Joël Cuissinat about 4 years ago
- Description updated (diff)
#8 Updated by Joël Cuissinat about 4 years ago
- Due date set to 10/11/2019
- Target version set to Prestation Cadoles 39-41
- Start date set to 09/23/2019
#9 Updated by Philippe Caseiro about 4 years ago
- Assigned To set to Philippe Caseiro
#10 Updated by Philippe Caseiro about 4 years ago
Bonjour
Je viens de passer la matinée à analyser la situation, et pour y voir plus clair, voici un résumé.
Lorsqu'on utilise un certificat "acheté" ou "fournis" par une autorité, on passe le serveur en mode "Manuel" actuellement dans ce mode nous sommes incapables de vérifier la validité du certificat car notre méthode de vérification se base sur des CA locales. Problème supplémentaire si on utilise un certificat signé par une autorité intermédiaire (TERENA par exemple) nous ne sommes pas en mesure de vérifier le certificat car nous n'avons pas cet intermédiaire.
Dans le cas évoqué par Emmanuel, nous avons un certificat TERENA et nous avons placé l'autorité intermédiaire dans le fichier indiqué dans la variable server_pem donc si j'utilise ce fichier, je peut vérifier le certificat mais c'est valable pour notre cas et pas forcément dans le cas général.
Donc pour avancer sur le sujet, je propose qu'en mode manuel dans diagnose nous indiquions l'autorité de certification ainsi que la date limite du certificat et une alerte quand elle se rapproche, et uniquement en mode manuel. Cette proposition change légèrement la demande, pouvez-vous me valider cette proposition ?
Merci.
#11 Updated by Fabrice Barconnière about 4 years ago
<Puppet_Master> Bonjour
<Puppet_Master> jojo2024: https://dev-eole.ac-dijon.fr/issues/27453
<Puppet_Master> pour avis et validation
<Puppet_Master> merci
<Puppet_Master> je suis dispo au téléphone si besoin
<jojo2024> Puppet_Master: on regarde
<Puppet_Master> merci jojo2024
<barco> Puppet_Master: il me semble qu'un service ne peut pas fonctionner s'il n'a pas toutes les CA intermédiaires
<barco> donc la variable server_pem doit faire référence à la chaîne dans tous les cas, non ?
<Puppet_Master> barco: pas forcément par contre on peut avoir des services ou du coup le certificat n'est pas considéré comme valide
<Puppet_Master> si t'as pas toute la chaine
<barco> Puppet_Master: en tout cas, openssl en a besoin pour vérifier le certificat. Je n'ai pas de service en tête qui n'aurai pas besoin des CA intermédiaires.
<Puppet_Master> barco: tu peux mettre à jour la demande, je bosse déjà sur une version spécifique du diagnose pour le mode "manuel" je vais ajouter la vérfication avec le chain.pem
<Puppet_Master> enfin avec la chaine quoi
<Puppet_Master> merci barco
#12 Updated by Fabrice Barconnière about 4 years ago
- Related to Tâche #29041: Validation du scénario : diagnose des certificats doit prendre en compte les CA natives si on ne spécifie pas de CAFILE ($4) added
#13 Updated by Fabrice Barconnière about 4 years ago
- Status changed from Nouveau to Terminé (Sprint)
#14 Updated by Joël Cuissinat almost 4 years ago
- Release changed from Carnet de produit (Cadoles) to EOLE 2.7.1.2