Cuando tu certificado SSL caduca, tu sitio web muere#

Martes, 14:47. Tu CEO recibe una llamada del cliente más grande: "Vuestro sitio no carga. Nos sale un aviso de seguridad."

Tu equipo de desarrollo entra en pánico. La API parece estar bien. La base de datos responde. El balanceador de carga está sano. Entonces alguien lo comprueba: el certificado SSL caducó hace dos horas.

El navegador muestra un enorme aviso rojo. Los usuarios piensan que el sitio ha sido hackeado. El soporte al cliente se inunda de llamadas. Las redes sociales estallan. Para cuando renuevas el certificado, ya has perdido ingresos, confianza de los clientes y moral del equipo.

Esto le pasa a los equipos constantemente. Según análisis recientes, el 65 % de las organizaciones ha sufrido caídas relacionadas con SSL. ¿Tiempo medio para detectar un certificado caducado? Más de 2 horas. ¿Tiempo medio para arreglarlo? 45 minutos. 147 minutos de downtime total por un problema que el monitoring automatizado habría detectado con 90 días de antelación.

Lo peor: la caducidad de SSL no falla con elegancia. Los navegadores muestran avisos de seguridad completos. Los usuarios asumen que el sitio está comprometido. La confianza se destruye en minutos.

Esta guía recorre por qué los certificados SSL se cuelan a través del monitoring, los huecos en las estrategias actuales y la implementación práctica de alertas de caducidad SSL que realmente funcionan.

Por qué los certificados SSL caducan sin que nadie lo note#

El punto ciego del monitoring#

La mayoría de los equipos tiene algo de monitoring SSL. Simplemente no lo tienen en todas partes.

Lo que se monitoriza:

Certificado SSL del dominio principal (example.com)
Quizás el dominio de la API (api.example.com)
A veces el certificado de origen del CDN

Lo que no:

Certificados internos (staging.internal.example.com)
Certificados CDN regionales (staging, QA, production-asia)
Certificados en servicios no HTTP (SMTP/TLS para email, conexiones de base de datos)
Certificados intermedios (el bundle CA, no el certificado leaf)
Certificados en servicios de terceros que posees (API keys de clientes, certificados de firma de apps móviles)
Certificados wildcard que cubren subdominios pero no se monitorizan individualmente

Una empresa típica del mid-market tiene 12-15 certificados en producción. La mayoría tiene monitoring solo en 3-4.

El resultado: un certificado olvidado caduca un domingo. El lunes por la mañana, los clientes no pueden acceder al servicio.

Por qué el monitoring actual se salta certificados#

Incluso los equipos con monitoring SSL a menudo se pierden las caducidades porque:

Monitorizan el certificado leaf, no la cadena: Tu herramienta de monitoring comprueba si el certificado principal caduca el 15 de marzo. Lo que no comprueba: el certificado intermedio de tu CA caduca el 1 de marzo. Los navegadores rechazan toda la cadena, el sitio se cae y la herramienta de monitoring sigue mostrando "verde".

Comprobaciones puntuales, no seguimiento continuo: Comprobaste la caducidad del certificado el mes pasado. No volviste a comprobarla. El certificado fue actualizado por el equipo de seguridad y la herramienta de monitoring no lo sabe. O comprobaste el certificado, pero dejaste la herramienta sin supervisión durante un mes y la caducidad ocurrió hace 2 semanas.

Sin cobertura para nueva infraestructura: El equipo de DevOps levanta un nuevo entorno de staging con un certificado autofirmado. La herramienta de monitoring no está configurada para ello. Seis meses después, el certificado caduca. "No sabía que estábamos monitorizando eso", dice el ingeniero.

Calendario de renovación manual (poco fiable): Tienes un recordatorio en el calendario para el 15 de abril para renovar certificados. En abril, estás ocupado con un incidente en producción. Ignoras el recordatorio del calendario. El certificado caduca tres semanas después.

Suposiciones erróneas sobre la renovación: Crees que Let's Encrypt renueva automáticamente tus certificados (lo hace, a veces). Crees que tu proveedor cloud renueva automáticamente (no siempre lo hacen). Crees que tu autoridad certificadora envía avisos (los envían, pero tu email va a una dirección antigua o a la carpeta de spam). Asumes que alguien está vigilando (no lo están).

El coste real de una caducidad SSL no detectada#

Impacto inmediato: indisponibilidad total del servicio#

A diferencia del HTTP 503 (servicio no disponible), un SSL caducado no le ofrece al usuario una página de error elegante. Los navegadores modernos muestran un agresivo aviso de seguridad: "Tu conexión no es privada", con una enorme X roja.

El primer pensamiento del usuario: "Este sitio está hackeado. No voy a meter mi tarjeta de crédito."

Para e-commerce: la tasa de conversión cae casi a cero durante errores de SSL. Para SaaS: los clientes creen que sus datos están en riesgo. Para APIs: todas las peticiones fallan inmediatamente.

Ejemplo real: Una empresa de procesamiento de pagos dejó caducar un certificado SSL durante 3 horas. Las transacciones no se pudieron procesar. La empresa perdió un volumen de transacciones estimado en 180.000 $. La confianza del cliente tardó semanas en recuperarse.

Fallos en cascada: las dependencias se rompen#

La caducidad de tu certificado SSL no solo rompe tu sitio. Rompe servicios derivados:

Caduca el certificado de tu API → las apps móviles no pueden autenticarse → los usuarios no pueden iniciar sesión
Caduca el certificado de tu webhook → las integraciones de terceros no pueden enviar eventos → la sincronización de datos se rompe
Caduca el certificado de la conexión a tu base de datos → las aplicaciones no pueden conectarse → todo falla
Caduca el certificado TLS de tu email → los emails no se envían → las notificaciones se rompen

Un certificado caducado puede tumbar 5 o más servicios dependientes.

Incumplimientos normativos: auditorías y sanciones#

Para sectores regulados:

Sanidad: HIPAA exige TLS para toda transmisión de PHI. Certificados caducados = incumplimiento. Los auditores lo marcan. Posibles multas.
Financiero: PCI DSS exige SSL/TLS válidos para las páginas de pago. Certificado caducado = incumplimiento. Las auditorías periódicas detectan esto.
Administración pública: El cumplimiento de FedRAMP exige validez del certificado 24/7. Certificado caducado = sistema retirado del servicio.

Que se te escape una caducidad SSL durante una auditoría de cumplimiento es especialmente doloroso: no solo has tenido downtime, sino que has incumplido requisitos de seguridad mientras estabas caído.

Daño reputacional: duradero#

Los errores de SSL se quedan grabados en la mente de los usuarios. "Intenté usar example.com pero decía que estaba hackeado" se comparte en comunidades, foros de soporte y redes sociales.

La recuperación lleva tiempo. Incluso después de arreglar el certificado, los usuarios desconfían. Hay que reconstruir la confianza.

Cómo funcionan los certificados SSL: entender qué falla#

La cadena de certificados (la parte que la gente olvida)#

Tu certificado SSL no es solo un certificado. Es una cadena:

Certificado leaf (tu dominio): example.com, emitido por Let's Encrypt, caduca el 15 de marzo
Certificado intermedio (la CA): Let's Encrypt Authority X3, emitido por ISRG, caduca el 20 de enero de 2026
Certificado raíz (autoridad de confianza): ISRG Root X1, emitido por ISRG, caduca el 4 de junio de 2035

Tanto el leaf como el intermedio deben ser válidos. Si cualquiera de ellos caduca, el navegador rechaza toda la cadena.

La mayoría de los equipos monitoriza el certificado leaf (15 de marzo). Pocos monitorizan el intermedio (20 de enero). El error en el navegador aparece 2 meses antes.

Tipos de certificados y dónde se esconden#

Certificados de dominio:

Emitidos para un dominio específico: example.com
Cubren solo ese dominio
Caducidad típica: 90 días (Let's Encrypt), 1 año (CAs tradicionales)

Certificados wildcard:

Emitidos para *.example.com
Cubren todos los subdominios (api.example.com, staging.example.com, etc.)
Un certificado que cubre más de 20 servicios
Una sola caducidad afecta a todos los servicios

Certificados multidominio/SAN:

Cubren varios dominios: example.com, example.co, cdn.example.com, todos en un mismo certificado
La caducidad de un certificado afecta a varios servicios
Una sola renovación arregla varios problemas

Certificados autofirmados:

Generados localmente para pruebas/staging
No emitidos por una CA
Los equipos ignoran sus tiempos de caducidad ("es solo para pruebas")
Y luego el entorno de pruebas pasa a producción y el certificado va con él

Certificados internos/privados:

Para servicios internos, bases de datos, TLS mutuo
No los monitorizan los SSL checkers estándar
La caducidad provoca fallos de autenticación
Los equipos no tienen visibilidad

La estrategia de monitoring SSL: cobertura completa#

Paso 1: Inventariar todos tus certificados (la auditoría)#

Esto es crítico y la mayoría de los equipos se lo salta. No puedes monitorizar lo que no sabes que existe.

Haz una auditoría exhaustiva de certificados:

Para servicios públicos (web):

# Scan your domains for all certificates
for domain in example.com api.example.com staging.example.com cdn.example.com; do
  openssl s_client -connect $domain:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -dates -subject
done

Para infraestructura cloud: Comprueba AWS Certificate Manager, Google Certificate Manager, Azure Key Vault:

¿Qué certificados existen?
¿Qué dominios cubren?
¿Cuándo caducan?
¿Quién los gestiona?

Para servicios de infraestructura:

Certificados de bases de datos (RDS, MongoDB Atlas, PostgreSQL TLS)
Certificados TLS de email (SMTP/TLS para sendmail, Postfix, SendGrid)
Certificados del balanceador de carga
Certificados del API gateway
Certificados del service mesh (si usas Istio, Linkerd, etc.)

Para aplicaciones:

Certificados de API key (apps móviles, claves OAuth con certificados)
Certificados de firma de JWT
Certificados de cliente (autenticación mTLS)
Certificados de firma de código (para distribución de apps)

Entregable: Una hoja de cálculo con:

Nombre/dominio del certificado
Fecha de caducidad
Autoridad emisora
Proceso de renovación
Destinatario de las alertas
Criticidad para el negocio

Una empresa típica del mid-market encuentra entre 15 y 30 certificados. Los equipos enterprise encuentran más de 100.

Paso 2: Clasifica tus certificados por criticidad#

No todas las caducidades son iguales. Categoriza:

CRÍTICO (avisar al on-call, alerta 60 días antes de la caducidad):

Dominio web de producción
Dominio de la API de pagos
Dominio del servicio de autenticación
Servicios de cara al cliente

ALTO (alerta en Slack, alerta 30 días antes de la caducidad):

Dominios de API (no de pago)
Certificado de borde del CDN
Certificado TLS de email (impacto en operaciones de negocio)
Dominio de WebSocket

MEDIO (resumen por email, alerta 14 días antes de la caducidad):

Dominio de staging (pruebas previas a producción)
Certificado de servicio interno
Certificado del panel de administración

BAJO (sin alerta, seguimiento en el dashboard):

Certificados de desarrollo/locales
Certificados de prueba
Certificados con renovación automática (Let's Encrypt)

Asigna destinatarios de alertas a cada nivel.

Paso 3: Implementa monitoring SSL para cada tipo de certificado#

Para certificados de dominio (HTTPS):

Usa una herramienta dedicada de monitoring SSL que compruebe:

Caducidad del certificado leaf (principal)
Caducidad del certificado intermedio (crítico — a menudo olvidado)
Validez del certificado (aún no inválido, correctamente emitido)
Completitud de la cadena de certificados (todos los intermedios presentes)
Fortaleza del cipher suite (alerta de versiones TLS débiles)
Cobertura SAN (todos los dominios esperados aparecen)

Configuración para un dominio crítico:

Domain: api.example.com
Check interval: Daily
Alert on: &lt; 60 days to expiry, chain broken, weak ciphers
Recipients: ops-team@example.com

Para certificados de bases de datos/internos:

La mayoría de las herramientas no los comprueban. Configúralo en tu infraestructura:

AWS Certificate Manager: activa las notificaciones 60 días antes de la caducidad
Kubernetes: despliega cert-manager con un webhook de monitoring
HashiCorp Vault: activa los dashboards de monitoring de certificados
Manual: un script que compruebe las fechas con OpenSSL y envíe alertas

Para certificados de firma de código / claves:

Estos viven en sistemas de gestión de claves:

Comprueba la cuenta de Apple Developer para los certificados de firma de iOS
Comprueba Android Play Console para las claves de firma de apps
Comprueba GitHub/GitLab para las deploy keys
Manual: recordatorio en el calendario + alerta por email 3 meses antes

Paso 4: Configura canales de notificación (en varias capas)#

No te apoyes en un único canal de alertas. La caducidad SSL exige redundancia:

60 días antes de la caducidad:

Notificación en el dashboard (revisa el dashboard mensualmente)
Email al equipo de ops (ops@example.com)

30 días antes de la caducidad:

Notificación en el dashboard
Canal de Slack #ops-alerts
Email al equipo de ops + CTO

14 días antes de la caducidad:

Todo lo anterior, más
SMS al ingeniero on-call
Email de escalado al CEO (solo certificados críticos)

7 días antes de la caducidad:

Todo lo anterior
Avisar al ingeniero on-call por buscapersonas (si aún no se ha renovado)

Día de la caducidad:

Avisar al ingeniero on-call inmediatamente
Declarar incidente SEV1
Iniciar el proceso de renovación de emergencia

Este enfoque por capas garantiza que la caducidad no se escape.

Paso 5: Automatiza la renovación cuando sea posible#

La renovación manual es como ocurren las caducidades. Automatiza:

Let's Encrypt (renovación automática):

# Certbot auto-renewal (runs via cron daily)
0 0 * * * certbot renew --quiet --post-hook "systemctl reload nginx"

Verifica que la renovación automática funciona:

# Check last renewal date
certbot certificates

AWS Certificate Manager (renovación automática):

Certificados públicos: AWS los renueva automáticamente 60 días antes de la caducidad
Certificados privados: hay que renovarlos manualmente, pero AWS envía notificaciones
Verifica el estado de renovación en la consola de ACM

Kubernetes (cert-manager):

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
spec:
  secretName: example-com-tls
  issuerRef:
    name: letsencrypt-prod
  renewBefore: 720h  # 30 days

cert-manager renueva automáticamente antes de la caducidad.

Para todo lo demás: Si se necesita renovación manual, dispara la renovación automáticamente al llegar a los 30 días:

Engancha la herramienta de monitoring para que dispare el script de renovación
El script de renovación se encarga de actualizar el certificado
El monitoring confirma que el nuevo certificado está activo

Implementación paso a paso del monitoring SSL#

Paso 1: Elige tu herramienta de monitoring (1-2 horas)#

Evalúa según:

Cobertura (¿solo certificados web o también de bases de datos/internos?)
Granularidad de alertas (¿puedes alertar a 60, 30 y 14 días por separado?)
Integración (¿Slack, email, PagerDuty?)
Coste (¿basta el plan gratis? ¿precios enterprise?)
Automatización de la renovación (¿la automatiza o solo avisa?)

Compara:

Nova Uptime: dominio + email health + alertas SSL, precio plano, UI sencilla
SSL Labs: gratis, completo, sin alertas (solo dashboard)
Better Stack: monitoring SSL + uptime + logging, 50 $+/mes
Hyperping: monitoring todo en uno, 24 $/mes, incluye comprobaciones SSL
Datadog: solución enterprise, lo cubre todo, muy caro

Decisión: Para la mayoría de los equipos, elige una herramienta dedicada de monitoring SSL (Nova Uptime, Better Stack, Hyperping) + automatiza las renovaciones con Let's Encrypt/ACM.

Paso 2: Inventario y configuración (2-4 horas)#

Haz la auditoría de certificados (ver Paso 1 más arriba)
Mete cada certificado en la herramienta de monitoring
Define los umbrales de alerta: 60 días, 30 días, 14 días
Prueba las alertas (verifica que llegan a Slack/email)
Documenta en una hoja de cálculo

Paso 3: Configura la integración con Slack (30 minutos)#

Configura la herramienta de monitoring para que envíe alertas a #ops-alerts:

La plantilla del mensaje de Slack debería incluir:

Dominio del certificado
Fecha de caducidad
Días restantes
Enlace/instrucciones de renovación
Impacto en el negocio si caduca

Paso 4: Crea un runbook (30 minutos)#

Para cada nivel de certificado, documenta:

¿Dónde vive este certificado? (AWS ACM, Let's Encrypt, servidor propio)
¿Quién es responsable de la renovación? (DevOps, SRE, contratista)
¿Cómo se renueva? (comando de Certbot, consola de AWS, portal del proveedor)
¿Cómo se verifica que está activo? (SSL checker, petición HTTPS de prueba)
¿A quién avisas cuando termines? (líder del equipo, herramienta de monitoring)
¿Cuánto suele tardar? (¿5 minutos, 30 minutos, 24 horas?)

Ejemplo de runbook:

Certificate: api.example.com (AWS ACM)
Responsibility: DevOps team
Renewal process:
  1. Go to AWS Certificate Manager console
  2. Click "Request certificate"
  3. Select "Domain validation"
  4. Wait for email validation (2-4 hours)
  5. Approve in email
  6. Update load balancer to use new cert
  7. Test: curl https://api.example.com -v
  8. Notify: #ops-alerts channel

Typical time: 30 minutes (4 hours if email slow)

Paso 5: Prueba tu sistema (1 hora)#

No descubras tu monitoring durante una caducidad real.

Prueba 1: entrega de alertas

Dispara una alerta de prueba en la herramienta de monitoring
Verifica que el email llega en menos de 2 minutos
Verifica que la notificación de Slack llega en menos de 1 minuto
Verifica que el SMS llega en menos de 3 minutos (si está configurado)

Prueba 2: proceso de renovación

No esperes a tener 14 días para la caducidad
Simula una renovación en un certificado no crítico
Sigue tu runbook
Verifica que el nuevo certificado está activo
Verifica que la herramienta de monitoring se actualiza

Prueba 3: escalado

Si la alerta no se reconoce en 1 hora, ¿quién hace el escalado?
¿Avisan al on-call?
Prueba todo el flujo de escalado

Errores comunes a evitar#

Error 1: monitorizar solo el certificado leaf#

Estás comprobando cuándo caduca el certificado del dominio (15 de marzo). Estás ignorando el certificado intermedio (que caduca el 20 de enero).

Resultado: los navegadores rechazan la cadena de certificados el 20 de enero, el sitio se cae y tu monitoring no salta hasta febrero.

Solución: asegúrate de que tu herramienta de monitoring comprueba toda la cadena de certificados, no solo el certificado leaf.

Error 2: asumir que Let's Encrypt "simplemente funciona"#

Let's Encrypt renueva automáticamente, así que puedes ignorarlo, ¿no?

Pues no. La renovación automática falla si:

El hook de renovación está mal configurado (el certificado se renueva pero el servidor no se recarga)
Falla la validación DNS (no se puede verificar el dominio)
Saltan los rate limits (chocas con los límites de Let's Encrypt)
El servidor está caído durante la ventana de renovación

"Configúralo y olvídate" es como acabas con certificados caducados.

Solución: monitoriza el estado de renovación de Let's Encrypt. Certbot no fallará de forma visible si la renovación no funciona — tienes que mirar los logs.

Error 3: certificados en varios sitios, monitorizados en uno solo#

Tienes certificados en:

AWS ACM (para el balanceador de carga)
Secrets de Kubernetes (para los pods de la app)
Archivos locales en el servidor (para backup)

Solo monitorizas ACM. Cuando alguien actualiza el certificado del archivo local y se olvida de la versión de ACM, el certificado local caduca, la app usa el certificado viejo y no salta ninguna alerta.

Solución: inventaria todos los certificados. Monitoriza cada uno por separado. Exige que el despliegue de certificados actualice todas las ubicaciones simultáneamente.

Error 4: fatiga de alertas con avisos de certificados#

Mandas alertas a 60 días, 30 días, 14 días y 7 días antes de la caducidad.

Los equipos ven 4 alertas para el mismo certificado, dejan de prestar atención y se pierden la ventana real de renovación.

Solución: alerta solo en intervalos clave (60 días y 7 días). Crea tareas de recordatorio en lugar de alertas para los hitos de 30/14 días.

Error 5: responsabilidad de renovación poco clara#

"¿Quién renueva este certificado?" Nadie lo sabe.

Dos personas asumen que la otra se está encargando. El certificado caduca.

Solución: asigna un responsable explícito a cada nivel de certificado. Ten un responsable de respaldo. Escala si el principal no reconoce la alerta.

Error 6: certificados autofirmados en producción#

El equipo de desarrollo crea un certificado autofirmado para staging. Funciona en local. Luego se copia a producción "temporalmente". Seis meses después, nadie recuerda que está ahí. Caduca. Producción se cae.

Solución: los certificados autofirmados no llegan a producción. Punto. Hazlo cumplir con reglas de despliegue.

Cómo Nova Uptime te protege frente a la caducidad de certificados SSL#

Nova Uptime combina el monitoring de certificados SSL con el seguimiento de caducidad de dominios y el chequeo de salud del email — un monitoring de infraestructura completo en un solo sitio:

Validación SSL automática en cada chequeo:

Cada vez que Nova Uptime comprueba el uptime de tu dominio, también valida el certificado SSL
Detecta certificados SSL caducados, inválidos o rotos y envía alertas inmediatas
Tipos de notificación separados para avisos de caducidad SSL frente a estados de SSL inválido/roto

Alertas escalonadas de caducidad:

Alertas configurables en varios intervalos antes de la caducidad del certificado
Notificaciones por email enviadas al propietario del dominio con los días restantes
Las alertas SSL se deduplican durante 24 horas para evitar el spam de notificaciones

Dashboard de monitoring unificado:

Sigue el uptime del dominio, el estado SSL, la caducidad del registro del dominio y la salud del email en un solo sitio
Estado del certificado SSL visible directamente en las tarjetas de dominio del dashboard
Los emails con el informe semanal resumen el estado completo de tu monitoring

Seguimiento de caducidad de dominio incluido:

Las consultas RDAP y WHOIS rastrean cuándo caduca el registro de tu dominio
El flujo de confirmación de renovación te permite indicar cuándo has renovado
Evita que tanto el certificado SSL como el registro del dominio caduquen

Resumen y plan de acción#

La caducidad de certificados SSL es prevenible. No es un problema técnico — es un problema operativo que se resuelve con visibilidad y automatización.

Aquí tienes tu plan de acción:

Esta semana: haz una auditoría completa de certificados. Inventaría todos los dominios, servicios internos, bases de datos, certificados de firma de código. Crea una hoja de cálculo.
Semana 2: clasifica los certificados por criticidad. Asigna destinatarios de alertas y responsables de renovación a cada nivel.
Semana 3: monta la herramienta de monitoring SSL. Mete todos los certificados. Configura alertas a 60/30/14/7 días.
Semana 4: crea runbooks de renovación para cada tipo de certificado. Documenta los pasos, quién es responsable, cómo verificar.
Semana 5: prueba tu sistema. Dispara alertas de prueba. Simula el proceso de renovación. Verifica que el escalado funciona.
Continuo: revisa el inventario de certificados mensualmente. Añade nuevos certificados a medida que crece la infraestructura. Prueba el proceso de renovación trimestralmente.

Cada certificado que monitorizas es uno que no caducará sin que nadie lo note. Cada automatización que pones en marcha es una tarea manual menos que olvidar.

Lecturas relacionadas#

Guía de monitoring de certificados SSL — Profundiza en buenas prácticas y estrategias de automatización del monitoring SSL.
Fatiga de alertas: por qué te estás ahogando en alertas — Aprende a afinar tus alertas para que los avisos SSL no se pierdan en el ruido.
Monitoring de caducidad de dominios: evita las caídas — No monitorices solo el SSL — sigue también la caducidad del registro del dominio.
¿Qué es el monitoring de uptime de un sitio web? — Entiende cómo trabajan juntos el monitoring de uptime y el monitoring SSL.
Calculadora del coste del downtime de un sitio web — Cuantifica el impacto en ingresos del downtime relacionado con SSL.

¿Listo para no volver a perder ninguna caducidad de certificado? Activa el monitoring de certificados SSL con Nova Uptime y recibe alertas antes de la caducidad, con monitoring unificado de dominio, SSL y salud del email. Empieza hoy.

Prevención de la caducidad de certificados SSL: no vuelvas a perder una renovación