Step-CA : ton HTTPS local sans compromis, sans port ouvert

Avoue : tu as déjà vu ce cadenas barré dans ton navigateur, sur un service pourtant chez toi. Jellyfin, Home Assistant, l'interface de ton proxy ou de ta NAS… tout tourne nickel sur ton réseau, mais le navigateur t'affiche un avertissement rouge menaçant dès que tu passes en HTTPS. Alors tu coches « continuer malgré tout », en fermant les yeux, et ça te fait le même effet qu'une porte blindée laissée ouverte.

Le coupable est toujours le même : tes services locaux n'ont pas de certificat signé par une autorité que ton navigateur connaît. Et si tu sors le grand jeu avec Let's Encrypt sur un domaine public, tu tombes sur deux nouveaux problèmes : la validation se complique quand le service n'est pas accessible depuis Internet, et tes noms d'hôtes finissent inscrits dans un registre mondial, visible par tout le monde. Il existe une troisième voie, plus propre : montrer à ton navigateur que c'est toi l'autorité. On va déployer Step-CA, une autorité de certification open source qui délivre et renouvelle des certificats HTTPS automatiquement, sans jamais exposer un seul port vers l'extérieur.

Dans nos précédents tutos, on a déjà posé les fondations : un réseau privé chiffré avec Tailscale ou Headscale, et un proxy qui gère tout seul le HTTPS public avec Caddy. Il ne manque qu'une pièce : une autorité de certification à nous. C'est parti.

Une autorité de certification, c'est quoi au juste

Petite vulgarisation d'abord, parce que ce jargon fait peur pour rien. Une autorité de certification (ou CA, pour Certificate Authority) est un tiers de confiance : elle signe des certificats qui prouvent qu'un serveur est bien celui qu'il prétend être. Quand ton navigateur affiche un cadenas vert sur ton site préféré, c'est qu'une CA publique — Let's Encrypt, par exemple — a signé le certificat du site. Ton navigateur connaît et fait confiance à une petite liste de CA publiques, embarquée dans le système.

Quand personne de cette liste n'a signé le certificat de ton serveur local, le navigateur hurle. Et il a raison : n'importe qui peut générer un certificat auto-signé en deux commandes. Le cadenas barré ne dit pas « la connexion n'est pas chiffrée » : elle l'est. Il dit : « je n'arrive pas à prouver que je parle au bon serveur ». La solution n'est donc pas de désactiver la vérification, mais de créer ta propre CA, de l'installer comme autorité de confiance sur tes appareils, et de lui faire signer les certificats de tes services. Ton navigateur retrouve son cadenas vert, parce que l'autorité signataire, c'est toi.

Schéma du flux ACME local : le proxy demande un certificat à Step-CA, qui le signe sans jamais sortir du réseau.

Schéma explicatif NumeriBrain — réalisé par la rédaction pour illustrer le fonctionnement de Step-CA (ce n'est pas une capture du produit).

Au passage, deux termes qui reviendront tout l'article. ACME est le protocole d'automatisation inventé par Let's Encrypt : le client (ton proxy) prouve qu'il contrôle le domaine, et la CA délivre le certificat, puis le renouvelle avant expiration. Un certificat racine est le certificat maître de ta CA : tout ce qu'il signe devient automatiquement de confiance pour quiconque l'a installé.

Le problème Let's Encrypt sur un réseau privé

Let's Encrypt fait un travail remarquable et gratuit : en France, comme ailleurs, c'est la CA publique la plus utilisée du web. Mais son modèle repose sur une évidence : pour vérifier que tu contrôles le domaine jellyfin.mondomaine.fr, elle doit pouvoir le tester. Deux mécanismes existent : soit ton serveur répond depuis l'Internet public (épreuve HTTP), soit tu prouves le contrôle en posant un enregistrement DNS précis chez ton registrar (épreuve DNS).

Sur un réseau purement local, ou derrière un VPN maillé du style Tailscale, le service n'est simplement pas joignable depuis l'extérieur. Reste l'épreuve DNS : elle marche, mais oblige à brancher une API de registrar, à stocker un jeton d'accès à ton DNS, et à maintenir tout ça pour chaque renouvellement. Pour un service qui ne sort jamais d'Internet, la fête devient vite disproportionnée.

Et il y a la question que personne ne lit avant de cliquer : la Certificate Transparency. Chaque certificat d'une CA publique doit être publié dans des journaux publics et vérifiables, pour détecter les CA qui émettraient en catimini. C'est excellent pour la sécurité du web… et très bavard sur ta vie privée : n'importe qui peut chercher un domaine et voir tous les certificats jamais émis pour lui.

Recherche crt.sh sur un domaine : tous les certificats émis apparaissent publiquement, avec dates et autorité.

Capture crt.sh — la recherche d'identité montre les certificats émis pour un domaine ; service public de consultation des journaux de transparence.

Teste par toi-même : ouvre le site crt.sh et tape un domaine que tu connais. Tu verras la liste des certificats émis, avec leurs noms exacts. Pour un site public, c'est sans conséquence. Pour une infra personnelle dont les noms d'hôtes n'ont pas à être publics, c'est une fuite d'information inutile : autant garder tes noms internes pour toi.

Step-CA : ta propre autorité en open source

C'est là qu'entre en jeu Step-CA, développé par la société Smallstep. C'est une autorité de certification complète, open source (licence Apache 2.0), qui tourne sur ton matériel : une petite machine, un conteneur Docker sur ta NAS, un Raspberry Pi. Le projet affiche plus de 8 800 étoiles sur GitHub, est activement maintenu (dernière version 0.30.2, mars 2026) et fait tourner des CA d'entreprise sérieuses. Son idée forte : parler le même protocole ACME que Let's Encrypt, mais en local. Ton proxy Caddy, Traefik ou Nginx, qui sait déjà demander des certificats tout seul, n'a qu'à changer d'URL d'autorité. Le reste, il le fait déjà.

Le certificat racine reste sous ton contrôle exclusif : il n'est jamais envoyé sur Internet, jamais journalisé nulle part. Tes noms d'hôtes internes (jellyfin.maison, ha.local, ce que tu veux) restent chez toi. Et les certificats émis sont courts : de quelques heures à quelques jours selon ta configuration, ce qui limite mécaniquement les dégâts si une clé fuit — une pratique de sécurité que les grandes entreprises paient cher et que tu obtiens gratuitement.

La mise en place pas à pas

On reste sur du classique : un serveur Linux pour la CA, et Caddy en reverse-proxy devant tes services. Les commandes ci-dessous viennent de la documentation officielle de Smallstep.

# Debian / Ubuntu (dépôt officiel Smallstep)
apt-get update && apt-get install -y --no-install-recommends curl gpg ca-certificates
curl -fsSL https://packages.smallstep.com/keys/apt/repo-signing-key.gpg -o /etc/apt/keyrings/smallstep.asc
cat << EOF > /etc/apt/sources.list.d/smallstep.sources
Types: deb
URIs: https://packages.smallstep.com/stable/debian
Suites: debs
Components: main
Signed-By: /etc/apt/keyrings/smallstep.asc
EOF
apt-get update && apt-get -y install step-cli step-ca

Sur une autre distribution, des paquets existent aussi pour Fedora, Arch, Alpine et NixOS ; macOS l'a dans Homebrew, et il y a une image Docker officielle smallstep/step-ca. On initialise ensuite la CA :

$ step ca init
✔ What would you like to name your new PKI? (e.g. Smallstep): NumeriBrain Home
✔ What DNS names or IP addresses would you like to add to your new CA? (e.g. ca.smallstep.com[,1.1.1.1,etc.]): ca.mondomaine.fr
✔ What address will your new CA listen at? (e.g. :443): :9000
✔ What would you like to name the first provisioner for your new CA? (e.g. you@smallstep.com): admin@mondomaine.fr
✔ What do you want your password to be? [leave empty and we will generate one]: (une longue phrase secrète)

Trois minutes plus tard, ta PKI est générée dans le dossier .step : certificat racine, clé racine, certificat intermédiaire, configuration. Note bien la fingerprint (l'empreinte) du certificat racine affichée à la fin : c'est elle qui permet à n'importe quel appareil de vérifier qu'il parle bien à TA CA, et pas à un imposteur.

✉️ Un moment, avant de continuer la lecture…

La newsletter condense l'actu tech chaque dimanche : les 4-5 infos qui comptent + un outil open source à installer, en français. Inscription gratuite, désinscription en un clic.

Installer la confiance sur tes appareils

C'est l'étape que tout le monde sous-estime, et pourtant c'est elle qui fait la magie : chaque appareil qui doit afficher le cadenas vert doit connaître ton certificat racine. Le fichier root_ca.crt va donc être installé une fois par appareil :

Linux (Debian/Ubuntu) : copie le fichier dans /usr/local/share/ca-certificates/ puis lance update-ca-certificates.
macOS : step certificate install root_ca.crt ou import dans l'accès aux trousseaux, en marquant le certificat « toujours faire confiance ».
Windows : double-clic sur le fichier, « Installer le certificat », magasin « Autorités de certification racines de confiance ».
Android : Paramètres, puis « Chiffrement et identifiants », « Installer un certificat », « Autorité de certification ». (Selon les versions, Chrome peut réclamer un réglage supplémentaire.)
iOS : profil de configuration via Réglages, puis active la confiance manuelle pour ce certificat.

Une fois par appareil, c'est tout. C'est le prix de l'indépendance : contre une manipulation de deux minutes, tu récupères un HTTPS propre sur tout ton réseau.

Brancher Caddy sur ta CA

Côté proxy, c'est presque décevant de simplicité. Caddy parle ACME nativement : on lui donne l'URL de ta CA et son certificat racine, et il fait le reste tout seul — demande, renouvellement, installation :

mondomaine.fr {
    tls {
        ca https://ca.mondomaine.fr:9000/acme/acme/directory
        ca_root /etc/ssl/certs/root_ca.crt
    }
    reverse_proxy 127.0.0.1:8096   # ton service Jellyfin, par exemple
}

Au premier démarrage, Caddy négocie avec ta CA et obtient un certificat valable pour mondomaine.fr. Le renouvellement se fait sans que tu y penses. Traefik et Nginx suivent le même principe : Smallstep fournit des exemples de configuration pour chacun dans sa documentation ACME.

Step-CA, Let's Encrypt ou certificats Tailscale ?

Petit comparatif honnête, parce que tu te poses sûrement la question. Tailscale propose même des certificats HTTPS intégrés pour tes machines, avec Let's Encrypt en coulisses.

Let's Encrypt (HTTP ou DNS) : le standard du web public. Parfait pour ce qui doit être joignable d'Internet ; l'épreuve DNS est la seule voie pour un service caché, et elle expose les noms dans les journaux de transparence.
Certificats Tailscale (tailscale cert) : la simplicité absolue, zéro serveur à maintenir. Mais limité aux noms en .ts.net de ton tailnet, et tes noms de machines finissent dans les journaux publics — exactement ce qu'on voulait éviter.
Step-CA : demande un peu plus de travail au départ (une CA à faire tourner, la racine à installer par appareil), mais aucun port ouvert, aucun nom publié, des noms de domaine totalement libres, et des renouvellements entièrement automatiques.

Mon verdict : si tu es déjà sous Tailscale avec un seul ou deux services, tailscale cert fait le travail. Dès que tu veux tes propres noms de domaine, ou que la fuite des noms te dérange, Step-CA gagne haut la main. Et si tu héberges pour ta famille ou une petite asso, tu as en plus le plaisir de maîtriser toute la chaîne de confiance.

Les limites

D'abord, l'installation de la racine est un vrai coût d'entrée. Formate ou remplace un appareil, et il faudra refaire la manipulation. Sur un réseau familial, ça se gère ; dans une PME, on voudra un déploiement automatisé (MDM ou outil équivalent), ce qui dépasse le cadre de cet article.

Ensuite, ta CA devient un composant critique : si tu perds les clés racine et intermédiaire, tous tes certificats deviennent invalides et il faut tout réinstaller. Sauvegarde le dossier .step (clés comprises) sur un support chiffré, et ne laisse pas traîner la clé racine sur un partage réseau. À l'inverse, si quelqu'un obtient ta clé racine, il peut signer des certificats que tes appareils jugeront parfaitement légitimes : c'est le prix du pouvoir. La doc de Smallstep détaille les options pour renforcer la protection des clés (HSM, YubiKey).

Enfin, Step-CA ne convient qu'à un usage interne : il ne délivre pas de certificats publics reconnus par les navigateurs du grand public, ne s'intègre pas aux journaux de transparence, et n'offre pas de révocation active complète (CRL/OCSP). Ce n'est pas un bug : c'est sa philosophie — la sécurité par des certificats très courts, renouvelés automatiquement, plutôt que par des listes de révocation.

Tu passes à l'action ?

En une demi-heure, tu as une autorité de certification complète chez toi, un proxy qui renouvelle ses certificats tout seul, et des services locaux en HTTPS sans avertissement. Aucun port ouvert, aucune fuite de noms, aucune dépendance à un service externe pour chiffrer ton propre trafic. Le cadenas vert du coin de l'adresse, enfin chez toi — et il n'a plus besoin de personne pour rester vert.