[Résolu] Letsencrypt, impasse OVH également

[mjeanne]

Le seul moyen de démarrer apache est de supprimer le contenu de /etc/apache2/sites-available

Non, il suffit de désactiver les éléments qui ne fonctionnent pas et/ou corriger les erreurs.

Impossible de lancer certbot-auto, je me heurte toujours à ce message:

Normal, puisque votre apache n'est pas fonctionnel

Vous cherchez a corriger apache en créant un nouveau certificat, alors qu'il vous faut apache pour cette création. C'est le serpent qui se mord la queue.
Laissez tomber les certificats le temps de remettre apache en fonctionnement.
Ne supprimez rien dans le dossier 'sites-available', c'est dans le dossier 'sites-enable' qu'il faut activer ou non une config. Cela se fait via la commande 'a2dissite'

Dans un premier temps, listez le contenu de 'sites-enable' pour voir combien de configs sont chargée au démarrage d'apache. Ensuite désactivez les toutes sauf '000-default.conf' (commande 'a2dissite' suivi de 2 tabulation pour les lister, ou suivi du nom pour desactiver).
Editez la config '000-default.conf'. Normalement, elle ne devrait pas contenir grand chose. Ceci devrait suffire:

Code : Tout sélectionner

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog /var/www/html/log/http.error
</VirtualHost>

A partir de la, Apache doit redémarrer (sans https). C'est la config la plus simple.

[Gouzou]

(EDIT en fin de post pour réponses croisées)

Je reviens sur le problème de certificat.

En effaçant tout et en reprenant ton 000-default.conf, j'avais les mêmes erreurs...

Reboot multiples, test de fichiers vides, rien.

Et en retentant tout à zero avec ton fichier il y a 5 minutes, certificat genéré et j'ai de beaux fichiers conf tout neufs... Weird, mais connection ssl ok, incroyable!

Je résume les dernières étapes qui ont je pense tout solutionné:

supprimer tout dans /etc/apache2/sites-available et enabled sauf 000-default.conf (et le raccourci associé)
éditer 000-default.conf et y mettre la config proposée par poluket (merci encore pour l'aide au passage)

Code : Tout sélectionner

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog /var/www/html/log/http.error
</VirtualHost>

Relancer apache et la machine jeedom une bonne 15aine de fois sur 3-4 jours en pestant et navigant sur 9gag pour décompresser.
Router correctement les ports

dans /etc:
./certbot-auto --standalone -d xxxxxx.truc

certbot va recréer les autres fichiers

Code : Tout sélectionner

Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf

Congratulations! You have successfully enabled https://xxxxx.truc

Et tout remarche après un reboot, telegram (avec tout en double comme d'hab, cf post sur le sujet , IFTTT, etc.

Merci à vous

Je passe en résolu, bonne soirée

EDIT: Je tapais ma réponse et ai loupé le dernier post de mjeanne, qui résume bien la situation. Merci à toi aussi du coup. J'avais bien saisi le coté paradoxal de la situation, mais quand on est limite en CLI, même avec beaucoup de motivation et des nuits courtes, on tatonne beaucoup.
Bref, d'avoir retourné le soucis dans tous les sens m'a au moins permis de dégrossir le sujet apache, httpd, certificats et processus.

[Gouzou]

One more thing:
Comment on change le texte du sujet pour le passer en resolu?....

[poluket]

De rien, avec plaisir. Tu édites ton premier message

[Gouzou]

J'y vais
Bonne soirée à tous

[thxmono]

Merci pour l'astuce !!
J'avais complètement planté mon apache et problème résolu grâce à vos messages.
Enfin le SSL sur mon jeedom

[LuluDom]

Merci aussi mjeanne ! La commande a2dissite m'a sauvé.

[LuluDom]

Bon ! J'ai refait depuis zéro mon certificat Letsencypt la semaine dernière qui est parti pour 3 mois... mais il est encore TLS et donc non sécurisé...

Je dois tout recommencer mais je ne sais pas où trouver la bonne procédure pour ce faire du coup.

J'ai utilisé celle-ci la semaine dernière qui pourtant annonce du HTTP-01 et non du TLS :
EDIT :
Pour tenter de révoquer l'ancien certificat :
https://www.domo-blog.fr/securiser-jeed ... http-01/2/
Pouyr créer le nouveau :
https://domohab.be/index.php/2019/02/08 ... -internet/

Comme j'ai eu un problème lors de la révocation du précédent certificat sur la même adresse https, peut-être que mon problème est là.

Au passage : j'ai trouvé un site de test du HTTPS super pratique :
https://www.whynopadlock.com/

[Salvialf]

Salut,

Pour la révocation de l'ancien certificat, il y a de mémoire 2 fichiers à supprimer... c'est ce que tu as fait?

EDIT: Je n'avais pas vu que c'était écrit quelques messages plus haut sur TapaTruc.

[LuluDom]

Salut,

Pour la révocation de l'ancien certificat, il y a de mémoire 2 fichiers à supprimer... c'est ce que tu as fait?

Oui, après la commande demandée

Code : Tout sélectionner

sudo /opt/letsencrypt/letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/domaine/fullchain.pem

qui n'avait pas fonctionné, ce qui avait fait planter mon apache, impossible à relancer jusqu'à ce que je trouve la solution que je redonnais quelques posts plus haut.

Bizarre mais j'ai fait un cerbot renew et mon site est de nouveau vu sécurisé sur Firefox, même si le challenge est toujours TLS.

[poluket]

Juste une remarque pour les browsers. Il faut absolument les fermer après avoir mis a jour le certificat. Le browsers garde en cache le certificat précédent et met tjrs un message d'erreur même si le certificat est bon.

C'est quoi le problème TLS?

[LuluDom]

C'est quoi le problème TLS?

Le site qui teste la sécurité de l'adresse me dit :

Protocols :
You currently have TLSv1 enabled.
This version of TLS is being phased out. This warning won't break your padlock, however if you run an eCommerce site, PCI requirements state that TLSv1 must be disabled by June 30, 2018.

[poluket]

C'est pas très grave ce message. Il n'a rien a voir avec le certificat, est lié aux TLS 1 et TLS 1.1 qui n'ont rien a voir avec le certificat.

Regarde ceci:
https://www.leaderssl.com/news/471-how- ... -in-apache

[LuluDom]

C'est pas très grave ce message. Il n'a rien a voir avec le certificat, est lié aux TLS 1 et TLS 1.1 qui n'ont rien a voir avec le certificat.

Regarde ceci:
https://www.leaderssl.com/news/471-how- ... -in-apache

Merci beaucoup pour ta réponse.

Tant mieux si je peux vivre avec ça car mon précédent changement de certificat m'avait fait perdre mon serveur apache et je m'étais donné du mal.

Je pensais que ce message sur le protocole était le même propos que le challenge obsolète objet du message de Letsencrypt reçu pour mon précédent certificat :

You may need to update your client to the latest version in case it is still using the deprecated TLS-SNI-01 validation method.

Me conseilles-tu d'appliquer les commandes de ton lien dans mes fichiers de configuration de mon Jeedom DIY ?

[poluket]

Tu peux toujours essayer. La procédure est super simple. C'est modifier une ligne au niveau du fichier de config. Au pire, tu dupliques la ligne existante avec un # devant. Comme roolback, il te suffit de supprimer la nouvelle ligne et réactivité l'ancienne. Bien faire un redémarrage des services chaque fois

[LuluDom]

Tu peux toujours essayer. La procédure est super simple. C'est modifier une ligne au niveau du fichier de config. Au pire, tu dupliques la ligne existante avec un # devant. Comme roolback, il te suffit de supprimer la nouvelle ligne et réactivité l'ancienne. Bien faire un redémarrage des services chaque fois

Je vais tenter... mais je ne trouve pas le répertoire httpd donné par ton lien.

J'ai essayé de voir si le fichier donné par le lien de configuration de mon apache que j'ai utilisé correspondait :
/etc/apache2/sites-enabled/default-ssl.conf

mais je n'y trouve pas les lignes de protocoles et de Cipher dans le fichier conf donc ça ne doit pas être ça.

Une idée d'où aller chercher le fichier dans un Jeedom DIY ?

[LuluDom]

A supprimer

[LuluDom]

Voici du feedback et du fixing qui peuvent aider ceux qui constatent que le renouvellement automatique du certificat ne se fait pas.

La méthode de certificat que j'ai déployée pour la seconde création de certificat il y a plus de 2 mois a installé certbot-auto dans /opt/letsencrypt :
https://domohab.be/index.php/2019/02/08 ... -internet/

C'est un autre endroit que le premier certificat que j'avais installé par une autre méthode : /etc.

D'autres tutos donnent encore d'autres chemins d'exécution : /usr/local/sbin.

Je me rend compte que mes fichiers crontab et certbot-auto étaint multiples et aux contenus variables avec tantôt un chemin et tantôt l'autre !

Mon certificat ne s'est pas mis à jour après plus de 2 mois sans que je puisse dire si c'est par mauvaise écriture du crontab ou mauvais fichiers.

Voici quels tests pour discerner les choses !

• La commande préconisée dans le crontab ne marche pas quelque soit le chemin de commande retenu.

• Le certbot-auto de /opt/letsencrypt correspondant au certificat actuel renouvèle manuellement avec succès mon certificat depuis ce répertoire et seulement celui-ci.

• Il y a un autre certbot-auto et un autre crontab (dans /etc) vers lesquels malheureusement la commande "whereis" pointe sans que je sache pointer whereis sur ceux de /opt/letsencrypt.

Bref... je ne comprends pas tout... mais en exécutant manuellement la commande suivante (en sudo), qui ajoute de se déplacer dans le bon répertoire, le renouvèlement de certificat fonctionne depuis n'importe quel répertoire !

Code : Tout sélectionner

sudo -i
cd /opt/letsencrypt && /opt/letsencrypt/certbot-auto renew --no-self-upgrade --post-hook "systemctl restart apache2"

Par déduction, je parie que le bon crontab sera :

Code : Tout sélectionner

42 6 * * * cd /opt/letsencrypt && /opt/letsencrypt/certbot-auto renew --no-self-upgrade --post-hook "systemctl restart apache2"

Ne sachant pas quel crontab se lance, j'ai mis la ligne à la fois dans le crontab du répertoire /etc et dans celui du répertoire /opt/letsencrypt.

Enfin, pour blinder la chose, j'ai trouvé le moyen d'ajouter le chemin /opt/letsencrypt dans $PATH en remplaçant la ligne :

Code : Tout sélectionner

echo PATH

par :

Code : Tout sélectionner

echo PATH=/opt/letsencrypt:$PATH

Et ainsi on obtient :

Code : Tout sélectionner

jeedom@Jeedom:~$ echo $PATH
/opt/letsencrypt:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
jeedom@Jeedom:~$ whereis crontab
crontab: /usr/bin/crontab /etc/crontab /opt/letsencrypt/crontab /usr/share/man/man1/crontab.1.gz /usr/share/man/man5/crontab.5.gz
jeedom@Jeedom:~$ whereis certbot-auto
certbot-auto: /etc/certbot-auto /opt/letsencrypt/certbot-auto

Malgré tout j'ai encore un fonctionnement imparfait donc ma configuration a priori fonctionnelle n'est pas très propre :

Code : Tout sélectionner

jeedom@Jeedom:/$ sudo /opt/letsencrypt/certbot-auto renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/XXX.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Attempting to renew cert (XXX) from /etc/letsencrypt/renewal/XXX.conf produced an unexpected error: [b]Unable to find manual-auth-hook command ./manual-auth-hook.py in the PATH.
(PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)[/b]. Skipping.
[b]All renewal attempts failed.[/b] The following certs could not be renewed:
  /etc/letsencrypt/live/XXX/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/XXX/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

Si quelqu'un comprend mieux et peut nettoyer ma configuration, je l'en remercie.

Si cette solution a fonctionné pour vous, merci de le signaler en retour SVP.