Niveau 🟡 intermédiaire
Durée estimée : 25 min · Prérequis : Reverse proxy
TLS, c'est l'enveloppe scellée d'une lettre importante, plus le cachet de cire qui prouve
qu'elle vient bien de l'expéditeur annoncé. Sans enveloppe, n'importe qui sur le trajet peut lire
le contenu (pas de chiffrement). Sans cachet reconnu, rien ne prouve que la lettre vient
vraiment de qui elle prétend (pas d'authenticité). TLS fait les deux à la fois pour une
connexion réseau.
TLS (Transport Layer Security, successeur de l'ancien SSL) est le protocole qui chiffre
une connexion réseau et authentifie le serveur auquel on se connecte. HTTPS est simplement
HTTP transporté sur une connexion TLS — le cadenas dans la barre d'adresse d'un navigateur
signale une connexion TLS active.
Un certificat est le document numérique qui porte cette preuve d'identité : il associe un
nom de domaine à une clé publique, et est signé par une autorité de certification (CA,
Certificate Authority) — une entité dont le rôle est justement de vérifier une identité avant
de signer.
La chaîne de confiance fonctionne ainsi : le navigateur fait confiance à une liste
d'autorités racines, préinstallées avec le système d'exploitation ou le navigateur. Un
certificat de serveur est valide aux yeux du navigateur s'il est signé (directement ou via des
intermédiaires) par une de ces autorités déjà connues et approuvées. Sans cette chaîne, un
navigateur affiche un avertissement de sécurité — le certificat existe peut-être, mais rien ne
garantit son authenticité aux yeux de ce navigateur précis.
Let's Encrypt est une autorité de certification publique et gratuite, largement utilisée
pour délivrer des certificats reconnus par tous les navigateurs du monde — à une condition
stricte : le domaine doit être vérifiable publiquement, ce qui suppose que le service soit
exposé sur Internet (via une des méthodes de la page NAT et box). Pour un
homelab qui ne veut justement rien exposer, cette condition n'est pas remplie.
L'alternative locale : mkcert. Pour des services qui ne vivent que sur le réseau local (les
domaines .internal vus en DNS), mkcert crée sa propre autorité de certification
locale, puis installe le certificat racine de cette autorité dans le magasin de confiance de
chaque machine cliente qui doit accéder aux services concernés. Une fois cette autorité locale
installée sur une machine, tout certificat signé par elle est reconnu comme valide — exactement
comme Let's Encrypt, mais à l'échelle du réseau local uniquement, sans jamais avoir besoin
d'exposer quoi que ce soit publiquement.
⚠️ Point d'attention honnête : un certificat mkcert doit lister explicitement chaque nom.
Un certificat généré pourservice.internalne couvre pas automatiquementautre.internal—
chaque nom (ou un certificat « wildcard » couvrant*.internal) doit être prévu à la
génération. Un oubli à ce niveau se traduit par un avertissement de sécurité pour les seuls
noms non couverts, alors que les autres fonctionnent normalement — un symptôme qui peut
dérouter si on ne pense pas à vérifier précisément quels noms figurent dans le certificat.
🧪 Concrètement, sur notre exemple : les services sont accessibles en HTTPS local via des
certificats générés parmkcert, avec l'autorité locale installée sur les machines clientes.
Un exemple honnête de correction réelle : un premier certificat ne couvrait pas tous les noms
.internalutilisés, provoquant des avertissements pour certains services seulement — corrigé
ensuite en régénérant un certificat couvrant explicitement l'ensemble des noms nécessaires
(ou un certificat wildcard).
Les deux mécanismes produisent un certificat TLS valide — la différence est l'échelle de
confiance : mondiale et automatique pour Let's Encrypt (au prix d'une exposition publique
obligatoire), limitée aux machines ayant explicitement installé l'autorité locale pour mkcert.
mkcert -install
# Installe l'autorité de certification locale mkcert dans le magasin
# de confiance du système -- à faire une fois par machine cliente
mkcert service1.internal service2.internal "*.internal"
# Génère un certificat couvrant plusieurs noms explicites ET un
# wildcard -- évite le piège du nom oublié
openssl x509 -in certificat.pem -noout -text | grep -A1 "Subject Alternative Name"
# Affiche la liste exacte des noms couverts par un certificat existant --
# la vérification directe en cas de doute
Dans un navigateur, ouvre un service en HTTPS via son nom .internal et clique sur le cadenas
pour inspecter le certificat. Il doit apparaître comme valide, émis par l'autorité locale
attendue, et couvrir le nom de domaine effectivement utilisé.
| SymptĂ´me | Cause probable | Solution |
|---|---|---|
| Avertissement de sécurité pour un seul service, les autres fonctionnant normalement | Le certificat ne couvre pas ce nom de domaine précis | Vérifier avec openssl x509 ... -text quels noms sont réellement couverts, régénérer si besoin |
| Avertissement de sécurité sur toutes les machines, un seul service | Autorité locale non installée sur cette machine cliente précise | mkcert -install sur chaque nouvelle machine cliente qui doit accéder aux services locaux |
| Tentative d'obtenir un certificat Let's Encrypt pour un service jamais exposé | Confusion entre les deux cas d'usage (public vs local) | Let's Encrypt exige une vérification publique du domaine — inutilisable pour un service qui reste uniquement local |
Parce qu'il exige de vérifier publiquement la propriété du domaine, ce qui suppose une
exposition sur Internet — précisément ce qu'un homelab qui reste local évite.
Il installe l'autorité de certification locale mkcert dans le magasin de confiance du système.
Chaque machine doit l'installer individuellement pour reconnaître comme valides les certificats
signés par cette autorité — la confiance ne se propage pas automatiquement comme avec une
autorité publique préinstallée.
Non — chaque nom doit être explicitement listé lors de la génération (ou couvert par un
certificat wildcard *.internal), sinon le nom non couvert déclenche un avertissement de
sécurité alors que les autres fonctionnent normalement.
Si mkcert est installé (ou après l'avoir installé) sur une machine à disposition, génère un
certificat pour deux noms fictifs (test1.local, test2.local) et vérifie avec openssl x509 ... -text que les deux apparaissent bien dans le certificat généré.
TLS ·
certificat ·
autorité de certification ·
Let's Encrypt ·
mkcert
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.