La cadena completa y a quién confías la raíz

Un servicio de CifraLab presenta su certificado pero no envía el de la emisora intermedia que lo firmó, solo el suyo. Algunos clientes tienen la intermedia a mano por otra vía y la conexión les funciona; otros no pueden construir la cadena hasta la raíz y rechazan el certificado, o peor, alguien «lo arregla» desactivando la validación. El certificado es correcto; lo que falta es que el servidor entregue la cadena completa —su certificado más el de la emisora intermedia— para que cualquier cliente pueda enlazarla hasta la raíz en la que confía. El arreglo es configurar el servidor para que sirva la cadena intermedia, no pedir a los clientes que aflojen la validación.

El fallo es de entrega, no del certificado: la confianza existe pero el servidor no da los eslabones para seguirla.

Un cliente de CifraLab daba error con un servicio, y alguien lo «arregló» metiendo el certificado de ese servidor directamente en el conjunto de confianza del cliente. Funciona, y está mal por dos motivos. Primero, ahora el cliente confía en ese certificado concreto como si fuera una autoridad, así que cuando el servidor renueve su certificado —que caduca— el cliente volverá a fallar. Segundo, confiar en un certificado de servidor en vez de en la raíz de la CA salta todo el modelo de cadena: no estás validando que una autoridad respalde al host, estás grabando a fuego un host. Lo correcto es añadir al conjunto de confianza la raíz de la CA del laboratorio, no el certificado del servidor; así el cliente valida por cadena cualquier certificado que esa CA emita, hoy y tras renovar.

El fallo es confundir «confío en este servidor» con «confío en la autoridad que lo respalda»: solo la segunda sobrevive a una renovación.

Un servicio responde en pagos-nuevo.cifralab.local presentando un certificado emitido para pagos.cifralab.local. El certificado es válido, está vigente y lo firmó la CA correcta, pero su nombre no cubre el host que lo presenta, así que un cliente que valide bien el nombre lo rechaza —y con razón: aceptar un certificado para un nombre distinto es justo el agujero que vimos en la sala anterior—. El nombre que vale es el que está en el campo de nombres alternativos del certificado (SAN); un comodín como *.cifralab.local cubre un nivel de subdominios, pero no cualquier variación. El arreglo es emitir o reemitir el certificado con el nombre correcto del host en su SAN, no relajar la comprobación del nombre en el cliente.

El fallo es un desajuste de nombre, y la tentación —aceptarlo igual— reabre justo el hueco que la validación de nombre existe para cerrar.

Viste la cadena incompleta, la confianza puesta en el host en vez de en la raíz, y el nombre del certificado que no cubre el host. Abre el laboratorio, recorre esos tres casos de la cadena y lee el código que la auditoría anotó al cerrar la sala.