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.
@@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....
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é
![Devenez votre propre autorité de certification 🔏 step-ca [Docker, Proxmox, ACME, TLS, X.509, SSH]](/img/logo.svg){kind=logo}
