Certificat client auto-signé ? Le serveur VPN le refuse toujours

L’opérateur envoie une adresse et un nom d’utilisateur, et le client demande un fichier d’AC, un certificat et une clé. Générer ces trois éléments localement semble l’étape suivante évidente. Il en résulte un certificat auquel seule votre propre machine croit. La confiance du serveur est ancrée dans une AC que vous ne contrôlez pas, donc la poignée de main se termine avant de commencer.

La confiance vit sur le serveur, pas dans votre profil

L’authentification par certificat est une comparaison. Le client présente un certificat ; la passerelle vérifie s’il a été signé par l’une des AC de sa configuration.

Votre profil nomme le fichier d’AC que le client doit utiliser pour vérifier le serveur. Il ne peut pas nommer une AC que le serveur devrait utiliser pour vous vérifier. Cette moitié de la configuration ne vous appartient pas.

Un certificat fabriqué par vous échoue à cette comparaison même lorsqu’il est techniquement parfait. Il possède une signature valide, un sujet et des dates, mais l’émetteur est une AC dont la passerelle n’a jamais entendu parler. L’erreur apparaît pendant la poignée de main, après que le serveur a déjà demandé un certificat. Rien dans le profil client ne peut changer la réponse.

Pourquoi un certificat auto-signé ne peut pas le remplacer

Un certificat auto-signé est signé par sa propre clé. La signature se vérifie contre le même fichier, ce qui le rend cohérent avec lui-même et inutile comme justificatif pour la passerelle d’un autre.

La passerelle ne demande pas si le certificat est cohérent en interne. Elle demande si un émetteur de confiance l’a signé.

C’est pourquoi les messages d’erreur sont déroutants. Le client peut signaler un échec de vérification qui ressemble à un problème de serveur, tandis que le serveur journalise un émetteur inconnu. Les deux décrivent le même désaccord depuis des extrémités opposées.

La voie de la CSR conserve votre clé privée

Vous pouvez encore faire l’essentiel du travail localement. Générez une paire de clés, construisez une demande de signature de certificat autour de la moitié publique et envoyez cette demande à l’opérateur. Seule la demande quitte votre machine. La moitié privée reste là où vous l’avez générée.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

L’opérateur signe la demande avec son AC et renvoie un certificat. Votre clé privée n’a jamais voyagé, et le résultat remonte à l’ancre à laquelle la passerelle fait confiance.

Les services gérés sautent souvent la CSR et délivrent le paquet complet. C’est un échange raisonnable lorsque le même fournisseur termine déjà le tunnel et détient l’AC. La garde de la clé n’est pas améliorée par le fait de la conserver, car le fournisseur pourrait en frapper une nouvelle à tout moment.

Les paquets s’importent, ils ne s’installent pas

Les paquets de fournisseurs aux noms rassurants sont souvent des profils OpenVPN. Ils contiennent de la configuration et parfois des certificats, et ils n’installent rien. Importez le fichier dans un client qui parle le protocole, et la connexion est configurée.

La règle de manipulation découle du contenu. Si le profil intègre une clé privée, c’est un justificatif et il mérite le même soin qu’un mot de passe : pas d’e-mail, pas de dépôt, pas de dossier de téléchargements partagé. Lorsque l’opérateur fournit ca.crt, client.crt et client.key séparément, conservez-les ensemble avec des permissions restrictives et pointez le profil vers eux.

Ajoutez les contrôles que l’opérateur a peut-être omis

Un profil généré par le routeur manque parfois de vérification du pair. remote-cert-tls server exige que le certificat du pair porte l’usage d’authentification serveur, afin qu’un certificat client ne puisse pas être rejoué comme serveur. Cette ligne est un petit changement avec une justification claire.

verify-x509-name va plus loin lorsque l’opérateur peut nommer le sujet ou le SAN attendu. Les deux sont de petits ajouts à un profil, et les deux sont défendables. Inspectez ce que vous avez reçu avant de l’importer.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Les réglages de vérification ne réparent pas une chaîne cassée. Si l’émetteur est faux, la réponse est un certificat de la bonne AC, pas un indicateur qui désactive la vérification. Désactiver la vérification transforme un échec d’authentification en échec non détecté.

Demandez un seul paquet : le certificat de l’autorité au format PEM, un certificat client signé par cette autorité, une clé que vous avez générée ou qui est arrivée par un canal auquel vous faites confiance, et le nom exact du serveur que le certificat doit présenter. Notez la date d’expiration dans le même message, car un certificat expiré ressemble à une panne réseau des mois plus tard.