L'une des défaillances réseau les plus insidieuses se produit lorsqu'un site Web se charge parfaitement sur votre ordinateur portable, mais que les clients API, les applications mobiles ou les webhooks backend échouent avec une erreur de certificat non approuvé. C'est la marque d'une chaîne de certificats incomplète.

Tout semble sain jusqu'à ce que le trafic disparaisse de certains types de clients. Voyons exactement pourquoi cela se produit et comment le prouver.

Le chemin de la confiance

Lorsque vous achetez un certificat TLS, il est rarement signé directement par une autorité de certification (CA) racine présente dans le magasin de confiance d'un appareil. Au lieu de cela, il est signé par une CA intermédiaire pour protéger les clés racines.

Étant donné que le client ne connaît pas cette CA intermédiaire, la spécification TLS exige que votre serveur ajoute les certificats intermédiaires pendant le handshake. Si vous configurez votre serveur uniquement avec le certificat feuille, le client ne peut pas construire de chemin vers la racine approuvée.

Pourquoi les navigateurs cachent le problème

Si la chaîne est brisée, pourquoi Chrome affiche-t-il toujours un cadenas vert ? Les navigateurs Web modernes mettent en cache les certificats intermédiaires des sites précédemment visités et utilisent 'AIA Fetching' pour télécharger les certificats chaînés manquants à la volée.

Cependant, les clients programmatiques (comme un script Axios, Curl ou un backend Java) n'ont pas ce luxe. Ils évaluent exactement ce que le serveur envoie. S'il manque l'intermédiaire, le handshake échoue immédiatement avec 'unable to get local issuer certificate'.

Débogage interactif avec OpenSSL

Pour prouver qu'une chaîne est intacte, nous devons interroger le serveur sans que la mise en cache du navigateur ne gêne. Utilisez openssl pour inspecter la séquence de la chaîne :

openssl s_client -showcerts -connect yourapi.com:443

Regardez le bloc 'Certificate chain' dans la sortie. Si vous ne voyez qu'un seul certificat (profondeur=0), votre serveur est mal configuré. Une chaîne saine devrait ressembler à ceci :

Certificate chain
 0 s:/CN=yourapi.com i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1

Stratégie de surveillance

C’est là que la plupart des configurations de surveillance ont des angles morts. Les systèmes internes ne simulent pas souvent de simples clients programmatiques contre des points de terminaison externes.

Pour éviter cela, vous avez besoin d'une surveillance synthétique explicite qui impose une vérification SSL stricte. En utilisant une plateforme comme Heimdall Observer, vous pouvez évaluer en continu la charge utile de la chaîne complète de votre infrastructure.