J’ai ajouté cette remarque sur le tutoriel Accès de l’extérieur en HTTPS avec Nginx Proxy Manager paragraphe Nettoyage de la configuration
Dans ce cas, la redirection de port que tu dois faire ce n’est pas vers ton point d’accès (le google nest) mais directement sur le RPi3. C’est lui qui va répondre à la requête de Let’s Encrypt (l’url avec .well-known dedans). Pas google nest.
Merci McFly pour sur ce tuto et le temps que tu passes pour expliquer à tous.
Mais pour un newbie comme moi 
fermer le port 80 avant de se faire start sur Let"s encrypt cela génére une erreur sur l’accés au domaine en laissant le port 80 à cette étape cela fonctionne.
Si cela peut aider…
1 « J'aime »
Il a pourtant précisé :
Bonjour McFly,
J’ai bien noté cette partie que j’ai commenté pour le moment. En effet, les fichiers ne sont pas créés à cause du message indiqué dans mon post initial.
Mon problème vient de la structure de mon réseau. Réseau box Orange et ensuite réseau « Google Wifi » où se trouve mon HA.
Il faut que je creuse sur la partie réseau et tout devrait rentrer dans l’ordre.
Merci de ton aide.
Franck
Bonjour Clemalex,
Merci de ton retour, mais mon problème est en amont. Je n’arrive pas à générer le certificat. La structure de mon réseau doit être à l’origine du problème.
Tu peux donner les adresses IP que tu as?
Le LAN de la Livebox est en 192.168.1.X je suppose.
Un truc connecté sur le wifi de la livebox va être en 192.168.1.Y ?
Le wifi google, quand tu es connecté dessus tu as quoi 192.168.1.Z ou 192.168.2.Z (2 ou autre chose que .1 en tout cas).
Bonjour golfvert,
C’est ce que j’en ai déduit mais depuis la box Orange, il n’est pas possible d’adresser le RPi3 car par sur le même plan d’adressage réseau.
Je n’utilise pas la partie réseau d’Orange en dehors de la TV.
Une idée ?
Franck
Ta box fait du NAT, ça OK, mais ton routeur Google Nest Hub, que fait-il ? NAT aussi ? Ton RPi sort sur Internet ?
Je pense que c’est obligé, la livebox ne sait pas adresser un autre sous réseau. Donc, forcément le nest doit NATter tout le 192.168.86.x sur son adresse en 192.168.0.y et ensuite la livebox NATte à nouveau.
Donc, il faut ouvrir le port 80 sur la livebox vers google net (pas vers le PI!) et le même port 80 sur le google nest vers le RPi.
Je pense qu’il me manque en effet la dernière partie entre le Google Nest et la RPi.
Je test et vous tiens au courant.
PS : une autre solution pourrait être de mettre tout le réseau Goggle Nest en DMZ. A voir ?
Tu peux le faire pour les tests mais après je te conseil de jouer seulement avec les ports.
Pour la DMZ, le principe est d’exposer tout ce qui se trouve dedans c’est ça ? Donc tout ce qui se trouve derrière le Google Nest, si je le fait.
Oui, car, contrairement à ce que tu as indiqué au début :
et avec les adresses IP que tu donnes son google nest est un routeur. Pas un bridge.
Si tu dis à la livebox que ton google nest est ta « DMZ », alors plus aucun filtrage ne sera fait par la livebox.
Tu dépendra entièrement de ce sait faire (ou pas) google nest. Donc, bof, j’éviterai.
Tu pourrais le faire avec un vrai firewall (opnsense par exemple). Mais, avec google nest, pas certain que ce soit une bonne idée.
Merci de tes réponses.
Bonjour,
Je viens de suivre ce tuto, cependant l’Add-on ne démarre pas.
J’ai ça dans les logs :
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] file-structure.sh: executing...
[cont-init.d] file-structure.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[14:40:19] INFO: Selected http verification
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for ha.ndd.ovh
Waiting for verification...
Challenge failed for domain ha.ndd.ovh
http-01 challenge for ha.ndd.ovh
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: ha.ndd.ovh
Type: connection
Detail: Fetching
http://ha.ndd.ovh/.well-known/acme-challenge/988W7JXvUfR5qogmeA-Ai1yEiq6_xDwKKSkB3reKfp8:
Timeout during connect (likely firewall problem)
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting
Avez-vous eu ce genre de chose avec un nom de domaine OVH ?
Je vous en remercie par avance.
et :
Il doit manquer ça…
1 « J'aime »
Est-ce bon la :
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] file-structure.sh: executing...
[cont-init.d] file-structure.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[18:55:55] INFO: Selected DNS Provider: dns-ovh
[18:55:55] INFO: Use propagation seconds: 60
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-ovh, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for ha.ciret.ovh
Waiting 30 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges
Non-standard path(s), might not work with crontab installed by your operating system package manager
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/data/letsencrypt/live/ha.ciret.ovh/fullchain.pem
Your key file has been saved at:
/data/letsencrypt/live/ha.ciret.ovh/privkey.pem
Your cert will expire on 2021-05-12. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.
Si je comprends bien, je dois à nouveau relancer l’add-on le 12/5, afin de renouveler le certificat, tout en pensant à changer les ports en 80 ?
Merci pour vos conseils.
Oui et non.
Les certificats let’s encrypt sont valables 90 jours. Donc, ils doivent être renouvelés avant le 12/5.
Pour le renouveler la machine avec HA doit être accessible sur le port 80. Donc la redirection doit être ouverte sur la box. Mais:
- HA en tant que tel restera en HTTPS. Donc il faudrait garder ouvert le port pour HTTPS (j’imagine 443) et avoir en plus le 80 pour le renouvellement
- le renouvellement est automatiquement fait par l’addon. Mais, je ne sais pas quand. Logiquement on attend pas le dernier jour pour le faire.
Donc, soit tu laisses tout le temps le port 80 ouvert soit tu l’ouvres quand c’est le moment. Le problème est de le connaître
En résumé, les ports à ouvrir sur la box:
- 443 toujours
- 80 quand c’est nécessaire…