Connexion refusée n’est pas un problème de certificat : un guide VPN

Le client signale une connexion refusée juste après que vous avez régénéré la CRL, donc la CRL semble coupable. Elle ne l’est pas. Le refus est une réponse de la couche transport, et la validation du certificat intervient plus tard, à l’intérieur de la poignée de main du tunnel. Le timing est un contexte, pas une preuve.

Deux vérifications séparent les cas en moins d’une minute, et aucune des deux ne touche aux réglages de confiance.

Lisez l’erreur à la couche qui l’a produite

Un ECONNREFUSED venant de connect signifie que la tentative de transport a été rejetée : quelque chose a répondu par un reset, ou la pile a signalé un port injoignable. Un problème de certificat ne peut pas produire cette erreur, car la poignée de main TLS ne commence jamais sans connexion de transport. Si vous voyez un refus, le client n’est jamais allé assez loin pour présenter un certificat. Ce seul fait écarte la révocation comme cause.

L’inverse est vrai aussi. Un certificat révoqué produit une connexion TCP aboutie et une poignée de main échouée, consignée sur le serveur comme une erreur de vérification.

Refus TCP : personne n’écoute

Pour TCP, vérifiez si l’instance prévue tourne et est liée à l’adresse et au port du profil. ss -lntp montre les écoutes, et l’absence de l’une est l’explication habituelle. Un pare-feu qui rejette au lieu de supprimer produit le même message côté client, c’est pourquoi vous vérifiez les deux.

Vérifiez aussi la famille d’adresses. Un service lié à 127.0.0.1 ou uniquement à IPv6 refusera un client qui se résout vers l’autre.

Lisez ensuite le journal du service au lieu de deviner. Un redémarrage après la maintenance de la CA peut échouer sur un fichier illisible ou absent et ne jamais atteindre l’état d’écoute, et le journal nomme le fichier. C’est un échec de démarrage, un bug différent d’un certificat rejeté.

UDP n’a pas de poignée de main à refuser

OpenVPN sur UDP n’établit pas de connexion au sens TCP, donc il n’y a rien à refuser au moment du connect. Sous Linux, une erreur remontée par une socket UDP peut venir d’un ICMP port-unreachable généré par un datagramme antérieur. La page de manuel udp(7) décrit ce comportement asynchrone.

C’est pourquoi un client UDP peut afficher un refus alors que le processus serveur tourne mais n’est pas lié à l’adresse attendue.

Où une CRL est réellement vérifiée

La CRL est consultée pendant la poignée de main TLS, après que le pair a présenté son certificat, et seulement si la configuration du serveur l’autorise. L’option crl-verify d’OpenVPN pointe vers le fichier, et un échec apparaît dans le journal du serveur comme une erreur de vérification nommant le certificat.

Un client révoqué se connecte donc au niveau de la couche transport puis échoue à l’authentification. Même serveur, même port, message complètement différent.

Vérifiez l’émetteur et les dates de validité de la CRL lorsque vous atteignez cette étape. Une CRL signée par la mauvaise CA, ou une qui a expiré avant la connexion du client, produit des erreurs de vérification qui n’ont rien à voir avec le certificat du client lui-même.

Un guide court pour la prochaine fois

Confirmez d’abord le transport : une écoute présente, la bonne famille d’adresses, un pare-feu qui ne rejette pas. Confirmez ensuite que le service a atteint son état d’écoute en lisant le journal de démarrage. Puis, et seulement alors, regardez les erreurs de poignée de main pour des messages de vérification. Gardez cet ordre fixe, car chaque étape élimine toute une classe de causes.

Notez le transport, la destination résolue, le port et le texte exact de l’erreur. Réinstaller le client détruit cette preuve et ne change généralement rien.