@@tempa9303 dans ce cas, pourquoi ca marche avec pve.home, sans le mettre en subject alternative name ? on est pourtant dans un cas de figure similaire
Bonjour, meci pour cette vidéo qui tombe à point pour un sujet qui vient de m'être confié au boulot !!! Juste par rapport à ton problème de "certificat non valide" après installation de ton certificat généré à la main et que le acme/certbot "corrige" quand exécuté par Proxmox, je remarque que quand tu le génères tu lui donnes le nom pve.local, ça apparaît bien dans le subject mais il n'apparaît pas dans les alternatives names dans l'interface Proxmox des certificats (car non rajouté en tant que --san dans la CLI, jusque là logique). Alors que quand c'est le Proxmox qui le génère, le nom pve.home appraît à la fois dans le "Subject" ET dans le "alternative names"..... peut-être une piste à creuser....
Un grand merci et super travail ! C'est lors de la génération du certificat que vous avez omis : `pve.local`, la ptite coquille était là. Bon week-end. step ca certificate pve.local srv.ctr srv.key --san IP --san pve.local --san pve --not-after 43800h
Génial, merci pour cette vidéo je la commence mais déjà je sais que cela va être très intéressant et que je vais apprendre plein de choses, bravo pour la recherche et la variété des vidéos publiées.
Sinon, un nom de domaine ca coûte trois fois rien, et des reverse proxy comme nginx proxy manager ou traefik gèrent très bien la génération de certificat avec un certbot et let'sencrypt. Y'a une raison particulière qui t'as poussée à ne pas faire comme ça ?
C'est l'objet de cette vidéo. Un nom de domaine c'est restreint à des machines exposées sur internet. Pour des machines internes, ce n'est pas ainsi que l'on s'y prend si on veut bien faire les choses.
@@GuiPoM bah, j'utilise mon nom de domaine aussi en interne, dans traefik ou npm tu peux restreindre l'accès à certains services uniquement en local. Certains ajoutent même un .local comme subdomain. Qu'est ce qui te fais dire qu'on ne doit pas s'y prendre comme ça?
@@francois.h Tu n'as pas du bien comprendre la problématique. Aucun lien entre une autorité de certification et un reverse proxy. Il n'y a pas a avoir de reverse proxy en place puisque ces machines ne sont pas exposées et exposables a internet, elles ne doivent donc pas être déclarées dans un reverse proxy, ça n'a aucun intérêt et ça créé des problèmes de sécurité s'il est incorrectement configuré.
@@GuiPoM "s'il est incorrectement configuré" comme pour tout je dirais. Le reverse proxy + le certbot me permettent justement de ne pas avoir à gérer les certificats sur chaque machine / VM / conteneur docker. Et certains services ne permettent pas d'utiliser nativement un certificat
@@francois.h je ne sais pas qui tu essayes de convaincre, mais je te le redis ce que tu fais est incorrect, une machine déployée en local n'a pas a se retrouver exposer sur un reverse proxy connecté a internet. La bonne manière de faire c'est d'utiliser des outils faits pour ça. Ce n'est pas pour rien que ces outils existent et mon objectif c'est d'expliquer aux gens comment bien du prendre, pas comment mal déployer leur services auto hébergés.
Bonjour Guillaume, dans adguard, dans les réécritures DNS tu utilises des noms avec .local, c'est ce que j'avais fait et j'ai eu de gros problèmes de résolution de noms. Après quelques recherches j'ai constaté que les noms en .local étaient déconseillés. voir en.wikipedia.org/wiki/.local. Merci beaucoup pour la vidéo.
oui, c'est lié au mDNS et en général on ne réécrit pas les résolution de noms locales. Mais dans l'idée ce n'est pas trop génant si on ne fait pas de betises avec la fonctionnalité
![SWAG, mon reverse proxy 💖[docker, authelia, letsencrypt, fail2ban] - Découverte ! (01/XX)](/img/n.gif)
Merci beaucoup et bravo pour cette vidéo. Elle me sera très utile !
avec plaisir !
C est vrai que c est galère à mettre en place en général sur du local. Je testerais cette méthode qui semble résoudre des soucis
Bonsoir,
c'est parcequ'il faut mettre aussi pve.local dans le --san ;)
Ok, je rententerai, a l'occasion
En effet c'est bien ça !
@@tempa9303 ;)
@@tempa9303 dans ce cas, pourquoi ca marche avec pve.home, sans le mettre en subject alternative name ? on est pourtant dans un cas de figure similaire
Ta vidéo tombe à pic, juste au moment où je cherchais une solution pour répondre au même besoin! Un grand merci pour ton excellent travail
Je suis l'homme qui fait des vidéos qui tombent à pic ! 😀
Bonjour, meci pour cette vidéo qui tombe à point pour un sujet qui vient de m'être confié au boulot !!!
Juste par rapport à ton problème de "certificat non valide" après installation de ton certificat généré à la main et que le acme/certbot "corrige" quand exécuté par Proxmox, je remarque que quand tu le génères tu lui donnes le nom pve.local, ça apparaît bien dans le subject mais il n'apparaît pas dans les alternatives names dans l'interface Proxmox des certificats (car non rajouté en tant que --san dans la CLI, jusque là logique). Alors que quand c'est le Proxmox qui le génère, le nom pve.home appraît à la fois dans le "Subject" ET dans le "alternative names"..... peut-être une piste à creuser....
oui, c'est très possible que ce soit une petite bêtise de ce genre. Normalement ce genre de configuration n'est pas nécessaire.
Un grand merci et super travail !
C'est lors de la génération du certificat que vous avez omis : `pve.local`, la ptite coquille était là. Bon week-end.
step ca certificate pve.local srv.ctr srv.key --san IP --san pve.local --san pve --not-after 43800h
Génial, merci pour cette vidéo je la commence mais déjà je sais que cela va être très intéressant et que je vais apprendre plein de choses, bravo pour la recherche et la variété des vidéos publiées.
merci !
bonjour et merci pour cette présentation, solution top, mis en place sur mon lab interne, ça fait le taf !
Merci, aussitôt vu, aussitôt adopté pour mes proxmox.
👍
Bravo pour ta vidéo, cela permet de monter en compétence, ça serait/sera bien utile aussi pour portainer !
pourquoi pas, oui !
Sinon, un nom de domaine ca coûte trois fois rien, et des reverse proxy comme nginx proxy manager ou traefik gèrent très bien la génération de certificat avec un certbot et let'sencrypt.
Y'a une raison particulière qui t'as poussée à ne pas faire comme ça ?
C'est l'objet de cette vidéo. Un nom de domaine c'est restreint à des machines exposées sur internet.
Pour des machines internes, ce n'est pas ainsi que l'on s'y prend si on veut bien faire les choses.
@@GuiPoM bah, j'utilise mon nom de domaine aussi en interne, dans traefik ou npm tu peux restreindre l'accès à certains services uniquement en local.
Certains ajoutent même un .local comme subdomain.
Qu'est ce qui te fais dire qu'on ne doit pas s'y prendre comme ça?
@@francois.h Tu n'as pas du bien comprendre la problématique.
Aucun lien entre une autorité de certification et un reverse proxy.
Il n'y a pas a avoir de reverse proxy en place puisque ces machines ne sont pas exposées et exposables a internet, elles ne doivent donc pas être déclarées dans un reverse proxy, ça n'a aucun intérêt et ça créé des problèmes de sécurité s'il est incorrectement configuré.
@@GuiPoM "s'il est incorrectement configuré" comme pour tout je dirais.
Le reverse proxy + le certbot me permettent justement de ne pas avoir à gérer les certificats sur chaque machine / VM / conteneur docker. Et certains services ne permettent pas d'utiliser nativement un certificat
@@francois.h je ne sais pas qui tu essayes de convaincre, mais je te le redis ce que tu fais est incorrect, une machine déployée en local n'a pas a se retrouver exposer sur un reverse proxy connecté a internet.
La bonne manière de faire c'est d'utiliser des outils faits pour ça. Ce n'est pas pour rien que ces outils existent et mon objectif c'est d'expliquer aux gens comment bien du prendre, pas comment mal déployer leur services auto hébergés.
Bravo 👏 vidéo très utile. Merci
Avec plaisir 👍
Merci et bravo pour cette vidéo. Top, comme d’habitude: clair et simple.
Merci ! 😊
@@GuiPoM merci à toi surtout 😉
Bonjour Guillaume, dans adguard, dans les réécritures DNS tu utilises des noms avec .local, c'est ce que j'avais fait et j'ai eu de gros problèmes de résolution de noms. Après quelques recherches j'ai constaté que les noms en .local étaient déconseillés. voir en.wikipedia.org/wiki/.local. Merci beaucoup pour la vidéo.
oui, c'est lié au mDNS et en général on ne réécrit pas les résolution de noms locales. Mais dans l'idée ce n'est pas trop génant si on ne fait pas de betises avec la fonctionnalité