YunoHost 2.5.0 Beta - Call for beta-testers and translators

Okay, merci pour le test et le feedback ! Quelqu’un d’autre a rencontré un bug similaire avant toi je crois, j’ai donc ouvert un ticket sur le bugtracker : https://dev.yunohost.org/issues/671

A+ !

@Moul @Bram @CaptainSqrt2,

Suite à l’upgrade v2.4.x à v2.5.2, j’ai certifié mon domaine principal via le panel et Let’s Encrypt.
J’ai fait un test sur ssl labs https://www.ssllabs.com/ssltest/ et j’obtiens un score à “B” car “This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. MORE INFO” > https://weakdh.org/ | https://weakdh.org/sysadmin.html (chercher la rubrique nginx).
Je ne m’y connais pas du tout dans ce genre de chose, mais si ça peut aider à faire évoluer la v2.5.x … :wink:

ppr

1 Like

Oep, on est au courant. C’est un problème différent que celui de gérer le certificat. Il y a un ticket ouvert depuis pas mal de temps dessus : https://dev.yunohost.org/issues/92 . Il traine quelque part dans ma todo… Le problème est surtout lié aux architectures “lentes” (e.g. Raspi / Briques) sur lesquelles ça prends du temps. Mais on devrait finir pondre un truc qui fait le taf ;).

Et je confirme que ça prends vraiment longtemps… (faut lancer avant d’aller dormir ^^)
De mon côté j’ai “résolu” le problème en désactivant les ciphers DH, je garde que celles à base de ECDHE.
Donc c’est pas compatible avec tout les navigateurs, mais pour du logiciel relativement récent (type navigateur de moins de 5ans) ça passera sans encombre - et ça convient pour mon matériel.
(Je donne l’information comme ça, je suppose que pour yunohost c’est pas la meilleure solution ^^)

1 Like

Pas nécessairement si on utilise les bonnes options et qu’on a de bonnes sources d’entropies sur la machine :P. Dans le post du ticket, je mentionne justement que l’option -dsaparam permet de générer les paramètres DH beaucoup plus vite, sans réduire la sécurité (d’après le milieu universitaire). Avec les tests que j’ai fait, cela prennait ~1 minute sur un Raspi 2 pour des paramètres de 2048bits.

Si, ça c’est intéressant, je ne savais pas que les paramètres DH étaient liés à des ciphers particuliers ! Il y a un autre ticket ouvert qui propose de mettre en place un système pour choisir les ciphers que l’on veut activer. (Et perso j’aurais tendance à croire que peu d’utilisateurs Yunohost sont intéressés par le fait de supporter des navigateurs vieux de plus de 5 ans)

Pour l’entropie c’est bon, par contre pour les options je suis curieux d’essayer. Mais va falloir que je regarde ce que fait cette option, ça semble trop simple ^^
1 min sur un raspberry 2 ? Alors ça vaut clairement le coup par défaut, c’est un peu long mais avec les bons logs (un petit message l’indiquant par exemple) ça me semble peu problématique.

Je suis loin d’être un expert sur le sujet, mais de ce que j’en ai lu/compris, seules les cipher DHE bénéficient de cette clé que l’on génère, pas les ECDHE.

J’ai dis ça à la louche, SSL Labs indiquerait même plus vieux, en gardant TLS 1.0. (je l’ai fais quand même, sait-on jamais ça pourrait dépanner, même si j’ai configuré nginx pour qu’il passe en priorité par TLS 1.2)
Voilà ce que ça donne chez SSL Labs, avec d’autres paramétrages certes mais pas grand chose de plus (je suis passé de A à A+)

Comme paramétrage par défaut, ça me semble déjà bien ^^

Je peux m’occuper de la traduction en allemand.

Awesome! I’ll go and upgrade in a bit. But do I need to remove the LE application first before the upgrade?

Yunohost should ask you to if you attempt to use the new built-in feature. (We’re actually pretty interested in knowing if it does indeed ask you it correctly, especially from the yunohost-admin where some weird bug is present at the moment :P)

Super, merci :heart:

Yes, as specified, otherwise YunoHost will tell you to do so and refuse to execute its LE code.

This core integration of LE in YunoHost as been done by the same person than the one who did the application :slight_smile:

I’ve upgraded to the 2.5.0 beta, and removed the LE plugin after upgrade. Turns out the plugin didn’t uninstall properly because it left the same config and did not fully remove the certificate references. Which, obviously, led to nginx complaining about the cert not existing. Attempting to access the interface gave a “Address unavailable.mjk” I solved this by using “certbot certonly” with standalone option and nginx started successfully.
Yunohost’s CLI tool itself actually complained about nginx not being up when trying to cert-install a domain. Once the issue was fixed, I got this:
```
Warning: Unable to execute command 'service nginx reload’
Success! The SSOwat configuration has been generated
Error: Wrote file to /tmp/acme-challenge-public/Tq2lepjs2Sk5fKUeggnZ0F9WmZdOCq3FRbkNDmOGrsU, but couldn’t download http://gandalf.kthxbai.xyz/.well-known/acme- challenge/Tq2lepjs2Sk5fKUeggnZ0F9WmZdOCq3FRbkNDmOGrsU
Error: Certificate installation for gandalf.kthxbai.xyz failed !
Exception: [Errno 22] Signing the new certificate failed

1 Like

But what should be test ? I guess installing a LE certificate when you have nothing else works if it works after removing the app (I suppose it’s the same process) - but shouldn’t we test the uninstallation after, to ensure a migration could be done smoothly ?

Hm, not cool, I was worry that would happen to some people :confused: . Do you happen to have some log specifically for what went wrong in the uninstall of the app ?

I looked in the yunohost-api logs (/var/log/yunohost/yunohost-api.*) and found logs of the LE plugin being removed.
I’ve pasted them into a gist: https://gist.github.com/xshotD/c0999cb4071f7bb31689ae1eef53bf6f

Thanks a lot ! Sounds like for some reason, a particular domain didn’t have a backup of the previous certificate, and ended up with a nginx configuration pointing to certificate that doesn’t exist (it always points to /etc/yunohost/certs/domain.tld/*.pem and .crt, but there were none).

Not sure how to properly handle that … But I think user should be able to force the install of a new cert after that, using the builtin LE feature, with something like yunohost domain cert-install --force I think. We should document that probably - I was thinking about doing a FAQ for the LE feature.

Passage de 2.4 à 2.5 s’est passé comme une lettre à la poste !

une fois à jour, j’ai viré l’app LE, puis "yunohost domain cert-install " et 1 min après tout va bien !

Bref j’ai rien à re dire tellement c’était smooth !

Hello,

J’ai également passé mon serveur en 2.5 beta. Install sans problème.
Concernant Let’s encrypt, c’était un peu le bordel dans mes domaines car j’avais déjà modifié mes conf nginx mais les infos données par yunohost étaient correctes. J’ai reset le tout en forçant un regen-conf puis tout est passé sans problème.
Testé également via l’interface web pour de nouveaux sous domaines et tout fonctionne très bien.

Deux petits truc dommage mais pas bloquant :

  • On devrait pouvoir choisir directement à la création du domaine que l’on veut un certificat let’s encrypt avec. Ca éviterait d’avoir à le faire en 2 temps.
  • Pour moi les clés Diffie-Hellman devraient êtres générées et activées par défaut à l’install de yunohost, ou alors pouvoir choisir le template nginx que l’on utilise (pouvoir les surcharger ?).

Bref bravo à l’équipe pour la release !

On avait choisi de pas le faire finalement car on a aucune garantie que le domaine soit correctement configuré au moment de la création (et c’est même souvent rarement le cas vu que les DNS mettent du temps à être mis à jours).

À terme je vois bien un daemon/cronjob chargé de passer automatiquement tous les domains auto-signé non piné à LE mais on va déjà commencer par avoir un truc blindé :slight_smile:

Sur du petit matériel c’est méga long, genre en dizaines de minutes, on ne peut pas se permettre ça. Là on test avec jesaisplusquoi pour améliorer grandement le temps, peut être que ça rendra ça réaliste. Pour les templates à surcharger ça viendra quand on aura une config global pour YunoHost je pense (j’ai un proto qui traine mais qui est pas encore 100% fonctionnel).

1 Like

C’est pour ça que je pensais à un choix, genre case à cocher dans l’interface admin et un flag dans la CLI. Même dans le fonctionnement actuel on a aucune garantie que le domaine soit correctement configuré lorsque l’on demande un certificat. Si c’est mal configuré ça va planter tout simplement.
Pour le “rarement le cas” je ne suis pas d’accord, pour mon cas par exemple c’est toujours le cas car j’ai un wildcard sur mon domaine qui pointe vers mon instance yunohost, donc quand je créé un sous domaine c’est ok directement. Et d’une manière générale je configure les DNS avant de rajouter le domaine dans yunohost.

Personnellement qu’il y ait une action un peu longue à la 1ère install de yunohost ne me choque absolument pas, surtout qu’on parle quand même de sécurité. Une autre solution serait de livrer avec yunohost un fichier de clé pré-généré (donc insecure) et de lancer une tache en background non bloquant pour l’install qui se charge de les régénérer et de faire un reload nginx à la fin

C’est ton usage d’utilisateur déjà très averti. (précision: ce n’est pas une remarque cinglante hein :slight_smile: )
Yunohost ce veux accessible, et l’utilisateur “labmda” sera plutôt celui qui récupérera son nom de domaine chez OVH, Gandi ou 1&1 par exemple - ou chez son asso locale, qui fera peut-être de même.
Donc avec un DNS qui ne sera pas près de suite de suite.
Je pense que c’est ce à quoi bram faisait référence, penser à avoir son nom de domaine et les DNS réglés dès l’installation, une majorité d’utilisateur ne l’aura pas fait.
Donc au final, ça ne désavantage pas vraiment l’utilisateur avancé - certes c’est en 2 temps, mais sans que ce soit une grosse contrainte - et c’est mieux pour l’utilisateur peu technique - qui ne comprendrait pas une erreur si tôt dans le processus.

Une dizaine de minutes ça fait quand même beaucoup au moment de l’installation (en plus du reste). Ça peut être très frustrant - voir faire penser à un problème.
NB: sur un raspberry pi 3 la dernière fois il m’a fallut 38 min… (malgré une bonne entropie)

Et certes c’est mieux en terme de sécurité, mais pas non plus fondamental, la sécurité de la connexion par défaut est déjà bonne.