révoquer l’ancien certificat
Afin de faire les choses proprement, voyons comment révoquer le certificat en cours qui est sous le challenge TLS. Pour cela, exécutez la commande suivante en pensant bien à remplacer domaine par votre vieux domaine freebox (ex: monvieuxdomaine.freeboxos.fr).
sudo /opt/letsencrypt/letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/domaine/fullchain.pem
Vous obtenez alors le message suivant :
L’autre methode de revocation est l’utilisation de la nouvelle commande
sudo apt-get remove certbotVous venez de révoquer le vieux certificat. Passons à présent à une petite phase de nettoyage.
supprimer les fichiers
Afin de partir sur des bases saines, il nous faut maintenant nettoyer les traces du domaine révoqué. Pour cela, passez simplement les 3 commandes suivantes, toujours en remplaçant domaine par votre ancien domaine freeboxos.fr…
rm /etc/letsencrypt/live/domaine -r rm /etc/letsencrypt/renewal/domaine.conf rm /etc/letsencrypt/archive/domaine -r
Relance apache
Après toutes ces manipulations, il est temps de redémarrer Apache pour actualiser la configuration.
sudo /etc/init.d/apache2 restart
Normalement vous devriez avoir un message qui dit que le serveur Apache a correctement démarré. Dans ce cas tout est en ordre, passez à l’étape suivante.
Un problème de servername?
1 Si toutefois vous avez un avertissement qui indique un problème de configuration, utilisez la commande suivante pour avoir plus de détails sur le problème. Si tout est OK pour vous, vous pouvez passer à l’étape suivante.
sudo apachectl configtest
Vous pouvez par exemple avoir ce message en retour :
2 Si c’est le cas, je vous invite à renseigner votre nom de domaine dans le fichier hosts du Raspbrerry Pi, pour cela ouvre le fichier hosts.
sudo nano /etc/hosts
3 Ajoutez la ligne suivante au fichier :
ServerName www.domaine.ovh
4 Éditez ensuite le fichier apache2.conf avec la commande suivante :
sudo nano /etc/apache2/apache2.conf
5 Ajoutez la ligne suivante en haut du fichier :
ServerName www.domaine.ovh
6 Redémarrez une nouvelle fois Apache.
sudo /etc/init.d/apache2 restart
7 Testez de nouveau la configuration.
sudo apachectl configtest
8 Si tout est OK, vous recevez le message :
Syntax OK
Vous avez votre nom de domaine, votre ancienne configuration de Let’s Encrypt est nettoyée, nous allons pouvoir passer à la génération du nouveau certificat avec la nouvelle méthode sécurisée HTTP-01.
9 Avant, il convient tout de même de vérifier que les redirections sont OK au niveau du routeur, en l’occurrence ici, la freebox Revolution.
Par sécurité dans un premier temps, configurez deux redirections de port. une première sur le port 80 (http), puis une seconde sur le port 443 (https).
10 À présent, vérifiez que votre nouveau nom de domaine pointe bien vers votre Jeedom en HTTP dans un premier temps. Pour cela, rien de plus simple, saisissez simplement l’adresse http://domaine dans un navigateur.
Progression de la lecture
A suivre en page 3, la génération du nouveau certificat, le renouvellement et le débug des problèmes
Bonjour,
C’est la première fois que je mets en place un certificat SSL pour mon jeedom j’ai acheté du coup un nom de domaine chez ovh tout est ok jusque-là.
J’ai ajouté ma zone DNS avec mon ip publique et j’ai suivi toutes les étapes de page 2 du tuto, j’ai la syntax ok après la vérification du test apache.
J’ai bien ouvert mes ports 80 et 443 sur ma box à l’époque déjà pour avoir accès à mon jeedom à distance via mon ip publique.
A présent quand je vais sur mon navigateur sur mon domaine.ovh j’ai la page par défaut d’OVH “Félicitation Votre domaine mondomaine.ovh a bien été créé chez OVH.”
Est-ce c’est parce que j’ai fait la configuration de ma zone DNS il y a une heure et que je dois encore attendre ?
Merci à vous.
bonjour, oui il y a un delais de propagation DNS.
bonjour,
erreur de port dans le texte 433 au lieu de 443.
merci pour le blog 🙂
oups ! boulette corrigée ! Merci
Bonjour Mr Brunet.
Merci pour les excellents tutos que vous proposez.
J’avais utilisé cette procédure d’accès à Jeedom en HTTPS avec certificat SSL gratuit sur un RPI 3B+ avec Debian Stretch. Ça avait très bien fonctionné.
Je viens de passé à Jeedom V4 sur Debian Buster 10. Pensez-vous que la procédure soit encore applicable ?
Merci beaucoup
Bonjour Jean-Claude,
normalement rien n’a changé, sur le protocole de sécurisation, cela doit fonctionner même sur Rpi 4 avec une version Raspberry Pi OS récente.
Bonjour,
Merci pour ce tuto très bien fait.
Juste une remarque, je pense qu’il faut utiliser sudo crontab -e au lieu de sudo nano crontab -e
Bonjour,
je me permet s une remarque, le dernier commentaire corrige une coquille dans le tutoriel ‘sudo crontab -e’ afin d’accéder au bon fichier de planification.
J’ai à mon tour une question, j’ai utilisé
sudo certbot –apache
d’après le descriptif, c’est après cette commande
sudo certbot certonly –webroot
que la suite de la config se fait. A quoi sert cette seconde commande ?
je ne comprends pas son utilité, et si après avoir inscrit en crontab le renouvellement il va effectuer la tâche seul.
Par avance, merci de votre retour, et merci pour ce super tuto !!
Bonjour,
Lorsque je lance la commande sudo apachectl configtest j’ai bien le message evoqué (could not reliably…to suppress this message).
Toutefois j’ai une question. Quand je lance la commande sudo nano /etc/apache2/apache2.conf un long texte s’affiche m’expliquant tout un tas de choses sur Apache mais je ne sais pas où exactement entrer la ligne ServerName http://www.domaine.ovh.
Pourriez-vous détailler ce point pour le noob que je suis !
Merci
Salut, pour info :
je viens de réinstaller jeedom sur un nouveau nuc, et donc de refaire la sécurisation via ton tuto.
Tout se passe bien, et en fin de génération de certificat j’obtiens le message suivant “certbot has setup a scheduled task to automatically renew this certificate in the background”.
Je comprends donc que le renouvellement est donc désormais automatisé, sans avoir fait la partie crontab , et il m’est d’ailleurs indiqué la date d’expiration pour dans 90 jours.
On peut aussi contrôler la présence de cette tâche parmi toute celle du système avec la commande
systemctl list-timers
Bonjour,
Je souhaite passer jeedom en SSL, j’ai suivi la manip bien détaillé mais ça bloque à l’installtion du certificat et plus précisemment à “sudo certbot –apacache”
Je précise que j’ai bien accès à via mon nom de domaine en http.
J’ai cela à la fin de la commande “sudo certbot –apacache”
RuntimeError: OpenSSL 3.0’s legacy provider failed to load. This is a fatal error by default, but cryptography supports running without legacy algorithms by setting the environment variable CRYPTOGRAPHY_OPENSSL_NO_LEGACY. If you did not expect this error, you have likely made a mistake with your OpenSSL configuration.
J’ai peut être loupé quelque chose.
Je suis sur debian 11 avec jeedom 4.4.19 et du Python 3.9.2
Merci d’avance.
Bonjour,
cela fait bien longtemps que je n’a pas utilisé cette méthode mais aux dernières nouvelles elle fonctionnait encore il y a pas si longtemps.
Le message semble tout de même indiquer quelque chose qui manque pour permettre à la commande de s’executer correctement.
Bonjour,
je viens de suivre le tuto, et j’ai exactement la même erreur que Florian 🙁
Bonjour,
J’ai également le même message d’erreur que Florian
Bonjour,
Plus ce pb depuis que je suis passé en Debian 12.
1 fois sur 3 j’ai la page “site en construction” quand j’essaie en HTTP. Une idée.
Pour le certificat à priori tous s’est bien passé en revanche j’ai mis cette ligne “sudo certbot –apache” fait toute la config du mail puis du nom de domaine et ensuite j’ai mis cette ligne “sudo certbot certonly –webroot” qui on dirait n’a servi a rien car j’ai eu un retour que c’était déjà configuré. Ai-je bine fait ?
Pour l’instant quand j’utilise le site check SSL j’ai failed to open TCP connection…