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
Sous-tâches
Demandes liées
Historique
#1 Mis à jour par Fabrice Barconnière il y a environ 5 ans
- Tracker changé de Demande à Scénario
- Sujet changé de diagnose des certificats étrange à diagnose des certificats doit prendre en compte les CA natives si on ne spécifie pas de CAFILE ($4)
- Début
28/03/2019supprimé - Release mis à EOLE 2.6.2.2
- Points de scénarios mis à 1.0
#2 Mis à jour par Gilles Grandgérard il y a plus de 4 ans
- Echéance mis à 20/09/2019
- Version cible mis à sprint 2019 36-38 Equipe MENSR
- Début mis à 20/08/2019
#3 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Echéance
20/09/2019supprimé - Version cible
sprint 2019 36-38 Equipe MENSRsupprimé - Début
20/08/2019supprimé - Release changé de EOLE 2.6.2.2 à Carnet de produit (Cadoles)
#4 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Description mis à jour (diff)
#5 Mis à jour par Gilles Grandgérard il y a plus de 4 ans
- Description mis à jour (diff)
#6 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Lié à Tâche #23543: Let's Encrypt et diagnose ajouté
#7 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Description mis à jour (diff)
#8 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Echéance mis à 11/10/2019
- Version cible mis à Prestation Cadoles 39-41
- Début mis à 23/09/2019
#9 Mis à jour par Philippe Caseiro il y a plus de 4 ans
- Assigné à mis à Philippe Caseiro
#10 Mis à jour par Philippe Caseiro il y a plus de 4 ans
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 Mis à jour par Fabrice Barconnière il y a plus de 4 ans
<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 Mis à jour par Fabrice Barconnière il y a plus de 4 ans
- Lié à 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) ajouté
#13 Mis à jour par Fabrice Barconnière il y a plus de 4 ans
- Statut changé de Nouveau à Terminé (Sprint)
#14 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Release changé de Carnet de produit (Cadoles) à EOLE 2.7.1.2