HTTPS sur son réseau local : en finir avec l'avertissement de sécurité

Trois façons d'obtenir du HTTPS valide en interne : certificat auto-signé, autorité maison, ou certificat public par validation DNS. Ce que chacune coûte réellement, et pourquoi l'une d'elles ne fonctionne plus sur mobile.

Vous accédez à l'interface de votre NAS, le navigateur affiche un avertissement rouge, vous cliquez sur « continuer malgré le risque ». Tous les jours. Le trafic est chiffré, donc l'essentiel est là.

Sauf que le vrai coût n'est pas technique. À force de contourner ces avertissements, vous vous entraînez à ne plus les lire — y compris celui qui, un jour, sera justifié.

Ce que le certificat auto-signé ne fait pas

Un certificat a deux fonctions : chiffrer la communication, et authentifier le serveur.

Le certificat auto-signé remplit la première parfaitement. Il ne remplit pas du tout la seconde : n'importe qui peut en générer un affirmant être votre NAS. Le navigateur n'a aucun moyen de distinguer le vôtre d'un intrus, et c'est précisément ce que l'avertissement dit.

Sur un réseau domestique maîtrisé, le risque réel reste modéré. L'habitude prise, elle, vous suit partout.

L'autorité maison : correcte, mais pénible

La solution classique consiste à créer sa propre autorité de certification, à signer ses certificats avec, et à installer la racine sur tous ses appareils. Techniquement, c'est la bonne réponse.

En pratique, deux difficultés apparaissent.

La première est le déploiement. Chaque appareil doit recevoir la racine : ordinateurs, téléphones, tablettes, télévision, et chaque nouvel arrivant. Certaines applications maintiennent leur propre magasin de confiance et ignorent celui du système — c'est fréquent avec les environnements de développement et certains outils en ligne de commande.

La seconde est le durcissement des mobiles. Les systèmes récents compliquent délibérément l'ajout d'autorités manuelles : manipulations supplémentaires, avertissements permanents, relégation à un niveau de confiance moindre, et applications qui refusent tout ce qui n'est pas d'origine. Vous obtenez une solution qui marche sur les ordinateurs et échoue sur les téléphones.

Ajoutez la gestion de la clé privée de l'autorité — qui, si elle fuite, permet d'usurper n'importe lequel de vos services — et le coût devient sérieux pour un usage domestique.

La validation DNS : la voie propre

Il existe une troisième option, largement sous-utilisée : obtenir un certificat public reconnu pour un service qui n'est jamais exposé à l'internet.

Le principe repose sur la méthode de validation. Habituellement, une autorité vérifie que vous contrôlez un service en le contactant sur son adresse publique — impossible ici. Avec la validation par DNS, vous prouvez que vous contrôlez le domaine en y créant un enregistrement temporaire que l'autorité vient lire.

Rien n'exige que le service soit joignable. Il peut rester entièrement privé, derrière votre pare-feu, sur une adresse non routable.

Le certificat obtenu est signé par une autorité déjà reconnue par tous vos appareils. Rien à installer, rien à déployer, aucun avertissement — y compris sur les téléphones et les appareils dont vous ne contrôlez pas le magasin de confiance.

Le point qui débloque tout : un certificat atteste d'un nom, pas d'une adresse. Que nas.lan.mondomaine.fr pointe vers une adresse privée n'entre pas dans la validation. Le navigateur vérifie le nom demandé, rien d'autre.

Ce que cela suppose

Trois prérequis, tous raisonnables :

Un domaine que vous possédez. C'est la condition principale. Un domaine inventé ne fonctionne pas — aucune autorité ne signera pour une extension qui ne vous appartient pas.

Un hébergeur DNS pilotable automatiquement. La validation crée et supprime des enregistrements temporaires ; sans automatisation, il faudrait le faire à la main à chaque renouvellement, ce qui devient vite intenable.

Un résolveur interne qui fait pointer ces noms vers vos adresses privées. C'est le complément naturel du DNS local.

Le certificat générique, pour n'en gérer qu'un

Plutôt qu'un certificat par service, demandez un certificat générique couvrant tous les sous-domaines d'un niveau. Un seul certificat pour l'ensemble de vos services internes, un seul renouvellement à surveiller.

Ce type de certificat n'est délivrable que par validation DNS — ce qui tombe bien, c'est déjà la méthode retenue.

Une contrainte à connaître : le caractère générique ne couvre qu'un seul niveau. Un certificat pour *.lan.mondomaine.fr couvre nas.lan.mondomaine.fr mais pas admin.nas.lan.mondomaine.fr. Concevez votre nommage à plat plutôt qu'en profondeur.

La distribution par le reverse proxy

Dernière brique : ne déployez pas le certificat sur chaque service. Placez un reverse proxy en entrée, qui porte le certificat unique et distribue vers les services internes.

Vous obtenez un seul point de renouvellement, un seul endroit où le certificat est stocké, et vous n'avez plus à vous soucier des services incapables de gérer proprement du TLS. C'est aussi l'endroit naturel pour ajouter une authentification devant les interfaces qui n'en ont pas.

Comment choisir

  • Vous ne possédez pas de domaine et n'en voulez pas : autorité maison, en acceptant les limites sur mobile.
  • Vous possédez un domaine : validation DNS avec certificat générique, sans hésiter. C'est moins de travail que l'autorité maison, et ça fonctionne partout.
  • Un service isolé, temporaire : l'auto-signé reste acceptable, à condition que ce soit un choix conscient et non une habitude.

Questions fréquentes

Un certificat auto-signé est-il vraiment insuffisant ?
Il chiffre correctement le trafic, mais il n'apporte aucune authentification : rien ne prouve que le serveur en face est bien le vôtre. C'est exactement ce que l'avertissement du navigateur signale. Le vrai coût est comportemental : à force de cliquer sur « continuer », on cesse de lire ces avertissements — y compris le jour où l'un d'eux est légitime. Sur un réseau domestique le risque technique reste faible ; l'habitude prise, elle, ne l'est pas.
Peut-on obtenir un certificat reconnu pour un service non exposé à l'internet ?
Oui, par validation DNS. Au lieu de prouver que vous contrôlez le service en le rendant joignable, vous prouvez que vous contrôlez le domaine en y créant un enregistrement temporaire. L'autorité vérifie cet enregistrement, délivre le certificat, et le service peut rester entièrement privé. C'est la méthode la plus propre pour un homelab, et elle fonctionne même si votre connexion n'accepte aucun trafic entrant.
Un certificat public fonctionne-t-il sur une adresse IP privée ?
Oui. Un certificat atteste d'un nom de domaine, pas d'une adresse. Si le navigateur demande nas.lan.mondomaine.fr et que le certificat couvre ce nom, la validation réussit — que ce nom résolve vers une adresse privée n'entre pas dans la vérification. C'est ce qui rend la combinaison DNS interne plus certificat public si efficace.
Faut-il un certificat par service ?
Un certificat générique couvrant tous les sous-domaines d'un niveau est bien plus pratique : un seul certificat pour l'ensemble de vos services internes, un seul renouvellement à surveiller. Il n'est délivrable que par validation DNS, ce qui tombe bien puisque c'est déjà la méthode retenue. Point d'attention : un caractère générique ne couvre qu'un seul niveau de sous-domaine, pensez-y en concevant votre nommage.
Pourquoi mon autorité maison ne fonctionne-t-elle pas sur mobile ?
Parce que les systèmes mobiles ont durci l'installation des autorités ajoutées manuellement : elles nécessitent des manipulations supplémentaires, sont parfois reléguées à un magasin de confiance de moindre niveau, et certaines applications refusent purement et simplement les autorités qui ne sont pas d'origine. Vous obtenez alors une configuration qui fonctionne sur vos ordinateurs et échoue sur vos téléphones — le pire des deux mondes en termes de maintenance.

Cet article vous a plu ?

Commentaires

Morgann Riu

Expert en cybersécurité et administration Linux. J'aide les entreprises à sécuriser et optimiser leurs infrastructures critiques.

Retour au blog

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.