Lamassu IoT DocsDistribución y actualización de confianza
Separa raíces, intermedias y confianza TLS inicial al distribuir o migrar certificados.
Esta guía se dirige a quien administra la confianza de dispositivos y consumidores. Necesitas inventario de emisores, acceso a los almacenes de confianza y un canal autenticado de actualización. Distribuir certificados es distinto de decidir cuáles serán anclas confiables.
Tres relaciones de confianza
| Relación | Material que prepara el responsable |
|---|---|
| Dispositivo → servidor EST | Raíz, cadena o pin previamente verificado del servidor y su nombre TLS. |
| DMS → solicitante | CAs y reglas que autorizan la credencial inicial o de renovación. |
| Consumidor → dispositivo | Raíces de la identidad operativa, intermedias, validación y permisos. |
Un dispositivo que obtiene un certificado no configura automáticamente ninguna de esas relaciones en terceros. Revisa el modelo de confianza.
Qué devuelve cacerts
El DMS puede incluir el certificado TLS downstream disponible, las Managed CAs elegidas y la CA de enrolamiento. No incorpora todos los ascendientes por seleccionar la emisora. El conjunto puede contener hojas, raíces e intermedias, incluso más de una jerarquía durante una migración.
La posición no define la cadena. Identifica cada certificado por sujeto, emisor, AKI/SKI, firma y restricciones. Descarga e inspecciona con Cliente EST.
Instala lo necesario
- Mantén por separado la confianza inicial del servidor EST y la del consumidor de identidades.
- Selecciona raíces que tu política haya aprobado como anclas.
- Conserva intermedias para construir o presentar cadenas; no las conviertas automáticamente en raíces.
- Presenta hoja e intermedias requeridas en mTLS. Normalmente no necesitas enviar la raíz al interlocutor que ya confía en ella.
- Verifica cadena, fechas, nombres, usos y revocación desde el consumidor.
No uses indiscriminadamente todo cacerts.pem como -CAfile: eso puede ampliar el conjunto de autoridades confiadas, ocultar intermedias faltantes o confiar una hoja TLS que tenía otra finalidad.
Migra la confianza
Antes de cambiar Enrollment CA, inventaría equipos desconectados, bootstrap, certificados operativos y consumidores. Distribuye la nueva raíz y las intermedias necesarias; comprueba que una cohorte acepta cadenas antigua y nueva.
En el DMS, separa las CAs distribuidas de las CAs de validación de reenrolamiento en reenrollment_settings.est_rfc7030_settings.client_certificate_settings.validation_cas, utilizadas para la credencial de reenrolamiento. Esa lista es opcional porque la CA de enrolamiento siempre valida las credenciales de reenrolamiento, pero al cambiar la CA de enrolamiento, añade a ella la CA de emisión anterior para que las identidades de la CA antigua sigan reenrolándose durante el solapamiento. El validador examinado prueba la CA de enrolamiento y después esas CAs con la hoja recibida; aceptar una cadena multinivel requiere verificar cómo llega al servicio y qué emisor está configurado.
Cambia emisión, renueva por grupos y compara la serie instalada con el slot activo. Retira la confianza anterior cuando ningún equipo legítimo la necesite y tu política permita cerrar el solapamiento. Sigue Jerarquía y rotación para la operación PKI.
Comprueba la actualización
Prueba una identidad antigua permitida durante el solapamiento, una nueva, una cadena desconocida y el resultado después de retirar la confianza antigua. Conserva versión del almacén, conjunto aprobado, fecha y resultado. /cacerts accesible solo demuestra distribución; no demuestra instalación ni aceptación por todos los dispositivos.