Devenez votre propre autorité de certification 🔏 step-ca [Docker, Proxmox, ACME, TLS, X.509, SSH]
HTML-код
- Опубликовано: 11 июл 2024
- step-ca est une autorité de certification auto-hébergée et open-source qui permet de gérer les certificats TLS et SSH de manière sécurisée et automatisée. Il facilite le déploiement et la gestion des infrastructures PKI dans les environnements autohébergés/homelabs.
Déployable avec Docker, il permet de générer des certificats TLS pour les serveurs Proxmox et de configurer ACME.
Un outil puissant pour sécuriser vos infrastructures et automatiser la gestion des certificats.
📱 Suivez moi ! 💻
►lhub.to/GuiPoM
🔗 Les liens et commandes 🔗
► Documentation step-ca: smallstep.com/docs/step-ca/
► Documentation step-cli: smallstep.com/docs/step-cli/
► Image docker step-ca: hub.docker.com/r/smallstep/st...
► ... dans les chapitres de la vidéo !
📃 Sommaire 📃
00:00 ⚠️ Attention, vous êtes en danger ⚠️
01:13 C'est très différent de la mise en place d'un reverse proxy, même si les deux sujets peuvent, si nécessaire, se combiner
02:25 Une manière simple de générer des certificats en déployant votre propre autorité de certification locale
03:30 smallstep: les projets opensource step-ca et step-cli
05:15 🤯Attention, le sujet est un peu complexe à présenter et à suivre
08:04 Comprendre le problème: les risques d'un certificat non valide et les raisons de la non validité
10:50 L'écran d'avertissement de votre navigateur et les détails de l'erreur associée
13:45 Dans Proxmox, le certificat est automatiquement généré et la résolution du problème serait très simple: enregistrer le certificat racine dans votre navigateur
15:25 Une machine virtuelle que j'ai dédié à step-ca, le serveur qui héberge l'autorité de certification (CA)
16:22 La gestion locale DNS et DHCP pour prendre le contrôle de vos serveurs DNS chez vous
18:45 La mise en place de cette machine n'est pas couverte par la vidéo. J'ai personnellement fait le choix d'un conteneur (LXC) installé en Debian 12, avec docker. J'ai ajouté portainer pour la lisibilité.
21:13 L'image docker de step-ca et la documentation associée
23:58 Mon docker compose configuré pour mes besoins
27:13 Les logs du conteneur et les informations intéressantes qui y figurent
29:55 Le contenu du répertoire de step-ca: certificats racine et intermédiaire, configuration, secrets .. on y ajoute les infos administrative
31:07 On vérifier si le serveur step-ca fonctionne, en testant la ressource /health
31:58 Installer la ligne de commande sur la ou les machines de votre choix
36:42 Des certificats a durée limité: 1 journée. Vous pouvez changer la configuration du CA
38:55 On génère manuellement un certificat pour la machine Proxmox et on le charge dans le serveur
42:40 Le certificat lui n'est pas reconnu comme valide. Il reste à enregistrer l'autorité de certification racine et intermédiaire dans vos navigateurs
44:50 Petit soucis de cette vidéo: le navigateur refuse de me reconnaître le certificat valide pour mon common name local, mais le reconnait pour mon adresse IP
46:13 Et maintenant le plus intéressant dans l'histoire: utilise de ACME pour la génération et le renouvellement automatique de vos certificats
50:40 On retente le certificat généré mais avec pve.home au lieu de pve.local. Et ça fonctionne dans ce cas là.
54:40 J'espère que cette vidéo vous aura permis de mieux comprendre comment les autorités de certification vous fournissent vos certificats en vérifiant votre authenticité 
Наука
bonjour et merci pour cette présentation, solution top, mis en place sur mon lab interne, ça fait le taf !
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 ! 😀
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
Bravo 👏 vidéo très utile. Merci
Avec plaisir 👍
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 !
Merci et bravo pour cette vidéo. Top, comme d’habitude: clair et simple.
Merci ! 😊
@@GuiPoM merci à toi surtout 😉
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 !
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.
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
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.