Aller au contenu principal

Diagnostiquer les erreurs TLS et réseau

Utilisez ce guide lorsqu’un appel SyAuth échoue avec BAD_RECORD_MAC, une erreur TLS, une réinitialisation ou une réponse vide avant tout statut HTTP. Si vous recevez HTTP 401, 403 ou un autre statut, consultez les erreurs API.

1. Comparer la négociation normale, TLS 1.2 et TLS 1.3​

Lancez chaque commande séparément sur l’ordinateur concerné, en conservant le réseau, l’état du VPN et l’installation de curl. L’endpoint public de découverte ne demande aucun jeton et renvoie normalement HTTP 200. Choisissez l’onglet de votre terminal ; les exemples Windows utilisent l’invite de commandes CMD.

curl --version
curl --http1.1 --connect-timeout 10 --max-time 20 -v -i "https://api.syauth.com/e/v1/.well-known/openid-configuration"
curl --tlsv1.2 --tls-max 1.2 --http1.1 --connect-timeout 10 --max-time 20 -v -i "https://api.syauth.com/e/v1/.well-known/openid-configuration"
curl --tlsv1.3 --tls-max 1.3 --http1.1 --connect-timeout 10 --max-time 20 -v -i "https://api.syauth.com/e/v1/.well-known/openid-configuration"

La première requête utilise la négociation TLS normale ; les deux suivantes forcent respectivement TLS 1.2 et TLS 1.3. Les trois utilisent HTTP/1.1 et les mêmes délais maximaux. -v affiche les détails de connexion/TLS et les erreurs ; -i affiche les en-têtes de la réponse HTTP.

Les deux bornes TLS sont nécessaires : --tlsv1.2 seul autorise les versions plus récentes. L’ajout de --tls-max 1.2 limite cet appel à TLS 1.2. Une option ou une bibliothèque locale qui ne prend pas en charge TLS 1.3 ne démontre pas une panne réseau. Voir les options curl.

Répétez chaque requête 20 fois si la panne est intermittente. Conservez pour chaque essai l’heure UTC, le réseau, l’IP de destination, la version TLS négociée, le statut HTTP et l’erreur. N’ajoutez pas de tentatives automatiques pendant le diagnostic : elles peuvent masquer les échecs. curl --version indique sa bibliothèque TLS. Des clients HTTP différents peuvent utiliser des implémentations TLS différentes ; les résultats d’un client ne prouvent pas qu’un autre fonctionne.

2. Comparer les réseaux et les adresses de destination​

Répétez les mêmes commandes sur un partage de connexion, puis revenez au réseau initial. Conservez le VPN et les autres réglages. Si possible, testez Ethernet sur le routeur initial en désactivant le Wi-Fi. Vérifiez la route choisie pour la destination : la présence d’un adaptateur VPN ne prouve pas que ce trafic emprunte le tunnel.

Si l’IP de destination change, refaites la comparaison avec une même IP actuelle sur les deux réseaux. Ajoutez --resolve "api.syauth.com:443:CURRENT_IP" aux requêtes curl, en remplaçant CURRENT_IP par cette adresse. Gardez l’URL HTTPS inchangée pour conserver le nom d’hôte et sa vérification dans le certificat.

Ne conservez pas cette IP dans la configuration permanente de l’application. Cloudflare utilise l’anycast : une même IP peut atteindre des centres différents selon le réseau. Ce test élimine une différence DNS, sans garantir un serveur ou un trajet identique. Voir le routage Cloudflare.

3. Forcer temporairement TLS 1.2 sur la connexion concernée​

Pour une requête réelle de la Developer API, remplacez directement YOUR_DEVELOPER_TOKEN par votre jeton :

curl --tlsv1.2 --tls-max 1.2 -i "https://api.syauth.com/e/v1/developer/workspaces/" -H "X-Developer-Token: YOUR_DEVELOPER_TOKEN" -H "Accept: application/json"

Des réponses réussies de façon répétée confirment que cette requête fonctionne avec TLS 1.2 sur le client et le réseau testés. Comparez avec la même requête sans restriction, ou avec --tlsv1.3 --tls-max 1.3, avant d’attribuer la différence à la version TLS.

Si la comparaison montre que TLS 1.2 réussit alors que TLS 1.3 échoue, utilisez la restriction à TLS 1.2 comme contournement temporaire pour cette connexion. Dans votre application, utilisez les réglages TLS minimal et maximal prévus par sa bibliothèque HTTP. Conservez la vérification de la chaîne de certification et du nom d’hôte. Autoriser TLS 1.2 en parallèle de TLS 1.3 ne force pas le client à l’utiliser. Le fetch du navigateur n’expose pas ces réglages TLS natifs.

Retestez sans restriction après résolution du problème réseau/client. Un partage de connexion ou un lien Ethernet qui réussit les mêmes tests peut aussi servir de contournement temporaire. Ces résultats orientent le diagnostic sans désigner à eux seuls SyAuth, le routeur, Windows ou le VPN comme responsable.

Informations à transmettre au support​

Fournissez le nom d’hôte et le chemin concernés, les heures UTC, les versions du système et de curl, les résultats de chaque essai, la comparaison entre réseaux et les identifiants de requête reçus. Joignez les commandes nettoyées et précisez si TLS 1.2 était forcé, simplement autorisé ou non testé. Retirez jetons, en-têtes Authorization, cookies, mots de passe et clés privées avant de partager les résultats.