Caddy

Proxmox Datacenter Manager 1.1 sait servir des fichiers de réponse à l’installateur automatique de Proxmox, ce qui en fait un serveur d’installation tout trouvé pour un MSP qui gère de nombreux sites clients. Le cas d’usage est un client qui voulait que chaque site soit construit avec son propre nommage, son propre mot de passe root et ses propres clés SSH, simplement en branchant un serveur sur le bon VLAN et en le démarrant, sans numéros de série à relever ni fichier de réponse par machine ; ce billet couvre cette moitié, le démarrage et l’installation, et laisse de côté l’intégration au cluster. Il ne sait pas choisir une réponse selon le site, et il ne sait pas donner un script de premier démarrage à un nœud, et les deux limites sont prouvées par le code source de PDM lui-même. Ce billet construit malgré tout un seul parc PXE pour tous les sites : une seule image de démarrage qui porte un jeton générique non secret, une découverte par enregistrement DNS TXT pour que l’image ne contienne aucune URL, et un proxy Caddy qui remplace le jeton générique par le jeton bearer propre au site, choisi selon le sous-réseau source. Il couvre la façon dont PDM choisit une réponse, prepare-iso pour iPXE, les enregistrements DNS, dnsmasq et la boucle iPXE, un Caddy durci qui sert toute l’interface de PDM sur le 443 avec le 8443 fermé par nftables, la journalisation du jeton utilisé par son seul nom, le webhook de post-installation, l’ajout de Proxmox Backup Server, et les compromis qui restent.

Utiliser step-ca 0.30.2 pour émettre des certificats clients pour le TLS mutuel, testé de bout en bout avec nginx 1.30.5 et Caddy 2.11.7. Pourquoi les téléphones sont le cas difficile, relever la limite de 24 heures dans ca.json, activer la CRL, pourquoi elle échoue avec « different CRL scope » tant que idpURL et un modèle n’ajoutent pas un point de distribution correspondant, la CRL racine dont nginx a besoin pour toute la chaîne, la publication des CRL en HTTP simple sur IPv4 et IPv6, la tâche de rafraîchissement qui empêche une CRL expirée de bloquer tout le monde, et l’émission, l’empaquetage, l’installation et la révocation du certificat d’un téléphone.

Verrouiller l’application Home Assistant par un certificat client avec nginx ou Caddy à la maison, avec step-ca comme autorité de certification à la place de Cloudflare. Ce qui change quand Cloudflare sort du chemin, une configuration nginx et une configuration Caddy testées chacune sans certificat, avec un bon, avec un révoqué et avec une montée en WebSocket, en IPv4 et en IPv6, pourquoi nginx sait vérifier une CRL alors que Caddy ne peut tenir qu’une liste d’autorisation, les réglages de proxy de confiance de Home Assistant, ce qu’il faut installer sur le téléphone, et là où ça coince.

Faire tourner step-ca 0.30.2 de Smallstep dans un conteneur Podman ou Docker comme autorité de certification de tout ce qui se trouve dans la maison, le tout testé. Pourquoi une AC privée bat les certificats auto-signés et les certificats publics pour les noms internes, le démarrage avec ACME et SSH activés, les deux mots de passe que l’image génère et où va chacun, la confiance dans la racine sur chaque appareil, le HTTPS interne pour Caddy ou tout ce qui parle ACME, et step ca renew pour les services qui ne le parlent pas. Les certificats clients et SSH ont chacun leur propre article.