¿Qué es un certificado SSL?
Un certificado SSL/TLS es un documento digital, firmado por una autoridad certificadora (CA) de confianza, que vincula una clave pública a uno o más nombres de host. Cuando un cliente se conecta, el servidor presenta el certificado durante el handshake TLS y el cliente verifica la firma de la CA, la ventana de validez del certificado y que uno de los nombres listados coincide con el host al que se conecta.
A pesar del nombre heredado, los certificados modernos usan el protocolo TLS (TLS 1.2 y TLS 1.3 hoy en día) y no el ya obsoleto SSL. El formato X.509 y la cadena PKI se definen en **RFC 5280**, con el comportamiento específico para HTTPS en **RFC 2818**.
¿Por qué comprobar tu certificado SSL?
1Evita expiraciones sorpresa
Cualquier navegador y cliente de correo moderno deja de funcionar en cuanto un certificado caduca — vigila los días restantes proactivamente
2Confirma la cobertura de host
Un certificado solo es válido para los hosts en su lista SAN — verifica cada subdominio que sirvas
3Detecta cadenas no confiables
Los certificados autofirmados o de CA desconocida provocan avisos del navegador — descúbrelos antes que tus usuarios
4Audita STARTTLS para correo
Los proveedores esperan que los endpoints MX negocien TLS sin problemas — un certificado roto degrada silenciosamente la entregabilidad
Cómo funciona la verificación SSL paso a paso
Un cliente abre una conexión TLS con tu dominio y envía un ClientHello.
Tu servidor devuelve su cadena de certificados: el certificado hoja + cualquier certificado intermedio.
El cliente recorre la cadena hasta llegar a una CA raíz de confianza instalada en su almacén.
Verifica cada firma, comprueba que cada certificado esté en su ventana de validez y que ninguno esté revocado.
Finalmente comprueba que la lista SAN del certificado hoja contenga el host al que el cliente quiere acceder.
Si todos los pasos pasan, el handshake termina y se intercambia la clave de sesión.
Campos del certificado de un vistazo
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -textCampos clave del certificado
Issuer— autoridad certificadora que firmó el certSubject CN— host principal heredadoSAN— lista moderna de hosts válidosNot Before / After— ventana de validezKey Usage— operaciones permitidas (auth de servidor, etc.)Fallos comunes de SSL y soluciones
Certificado expirado
Renueva inmediatamente y configura monitoreo — la mayoría de equipos avisan a 30 días restantes
Host no coincide
El host que probaste no está en el SAN — vuelve a emitir con el nombre que falta o un wildcard correcto
Certificado autofirmado
Los navegadores los rechazan — pasa a un certificado gratuito de Let's Encrypt o uno gestionado por tu CDN
Cadena incompleta
Si faltan intermedios, algunos clientes no pueden verificar la cadena — empaquétalos con la hoja en la configuración del servidor
Preguntas Frecuentes
Un verificador SSL/TLS confirma que un dominio sirve un certificado válido emitido por una autoridad certificadora de confianza, que los Subject y los Subject Alternative Names cubren el host probado, que el certificado está dentro de su ventana de validez actual y que no está autofirmado. Estas comprobaciones, en conjunto, prueban que un navegador o cliente de correo confiará en la conexión.
Una vez que un certificado expira, todos los navegadores muestran un aviso de seguridad y la mayoría de clientes de correo modernos rechazarán STARTTLS. Dejar caducar un SSL rompe a la vez el tráfico web y el envío de correo autenticado. Monitorizar los días restantes te da un margen para renovar — la mayoría de equipos alerta por debajo de 30 días.
El Subject CN (Common Name) es el campo heredado para un único host. El Subject Alternative Names (SAN) es una lista moderna de todos los hosts para los que es válido el certificado, incluyendo entradas wildcard. Navegadores y la mayoría de clientes de correo ignoran ya el CN y validan contra el SAN, así que cualquier host que falte en el SAN fallará la verificación TLS.
Los certificados autofirmados son inseguros para cualquier servicio público. Cifran la conexión pero no prueban identidad, así que navegadores, móviles y clientes corporativos los rechazarán. Solo son aceptables en desarrollo, en servicios internos privados donde controlas todos los clientes, o como paso previo a emitir un certificado de confianza.
Ocurre cuando la lista SAN del certificado no incluye exactamente el nombre que has probado. Causas habituales: probar un www contra un certificado solo del apex, falta de wildcard para sub-subdominios, o servir por error el vhost equivocado en una IP compartida. Vuelve a emitir el certificado con las entradas SAN correctas.
Sí, indirectamente. Los proveedores de buzón esperan que los endpoints MX, el envío SMTP y los dominios de tracking negocien TLS correctamente. Un certificado roto o caducado fuerza la bajada a texto plano o un fallo de entrega, lo que reduce la reputación con el tiempo. Mantener todos los dominios relacionados con correo con candado verde es parte de una buena postura de autenticación.