Cómo comprobar si un sitio web tiene un certificado SSL válido

Confirma el host exacto que deseas verificar

Comienza con la dirección exacta, no con el nombre de la marca en tu cabeza. Un certificado para www.example.com no es lo mismo que uno para example.com, y un subdominio como shop.example.com puede tener su propio certificado, su propio emisor y sus propios problemas.

Eso suena obvio, pero es donde muchas verificaciones fallan. Un visitante puede aterrizar en una redirección, un alias de marketing o un subdominio de país, y el certificado solo necesita coincidir con el host que el navegador realmente ve.

Escribe la URL completa con cuidado. Si el sitio utiliza tanto www como no-www, prueba ambos. Si estás verificando un área de inicio de sesión o un host de API, verifica también ese nombre de host exacto, porque un host puede estar bien mientras que otro falla.

Esto importa aún más en un sitio web corporativo con varios puntos de entrada, donde la página de inicio, el área de soporte y el dominio de la aplicación pueden comportarse de manera diferente. Un subdominio perdido puede crear una falsa sensación de seguridad.

Una nota rápida: un candado que parece seguro en una página no prueba que toda la familia de dominios esté cubierta. Solo prueba que una respuesta en un host presentó algún certificado.

Inspecciona la cadena de certificados, no solo el candado

El candado es solo la primera pista. Un navegador puede mostrar HTTPS mientras la cadena de certificados está incompleta, desordenada o anclada a un emisor en el que el navegador no confía.

Abre los detalles del certificado en tu navegador y busca la cadena completa: el certificado del sitio, cualquier certificado intermedio y la ruta de confianza raíz. Si falta un intermedio, algunos navegadores pueden recuperarse, pero otros se quejarán, y algunos clientes rechazarán la conexión de inmediato.

Por eso, cómo verificar si un sitio web tiene un certificado SSL válido no es una pregunta de un solo clic. Necesitas ver lo que el servidor envía, no solo lo que sugiere el ícono de candado.

En la práctica, una cadena incompleta a menudo aparece después de una renovación o migración del servidor. El certificado en sí puede estar actualizado, pero la cadena enviada por el servidor es incorrecta, por lo que los usuarios reciben advertencias de todos modos.

Utiliza los detalles del certificado del navegador, un verificador de SSL o una herramienta de línea de comandos si tienes acceso. Un sitio que funciona en un navegador puede fallar en otro si el servidor omite un certificado intermedio.

Un caso del mundo real: un sitio detrás de un CDN puede presentar un certificado de hoja válido en el borde, pero una cadena rota en un camino de origen legado. El visitante ve el problema solo en la ruta menos común.

Verifica que el certificado coincida con el nombre de host

Un certificado debe nombrar el host que el navegador está visitando. Los certificados modernos utilizan el campo SAN, y esa lista importa más que el antiguo campo CN, aunque la gente todavía mira primero el CN.

Verifica si las entradas SAN incluyen el dominio y subdominio exactos que probaste. Si el certificado lista example.com y www.example.com, eso puede estar bien para ambos. Si solo lista example.com, entonces www.example.com aún puede fallar.

No asumas que los comodines resuelven todo. Un comodín como *.example.com generalmente cubre un nivel de profundidad, por lo que shop.example.com puede estar cubierto, mientras que api.shop.example.com no lo está.

Los alias son una trampa común. El equipo de marketing podría promover go.example.com, pero el certificado solo cubre example.com y www.example.com. La página se carga, el candado aparece por un momento, y luego el navegador lanza un error de nombre.

Aquí está el hábito útil: coincide con lo que los usuarios escriben, lo que redirige a qué, y cuáles son realmente los nombres del certificado. Tres cadenas. Una verificación.

Si gestionas un sitio que depende de varios dominios de entrada, este es un buen lugar para conectar tu revisión de certificados con el trabajo de seguridad del sitio web. Un desajuste de certificado no es solo una molestia para el navegador; puede romper flujos de inicio de sesión, flujos de pago y cualquier cosa relacionada con la confianza.

Verifica el estado de expiración y renovación

Cada certificado tiene una fecha de inicio y una fecha de finalización. Verifica ambas. Si el certificado ya ha expirado, la advertencia del navegador no es un misterio, y si expira mañana, eso sigue siendo un problema para los usuarios que abren el sitio después de la medianoche.

Mira la ventana de validez en el visor de certificados. Algunas herramientas muestran 'no antes' y 'no después'. Esas dos líneas te dicen si el certificado está activo ahora y si una renovación ya está atrasada.

La renovación no siempre es instantánea. Un sitio puede estar en medio de un despliegue, con el antiguo certificado aún visible en un servidor y el nuevo en otro. Eso puede crear resultados inconsistentes durante una ventana de transición.

Un corto período de expiración no es en sí un defecto, pero aumenta las apuestas. Si una tarea de renovación automática falla una vez, el sitio puede pasar de estar bien a estar bloqueado con muy poco aviso.

Ten en cuenta la fecha cuando inspecciones un certificado sospechoso. Un certificado que expira en 2 días merece atención más rápida que uno con meses restantes, porque la solución puede ser simplemente una renovación que aún no se ha propagado.

Para los equipos que ya utilizan una plataforma de análisis y monitoreo de sitios web, emparejar las verificaciones de certificados con alertas de tiempo de actividad ayuda a detectar un fallo de renovación antes de que lo hagan los usuarios. La línea de tiempo importa aquí, no la teoría.

Busca problemas de confianza por parte de la autoridad emisora

Un certificado puede ser válido en papel y aún así activar una advertencia de confianza. Eso generalmente apunta a la autoridad de certificación emisora, la cadena de confianza, o un dispositivo que carece del certificado raíz correcto.

Abre la información del emisor y confirma que la CA es reconocida por los navegadores y sistemas operativos modernos. Si el emisor parece desconocido, o el certificado fue auto-firmado, el navegador puede rechazar la confianza incluso cuando HTTPS aparece en la barra de direcciones.

Los certificados auto-firmados son comunes en herramientas internas, servidores de prueba y páginas de administración privadas. También son una fuente común de confusión cuando alguien copia esa misma configuración a un sitio público.

Las advertencias del navegador valen la pena leerlas línea por línea. Una advertencia puede mencionar un emisor no confiable. Otra puede mencionar un problema de cadena. Una tercera puede decir que el certificado no está destinado para el host.

Esos mensajes son diferentes. Trátalos de manera diferente.

Si estás revisando un sitio público que debería ser confiable por defecto, una advertencia del navegador significa que el camino de confianza está roto en algún lugar. Eso puede suceder después de una migración mal manejada, una mala configuración de proxy, o un certificado instalado con el paquete intermedio incorrecto.

Una autoridad de confianza no significa, por supuesto, “contenido seguro”. Solo significa que el navegador acepta la ruta del certificado como legítima. Esa es una afirmación más limitada, y es la única afirmación que puede hacer el certificado.

Prueba de contenido mixto en la página

Un certificado SSL válido no salva una página que aún carga recursos inseguros. El contenido mixto ocurre cuando la página principal utiliza HTTPS pero las imágenes, scripts, fuentes o marcos provienen de URLs HTTP.

Abre las herramientas de desarrollador y actualiza la página. Busca advertencias sobre recursos bloqueados o actualizados. Una página puede seguir cargando visualmente mientras un script falla silenciosamente porque el navegador bloqueó un archivo inseguro.

Ese es un problema de seguridad práctico, no cosmético. Un solo script inseguro puede debilitar la protección que se supone que debe proporcionar el certificado.

Los infractores comunes son URLs de imágenes antiguas, widgets de terceros, etiquetas de análisis y reproductores de video incrustados. Un antiguo enlace HTTP en una plantilla puede contaminar docenas de páginas.

Si administras un portal de contenido sobre inversiones, esta verificación importa aún más porque un script de gráfico roto o un widget de cotización pueden hacer que la página parezca confiable mientras falla silenciosamente por debajo. El ícono de candado no te contará esa historia.

El contenido mixto también ayuda a explicar por qué los usuarios a veces informan “el sitio es seguro en mi laptop, pero no en mi teléfono”. El certificado puede estar bien; los recursos de la página no lo están.

Compara el comportamiento en escritorio y móvil

Realiza la misma verificación en al menos 2 entornos: un navegador de escritorio y un navegador o dispositivo móvil. Un certificado puede pasar en un escritorio moderno y fallar en un teléfono antiguo, especialmente si la tienda de confianza está desactualizada.

Esa diferencia importa. Una cadena de certificados que parece aceptable en Chrome en una laptop puede aún activar una advertencia en Safari en un iPhone antiguo o en un navegador con certificados raíz desactualizados.

Prueba el host principal y un subdominio. Si el sitio redirige de www a non-www, repite la prueba después de la redirección. Un fallo en el host redirigido sigue siendo un fallo.

Las verificaciones de dispositivos también revelan rarezas de cookies y sesiones. A veces, la advertencia del navegador aparece solo después de iniciar sesión, porque se llama a un host diferente una vez que el usuario llega a un área segura.

Lo simple es lo mejor aquí. Abre el sitio, inspecciona el candado, confirma el nombre del host y compara los detalles del certificado en ambos dispositivos. Cinco minutos pueden ahorrar un ticket de soporte más tarde.

Los equipos que ya dependen del soporte del sitio web después del lanzamiento suelen conocer bien este patrón: el informe del navegador del cliente rara vez es el mismo que el resultado de la máquina del desarrollador.

Sabe cuándo escalar al propietario del sitio o al proveedor de hosting

Escala cuando el certificado esté caducado, el nombre del host no coincida, la cadena esté rota o el navegador muestre una advertencia de confianza que no puedas explicar por la configuración del dispositivo local. Esos no son hallazgos de 'quizás más tarde'.

Cuando informes del problema, incluye el host exacto, la marca de tiempo, el nombre del navegador, el error visible y una captura de pantalla de los detalles del certificado. Si es posible, incluye las entradas SAN, el nombre del emisor y la fecha de expiración.

Mantén el informe concreto. Di “shop.example.com falla en iPhone Safari con un desajuste de nombre de host” en lugar de “el SSL está roto.” La primera frase le da a alguien un camino para solucionarlo.

Si gestionas el sitio para un cliente, infórmales si el problema está en un host o en varios. Esa distinción puede decidir si la solución pertenece a DNS, al balanceador de carga, al servidor web o al proveedor de certificados.

Los proveedores de hosting a menudo necesitan la evidencia exacta para actuar rápidamente. Una queja vaga puede rebotar entre equipos durante un día. Una precisa puede ser relacionada con una renovación, un intermedio faltante o un mal despliegue en minutos.

Para los equipos que trabajan en una plataforma interna o un producto público, la entrega más limpia es la que incluye el host, el tipo de fallo y la ruta del navegador. Eso es suficiente para separar un problema de certificado de un problema de página, lo que ahorra a todos conjeturas.

Una última verificación ayuda con casos obstinados: compara el certificado en el sitio en vivo con el de el servidor de origen o el host de staging, si tienes acceso. Un despliegue desajustado puede dejar un entorno fijo y otro aún fallando, y al navegador solo le importa el host que alcanza.