Matériel: Raspberry Pi 3b+ à la maison Version de YunoHost: 4.0.2 J’ai accès à mon serveur : En SSH | Par la webadmin Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Description du problème
Bonjour,
Cela fait 3 jours que j’essaie en vain d’installer un certificat SSL via l’interface Web de Yunohost et j’ai tout le temps le même résultat, le script d’installation plante sur la vérification du certificat.
Cependant je n’arrive pas à déterminer si le souci est standard où s’il vient de la v4.
Merci d’avance du temps à tous ceux qui chercheront la solution à mon problème.
Ci-dessous la fin du log du journal, là où ça plante.
2020-06-26 09:41:27,251: DEBUG - Journal complet de cette opération : '<a href="#/tools/logs/20200626-074125-regen_conf-dnsmasq" style="text-decoration:underline"> Régénérer les configurations du système 'dnsmasq' </a>'
2020-06-26 09:41:27,300: DEBUG - Prepare key and certificate signing request (CSR) for maindomain.tld...
2020-06-26 09:41:30,794: DEBUG - Saving to /tmp/acme-challenge-private/maindomain.tld.csr.
2020-06-26 09:41:30,796: DEBUG - Now using ACME Tiny to sign the certificate...
2020-06-26 09:41:30,797: INFO - Parsing account key...
2020-06-26 09:41:30,831: INFO - Parsing CSR...
2020-06-26 09:41:30,863: INFO - Found domains: xmpp-upload.maindomain.tld, maindomain.tld
2020-06-26 09:41:30,865: INFO - Getting directory...
2020-06-26 09:41:31,201: ERROR - Error getting directory:
Url: https://acme-v02.api.letsencrypt.org/directory
Data: None
Response Code: None
Response: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)>
2020-06-26 09:41:31,203: ERROR - Certificate installation for maindomain.tld failed !
Exception: Impossible de signer le nouveau certificat
C’est spécifique à l’image raspberry Pi de la v4 … il y a un soucis chelou avec les autorités de certif que j’ai pas encore totalement identifié … Tu peux tenter un apt install ca-certificates --reinstall, mais j’suis pas convaincu
J’avais réussi à fixer le soucis mais je ne sais pas plus comment donc il faut que je refasse des tests …
Note que normalement tu peux reproduire le soucis juste en faisant par exemple “curl https://fr.wikipedia.org/”, pas besoin de faire tout le schmilblki avec Yunohost
J’ai bien la même erreur dans les deux cas, mais qui n’est pas exactement la même que celle du journal de yunohost.
Par contre quand j’utilise :
curl -k https://acme-v02.api.letsencrypt.org/directory
J’ai le même retour que dans un navigateur.
Je cherche donc le script qui lance l’installation du certificat let’s encrypt pour le modifier et tester mais je ne le trouve pas. Tu as une idée ?
Wokay mais l’option -k c’est pour insecure, c.a.d. ignorer les verifications de certificat … oui ça marche, mais c’est une solution aussi acceptable que de balancer un grand coup de marteau à chaque fois que tu es devant une porte vérouillée.
— Mais … Mais pourquoi t’as défoncé la porte d’entrée t’es malade ?!
— Ben quand j’appuyais sur la clanche ça s’ouvrait pas alors j’ai fait un trou pour pouvoir passer, c’est pas comme ça qui faut faire ?
— Mais pourquoi t’as pas utiliser la clef !?
— Bah faire un trou ça marche aussi non ?
Bref, et dans le scrip d’install c’est en python donc ça n’utilise pas curl donc c’est pas la même option …
Je suis d’accord avec toi.
C’est pour ça que j’avais des réticences à l’utiliser mais en y réfléchissant, je me disais que je pouvais faire confiance au site qui donnait les certificats non ?
Par contre je voudrais bien comprendre pourquoi je n’ai pas de problème avec mon navigateur alors qu’avec un appel curl ça ne fonctionne pas…
Ah le script n’utilise pas Curl… mais il y a peut-être une autre solution.
Tu aurais l’emplacement du script d’installation que je regarde comment il fonctionne s’il te plaît ?
Ben c’est bien le soucis … comment est-ce que tu es sur que le site que tu contactes est le bon ? Quand tu te connectes à ta banque, qu’est-ce qui t’assure que c’est le vrai site de ta banque et pas un site qui fait “comme si” c’était ta banque. La réponse à ça c’est : le certif. Maintenant dans ton cas on a identifié que c’était pas une attaque et c’est juste un soucis dans la config des certifs en local, mais il n’empêche que la solution moyen-terme / long-terme c’est pas de dire “osef des certifs” dans le code.
Parce que le curl a lieu sur ton serveur et c’est là qu’il y a un soucis de config des certifs d’autorité de certification
Oui mais non, autoriser les requêtes non sécurisée, par définition, ça va à l’encontre de tous les principes de sécurité. Donc non, faut pas.
Hum, du coup il vaudrait mieux me renseigner sur la configuration des “certifs d’autorité de certification” dans ce cas
Tu aurais un point de départ pour moi, un site qui expliquerait ça ?
Alors après avoir décortiqué le code source de acme tiny, certificate.py et la doc de urlopen, j’ai trouvé une solution pour résoudre mon problème.
Maintenant j’aimerais savoir si tu peux me la valider, comme j’ai un chemin en dur dans un script et c’est assez moyen je trouve.
Mon installation de certificat a marché et j’ai même pas essayé de le faire en insecure
J’ai modifié le script acme_tiny.py pour inclure le chemin vers le fichier de tous les certificats concaténés.
J’ai ajouté ça en haut du script (c’est cette partie que j’aime pas trop) :
Oui ta solution marche et est similaire à un autre “fix” pour curl qui consiste à rajouter -cafile /etc/ssl/certs/ca-certificates.crt
Néanmoins pour Yunohost en général, ça reste un fix ad-hoc sur une commande / ligne de code précise et c’est pas une solution générale. D’autres bouts de code sur le système ou dans les apps peuvent dépendre des même genre de lib et rencontre le même problème, et s’amuser à patcher chaque bout de code de chaque app n’est pas une solution réaliste.
Le truc c’est que ce bug n’est présent que sur les images RPi Buster préinstallée avec Yunohost, donc il y a sans doute un truc à comprendre … J’ai cherché hier pendant des heures mais pas trouvé >.>
Les images pour les autres machines fonctionnent correctement ?
Y compris pour des machines sous debian buster avec du python 3 ?
Parce que je ne vois pas en quoi l’installation sur un RPI serait si différente en terme d’architecture.
Sinon j’ai essayé d’installer bitwarden sur mon yunohost RPI et j’ai l’impression qu’il y a le même genre de souci mais avec curl cette fois-ci.
Arf … est-ce que avant de faire ça depuis l’installation tu as fait des choses particulières ? Perso j’ai essayé de bricoler cette commande l’autre jour plein de fois et ça n’avais rien donné…
J’avais essayé d’installer PHPMyAdmin qui avait donc planté sur un appel curl.
Après j’avais fait d’autres tests hier également.
J’avais placé une nouvelle variable environnement dans /etc/environment
Mais je l’avais retiré ensuite car ça ne fonctionnait pas.
J’ai également ajouté un nouveau domaine (enfin plutôt un sous-domaine) dans YunoHost mais je ne sais plus si c’était avant ou après mon update-ca-certificates.
Zblerg ben du coup nope, ajouter le lien symbolique (+ update-ca-certificates) n’a pas l’air de fixer le truc … J’ai toujours curl qui arrive pas à trouver l’émetteur (issuer) des certificat.
Est-ce que tu te souviens d’autre chose ? Est-ce que la commande env montre des chose particulière par rapport aux certificats ?
Je viens de penser aussi à quelque chose.
Au moment de l’update-ca-certificates, j’avais par contre déjà un certificat valide pour mon domaine que j’avais obtenu en ayant préalablement modifié le code de acme tiny comme dans ma proposition plus haut dans la discussion avec cafile.
Cela dit, au moment de l’update, j’avais rétabli le code original de acme tiny et fait un reload de yunohost-api. Donc il n’était plus pris en compte normalement.
Je vais donc attendre un peu et si j’ai le temps je creuserai également.