Un certificado TLS vencido tiró toda la producción un domingo

Caso anonimizado. Los detalles del cliente fueron removidos; el incidente y la intervención son reales y representativos del tipo de trabajo de MayDay.

Qué pasaba

Un domingo a la mañana, la API de pagos de una fintech empezó a rechazar todas las conexiones. Los clientes veían errores de “conexión no segura” y la app móvil no podía autenticar. El equipo no tenía a nadie de guardia y tardó casi una hora en darse cuenta de que el certificado TLS había vencido esa madrugada.

La renovación automática existía, pero el hook de reload de nginx venía fallando en silencio desde hacía semanas: el certificado se renovaba en disco, pero nginx seguía sirviendo el viejo. Nadie lo monitoreaba.

Qué hicimos

1. Estabilización inmediata: forzamos la renovación y un reload limpio de nginx, validando la cadena completa con openssl s_client. Producción volvió en 38 minutos desde que nos llamaron.
2. Causa raíz: el deploy-hook de certbot apuntaba a un contenedor que había cambiado de nombre en un deploy anterior. La renovación corría, el reload no.
3. Blindaje: reescribimos el hook para que sea idempotente, agregamos un check de expiración del certificado efectivamente servido (no el del disco) y una alerta a 14 días de vencimiento.

Resultado

• Producción arriba en 38 minutos.
• Monitoreo de expiración real (lo que sirve nginx, no lo que hay en disco).
• Cero incidentes relacionados a certificados desde la intervención.

La deuda no era el certificado: era no estar mirando lo que el servidor realmente entrega. Eso es exactamente lo que un Health Check detecta antes de que explote.