Certificat VPN auto-signé : ce qu’il signifie et ce à quoi il fait confiance

Deux croyances font ici le plus de dégâts : qu’un certificat VPN auto-signé signifie que le tunnel n’est pas chiffré, et qu’installer tout ce que le client VPN a demandé n’affecte que le VPN. Aucune ne survit au contact d’un déploiement réel. Un certificat auto-signé décrit une relation de signature, pas un verdict de sécurité, et la portée de la confiance que vous ajoutez dépend du magasin où elle atterrit. J’ai vu un centre d’assistance importer une racine de fournisseur dans une machine Windows pour faire taire un avertissement, puis passer un après-midi à expliquer pourquoi le navigateur avait cessé de se plaindre d’un portail sans rapport. Les deux moitiés de cette question vont ensemble, alors traitez-les comme une seule.

Un certificat n’est pas un magasin de confiance

Le fichier que présente le serveur porte une clé publique, un nom de sujet, un nom d’émetteur, des dates de validité et des extensions. Auto-signé signifie que le sujet et l’émetteur sont la même entité et que la signature se vérifie avec la clé du certificat lui-même. Rien dans cette définition ne dit que la connexion est faible, et rien ne dit que le client l’acceptera.

L’acceptation vient d’ailleurs : un fichier CA vers lequel vous pointez le client, une empreinte que vous comparez à la main, ou une racine déjà présente dans un magasin que le client lit. Un déploiement peut être parfaitement sain alors que son certificat échouerait à tous les tests publics. openssl verify contre le paquet système signalera un émetteur inconnu, et ce rapport est correct, pas un défaut.

L’option ca d’OpenVPN est le cas le plus clair de confiance limitée à l’application. Ce fichier nomme les ancres que le client acceptera, et il peut contenir une CA privée ou, dans un petit déploiement, le propre certificat auto-signé du serveur. La version 2.6 accepte aussi --peer-fingerprint pour épingler une empreinte SHA-256 au lieu de distribuer un fichier CA. WireGuard se situe encore plus loin : il n’a aucun certificat, seulement une clé publique statique par pair, donc la question de l’auto-signature ne s’y applique pas.

L’endroit où vous installez la confiance décide qui en hérite

Placez le même certificat à trois endroits et vous obtenez trois rayons d’action différents. Un paquet lu uniquement par le client VPN affecte ce client. Une racine dans le magasin du système d’exploitation affecte tous les programmes qui consultent ce magasin. Un navigateur doté de sa propre base de confiance peut ignorer les deux, et c’est pourquoi un avertissement peut survivre à une importation qui semblait fonctionner.

Sous Debian ou Ubuntu, déposer un fichier dans /usr/local/share/ca-certificates/ et exécuter update-ca-certificates modifie le paquet à l’échelle du système. Sous Windows, certutil -addstore -f Root écrit dans le magasin de la machine et exige une invite élevée, tandis que l’ajout de -user cible plutôt le magasin de l’utilisateur courant ; les deux ne sont pas interchangeables. Firefox tient sa propre base NSS, donc une importation au niveau du système peut ne jamais y apparaître.

La portée compte à cause de ce qu’une autorité peut faire. Une CA émettrice peut signer des noms avec lesquels elle n’a aucune relation, donc tout ce qui fait confiance à ce magasin acceptera ces signatures. Une seule feuille épinglée ne peut pas le faire ; elle authentifie exactement une identité de pair. Si l’objectif est de faire connecter un VPN, une CA limitée à l’application ou une feuille épinglée y parvient, alors qu’une racine à l’échelle de la machine est une concession bien plus grande que ce que le symptôme exige.

Vous chiffrez toujours sans CA publique

La poignée de main TLS dérive des clés de session que le certificat du pair s’enchaîne ou non à quelque chose auquel vous faites déjà confiance. Auto-signé ne signifie pas texte en clair, et ne signifie pas que le trafic est lisible en vol. Cela signifie que le client n’a aucune raison a priori de croire que la clé appartient au serveur qu’il a demandé.

C’est dans cet écart que vivent les vraies attaques. Un client configuré pour accepter n’importe quel certificat, que ce soit par un réglage de vérification désactivé ou par un bouton « faire confiance quand même » cliqué une fois et oublié, chiffrera volontiers vers quiconque répond. L’interception se produit à l’étape d’authentification, avant que les données applicatives ne circulent. Le chiffrement sans contrôle d’identité tient un observateur passif à l’écart et ne fait guère plus.

Faire confiance à l’émetteur ne saute pas le contrôle du nom

La validation de chaîne, la correspondance du nom et l’usage du certificat sont des décisions distinctes. Une chaîne peut être valide alors que le nom est faux, et un nom peut correspondre alors que le certificat a été émis pour un autre rôle. RFC 5280 définit les champs qui portent ces contraintes, et la rigueur avec laquelle un client les applique est propre à chaque application.

OpenVPN rend la séparation visible. verify-x509-name épingle le sujet attendu via une correspondance name, name-prefix ou subject. remote-cert-tls server exige que le certificat du pair soit utilisable comme certificat de serveur, ce qui rejette un certificat client seul même lorsque l’émetteur est de confiance. Aucun des deux réglages n’est remplacé par l’envoi d’un fichier CA.

Inspectez le certificat avant de décider quoi que ce soit :

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName indique qui l’a émis, pour quels noms et jusqu’à quand.
• openssl verify -CAfile ca.crt server.crt vérifie si la chaîne que vous comptez envoyer valide réellement la feuille.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error fonctionne pour des points de terminaison TLS comme un portail web ; le protocole OpenVPN sur 1194 n’est pas un flux TLS ordinaire, donc ce test ne s’y applique pas.

Un certificat dont la date est expirée, sans subjectAltName pour le nom auquel vous vous connectez ou sans usage serverAuth échoue, quel que soit le soin apporté à l’installation de l’ancre.

Cinq contrôles avant d’en accepter un

Comparez l’empreinte par un canal qui n’est pas la connexion que vous essayez de réparer : une console, un installateur que vous possédez déjà, un fichier de configuration signé. openssl x509 -in server.crt -noout -fingerprint -sha256 sur le serveur et la même valeur dans le journal du client suffisent à savoir que vous regardez un seul objet.

Ensuite, décidez ce que vous installez : une feuille, ou une autorité qui peut en forger d’autres. Puis décidez où elle va, et nommez les applications qui lisent ce magasin. Notez le chemin de retrait pendant que vous vous en souvenez encore, car faire-confiance-et-continuer est ainsi qu’une importation temporaire devient permanente.

Enfin, planifiez le changement. Un certificat ou une empreinte épinglés doivent être mis à jour par le même canal de confiance lorsque le certificat tourne, et une CA privée a son propre cycle de vie d’émission et de révocation. Si la clé privée fuit, refaire confiance à une copie du même certificat ne répare rien ; l’identité doit être remplacée.

Si un avertissement survit aux cinq contrôles, la question utile n’est pas quel bouton le fait taire mais quel magasin le client lit réellement et d’où venait cette racine. Répondez à cela, et l’importation que vous êtes sur le point de faire devient une décision plutôt qu’un réflexe.