Certificados: cadena, nombres y caducidad

Cuando un cliente se conecta a un host, comprueba que ese nombre esté entre los que el certificado declara. Los clientes actuales miran la lista de nombres alternativos del sujeto, no el antiguo campo de nombre común, que hoy es casi decorativo.

En esa lista puede haber un comodín, como *.ejemplo.lab. El asterisco sustituye una sola etiqueta, la que va justo antes del dominio: cubre correo.ejemplo.lab, pero no ejemplo.lab a secas ni a.b.ejemplo.lab, que tiene dos etiquetas delante. Por eso es normal ver un comodín acompañado del dominio desnudo en la misma lista.

Abre el laboratorio y compara, fila por fila, el host con los nombres que cubre su certificado. Aplica la regla del comodín de la tarea anterior: cuenta las etiquetas que hay delante de simijaca.example.

La vigencia se mide contra la fecha de la evidencia, no contra el día en que escribes el informe: si el certificado venció antes del corte, el servicio estaba entregando un certificado caducado ese día. Un vencido no debilita el cifrado; rompe la confianza, y la forma en que la gente aprende a saltarse el aviso es el verdadero problema. En una aplicación de conductores, además, suele significar que la aplicación móvil deja de conectar.

El certificado de un servicio no lo firma la raíz directamente: lo firma un intermedio, y el intermedio lo firma la raíz. El cliente tiene las raíces en su almacén, pero el intermedio lo tiene que mandar el servidor. Si no lo manda, los navegadores que ya lo conocen de otra visita lo suplen y todo parece funcionar; las integraciones entre máquinas, que no guardan nada, fallan sin explicación aparente.

En el inventario hay un panel de gestión de la flota con un certificado autofirmado y diez años de vigencia. El contexto del laboratorio dice desde dónde se alcanza. Un autofirmado en un servicio público es un problema serio; en un panel interno, lo que importa es otra cosa: que nadie puede distinguir ese certificado de uno falso, así que los usuarios aceptan cualquiera.