Compruebe si una versión TLS sigue siendo compatible
Escriba una versión TLS y sepa al instante si sigue vigente: TLS 1.3 y TLS 1.2 son compatibles, mientras que TLS 1.0 y TLS 1.1 salen como obsoletas, cada una con el paso siguiente para su revisión de seguridad. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Versión
- TLS 1.3
- Estado
- supported
Este comprobador de compatibilidad clasifica TLS 1.0, TLS 1.1, TLS 1.2 o TLS 1.3 conforme a una interpretación clara y fija de las directrices habituales del sector. Indica si la versión suministrada está obsoleta, ofrece su estado de compatibilidad y propone brevemente el siguiente paso. Las versiones no reconocidas producen un error explícito, por lo que la herramienta resulta adecuada para revisiones, scripts, listas de control y documentación repetibles.
Entienda qué significa el resultado
Un resultado compatible significa que las directrices generales actuales del sector no suelen considerar obsoleta esa versión del protocolo. En este comprobador, TLS 1.2 y TLS 1.3 son compatibles, mientras que TLS 1.0 y TLS 1.1 están obsoletos. La clasificación se refiere deliberadamente solo a la versión del protocolo.
No demuestra que un servidor concreto esté configurado de forma segura, que un certificado sea válido ni que todos los conjuntos de cifrado habilitados sean adecuados. Un servicio TLS 1.2 aún puede contener opciones de configuración débiles, y un cliente moderno puede fallar por problemas del certificado, el nombre de host o la cadena de confianza. Use el estado devuelto como un elemento preciso dentro de una revisión de seguridad más amplia.
La respuesta incluye los indicadores booleanos de obsolescencia y compatibilidad para que una automatización pueda usarla sin interpretar prosa, además de una recomendación legible para informes. Como la tabla es fija y determinista, la misma entrada reconocida siempre obtiene la misma clasificación, lo que simplifica las comparaciones y las pruebas de auditoría.
Introduzca y normalice una versión TLS
Proporcione una versión cada vez. Las formas canónicas son TLS 1.0, TLS 1.1, TLS 1.2 y TLS 1.3. La comparación no distingue mayúsculas de minúsculas, ignora espacios alrededor del valor y también acepta la notación habitual TLSv1.2.
La salida siempre devuelve una etiqueta canónica como TLS 1.2, lo que ayuda a normalizar valores recopilados de inventarios o notas de configuración. El comprobador rechaza expresamente valores incompletos o desconocidos en lugar de adivinarlos. SSL 3.0, TLS 2.0, palabras como «más reciente» y cadenas incompletas no se convierten silenciosamente en un protocolo compatible.
Este comportamiento estricto es importante en controles automatizados: una errata debe detener el flujo o generar una excepción visible, no aprobar por accidente una regla de seguridad. Si lee un archivo de configuración, extraiga primero la versión real del protocolo de la sintaxis propia del producto y envíela después. Si un sistema habilita varias versiones, compruebe cada una por separado y considere cualquier versión obsoleta habilitada como motivo para revisar la configuración.
Aplique la clasificación en una revisión de seguridad
Utilice esta comprobación cuando un inventario de activos, cuestionario, manifiesto de despliegue o respuesta de proveedor mencione una versión TLS y usted necesite una clasificación inicial coherente. TLS 1.0 o TLS 1.1 obsoletos deberían generar normalmente una tarea de migración: confirme qué clientes aún dependen de la versión antigua, habilite TLS 1.2 o TLS 1.3, pruebe la interoperabilidad y después retire el protocolo heredado. Un resultado compatible para TLS 1.2 o TLS 1.3 no concluye la evaluación.
Continúe comprobando certificados, cadenas de confianza, validación del nombre de host, opciones de cifrado y firma, nivel de parches de bibliotecas y versiones realmente negociadas desde redes relevantes. Los requisitos también pueden ser más estrictos que las directrices comunes, sobre todo por contrato, marco normativo, línea base de plataforma o norma interna. En esos casos, adopte como autoridad final la política aplicable más estricta.
El navegador sirve para revisiones manuales rápidas y la respuesta estructurada se integra bien en procesos de cumplimiento y controles repetibles.
Qué puede hacer con ella
Revisar una línea base de servidor
Clasifique cada versión TLS indicada en la línea base de un servidor o balanceador antes de aprobar su configuración.
Normalizar cuestionarios de proveedores
Convierta respuestas con distintos formatos de versiones TLS reconocidas en una etiqueta y un estado coherentes.
Detectar protocolos heredados
Genere una tarea de migración cuando una entrada del inventario indique TLS 1.0 o TLS 1.1.
Preguntas frecuentes
¿Qué versiones TLS se reconocen?
Se reconocen TLS 1.0, TLS 1.1, TLS 1.2 y TLS 1.3, incluida la notación TLSv sin distinción entre mayúsculas y minúsculas.
¿Qué versiones se consideran obsoletas?
TLS 1.0 y TLS 1.1 se clasifican como obsoletos. TLS 1.2 y TLS 1.3 se clasifican como compatibles.
¿Compatible significa que un servidor es totalmente seguro?
No. El resultado solo cubre la obsolescencia de la versión, no certificados, cifrados, parches de implementación ni configuración del servidor.
¿Qué hago si un servidor todavía acepta TLS 1.0?
Planifique la migración. TLS 1.0 y TLS 1.1 están obsoletas, así que averigüe qué clientes dependen todavía de ellas y llévelos a TLS 1.2 o TLS 1.3. Si el sistema habilita varias versiones, compruebe cada una por separado.
¿Por qué se rechaza SSL 3.0 o TLS 2.0?
Porque la herramienta solo reconoce TLS 1.0, 1.1, 1.2 y 1.3 y nunca adivina. SSL 3.0, TLS 2.0, palabras como «latest» o versiones incompletas se rechazan de forma visible en lugar de aprobarse por error.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su 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)Ejemplo de solicitud
{
"version": "TLS 1.2"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.tls_version_support_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Aplique la clasificación en una revisión de seguridad
El precio de la API es de $0.002 por solicitud al automatizar la consulta.
Preguntas técnicas
¿Qué ocurre con una versión desconocida?
La solicitud devuelve un error invalid_input que enumera las cuatro versiones TLS reconocidas, sin intentar adivinar.
¿Cuánto cuesta una comprobación por API?
Cada solicitud de API cuesta $0.002. La capacidad realiza una clasificación determinista por solicitud.