Certificados y cadenas de confianza

Un servicio de CifraLab acepta cualquier certificado firmado por la autoridad del laboratorio, sin comprobar que el nombre del certificado sea el del servidor con el que habla. Validar la cadena confirma que la autoridad emitió ese certificado; no confirma que sea el del sitio correcto. Como la autoridad del laboratorio emite certificados para muchos servicios, otro servicio legítimo —o uno comprometido— presenta su propio certificado válido y el cliente lo acepta, hablando con quien no debía. La validación completa es tres cosas: la firma de la cadena, el nombre (que el certificado sea del host esperado) y la vigencia.

El fallo no es que falte confianza en la autoridad: es dar por buena la identidad sin comprobar a nombre de quién está el certificado.

Un servicio se conectaba a otro por TLS y daba error de certificado, así que alguien lo «arregló» desactivando la verificación —el cliente ahora acepta cualquier certificado, sin comprobar nada—. Es el peor arreglo posible: desactivar la verificación anula toda la autenticación de TLS, y cualquiera que se interponga presenta su propio certificado y lee o altera el tráfico. La causa real solía ser que el cliente no confiaba en la autoridad del laboratorio. El arreglo correcto es añadir la raíz de la CA de CifraLab al conjunto de confianza del cliente, para que valide de verdad, no apagar la comprobación.

El atajo convierte un canal autenticado en uno que acepta a cualquiera; el error se disfraza de solución porque «ya no da error».

Un servicio de CifraLab dejó de responder por HTTPS: su certificado expiró y nadie vigilaba la fecha. Un certificado caducado no es un problema de confidencialidad —el cifrado seguía bien— sino de disponibilidad: rompe TLS y tira el servicio, y es una de las caídas evitables más comunes. El arreglo no es solo renovar este: es tratar las fechas de expiración como una métrica que se vigila, con alertas a 30, 60 y 90 días y renovación automática antes del vencimiento. Un certificado caducado se previene con proceso, no se descubre cuando el servicio ya está caído.

El fallo de uso aquí es operativo: nadie era dueño de la fecha, así que la fecha ganó.

La clave privada de un certificado de CifraLab se filtró, y el equipo decidió «esperar a que caduque» en vez de revocarlo. Mal: mientras el certificado siga vigente, quien tenga la clave robada puede suplantar al servicio, y el tiempo hasta la expiración es justo la ventana que hay que cerrar. La autoridad del laboratorio revoca de verdad: se marca el certificado como revocado —se publica en la lista de revocación y se responde por el servicio de consulta en vivo— y se emite uno nuevo con una clave nueva. Revocar es para exactamente este caso; dejarlo vivir hasta que caduque es regalar la ventana.

El fallo es no usar una capacidad que la CA sí tiene: la revocación existe para cuando una clave deja de ser secreta.

Revisaste la validación de la cadena y del nombre, la verificación desactivada, el certificado caducado y el que no se revocó. Abre el laboratorio, mira el panel de la autoridad del laboratorio y los clientes, y lee el código que la auditoría anotó al cerrar la sala.