Certificados SSL: caducidad, cadenas y errores que cuestan tráfico

Un certificado SSL caducado no se limita a degradar la experiencia de un sitio web: lo desconecta por completo tras una advertencia de seguridad a pantalla completa en el navegador que la inmensa mayoría de usuarios no se atreve a cruzar y que los rastreadores de Google interpretan como un sitio fuera de servicio.

La facturación cae a cero de forma inmediata. Y es un problema que afecta habitualmente incluso a organizaciones consolidadas, porque el fallo permanece completamente silencioso hasta que se manifiesta en toda su gravedad.

A continuación, analizamos las causas técnicas de estos fallos y cómo detectarlos con antelación.

Caducidad: la automatización que se interrumpe en silencio

Los certificados gratuitos de Let's Encrypt tienen una validez de 90 días y están programados para renovarse de forma automática a los 60 días. La automatización solventa el problema en teoría, hasta que la tarea cron de renovación falla de forma inadvertida y nadie lo percibe durante semanas.

Los fallos de renovación responden a motivos técnicos cotidianos: una regla de cortafuegos que bloquea la petición de validación ACME, un cambio en la ruta del servidor (webroot) durante un despliegue, la expiración de un token de API en el proveedor de DNS, falta de espacio en disco o una actualización del sistema operativo que rompe el paquete certbot. Ninguno de estos eventos emite una alarma visible: el certificado simplemente no se renueva y, treinta días después, la web queda bloqueada.

La regla de oro técnica: monitorice la fecha de caducidad del certificado en producción de forma externa e independiente del proceso de renovación. Si su sistema de alertas solo comprueba «si el script certbot se ejecutó con éxito», está confiando en el propio componente susceptible de fallar. Si su monitorización audita «si el certificado público accesible en el puerto 443 caduca en menos de 14 días», detectará cualquier contingencia imprevista.

Configure esa alerta a los 14 días: si un certificado con vigencia de 90 días no se renovó en el día 60 y le restan dos semanas, existe una avería evidente y dispondrá de tiempo suficiente para solucionarla con calma.

Cobertura de nombres de host: el problema de las www

Un certificado cubre únicamente los nombres de dominio explícitamente listados en su campo Subject Alternative Name (SAN). Un certificado emitido para example.com no cubre www.example.com salvo que www esté formalmente añadido.

Este es un fallo que rara vez detecta el propietario del sitio, porque siempre accede escribiendo la URL de la misma manera. Mientras tanto, los usuarios que escriben www o siguen un enlace antiguo reciben una advertencia de seguridad bloqueante.

Audite siempre ambas variantes.

Los certificados comodín (Wildcard) cubren exactamente un nivel de subdominio. Un certificado para *.example.com protege tienda.example.com pero no es.tienda.example.com. Tampoco cubre el dominio raíz example.com si no se incluye por separado.

Errores en la cadena de certificación: funciona en ordenador, falla en el móvil

El certificado de su servidor está firmado por un certificado intermedio, el cual está firmado por una entidad raíz en la que el navegador ya confía. Su servidor web tiene la obligación de entregar el certificado intermedio. La entidad raíz reside en el almacén de certificados del sistema; el intermedio, no.

Si su servidor web solo envía el certificado final (leaf), la mayoría de navegadores de escritorio subsanan la carencia descargando el certificado intermedio en segundo plano. Sin embargo, muchos navegadores móviles, dispositivos Android de versiones previas, clientes de API y herramientas de terminal no lo hacen, mostrando un error de conexión no confiable.

Por esta razón, una web puede abrirse perfectamente en el ordenador de un desarrollador y fallar en el teléfono de un cliente. Validar un certificado exclusivamente comprobando si su navegador muestra el icono del candado es una prueba insuficiente.

Nuestro verificador gratuito de certificados SSL audita la longitud y validez de la cadena de confianza completa, además de la fecha de caducidad y los nombres cubiertos.

Versiones del protocolo TLS

• TLS 1.3: el estándar actual recomendado. Completa la negociación en un único viaje de red (round trip), aportando una mejora medible en la velocidad de carga de cada conexión.
• TLS 1.2: el estándar mínimo aceptable.
• TLS 1.0 y 1.1: obsoletos, rechazados por navegadores modernos e incompatibles con la normativa de seguridad de tarjetas de crédito PCI-DSS.

Si su servidor aún negocia TLS 1.0 o 1.1, debe actualizar la configuración del servidor web de inmediato.

Certificados gratuitos frente a certificados de pago

A nivel criptográfico y de cifrado de datos, son exactamente idénticos. Let's Encrypt emplea los mismos algoritmos, las mismas longitudes de clave RSA/ECDSA y recibe el mismo reconocimiento en navegadores que un certificado de pago de coste elevado.

Lo que aportan los certificados de pago (OV y EV) es la validación de la entidad jurídica titular del dominio.

Sin embargo, los navegadores eliminaron esa distinción visual hace años. La barra verde con el nombre de la empresa desapareció de Chrome, Firefox y Safari. Un usuario común no puede distinguir un certificado de validación extendida de uno gratuito sin inspeccionar manualmente los detalles técnicos del certificado, algo que prácticamente nadie hace.

Recomendación técnica directa: utilice certificados gratuitos salvo que un pliego contractual corporativo o una regulación específica exija una modalidad determinada.

Reducción paulatina de la vigencia de los certificados

Los navegadores limitan la validez máxima de certificados públicos a 398 días, y los organismos reguladores avanzan hacia plazos mucho más breves (propuestas de 90 e incluso 45 días de vigencia máxima).

La consecuencia operativa es que la gestión manual de certificados es inviable a medio plazo. Si su procedimiento de renovación requiere que un técnico descargue e instale un archivo manualmente, ese sistema colapsará en breve. Automatizar la renovación hoy es infinitamente más económico que afrontar una incidencia crítica en plena actividad comercial.

Contenido mixto (Mixed Content)

Un certificado SSL válido no garantiza la ausencia de advertencias. Si una página cargada por HTTPS solicita recursos secundarios mediante HTTP inseguro (imágenes, scripts, hojas de estilo o fuentes), los navegadores bloquean el recurso o degradan la indicación de seguridad.

Los scripts y hojas de estilo por HTTP se bloquean de plano, rompiendo el diseño o la funcionalidad de la página. Las imágenes suelen cargarse pero eliminan el candado de seguridad.

Corrija cualquier enlace absoluto que mantenga el protocolo http:// en bases de datos o plantillas, migrándolos a https://.

Protocolo de supervisión periódica

Revisión mensual automatizada:

• Días restantes hasta la caducidad (para el dominio principal y para www)
• Integridad de la cadena de certificación intermedia
• Versión de TLS negociada

Tras cualquier cambio de hosting o CDN:

• Auditoría completa de los puntos anteriores y verificación de contenido mixto en páginas clave.

Configuración única y definitiva:

• Publicar un registro DNS de tipo CAA que especifique las únicas autoridades de certificación autorizadas a emitir certificados para su dominio. Puede consultar nuestra guía sobre registros DNS y auditar su dominio con la herramienta de consulta DNS.