Vérifiez si une version TLS reste prise en charge
Saisissez une version TLS et voyez aussitôt si elle reste valable : TLS 1.3 et TLS 1.2 sont prises en charge, TLS 1.0 et TLS 1.1 ressortent comme dépassées, chacune avec l’étape suivante pour votre revue de sécurité. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Version
- TLS 1.3
- Statut
- supported
Ce vérificateur classe TLS 1.0, TLS 1.1, TLS 1.2 ou TLS 1.3 selon une interprétation claire et fixe des recommandations courantes du secteur. Il indique si la version fournie est obsolète, précise son état de prise en charge et propose brièvement l’étape suivante. Toute version inconnue déclenche une erreur explicite, ce qui rend l’outil adapté aux revues, scripts, listes de contrôle et documents reproductibles.
Comprenez la signification du résultat
Un résultat indiquant une prise en charge signifie que les recommandations générales actuelles du secteur ne considèrent habituellement pas cette version du protocole comme obsolète. Dans ce vérificateur, TLS 1.2 et TLS 1.3 sont pris en charge, tandis que TLS 1.0 et TLS 1.1 sont obsolètes. Le classement porte volontairement sur la seule version du protocole.
Il ne prouve ni qu’un serveur donné est configuré de manière sûre, ni qu’un certificat est valide, ni que toutes les suites cryptographiques activées sont appropriées. Un service TLS 1.2 peut encore employer des réglages faibles, et un client moderne peut échouer à cause du certificat, du nom d’hôte ou de la chaîne de confiance. Utilisez donc l’état renvoyé comme un point précis d’une revue de sécurité plus large.
La réponse contient deux indicateurs booléens, obsolète et pris en charge, afin qu’un traitement automatisé puisse exploiter le résultat sans interpréter le texte, ainsi qu’une recommandation lisible pour les rapports. Le tableau étant fixe et déterministe, une même entrée reconnue reçoit toujours le même classement, ce qui facilite les comparaisons et les preuves d’audit.
Saisissez et normalisez une version TLS
Fournissez une seule version à la fois. Les formes canoniques sont TLS 1.0, TLS 1.1, TLS 1.2 et TLS 1.3. La comparaison ne tient pas compte de la casse, ignore les espaces placées autour de la valeur et accepte également la notation courante TLSv1.2.
La sortie restitue toujours une étiquette canonique telle que TLS 1.2, ce qui facilite la normalisation des valeurs recueillies dans des inventaires ou des notes de configuration. Le vérificateur rejette volontairement toute valeur incomplète ou inconnue au lieu de la deviner. SSL 3.0, TLS 2.0, des mots comme « dernière » et les chaînes incomplètes ne sont pas silencieusement associés à un protocole pris en charge.
Cette rigueur est importante dans les contrôles automatisés : une faute de frappe doit interrompre le traitement ou créer une exception visible, et non valider accidentellement une règle de sécurité. Si vous consultez un fichier de configuration, extrayez d’abord la version réelle du protocole depuis la syntaxe propre au produit, puis soumettez-la. Si un système autorise plusieurs versions, vérifiez chacune séparément et considérez toute version obsolète activée comme un motif de réexamen.
Exploitez le classement dans une revue de sécurité
Utilisez ce contrôle lorsqu’un inventaire d’actifs, un questionnaire, un manifeste de déploiement ou la réponse d’un fournisseur mentionne une version TLS et que vous avez besoin d’un premier classement cohérent. La présence de TLS 1.0 ou TLS 1.1, tous deux obsolètes, doit généralement déclencher une tâche de migration : identifiez les clients qui dépendent encore de l’ancienne version, activez TLS 1.2 ou TLS 1.3, testez l’interopérabilité, puis retirez l’ancien protocole. Un résultat positif pour TLS 1.2 ou TLS 1.3 ne clôt pas l’évaluation.
Vérifiez ensuite les certificats, les chaînes de confiance, la validation du nom d’hôte, les choix de chiffrement et de signature, le niveau de correctifs des bibliothèques et les versions effectivement négociées depuis les réseaux pertinents. Certaines exigences contractuelles, réglementaires, internes ou propres à une plateforme peuvent être plus strictes que les recommandations courantes. Dans ce cas, retenez la politique applicable la plus exigeante comme référence finale.
Le navigateur convient aux contrôles manuels rapides, tandis que la réponse structurée s’intègre aux processus de conformité reproductibles.
Cas d’usage
Examiner la référence d’un serveur
Classez chaque version TLS citée dans la référence d’un serveur ou répartiteur avant d’approuver sa configuration.
Normaliser les questionnaires fournisseurs
Transformez les réponses exprimées sous différents formats en une étiquette et un état de prise en charge cohérents.
Signaler les protocoles anciens
Créez une tâche de migration dès qu’une ligne d’inventaire mentionne TLS 1.0 ou TLS 1.1.
Questions fréquentes
Quelles versions TLS sont reconnues ?
TLS 1.0, TLS 1.1, TLS 1.2 et TLS 1.3 sont reconnus, y compris la notation TLSv sans distinction de casse.
Quelles versions sont considérées comme obsolètes ?
TLS 1.0 et TLS 1.1 sont classés comme obsolètes. TLS 1.2 et TLS 1.3 sont classés comme pris en charge.
Une version prise en charge garantit-elle un serveur sûr ?
Non. Le résultat concerne uniquement l’obsolescence de la version, pas les certificats, les suites cryptographiques, les correctifs ni la configuration.
Que faire si un serveur accepte encore TLS 1.0 ?
Prévoyez une migration. TLS 1.0 et TLS 1.1 sont dépréciées : identifiez les clients qui en dépendent encore et faites-les passer à TLS 1.2 ou TLS 1.3. Si le système active plusieurs versions, vérifiez chacune séparément.
Pourquoi SSL 3.0 ou TLS 2.0 sont-ils refusés ?
Parce que l’outil ne reconnaît que TLS 1.0, 1.1, 1.2 et 1.3 et ne devine jamais. SSL 3.0, TLS 2.0, des mots comme « latest » ou des versions partielles sont refusés clairement au lieu d’être acceptés par erreur.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/security/tls-version-support-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"version":"TLS 1.2"}'const res = await fetch("https://api.kit.forhosting.com/security/tls-version-support-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"version": "TLS 1.2"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/tls-version-support-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"version": "TLS 1.2"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/tls-version-support-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"version":"TLS 1.2"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"version":"TLS 1.2"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/tls-version-support-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"version": "TLS 1.2"
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.tls_version_support_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Exploitez le classement dans une revue de sécurité
Le tarif de l’API est de $0.002 par requête automatisée.
Questions techniques
Que se passe-t-il pour une version inconnue ?
La requête renvoie une erreur invalid_input qui énumère les quatre versions TLS reconnues, sans faire d’hypothèse.
Quel est le prix d’une vérification par API ?
Chaque requête API coûte $0.002. La capacité effectue un classement déterministe de version par requête.