Objet de certificat non pris en charge : pourquoi l'autorité intermédiaire échoue

L'objet du certificat serveur semble correct, la clé correspond, les dates sont bonnes, et la connexion échoue toujours avec unsupported certificate purpose. Le détail qui résout cela se trouve généralement sur la même ligne que l'erreur : une valeur de profondeur et un subject qui nomment un certificat plus haut dans la chaîne. Deux tests différents sont exécutés, et un seul d'entre eux porte sur le certificat final. Les comparer explique pourquoi remplacer le certificat serveur ne change rien.

Quel certificat le vérificateur a réellement rejeté

Une chaîne n'est pas un objet répété trois fois. Le certificat final porte le nom et la clé du serveur, les intermédiaires le relient à une racine, et chacun a sa propre période de validité, ses contraintes et ses usages. Quand l'erreur nomme une profondeur, ce nombre désigne une position dans la chaîne construite par le vérificateur, qui n'est peut-être pas celle que vous attendez si le serveur envoie une chaîne inattendue.

Lisez les champs du certificat à cette profondeur plutôt que du certificat que vous soupçonniez. Demandez les deux extensions qui encadrent l'émission au lieu de déverser tous les champs, car la réponse est presque toujours dans l'une d'elles. La sortie des extensions peut être partagée sans risque ; les clés privées jamais.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Si le certificat nommé est un intermédiaire dont l'usage étendu de la clé mentionne quelque chose sans rapport avec l'authentification de serveur TLS, le reste de l'échec s'ensuit mécaniquement. La chaîne ne peut pas servir à l'objet demandé par OpenVPN.

L'objet du certificat final et la politique de la chaîne sont deux tests

Le test du certificat final pose une question étroite : ce certificat d'entité finale autorise-t-il l'authentification de serveur pour ce nom ? Le test de la chaîne en pose une plus large : chaque certificat du chemin peut-il servir cet objet ? Une autorité de certification autorisée à n'émettre que des certificats clients passera ses propres contrôles de signature et échouera quand même au second test, car le chemin qu'elle autorise n'inclut pas l'objet dont l'application a besoin. Les deux tests échouent avec les mêmes mots et ont des réparations totalement différentes.

C'est pourquoi un certificat final fraîchement émis, correct dans chaque champ visible, peut échouer immédiatement. C'est aussi pourquoi le correctif relève généralement du profil de l'autorité émettrice et non de la configuration du VPN.

Une EKU absente n'est pas une EKU restrictive

La RFC 5280 rend l'extension d'usage étendu de la clé facultative et, lorsqu'elle est présente, restrictive. Un certificat d'AC sans l'extension n'a donc pas dit « non » à l'authentification de serveur, tandis qu'un certificat qui n'énumère qu'un objet sans rapport a dit quelque chose de très précis. Traiter ces deux états comme équivalents produit le mauvais diagnostic et, pire, la mauvaise réparation. La distinction explique aussi pourquoi deux autorités qui se ressemblent dans une console se comportent très différemment dans une chaîne.

Le comportement des bibliothèques n'est pas uniforme ici non plus. document d'OpenSSL sur les options de vérification décrit son propre traitement des contrôles d'objet sur les certificats d'AC, et ce traitement est une politique d'implémentation, non une règle que toutes les piles TLS suivraient à l'identique. Décrivez ce que fait votre vérificateur, puis confirmez-le avec la version que vous exécutez réellement.

Reproduisez l'échec hors ligne avant de réémettre

Une vérification hors ligne retire l'application de l'équation. Si la chaîne échoue de la même manière avec le même objet, le certificat est le problème et aucune configuration serveur ne le cachera. Si la chaîne passe hors ligne alors que le service refuse encore, l'application demande un autre objet ou utilise une autre chaîne que celle testée.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain compte parce qu'il imprime le chemin construit par l'outil, qui n'est souvent pas l'ordre des fichiers que vous avez fourni. Cette sortie est le moyen le plus rapide de découvrir qu'un second intermédiaire est tiré d'un magasin de confiance, que le serveur envoie une variante signée en croix que vous n'aviez pas prévue, ou que l'indicateur d'objet copié d'un tutoriel appartient à un rôle différent de celui servi.

Corrigez la politique d'émission, pas l'appel de vérification

La réparation durable est un intermédiaire émis selon une politique qui autorise les objets qu'il doit servir, avec la contrainte écrite et revue. Ajouter chaque objet à chaque autorité n'est pas une politique ; cela supprime la contrainte qui donnait son sens à l'extension et survit généralement à l'incident qui l'a motivée. Une courte note dans le profil décrivant quels rôles l'autorité peut certifier évite que la prochaine réémission répète le même débat.

Désactiver la vérification est l'autre raccourci tentant, et il transforme un problème de certificat en problème de confiance. Gardez le contrôle d'objet, corrigez la chaîne et relancez la même vérification hors ligne pour confirmer que le chemin sert désormais le rôle prévu avant de toucher à nouveau le service.