Step-Ca

Le 802.1X par certificat (EAP-TLS) pour les ports de switch filaires et un seul SSID WPA2/WPA3-Enterprise, où le serveur RADIUS décide sur quel VLAN atterrit chaque appareil. step-ca 0.30.2 inscrit un rôle dans chaque certificat d’appareil et refuse d’en émettre un sans ; FreeRADIUS 3.2.10 fait correspondre ce rôle à un VLAN, laisse une liste par appareil passer outre, et ne tourne qu’en TLS 1.3. Pourquoi un mot de passe WiFi partagé est le problème, pourquoi des certificats et pourquoi TLS 1.3, le piège de révocation où FreeRADIUS ignore une nouvelle CRL sur un HUP, ce qu’accepte un appareil qui ne vérifie pas le nom du serveur, la protection du trafic RADIUS lui-même avec Message-Authenticator et RadSec en TLS 1.3, radsecproxy pour le matériel qui ne parle qu’UDP, un port filaire et un réseau WiFi simulés de bout en bout, les réglages Netgear et TP-Link, les réglages clients Linux, Apple et Android, chaque fichier de configuration complet et en téléchargement, et pourquoi tant d’administrateurs et de MSP ne s’en donnent toujours pas la peine et pourquoi Cyber Essentials ne le leur demande pas.

Utiliser step-ca 0.30.2 comme autorité de certification SSH, testé avec OpenSSH 10.0. Pourquoi les certificats battent authorized_keys et la confiance au premier contact, activer l’AC SSH à la première mise en place de step-ca, signer une clé d’hôte (et l’ordre des arguments qui fait trébucher), les deux lignes de sshd_config et l’unique ligne @cert-authority dans known_hosts, un certificat utilisateur de 16 heures, quatre tests de connexion dont un mauvais utilisateur et un hôte non approuvé, le renouvellement d’un certificat d’hôte avec sshpop, et là où ça coince.

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.