Ca y est !
Je crois que ma confusion est là…
Le certificat ne « protège » pas.
Il est juste là pour dire « la page que tu essaies d’atteindre est bien celle que je reconnais »
D’où le fait que l’accès au Pi (ou autre) n’est pas « filtré », mais juste (comme son nom l’indique !) que son adresse est « certifiée valide » par letsencrypt.
Donc je lance la certification sur mon Syno pour « mondomaine.ovh » …
2 ou 3 adaptations à faire chez OVH…
Mise en place du reverse proxy…
Et là, « nas.mondomaine.ovh » et « jeedom.mondomaine.ovh » seront reconnus… et conduiront où je veux que ça conduise.
C’est ça ?
Je crois que j’étais parti sur une mauvaise route et que je la suivais sans réfléchir !
Je l’ai dit… c’est l’âge !
(j’admire ta patience ! … et je t’en remercie encore !)
Perso, les certificats * ça apporte plus d’ennuis que d’avantages, s’il est compromis, faut tout changer partout en urgence… Et ça péte en même temps
Puis ça fonctionne avec un seul sous niveau
Bon, maintenant, j’ai de quoi me mettre le feu aux neurones !
Allez… je pense que je vais prendre mon déambulateur et y aller doucement…
En cas de gros (faut quand même que je me démerde un peu par moi-même pour régler les petits ! ) soucis, je reviendrai faire un tour sur ce fil.
C’est pour ça que je disais que perso, j’aimais pas les *…
Quitte à automatiser (en partie du moins) la propagation d’un certif, j’en profite pour carrement avoir une génération et renouvellement auto, mais chacun le sien
Le problème du wildcard certif c’est que ça ratisse large et que je ne sais pas si Let’s Encrypt les gère proprement pas tester.
La solution HA Proxy est aussi très bonne mais pour les néophytes c’est pas simple de gérer les configs entre les listen les backend les frontend de HA proxy ça devient vite l’angoisse du débutant
Après tu peux aussi faire une simple redirection de ports en disant sur ta box :
le 1443 redirige en https sur ip_jeedom:443
le 2443 redirige en https sur ip_nas:443
et ainsi de suite faut juste bien penser à bookmark les bons ports dans ton browser
Faut simplement rediriger le port 443 ET 80 sur le serveur qui gérera le certificat let’s encrypt en effet certbot en tout cas utilise le 80 comme test pour joindre ton serveur enfin moi c’est ce qu’il m’a fait avec mon nom de domaine NO-IP
« simple » !?
c’est pas le mot que j’aurais choisi …
il faut se souvenir des ports à utiliser, les ouvrir sur ta box, les rediriger vers le bon équipement
VS
ouvrir une bonne fois pour toute un seul port sur ta box, et ensuite simplement gérer une redirection en fonction d’un sous-domaine
la gestion par (sous-)domaine, c’est juste ce que tout le monde utilise tous les jours !
heureusement que google ne nous demande pas d’aller sur google.fr:1289 si on faire une recherche concernant la cuisine et sur google.fr:9384 si c’est pour une voiture …!
mais l’essentiel avant tout : c’est que la personne qui met en place sa solution soit à l’aise avec ce qu’elle fait !
donc si vous vous sentez à l’aise avec vos gestions de ports, keep it that way
donc au final tu vends une solution avec les ports, alors que tu utilises la même chose que ce que je propose
(pas avec des sous-domaines, mais des ressources (préfix !? ) dans ton url)
Je ne vends rien … je ne suis pas commercial en fait une URL c’est http(s)://domain_name/URI et du coup tu peux mettre des préfix dans la partie URI pour « localiser » dans une partie précise et tu peux soit utiliser des directives Location dans apache soit faire si tu te sens des regle de rewrite mais c’est beaucoup plus complexe à gérer et présuppose que tu connaisses les regexp et j’en passe.
Bien souvent Location suffit dans apache pour gérer tout ça et après de simple symlinks dans /var/www/html vers les répertoires de tes contenus à servir suffise après pour faire le job
Je parlais surtout que par exemple HAProxy fait appel à pleins de concepts qui ne sont pas forcément triviaux pour le français moyen (pléonasme selon Coluche … mais je m’égare) de même que les mécanisme de Proxy qui ne sont pas aisés et puis qui ne sont pas non plus simple à debug.
ca date d’il y a 4 ans, je n’ai plus tous les détails en tete
l’IHM avait un peu de mal à répondre à un moment donnée (sur syno)
et du coup ca faisait des cafouillage entre front & backend, ne faisait plus les bons liens, puis le fichier de config a été corrompu et plus rien ne se lancait/s’executait correctement
En fait c’est même http(s)://sudomain.domain_name/URI
Et avec le reverse proxy, on se fiche purement et simplement de savoir si le root directory distant est /machin ou /truc… URL1 est renvoyée vers URL2 et URL2 reste inconnue du monde extérieur. Y compris s’il y a des ports exotiques sur URL2
Sauf à vouloir utiliser jeedom pour héberger autre chose => c’est pas un truc que je conseille d’aller fouiller dans le apache/wwwroot sans un peu de connaissance.
… et je t’en remercie encore !)
) soucis, je reviendrai faire un tour sur ce fil.
