Auto-signé ou CA publique pour un VPN : ce qui change vraiment

Vous arrivez sur la page des certificats d'une configuration VPN, vous voyez une option auto-signée gratuite à côté d'une CA publique payante, et la question ressemble à un choix de sécurité. C'est en réalité un choix d'audience. Les deux options chiffrent le tunnel avec les mêmes primitives, et les deux deviennent inutiles si la clé privée fuit. Ce qui les sépare, c'est qui formule l'affirmation sur l'identité du serveur et qui est en position de vérifier cette affirmation.

Un certificat remplit deux fonctions que l'on confond

Un certificat lie une clé publique à un nom, et la clé fait le travail de chiffrement et de signature. La signature du certificat est une déclaration distincte : une autorité a vérifié que le nom appartient à ce détenteur de clé. Un certificat auto-signé fait cette déclaration sur lui-même, ce qui n'est pas du tout une affirmation de tiers.

Les sites web publics ont besoin de la version tierce, car les visiteurs arrivent sans relation préalable et s'appuient sur le magasin de confiance du navigateur. Un client VPN n'est pas un inconnu. Vous lui donnez le certificat de la CA, ou vous épinglez le certificat du serveur, dans le profil qu'il installe, si bien que la vérification s'exécute contre exactement l'autorité que vous avez choisie. Aucune CA commerciale n'a besoin d'être impliquée pour que cette vérification ait un sens.

La force de la session obtenue vient de la taille de la clé et de la suite de chiffrement, pas du signataire. C'est pourquoi qualifier un certificat auto-signé de "moins chiffré" est tout simplement faux ; il est moins largement garanti, ce qui est une propriété différente.

Où une CA publique gagne ses honoraires

Le cas le plus clair est la page d'administration. Si des collègues, des prestataires ou quiconque sans profil préparé doivent ouvrir l'interface web du serveur VPN sans avertissement du navigateur, un certificat publiquement approuvé supprime cette friction. Le navigateur fait déjà confiance au signataire, donc il n'y a rien à importer et rien à expliquer.

Ce confort a des coûts qu'il vaut la peine de nommer avant d'acheter. Le renouvellement doit être automatisé, sinon le site casse selon un calendrier, les certificats publics exposent le nom d'hôte dans les journaux de transparence des certificats, et les limites de débit d'émission punissent un script qui réessaie trop ardemment. Aucun de ces points n'est une raison d'éviter une CA publique, mais c'est du travail d'exploitation qu'une CA privée déplace ailleurs.

Ce qu'un certificat public ne fait pas, c'est authentifier vos utilisateurs. L'identité du client est une décision distincte, prise avec des certificats client, des mots de passe ou un second facteur, et la CA qui signe le serveur ne dit rien sur qui peut s'y connecter.

Où une CA privée convient à un VPN

Pour un VPN privé avec un ensemble connu de clients, exploiter votre propre CA est le choix conventionnel. Vous créez la CA une fois, signez le certificat du serveur avec un nom que les clients utiliseront, et distribuez le certificat de la CA dans chaque profil. Chaque client vérifie alors le serveur auprès de votre autorité, et aucune partie extérieure n'apprend le nom d'hôte.

Les coûts sont réels mais bornés. Les navigateurs avertiront lorsque quelqu'un ouvre la page d'administration directement, car le navigateur n'a aucune raison de faire confiance à votre CA. La distribution des profils fait partie de l'intégration, et faire tourner la CA signifie toucher chaque client. Ce sont des prix acceptables pour un service avec dix ou cinquante utilisateurs connus et douloureux pour un point de terminaison public avec des milliers.

Une condition rend tout l'arrangement valable : la vérification doit avoir lieu. Un client configuré pour ignorer les erreurs de certificat accepte n'importe quel serveur présentant n'importe quel certificat, si bien que la garantie d'identité disparaît tandis que le chiffrement demeure. Ce réglage est la véritable faiblesse dans la plupart des récits du type "l'auto-signé n'est pas sûr".

La clé privée de la CA décide de ce que vous pourrez faire plus tard

La surprise arrive généralement des mois plus tard, quand vous voulez ajouter un appareil. Émettre un certificat client exige la clé privée de la CA, tout comme produire une liste de révocation. Si vous avez hérité d'un serveur qui possède les fichiers de certificat et de clé mais pas la clé de la CA, vous ne pouvez rien signer de nouveau. Vos options sont de reconstruire la PKI et de remettre à chaque client un nouveau certificat de CA, ou de passer à l'authentification par mot de passe, qui est un autre modèle de sécurité et ne restaure pas ce qui a été perdu.

Deux pièges plus petits vivent dans le même territoire. Les scripts easy-rsa supposent que vous vous tenez dans le répertoire qui les contient, donc une erreur de fichier manquant signifie généralement le mauvais emplacement plutôt qu'une installation endommagée. Et une conception uniquement par certificats est parfaitement légitime : vous pouvez exiger des certificats client sans clé pré-partagée, à condition que chaque client en ait un et que le serveur vérifie la chaîne.

Émettez un certificat par appareil plutôt qu'un certificat client partagé pour toute l'équipe. Un ordinateur portable perdu vous coûte alors une seule révocation au lieu d'une réémission pour tout le monde.

Vérifiez ce que vous avez hérité

Avant de planifier un quelconque changement, lisez le certificat que vous possédez déjà :

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Si l'émetteur est égal au sujet, le certificat est auto-signé, ce qui est un choix de conception et non un défaut. Les dates vous indiquent quand le renouvellement deviendra le problème de quelqu'un, et une vérification réussie contre la CA que vous comptez déployer confirme que la chaîne fonctionne avant qu'un seul client ne l'essaie.

Choisissez ensuite selon l'audience et la distribution : CA publique quand des navigateurs inconnus doivent faire confiance à la page d'administration, CA privée quand chaque client reçoit un profil que vous contrôlez. Aucune des deux réponses n'est plus chiffrée que l'autre.