# Échecs de certificats TLS : procédure de réponse pour un agent

Une erreur de certificat lors d'un appel API d'agent est un signal d'arrêt, pas un simple désagrément réseau. L'appel peut contenir un bearer token, une requête signée, une fiche client ou des instructions qui modifient l'état de la production. Si le client ne peut pas établir à qui appartient l'autre extrémité de la connexion, il n'a aucune raison de lui transmettre ces éléments.

Ce problème est souvent mal géré parce qu'une personne sous pression voit un certificat expiré et utilise une option qui désactive la sécurité. Avec un agent autonome, ce raccourci est encore plus dangereux. Il peut réessayer rapidement, suivre une instruction cachée dans un ticket de dépôt et répéter le même appel risqué avec plusieurs identifiants. Une bonne procédure arrête l'exécution, sépare les faits des suppositions et ne rétablit l'accès qu'après avoir prouvé que le point de terminaison prévu est bien celui qui reçoit de nouveau le trafic.

## Un avertissement de certificat modifie la décision de confiance

TLS remplit deux fonctions que l'on confond trop souvent. Il chiffre le trafic et vérifie l'identité du serveur. Le chiffrement sans vérification d'identité offre seulement à un attaquant une conversation privée avec votre client.

La RFC 6125 décrit comment une application compare l'identité d'un service à un identifiant de référence, généralement le nom DNS que le client voulait joindre. La RFC 5280 décrit la validation du chemin de certification : le client construit une chaîne depuis le certificat feuille présenté, en passant par les intermédiaires, jusqu'à une ancre de confiance. Les deux vérifications comptent. Un certificat peut avoir une signature valide et appartenir malgré tout à `api-attacker.example`, et non à `api.example`. Il peut contenir le bon nom d'hôte tout en remontant jusqu'à un émetteur que votre organisation n'a jamais approuvé.

Pour le trafic d'un agent, la conséquence est concrète. Un bearer token injecté dans une requête HTTPS devient utilisable par quiconque termine la connexion. Une requête signée avec un identifiant client peut autoriser des changements d'état. Une réponse API provenant d'un imposteur peut commander une action ultérieure ou contaminer le contexte de travail d'un agent. Le fait que la requête soit chiffrée ne change rien à ces risques.

Traitez ces messages comme des événements de sécurité jusqu'à ce que l'équipe en établisse la cause :

- certificat expiré ou pas encore valide
- nom d'hôte ou nom alternatif du sujet incohérent
- certificat de l'émetteur local introuvable ou impossibilité de vérifier le premier certificat
- certificat auto-signé dans la chaîne de certificats
- échec de la vérification du certificat après un changement de proxy, de DNS ou de réseau

Ne classez pas chaque échec comme une attaque en cours. Un certificat intermédiaire oublié et l'horloge incorrecte d'un ordinateur portable sont des problèmes opérationnels ordinaires. La réponse commence par l'incertitude, car la même catégorie d'erreur apparaît lorsqu'une personne redirige le trafic ou installe un proxy d'interception non approuvé.

Une connexion TCP réussie prouve seulement que quelque chose a répondu à une adresse. Une négociation TLS réussie avec la vérification désactivée prouve encore moins. La vérification de l'identité du serveur est le moment où un appel API utilisant des identifiants obtient l'autorisation de quitter la machine.

## Arrêtez l'exécution concernée avant de chercher des indices

La première mesure opérationnelle consiste à empêcher tout nouvel appel utilisant des identifiants vers la destination en échec. Suspendez le processus de l'agent, révoquez sa session active si votre couche d'action le permet ou retirez-lui l'autorisation d'effectuer l'action. Faites-le avant de passer une heure à débattre de la familiarité du certificat.

Conservez l'erreur d'origine exactement telle quelle. Notez le nom d'hôte et le port complets, la méthode de requête sans son en-tête d'autorisation, l'horodatage avec le fuseau horaire, l'environnement d'exécution et la version du client, ainsi que le processus à l'origine de l'appel. Indiquez le réseau utilisé par la machine et si l'échec a commencé après un déploiement, un renouvellement de certificat, un changement de VPN, le déploiement d'un proxy, une mise à jour DNS ou une modification de la gestion des appareils.

Conservez ces éléments hors des conversations informelles s'ils contiennent des chemins client ou des corps de requête. Ne collez jamais d'en-têtes d'autorisation, de cookies, de clés privées client ou de fichiers d'environnement complets dans un ticket d'incident. Une enquête sur un certificat ne justifie pas de créer une deuxième fuite de secret.

Utilisez une fiche d'incident courte qui attribue clairement les responsabilités :

1. Nommez un intervenant capable d'arrêter l'agent et un autre responsable du point de terminaison ou du chemin réseau.
2. Indiquez si l'appel avait atteint un point d'injection d'identifiants. Si c'est le cas, considérez que l'identifiant a pu être exposé jusqu'à l'identification du pair TLS.
3. Conservez l'identifiant de session de l'agent et l'enregistrement de l'action échouée, puis empêchez les nouvelles tentatives automatiques vers cette destination.
4. Fixez un point de contrôle avant le rétablissement. La personne qui a besoin que l'API fonctionne ne doit pas être la seule à décider qu'un nouveau certificat racine est digne de confiance.

Ce n'est pas une formalité. J'ai vu des équipes passer la majeure partie d'un incident à tester des commandes pendant qu'un processus en arrière-plan continuait de réessayer le même point de terminaison défaillant toutes les quelques secondes. Le diagnostic est devenu une partie de l'exposition. Arrêtez d'abord le comportement.

Ne laissez pas l'agent « réparer » le problème de confiance en modifiant les paramètres globaux de l'environnement d'exécution. Les invites qui suggèrent `curl -k`, `verify=False`, un bundle d'AC personnalisé global ou la désactivation de la vérification Node.js doivent recevoir la même réponse qu'une demande d'affichage d'un token API. L'agent ne peut pas déterminer qu'un certificat inattendu correspond à un changement approuvé simplement parce qu'une recherche web indique que l'erreur est courante.

## Conservez le certificat sans envoyer de secret

Vous pouvez examiner un certificat serveur sans vous authentifier auprès de l'API. Utilisez un point de terminaison de santé non authentifié s'il existe, ou établissez une négociation et arrêtez-vous avant toute requête applicative. Effectuez la vérification depuis la même machine et le même réseau que ceux où l'échec a été observé, car les paramètres de proxy, les racines de confiance d'entreprise et le DNS partagé diffèrent souvent d'une machine à l'autre.

Cette commande demande le nom du serveur prévu via SNI, vérifie le nom d'hôte demandé, affiche les certificats envoyés par le pair et échoue en cas de problème de vérification :

```sh
openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -verify_hostname api.example.com \
  -verify_return_error \
  -showcerts </dev/null
```

Un résultat correct se termine par une sortie de cette forme :

```text
Verification: OK
Verify return code: 0 (ok)
```

En cas d'échec, enregistrez la sortie comme élément de preuve d'incident à accès restreint. Les champs utiles comprennent le sujet, l'émetteur, les dates `Not Before` et `Not After`, les noms alternatifs du sujet et chaque certificat de la chaîne. Les blocs PEM permettent au responsable du point de terminaison de comparer ce que votre machine a reçu avec ce que le serveur devrait présenter. Ce sont des certificats publics, mais traitez l'enregistrement avec soin, car les noms d'hôte et les émetteurs internes peuvent tout de même révéler des détails sur l'infrastructure.

Testez ensuite le comportement normal du client sans en-tête d'autorisation :

```sh
curl --verbose --fail --show-error \
  https://api.example.com/health
```

La transcription détaillée révèle la version TLS, le certificat sélectionné et le message de vérification. Masquez les chemins de requête s'ils révèlent des noms de locataires. N'ajoutez pas `-k` pour faire aboutir cette commande. L'échec de la vérification est l'élément de preuve dont vous avez besoin.

Une erreur de diagnostic fréquente consiste à omettre `-servername`. De nombreux points de terminaison hébergés sélectionnent les certificats en fonction de SNI et renvoient un certificat par défaut lorsque le client l'omet. Cela crée une incohérence de nom d'hôte qui n'a jamais affecté le véritable client. Une autre erreur consiste à utiliser `openssl s_client` sans `-verify_hostname`, puis à considérer le résultat de la chaîne comme la preuve que le nom d'hôte correspondait. Ce n'est pas le cas.

Consignez séparément l'adresse résolue avec votre outil habituel de diagnostic DNS. Ne faites pas de la correspondance d'adresse l'ensemble du test. Les grands fournisseurs utilisent légitimement de nombreuses adresses, tandis qu'un attaquant peut contrôler une réponse DNS plausible. Le nom du certificat, le chemin de l'émetteur, le chemin réseau et l'enregistrement de changement approuvé racontent ensemble l'histoire.

## Classez l'échec avant de choisir une correction

Les erreurs de certificat se ressemblent dans un journal, mais nécessitent des corrections différentes. Classez les éléments de preuve avant de modifier la configuration de confiance. Sinon, les équipes corrigent l'erreur visible et laissent intact le problème initial de routage ou de déploiement.

Un certificat expiré signifie généralement que l'opérateur du point de terminaison a manqué le renouvellement ou n'a pas déployé le nouveau certificat feuille. Comparez l'intervalle de validité du certificat capturé avec une horloge fiable. Une erreur d'horloge peut faire paraître expiré ou pas encore valide un certificat actuel : vérifiez donc l'heure du client avant de demander à un fournisseur de changer quoi que ce soit.

Une incohérence de nom d'hôte signifie que le serveur n'a pas prouvé qu'il contrôlait le nom demandé par le client. Les causes habituelles sont une mauvaise URL de base de l'API, une erreur de configuration SNI, un hôte virtuel par défaut, un DNS obsolète ou un certificat de proxy correspondant à un autre nom. N'acceptez pas un autre nom parce qu'il ressemble à celui qui était prévu. `api.example.com` et `api.internal.example.com` peuvent représenter des services et des frontières de confiance différents.

Un émetteur inconnu peut signifier que le client ne possède pas un certificat racine privé ou intermédiaire légitime. Il peut aussi indiquer qu'un dispositif d'inspection TLS non approuvé a émis un certificat feuille de remplacement. Comparez l'émetteur et la chaîne avec les informations de déploiement publiées ou enregistrées par le responsable du point de terminaison, en passant par un canal indépendant. Un message provenant du même système que celui qui a produit l'erreur ne constitue pas une confirmation indépendante.

Une chaîne incomplète relève généralement du point de terminaison. Les serveurs doivent envoyer le certificat feuille et les certificats intermédiaires requis. Les clients ne devraient déjà posséder que leurs racines de confiance. Installer localement un intermédiaire manquant peut masquer la mauvaise configuration du serveur sur une machine et laisser tous les autres appelants en échec. Demandez au responsable du serveur de fournir la chaîne correcte.

Un certificat feuille auto-signé appelle une vigilance accrue. Il peut être normal sur un service interne de développement, mais il n'offre à lui seul aucune preuve d'identité publique. Une AC privée gérée peut fonctionner correctement si les administrateurs distribuent sa racine via un magasin de confiance approuvé pour les appareils ou les charges de travail et consignent qui contrôle cette AC. Un certificat auto-signé envoyé par e-mail par le responsable d'un point de terminaison ne constitue pas une politique de confiance.

La révocation des certificats demande de la prudence. De nombreux clients n'effectuent pas systématiquement les vérifications de révocation en ligne dans tous les environnements, et les défaillances réseau peuvent les affecter. Ne déclarez pas un certificat sûr simplement parce qu'une négociation de base renvoie `0 (ok)`. Si un responsable signale une clé privée compromise ou un certificat révoqué, bloquez la destination, faites tourner les identifiants exposés et déployez un remplacement.

## Distinguez le chemin serveur du chemin proxy

Un proxy géré peut légitimement terminer TLS et émettre des certificats de remplacement, mais cela doit être explicite. Si une machine commence soudainement à voir un émetteur d'entreprise inconnu, ne le déclarez pas inoffensif parce que le sujet contient le nom de votre entreprise. Confirmez le déploiement du proxy, sa racine approuvée, son périmètre et l'autorisation ou non du passage des données et des identifiants de l'API par ce proxy.

Vérifiez la configuration du proxy dans l'environnement appelant sans afficher les valeurs susceptibles de contenir des identifiants. Dans un shell de type Unix, cette commande affiche uniquement les noms des variables de proxy configurées :

```sh
for n in HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY http_proxy https_proxy all_proxy no_proxy; do
  [ -n "${!n}" ] && printf '%s is set\n' "$n"
done
```

Un paramètre de proxy peut expliquer pourquoi la même API fonctionne sur une connexion mobile mais échoue sur un réseau de bureau. Cela n'approuve pas le proxy. Comparez les résultats sur un autre réseau autorisé uniquement si les règles de votre organisation le permettent. Si l'émetteur du certificat change avec le réseau, consignez ce résultat et transmettez-le au responsable réseau.

Examinez également les changements de résolution de noms et de routage. Un enregistrement DNS obsolète après une migration peut diriger les appels vers un ancien répartiteur de charge qui présente un certificat retiré. Un DNS à vue séparée peut renvoyer une adresse interne avec un certificat privé aux appareils du bureau et une adresse publique ailleurs. Ces conceptions peuvent être corrigées, mais le client doit faire confiance à l'émetteur correspondant à la route et toujours correspondre au nom d'hôte demandé.

Ne contournez pas le problème en codant une adresse IP en dur. Les vérifications d'identité HTTPS utilisent les noms DNS, et une IP directe peut contourner le routage prévu, empêcher la sélection SNI ou masquer un problème de contrôle DNS. Une surcharge d'IP peut parfois servir à un test de diagnostic strictement contrôlé, mais elle nécessite l'accord du responsable du point de terminaison et ne doit jamais devenir la configuration permanente de l'agent.

Les proxys soulèvent aussi une question de gouvernance des données à laquelle une erreur de certificat ne suffit pas à répondre. Si le proxy termine TLS, il peut lire les corps des API et les éléments d'autorisation injectés. L'équipe de sécurité doit décider si cette inspection est autorisée pour cette API. Le fait que le point de terminaison fonctionne de nouveau ne dit rien sur l'acceptabilité de ce nouveau chemin.

## Gardez la confiance envers les AC privées limitée et contrôlable

Les autorités de certification privées répondent à un vrai besoin pour les API internes, les environnements de développement et les maillages de services contrôlés. Elles deviennent problématiques lorsque les équipes distribuent les racines de manière informelle et oublient quels processus leur font confiance. Un certificat racine donne à son détenteur un large pouvoir pour émettre des identités dans son domaine de confiance : l'ajouter constitue donc une modification de sécurité administrative, pas un simple ajustement de compatibilité.

Installez une racine privée approuvée via le système d'exploitation géré, l'image de conteneur ou le magasin de confiance applicatif qui possède l'appel. Consignez le sujet de la racine, son empreinte, son responsable, les suffixes DNS prévus, la date d'approbation et la procédure de retrait. Limitez l'étendue de la confiance lorsque l'environnement d'exécution le permet. Une AC de développement ne doit pas devenir discrètement approuvée par tous les agents de production sur toutes les machines.

Évitez de faire confiance à un certificat feuille unique pour contourner l'absence de processus d'AC. Cette confiance se brise au renouvellement et encourage les utilisateurs à coller des chaînes PEM dans les dépôts. Elle rend aussi difficile la distinction entre une rotation d'endpoint planifiée et un remplacement inattendu. Si vous contrôlez les deux extrémités, mettez plutôt en place un processus d'AC privée avec un matériel de signature protégé, une émission documentée et une rotation planifiée.

Le mTLS ajoute une autre direction d'identité. En HTTPS ordinaire, le client valide le certificat du serveur. En mTLS, le serveur demande aussi un certificat au client. Une erreur telle que « alert certificate required » ou « bad certificate » peut signifier que le client n'a pas fourni son propre certificat, qu'il en a présenté un provenant du mauvais émetteur ou qu'il ne possède pas la clé privée correspondante. Désactiver la vérification du serveur ne résoudrait pas le problème.

Gardez les clés privées client hors des invites, des extraits de shell et des espaces de travail des agents. Donnez à l'appelant contrôlé accès à l'identifiant client via un magasin du système d'exploitation ou un autre mécanisme protégé. Si un certificat client ou sa clé privée a pu transiter par une connexion TLS non vérifiée, révoquez-le ou remplacez-le selon la procédure de l'AC émettrice. Traitez-le différemment d'un certificat serveur, mais pas avec désinvolture.

L'agrafage de certificat est un autre domaine où les bonnes intentions provoquent des pannes. Agrafer un certificat feuille lie le client à un artefact de renouvellement précis, si bien qu'une rotation normale peut arrêter tous les agents. L'agrafage peut être pertinent pour une intégration étroite et à haut risque lorsque les opérateurs gèrent des empreintes de secours et testent la rotation. Pour la plupart des équipes, il vaut mieux imposer la vérification du nom d'hôte, gérer les racines de confiance approuvées et surveiller l'expiration des certificats.

## Ne rétablissez l'accès qu'après une vérification indépendante

Ne rétablissez l'agent que lorsque quelqu'un a vérifié la correction en dehors du flux de travail défaillant de l'agent. La vérification doit utiliser le véritable nom d'hôte, le magasin de confiance prévu et un client qui effectue une vérification normale. Une visite dans un navigateur suffit rarement, car les navigateurs et les clients en ligne de commande peuvent utiliser des paramètres de proxy et des magasins de confiance différents.

Pour une API publique, vérifiez que la chaîne présentée remonte jusqu'à une racine de confiance publique attendue, que les noms alternatifs du sujet incluent le nom d'hôte configuré et que le responsable du point de terminaison confirme le déploiement ou le renouvellement via une modification enregistrée. Pour une API privée, vérifiez la racine privée approuvée, l'émetteur, le nom d'hôte et la route réseau attendue. Placez le résultat positif de la commande à côté de l'échec initial.

Exécutez ensuite une action authentifiée à faible impact via le même chemin que celui utilisé par l'agent. Choisissez un point de terminaison en lecture seule ou un contrôle d'identité sans effet lorsque l'API en propose un. Surveillez le journal d'action et l'audit côté serveur si possible. Confirmez le nom d'hôte de destination, le statut de réponse et l'identité de l'identifiant utilisé. Ne rétablissez pas un vaste traitement par lots comme premier test.

Si l'échec précédent laisse la moindre possibilité qu'un token, une requête signée ou un identifiant mTLS ait atteint un imposteur, faites tourner cet identifiant avant de reprendre le fonctionnement normal. Les équipes hésitent souvent à effectuer cette rotation parce que les preuves sont incomplètes. C'est l'inverse : c'est précisément parce que les preuves sont incomplètes qu'un identifiant ayant traversé une connexion non vérifiée doit être considéré comme exposé.

Notez la correction exacte, et non une conclusion vague comme « TLS corrigé ». Une clôture utile indique que l'opérateur du point de terminaison a déployé un certificat intermédiaire, que le magasin de confiance géré a reçu une racine approuvée précise ou qu'une configuration de proxy a été supprimée. Elle indique qui a vérifié le nom d'hôte et quelles exécutions d'agent ont repris. Cette trace empêche le prochain intervenant de réintroduire une option non sécurisée lors du renouvellement du même certificat.

## Rendez le chemin sûr plus facile que le contournement

La procédure échouera si la gestion sécurisée prend des heures alors que le contournement tient dans une variable d'environnement. Concevez l'intégration de l'agent de sorte qu'il ne puisse pas choisir un mode TLS non sécurisé, modifier la configuration globale de confiance ou voir des identifiants persistants pendant le diagnostic. Soumettez les paramètres de connexion, les noms d'hôte approuvés et le matériel de confiance au processus normal de revue des changements.

Sallyport peut conserver les identifiants API dans un coffre chiffré et effectuer les appels HTTP pour un agent, afin que celui-ci ne reçoive jamais les identifiants eux-mêmes. Ses enregistrements de session et d'appel peuvent aussi conserver la trace de la personne ou du processus à l'origine de l'action, mais un humain doit toujours décider si un certificat modifié correspond à un changement approuvé ou à une route dangereuse.

Déclenchez une alerte en cas d'échecs de validation répétés et de tentative d'utiliser des contournements connus. Un appel échoué doit fournir suffisamment de contexte structuré pour permettre d'identifier le nom d'hôte, la catégorie d'échec et l'exécution de l'agent, sans inclure de secret. Donnez aux agents une instruction fixe : arrêter en cas d'erreur de validation du certificat, signaler l'erreur et le point de terminaison exacts, puis demander un examen humain. Ne leur demandez pas de chercher une solution de contournement.

La première correction à effectuer est généralement banale : supprimer des scripts toute option de vérification non sécurisée déjà présente et faire utiliser au client normal un magasin de confiance géré. Testez ensuite le renouvellement des certificats avant que la production ne s'en charge. Les équipes qui répètent un renouvellement et un incident d'émetteur inattendu réagissent plus vite que celles dont le seul plan TLS consiste à copier une commande trouvée sur un forum.

Un avertissement de certificat a rempli son rôle lorsqu'il interrompt une requête qui ne devrait pas continuer. Gardez les choses ainsi.