Tu web tiene el candado en el navegador, así que "ya es segura". Es la frase que más oímos y la más engañosa. El candado solo dice que existe un certificado válido para ese dominio: no dice nada de qué versiones del protocolo aceptas, qué cifrados negocias, si la cadena está completa o cuándo caduca. Por eso las herramientas de análisis dan una nota, de A+ a F, y por eso dos webs con candado pueden estar en extremos opuestos. Esta guía explica qué mide cada parte de esa nota, qué configuración es razonable en 2026 y cómo comprobar la tuya con dos comandos.
Qué evalúa una nota de TLS
Las herramientas serias combinan siete comprobaciones. Las dos primeras son eliminatorias: si fallan, la nota baja a F sin mirar el resto.
- Certificado válido: emitido por una autoridad reconocida, para el dominio correcto, dentro de su periodo de validez.
- Cadena completa: el certificado intermedio que une el tuyo con la autoridad raíz se envía con él.
- Versiones del protocolo: qué TLS aceptas y cuáles rechazas.
- Cifrados: qué algoritmos ofreces y en qué orden.
- Redirección: si HTTP lleva a HTTPS en todo el sitio.
- HSTS: si le dices al navegador que no vuelva a usar HTTP.
- Vulnerabilidades conocidas: renegociación insegura, compresión, ataques con nombre propio de la década pasada.
Versiones: solo 1.2 y 1.3
TLS 1.0 y 1.1 llevan obsoletos desde 2020 y los navegadores los rechazan. Si tu servidor sigue aceptándolos, la nota baja porque un atacante puede forzar a un cliente antiguo a usarlos. TLS 1.2 es el mínimo aceptable; TLS 1.3 es el estándar actual: menos ida y vuelta al conectar, cifrados modernos obligatorios y sin las opciones inseguras de las versiones anteriores. La configuración correcta hoy es aceptar 1.2 y 1.3 y nada más. Si usas Vercel, Netlify, Cloudflare o un hosting gestionado, esto ya viene así; si administras tu propio nginx o un balanceador, revísalo.
Cifrados: lo que importa de verdad
El cifrado define cómo se intercambia la clave y cómo se protege el tráfico. Dos cosas marcan la diferencia. La primera es el secreto perfecto hacia adelante (los cifrados que empiezan por ECDHE): si alguien roba tu clave privada en el futuro, no puede descifrar el tráfico que grabó antes. La segunda es evitar algoritmos rotos o débiles: RC4, 3DES, los modos CBC antiguos y el intercambio de clave RSA puro. Una lista razonable para TLS 1.2 se reduce a ECDHE con AES-GCM o ChaCha20; en TLS 1.3 el protocolo ya solo permite cifrados modernos, otra razón para activarlo.
La cadena de certificados: el fallo invisible
Tu certificado lo firma un intermedio, y el intermedio lo firma una raíz que los dispositivos ya conocen. El servidor tiene que enviar tu certificado y el intermedio. Si olvidas el intermedio, Chrome en escritorio lo descarga por su cuenta y no verás ningún error; pero muchos móviles, curl, los bots de IA y las integraciones de pago fallan con un "certificado no confiable". Es el fallo más común en servidores configurados a mano y el más difícil de notar porque "a mí me funciona". Compruébalo así:
openssl s_client -connect tudominio.com:443 -servername tudominio.com </dev/null 2>/dev/null | grep -E "s:|i:|Verify return"Deben aparecer al menos dos certificados en la cadena y la verificación debe terminar en Verify return code: 0 (ok).
Dominio y nombres alternativos
El certificado tiene que cubrir exactamente los nombres que usas: tudominio.com y www.tudominio.com son dos nombres distintos. Un certificado solo para el raíz hace que www dé error, y al revés. Los certificados actuales listan varios nombres en el campo SAN, y los comodines (*.tudominio.com) cubren subdominios de un nivel. Revisa también los subdominios olvidados: api, app, staging con certificados caducados son un clásico.
Caducidad: cada vez más corta
Los certificados de Let's Encrypt duran 90 días, el máximo permitido por los navegadores hoy es de 398 y la industria ha acordado bajarlo progresivamente hasta 47 días en 2029. El mensaje es claro: la renovación tiene que ser automática. Las plataformas gestionadas lo hacen solas; si tienes tu propio servidor, usa un cliente ACME con renovación programada y, sobre todo, una alerta externa que te avise si quedan menos de 14 días. La caída por certificado caducado es la más tonta y la más frecuente.
Redirección y HSTS
Todo el tráfico HTTP tiene que redirigir a HTTPS con un 301, en todas las rutas, no solo en la home. Y una vez que todo funciona en HTTPS, la cabecera Strict-Transport-Security le dice al navegador que no vuelva a intentar HTTP durante el tiempo que indiques, lo que elimina el pequeño hueco de la primera petición. Con includeSubDomains y preload puedes incluir tu dominio en la lista que traen los navegadores de fábrica. Es la diferencia habitual entre una A y una A+. Cómo se configura, en cabeceras de seguridad HTTP.
Contenido mixto
Un detalle que no afecta a la nota del certificado pero sí al candado: si tu página HTTPS carga una imagen, un script o una fuente por HTTP, el navegador lo bloquea o marca la página como no segura. Suele venir de URLs copiadas de una plantilla antigua. Búscalo en el código fuente con http:// y cámbialo a rutas relativas o HTTPS.
Si estás en una plataforma gestionada
Vercel, Netlify, Cloudflare Pages, Railway o Render emiten y renuevan el certificado, fuerzan versiones modernas y eligen cifrados seguros. No tienes que tocar nada de eso. Lo que sigue siendo tuyo: añadir HSTS, eliminar contenido mixto, redirigir los dominios alternativos y vigilar los subdominios que apuntan a otros sitios.
Por qué importa más allá de la nota
Un TLS débil permite interceptar sesiones en redes públicas, y un certificado mal configurado hace que tu web falle en dispositivos que no ves. Los procesadores de pago exigen TLS 1.2 como mínimo para cumplir PCI DSS. Google usa HTTPS como señal de posicionamiento y los navegadores marcan como "no seguro" cualquier cosa que no lo tenga. Y, de forma más terrenal, un certificado caducado un sábado por la mañana es una web caída hasta que alguien lo note.
Comprobarlo en treinta segundos
curl -sIL http://tudominio.com | grep -iE "^(HTTP|location|strict-transport)"
openssl s_client -connect tudominio.com:443 -servername tudominio.com -tls1_1 </dev/null 2>&1 | grep -iE "alert|error" | head -1El primero debe mostrar un 301 hacia https:// y después la cabecera HSTS. El segundo intenta conectar con TLS 1.1 y debe fallar: si conecta, aceptas una versión obsoleta.
Scanaris revisa tu TLS en cada escaneo
Scanaris comprueba versiones del protocolo, cifrados, cadena completa, nombres del certificado, días hasta la caducidad, redirección y HSTS, y te avisa por correo antes de que el certificado caduque. Cada hallazgo trae un fix prompt con la configuración exacta para tu servidor o tu plataforma. Son comprobaciones de solo lectura: se conecta a tu web igual que lo haría un navegador. Para ver todo lo que revisa en treinta segundos, lee cómo saber si tu web es segura en 5 minutos.
Preguntas frecuentes
¿Qué diferencia hay entre SSL y TLS?
SSL es el nombre antiguo del protocolo, retirado hace años por inseguro. Lo que se usa hoy es TLS, pero la gente sigue diciendo "certificado SSL". A efectos prácticos, cuando leas SSL piensa en TLS.
¿Necesito un certificado de pago?
No. Los certificados gratuitos de Let's Encrypt o los que emite tu plataforma cifran exactamente igual. Los de pago añaden validación de la organización o garantías, no más seguridad en la conexión.
¿Por qué saco una B si mi certificado es válido?
Normalmente por aceptar TLS 1.0 o 1.1, ofrecer cifrados débiles o no enviar la cabecera HSTS. El certificado es solo una de las siete cosas que se miran.