Une chaîne de certificats serveur peut-elle contourner le magasin de confiance du client ?

Un navigateur affiche un avertissement de certificat sur un site dont la chaîne est complète, et le premier réflexe est de corriger le serveur. Le serveur présente généralement exactement ce qu’il devrait. Le client décide quelles ancres il accepte, et aucun agencement de certificats intermédiaires ne peut changer cette décision depuis l’autre extrémité de la connexion. Cette frontière explique l’essentiel de ce qui ressemble à un problème de certificat.

La validation s’exécute sur le client, avec les ancres du client

La validation de chemin prend les certificats présentés et construit une chaîne jusqu’à une ancre de confiance que le système de validation possède déjà. La RFC 5280 décrit ce modèle, et elle place le choix de l’ancre dans l’implémentation locale plutôt que sur le serveur. Une application peut y ajouter sa propre politique : une clé épinglée, un magasin de confiance d’entreprise, ou une vérification d’identité plus stricte. La liste de certificats qu’un serveur envoie est une preuve offerte à ce processus, jamais une instruction qui lui est adressée.

Ainsi, une chaîne complète prouve que le serveur possède les pièces. Elle ne prouve pas que le client les acceptera.

Pour voir ce que le serveur envoie réellement, exécutez openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts et comptez les certificats dans la sortie. Une chaîne incomplète ici est une correction côté serveur. Une chaîne complète déplace la question vers le client et ses ancres, où le serveur n’a pas voix au chapitre.

Ce que l’inspection TLS change réellement

Un équipement d’inspection termine la session TLS côté client et ouvre une session distincte vers le service réel. Le client valide ensuite le certificat de l’équipement, qui doit chaîner vers une ancre à laquelle le client fait confiance. C’est pourquoi les appareils gérés reçoivent la racine d’inspection via la gestion des appareils, et pourquoi un appareil personnel qui en est dépourvu affiche un avertissement.

La disposition est délibérée et locale. Rien dans la chaîne du serveur d’origine ne peut forcer un navigateur non géré à accepter l’identité de substitution, et rien n’empêche un appareil géré de le faire.

La terminaison VPN n’est pas un déchiffrement HTTPS

Une couche VPN transporte des paquets entre un client et une passerelle. La retirer, ou lire sa configuration, n’expose pas de charge utile HTTPS à l’intérieur.

La session TLS continue entre le navigateur et le serveur web, avec les mêmes règles de validation, sauf si quelque chose y met explicitement fin. Confondre les deux couches produit une demande à l’administrateur du VPN de fournir le certificat, alors que le certificat en question appartient à un proxy d’inspection ou au site lui-même. Demandez quel composant présente le certificat avant de modifier un magasin de confiance.

Fixez les attentes dans le composant que vous contrôlez

Si vous exploitez l’application et son client, définissez ensemble l’identité de service attendue, les émetteurs acceptés et toute exigence d’épinglage ou d’authentification client. Planifiez le renouvellement et la reprise pour qu’un changement légitime de certificat ne devienne pas une panne. Si vous n’exploitez que le serveur public, documentez l’authentification que vous exigez et les environnements clients que vous prenez en charge. Envoyer une chaîne préférée ne certifie pas l’appareil d’un inconnu.

Sur un équipement géré, résolvez l’incompatibilité avec les responsables de l’application et du réseau. Désactiver la vérification, ajouter une racine inexpliquée ou tenter de survivre à une politique d’inspection n’établit pas la relation d’homologue voulue.

Testez le résultat sur un profil client propre, pas sur la machine où une exception a déjà été ajoutée. C’est le seul contrôle qui montre ce qu’un nouvel appareil vivra.