Modelo de confianza

En Lamassu, confianza no significa simplemente que un certificado exista en el inventario. Un consumidor confía en una identidad cuando puede construir una cadena hasta una raíz que reconoce, comprobar que el certificado sirve para el uso esperado y verificar que sigue vigente.

Las cuatro decisiones de confianza

Quién puede emitir

La jerarquía de CAs define qué autoridades pueden firmar. Una CA raíz establece el ancla de confianza; las CAs intermedias separan ámbitos operativos y evitan utilizar la raíz para cada emisión.

Qué puede emitirse

Los perfiles de certificado limitan validez, sujeto, usos, extensiones y parámetros criptográficos. La posesión de una CA no sustituye a una política de emisión.

Quién puede solicitarlo

El DMS actúa como punto de enrolamiento. Puede autenticar una solicitud EST con certificado cliente, webhook externo o una combinación de ambos. Las CAs configuradas para validar al solicitante no tienen por qué ser la CA que emitirá la identidad nueva.

Quién acepta el resultado

El servicio o dispositivo consumidor mantiene su propio almacén de confianza. Lamassu puede distribuir la CA del sistema, la CA de enrolamiento y otras CAs gestionadas mediante /cacerts, pero el consumidor decide cuáles instala y cómo aplica la validación.

Flujo de una identidad

1. El dispositivo demuestra que puede enrolarse según la política del DMS.
2. El DMS valida la solicitud y remite la CSR a la CA de enrolamiento.
3. La CA aplica el perfil y firma sin recibir la clave privada del dispositivo.
4. El dispositivo instala el certificado y la cadena que necesita.
5. El sistema que confía en el dispositivo valida cadena, fechas, usos y estado de revocación.

CAs de enrolamiento, validación y distribución

Un DMS relaciona tres conjuntos que conviene diseñar por separado:

• CA de enrolamiento: firma las nuevas identidades.
• CAs de validación: autentican certificados cliente usados para enrolamiento o migración. En re-enrolamiento, Lamassu prueba primero la CA de enrolamiento y después las CAs de validación adicionales.
• CAs distribuidas: forman el contenido que el dispositivo obtiene mediante EST /cacerts. Puedes incluir la CA del sistema, la CA de enrolamiento y una lista de CAs gestionadas.

Esta separación permite migrar una flota: aceptas temporalmente certificados de la jerarquía anterior, emites con la nueva y distribuyes ambas cadenas durante el solapamiento.

Validación y revocación

Una cadena válida no garantiza por sí sola que el certificado deba aceptarse. El consumidor también debe comprobar:

• que la fecha actual está entre Not Before y Not After;
• que Key Usage y Extended Key Usage permiten la operación;
• que nombres, SANs y sujeto coinciden con la identidad esperada;
• que el certificado no aparece revocado mediante OCSP o una CRL.

Durante la autenticación mTLS de un DMS, Lamassu intenta comprobar la revocación. Si el certificado no contiene información suficiente para efectuar esa comprobación, el backend registra una advertencia y continúa tratándolo como no revocado. Diseña los perfiles y puntos de distribución para evitar esa situación en producción.

Límites de custodia

El KMS conserva la referencia de la clave y delega la operación al motor configurado. Con un HSM o un KMS cloud, la clave privada puede permanecer no exportable. Eso protege la custodia, pero no impide por sí solo el uso indebido: todavía debes restringir quién puede ordenar una firma y auditar esas operaciones.

Patrón recomendado

• Mantén la raíz fuera de las operaciones diarias o con acceso muy restringido.
• Emite desde CAs intermedias separadas por entorno o dominio de riesgo.
• Asigna perfiles explícitos a cada caso de uso.
• Distribuye la nueva confianza antes de comenzar una rotación.
• Mantén solapamiento suficiente para renovar una flota desconectada.
• Valida desde el sistema consumidor, no solo desde la consola de Lamassu.

Continúa con Jerarquía y rotación de CAs para convertir este modelo en un procedimiento operativo.