Il y a quelques mois j’avais installé Let’s Encrypt manuellement sur ma brique en suivant les instuctions ici : How to: Install Let’s Encrypt certificates
Tout fonctionnait très bien.
La semaine dernière, j’ai fais la mise à jour 2.5 de YUNoHost. Tout a continué de très bien fonctionner (sans que je ne touche à rien du côté de YUNoHost quant aux certificats), jusqu’à ce que je recoive cette notification (courriel) de cron :
/etc/cron.weekly/certificateRenewer:
Checking sousdomaine.mondomaine.tld certificate …
Needs to be renewed. Attempting to …
rm: impossible de supprimer « /tmp/cron-cert-renewer.log »: Aucun fichier ou dossier de ce type
An error occured, an email was sent.
/etc/cron.weekly/certificateRenewer: ligne 71: mail : commande introuvable
I manually installed my Let’s Encrypt certificates
You should go in your nginx configuration, and remove the letsencrypt.conf (or whatever you called the file containing the location ‘/.well-known/acme-challenge’ block) for each of your domains. Remove your certificate renewer cron job in /etc/cron.weekly/, and backup and remove your /etc/letsencrypt/ folder.
Then run :
yunohost domain cert-install your.domain.tld --force
for each of your domains you want a Let’s Encrypt certificate.
En faisant yunohost domain cert-install sousdomaine.domaine.tld --force, j’ai :
Erreur : Impossible de lire le fichier de certificat pour le domaine sousdomaine.domaine.tld (fichier : /etc/yunohost/certs/sousdomaine.domaine.tld/crt.pem)
J’arrive toujours à me connecter au serveur (brique) en ssh, mais j’ai un échec de connexion via un navigateur.
Je suis bien incapable de dire si tout est détruit ou si c’est une « bête » erreur. Je ne maîtrise pas la gestion des certificats donc je m’efforce de suivre du mieux possible des instructions, je n’ai sans doute pas appliqué les bonnes…
Est-ce que quelqu’un comprend la situation ? Je ne sais pas trop par où prendre le problème pour chercher des réponses.
L’erreur à propos de mail : commande introuvable est un peu bizarre (normalement tout aurait du continuer à marcher comme avant).
Par contre si tu souhaites effectivement migrer vers la nouvelle gestion de certificat incluse directement dans Yunohost, tu es sur la bonne voie. La commande donnée par la doc est un peu incorrecte (ma faute, j’avais pas testé ;D).
Merci pour la réponse !
J’ai réalisé en écrivant le message qu’effectivement le fait que j’associe ce erreur mail avec un problème de LE suite au passage à la 2.5 est pas forcément un diagnostic très logique.
Mais au final, autant faire la transition.
Traceback (most recent call last): File "/usr/bin/yunohost", line 217, in <module> timeout=opts.timeout, File "/usr/lib/python2.7/dist-packages/moulinette/__init__.py", line 139, in cli moulinette.run(args, output_as=output_as, password=password, timeout=timeout) File "/usr/lib/python2.7/dist-packages/moulinette/interfaces/cli.py", line 358, in run ret = self.actionsmap.process(args, timeout=timeout) File "/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py", line 484, in process return func(**arguments) File "/usr/lib/moulinette/yunohost/domain.py", line 271, in domain_cert_install return yunohost.certificate.certificate_install(auth, domain_list, force, no_checks, self_signed, staging) File "/usr/lib/moulinette/yunohost/certificate.py", line 154, in certificate_install _certificate_install_selfsigned(domain_list, force) File "/usr/lib/moulinette/yunohost/certificate.py", line 234, in _certificate_install_selfsigned _enable_certificate(domain, new_cert_folder) File "/usr/lib/moulinette/yunohost/certificate.py", line 781, in _enable_certificate _backup_current_cert(domain) File "/usr/lib/moulinette/yunohost/certificate.py", line 805, in _backup_current_cert shutil.copytree(cert_folder_domain, backup_folder) File "/usr/lib/python2.7/shutil.py", line 208, in copytree raise Error, errors shutil.Error: [('/etc/yunohost/certs/sousdomaine.domaine.tld/key.pem', '/etc/yunohost/certs/sousdomaine.domaine.tld-backups/20170219.172340/key.pem', "[Errno 2] No such file or directory: '/etc/yunohost/certs/sousdomaine.domaine.tld/key.pem'")]
Est-ce que c’est possible que le fait que les fichiers /etc/yunohost/certs/sousdomaine.domaine.tld/key.pem et crt.pem sont des liens symboliques joue là-dedans ?
Cf. le point 4 de l’installation manuelle de LE.
Ah ! Effectivement maintenant la première commande fonctionne , mais nginx semble avoir un problème. J’ai ça après avoir fait yunohost domain cert-install sousdomaine.domaine.tld --force --self-signed :
Attention : Impossible d’exécuter la commande « service nginx reload »
Succès ! Installation avec succès d’un certificat auto-signé pour le domaine sousdomaine.domaine.tld !
Je n’ai pas accès à la brique en HTTP, mais effectivement mon client mail me demande d’approuver un certificat autosigné pour la boite mail de ma brique.
Si j’essaie quand même la suivante yunohost domain cert-install sousdomaine.domaine.tld :
Erreur : Certificate installation for sousdomaine.domaine.tld failed !
Exception: [Errno 22] Il semble que le domaine sousdomaine.domaine.tld n’est pas accessible via HTTP. Veuillez vérifier que vos configuration DNS et nginx sont correctes
J’avais regardé nginx -t qui affichait ça (avant redémarrage) :
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
J’ai les logs des commandes systemctl status nginx.service et journalctl -xn d’avant redémarrage si ça aide pour une raison ou une autre (aucune idée de ce que c’est exactement, mais c’est la réponse que j’avais en faisant service nginx restart moi-même).
Mais donc là après reboot, la commande yunohost domain cert-install sousdomaine.domaine.tld fonctionne, nginx semble rouler aussi et j’ai accès à ma brique en HTTP (signé LE).
Apparemment il était planté bien avant que je lance la commande :
root@brique:~# systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
Active: failed (Result: exit-code) since dim. 2017-02-19 17:21:21 CET; 2h 12min ago
Process: 476 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
févr. 19 17:21:21 sousdomaine.domaine.tld nginx[476]: nginx: configuration file /etc/nginx/nginx.conf test failed
févr. 19 17:21:21 sousdomaine.domaine.tld systemd[1]: nginx.service: control process exited, code=exited status=1
févr. 19 17:21:21 sousdomaine.domaine.tld systemd[1]: Failed to start A high performance web server and a reverse proxy server.
févr. 19 17:21:21 sousdomaine.domaine.tld systemd[1]: Unit nginx.service entered failed state.
févr. 19 19:24:33 sousdomaine.domaine.tld systemd[1]: Unit nginx.service cannot be reloaded because it is inactive.
févr. 19 19:24:58 sousdomaine.domaine.tld systemd[1]: Unit nginx.service cannot be reloaded because it is inactive.
févr. 19 19:25:08 sousdomaine.domaine.tld systemd[1]: Unit nginx.service cannot be reloaded because it is inactive.
févr. 19 19:30:56 sousdomaine.domaine.tld systemd[1]: Unit nginx.service cannot be reloaded because it is inactive.
févr. 19 19:32:01 sousdomaine.domaine.tld systemd[1]: Unit nginx.service cannot be reloaded because it is inactive.
févr. 19 19:32:38 sousdomaine.domaine.tld systemd[1]: Unit nginx.service cannot be reloaded because it is inactive.
Sans doute quelque chose que j’ai fait à ce moment-là (17h21)…
Encore merci.
