Ce que votre client VPN vérifie avant de faire confiance à un certificat

Votre client VPN indique que le certificat n’a pas pu être vérifié, et la boîte de dialogue s’arrête là. Le fichier est présent, le serveur tourne, et le même profil fonctionnait sur un autre portable le mois dernier. Sous cet avertissement d’une ligne, le client a fait passer le certificat du pair par quatre portes : une autorité de certification que vous avez configurée garantit le chemin de signature, ce chemin atteint l’autorité, le nom du pair est celui que vous avez demandé, et le certificat est utilisable maintenant pour cet usage. Trouvez la porte qui s’est fermée et la réparation tient souvent à un fichier ; sautez cette étape et vous réimporterez des paquets tout l’après-midi.

Lisez la boîte de dialogue avant de modifier le profil

Les erreurs de certificat sont formulées par la bibliothèque en dessous, pas par le produit VPN que vous avez installé, donc la chaîne exacte est votre première preuve. « Impossible d’obtenir le certificat de l’émetteur local » désigne le chemin ou l’ancre de confiance. « Le certificat a expiré ou n’est pas encore valide » désigne le temps. « Usage du certificat non pris en charge » désigne l’usage étendu de la clé. Un désaccord de nom vous indique quel nom il voulait. Aucune des quatre n’est réparée en réinstallant le client.

Montez le niveau de journalisation avant de changer quoi que ce soit. OpenVPN signale l’échec de vérification autour de la poignée de main quand vous le lancez avec --verb 4, et strongSwan consigne ses décisions d’identité et de chaîne dans le journal charon. Confirmez ensuite quel certificat vous inspectez, car on teste couramment le fichier sur le disque alors que le profil incorpore une copie plus ancienne. Quand le profil incorpore des blocs PEM, c’est le certificat incorporé qui est testé.

Une autorité de certification signe des identités, pas des permissions

L’autorité détient un nom et une clé de signature. Elle émet des certificats qui lient une clé publique à ce nom selon sa propre politique, avec une fenêtre de validité et des contraintes d’usage attachées. Votre client n’a besoin que du certificat de l’autorité pour reconnaître l’émetteur ; il n’a jamais besoin de la clé de signature, et livrer cette clé aux clients leur donnerait le pouvoir de fabriquer n’importe quelle identité à laquelle le déploiement fait confiance.

Faire confiance à une autorité rend candidat chaque certificat qu’elle a signé, pas le bon pair. Un certificat de serveur web de la même AC interne est aussi candidat. C’est pourquoi les portes du nom et de l’usage existent, et pourquoi une clé d’AC compromise compte plus que n’importe quel serveur isolé : elle atteint chaque identité que l’autorité a jamais émise. Distribuez des certificats client par appareil, pour qu’un portable perdu soit une révocation et non une régénération de clés sur tout le déploiement.

Reconstruisez le chemin que le client tente de construire

Le chemin part du certificat du pair, traverse zéro ou plusieurs intermédiaires, et aboutit à une racine de votre magasin de confiance. Un intermédiaire manquant est la panne de chaîne la plus courante, et côté client elle ressemble exactement à une racine non fiable. Lisez d’abord la feuille, puis laissez OpenSSL construire le chemin à partir du matériel que vous comptez livrer.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Un code de sortie nul signifie que le chemin a été construit à partir de ces fichiers ; un échec nomme le certificat qu’il n’a pas pu atteindre. Si openssl verify réussit alors que le client refuse encore, la différence tient à ce que le serveur envoie réellement ou au fichier de confiance que le profil charge. Dans OpenVPN, les intermédiaires peuvent voyager dans le fichier de certificat du serveur ou être fournis séparément avec --extra-certs, et un paquet contenant deux racines écrites sous le même nom de sujet enverra l’un de vos clients dans la mauvaise branche.

Le nom et l’usage sont des portes distinctes

La construction de la chaîne ne demande jamais si le nom est le vôtre. OpenVPN ne le vérifie que lorsque le profil définit --verify-x509-name, et la vieille habitude de ne faire correspondre que le nom commun se casse sur les certificats dont les identités vivent dans subjectAltName. Les déploiements IKEv2 font correspondre l’identité configurée aux entrées SAN ou au nom distinctif, selon le client, et une valeur joker ou %any désactive silencieusement la comparaison que vous croyiez avoir.

Viennent ensuite le temps et l’usage. Un portable dont l’horloge avance de quelques heures rejette un certificat qui n’est pas encore valide, et un intermédiaire expiré fait échouer le chemin alors que la feuille est valide. Les échecs d’usage viennent d’un certificat sans serverAuth dans l’usage étendu de la clé, ou avec un keyUsage qui n’autorise pas la signature de la poignée de main, ce qu’OpenSSL signale comme un usage de certificat non pris en charge. Réémettez depuis le bon modèle ; rien dans ce message n’est une raison de désactiver la vérification.

La révocation ne tourne que si quelqu’un l’a configurée

Une CRL ou une réponse OCSP n’est pas consultée automatiquement. Sur un serveur OpenVPN, les certificats client ne sont comparés à une liste que lorsque --crl-verify en désigne une. La vérification du certificat serveur côté client dépend de l’implémentation et est souvent absente. strongSwan a besoin de son greffon de révocation et d’une politique avant de regarder une CRL pour un pair.

C’est ce qui explique le ticket que vous finirez par recevoir : un certificat client révoqué se connecte encore, et tout le monde conclut que la révocation est cassée. Rien ne vérifiait. Publiez et rafraîchissez la CRL, ou gardez des certificats client assez éphémères pour qu’une révocation périmée ne compte que brièvement, et répétez le chemin de révocation sur un certificat de laboratoire avant d’en avoir besoin pendant un incident.

Un ordre de réparation qui garde la vérification active

Triez par symptôme avant de toucher aux fichiers, car chaque ligne du tableau vous envoie vers un objet différent.

Parcourez la liste en une seule passe : confirmez le fichier que le profil charge, construisez le chemin vous-même, vérifiez que le serveur envoie l’intermédiaire, comparez l’horloge, lisez le SAN, lisez l’EKU, puis reconnectez-vous et regardez la même ligne de journal disparaître. Si un appareil ne peut recevoir aucune AC, l’épinglage est l’alternative honnête, car OpenVPN 2.6 accepte --peer-fingerprint et réduit la confiance à une clé au lieu de supprimer la vérification. RFC 5280 est la référence pour la signification de chacun de ces champs.