Certificados y TLS de Libreta

Un certificado vencido tumba el servicio o, peor, enseña a todo el mundo a pulsar «continuar de todos modos». No es un fallo de confidencialidad sino de disponibilidad y de hábito, y es de las caídas más evitables. El traspaso afirma que un guion renueva todo a tiempo; el inventario trae la fecha de vencimiento de cada certificado, y la fecha de hoy es el 22 de octubre de 2026.

La afirmación se comprueba contra las fechas, certificado por certificado.

La vigilancia de caducidades es una métrica, no una tarea de memoria: se calcula cuántos días faltan, se alerta con margen y se renueva antes del vencimiento. Entre los certificados vigentes, el del portal público es el que vence antes. Para saber cuánto margen queda hay que restar la fecha de hoy a su fecha de vencimiento, en días naturales.

Un certificado que vence en dos semanas no es un hallazgo urgente de hoy, pero sí tiene que tener dueño y fecha de renovación.

El proceso que envía los archivos de cobro a la pasarela de pagos tiene desactivada la verificación de la cadena y del nombre del servidor. La nota del cliente cuenta que se desactivó «para que funcionara» con un certificado de pruebas. Sin validar, el cliente acepta cualquier certificado y cualquiera que se interponga en el camino puede hacerse pasar por la pasarela. El arreglo no es dejar de cifrar ni confiar en todo: es volver a validar y fijar la autoridad que emite el certificado de la pasarela como la única de confianza para ese destino.

Desactivar la verificación para que funcione es el atajo más repetido de todo el oficio.

TLS negocia versión y suites en cada conexión, y lo que el servidor deja habilitado es lo que un cliente viejo o un intermediario puede forzar. Un punto de servicio que sigue aceptando las primeras versiones del protocolo está ofreciendo algo que ya nadie necesita. El inventario de puntos de servicio dice, uno por uno, qué versiones acepta.

No se trata de apagar todo lo viejo a ciegas, sino de saber qué clientes lo usan antes de apagarlo.

Un certificado comodín cubre cualquier nombre de un dominio, y su clave privada está copiada en seis servidores. Cada copia es un sitio más donde la clave puede filtrarse, y si se compromete una sola, el atacante puede hacerse pasar por cualquier nombre del dominio. Es práctico, y por eso se repite. El arreglo de fondo es un certificado por servicio, con su propia clave, que no se mueve de donde se generó; si hay sospecha de exposición, se revoca y se reemite.

La comodidad de operar no se compara con el número de sitios donde vive una clave privada.