Identidad inicial y autenticación

Esta guía conecta al administrador DMS con quien fabrica o integra el dispositivo. Antes de solicitar su identidad operativa, el cliente debe poder autenticar al servidor EST y demostrar que tiene derecho a solicitar el ID previsto.

Confianza inicial del servidor

Instala una raíz, cadena o pin previamente verificado mediante un canal confiable: fabricación, configuración aprobada o distribución autenticada. Ese material permite verificar TLS y el nombre del servidor antes de descargar /cacerts.

No puedes obtener tu única prueba de confianza del mismo servidor todavía no autenticado. El certificado TLS del servidor EST, el certificado bootstrap y la CA emisora de la identidad operativa pueden pertenecer a jerarquías distintas.

Credencial bootstrap

Con CLIENT_CERTIFICATE, el dispositivo presenta su certificado inicial y demuestra posesión de su clave en TLS. El DMS lo valida frente a sus CAs de admisión. En el flujo examinado, el validador recibe una credencial de hoja: configura y prueba el emisor directo para el caso sencillo; enviar más intermedias desde el cliente no demuestra que lleguen al servicio.

Comprueba fechas, certificado y clave correspondientes y estado de revocación antes de provisionarlos. Una credencial compartida entre equipos identifica esa credencial compartida, no a un equipo concreto.

En el primer enrolamiento, la validación mTLS no compara por sí sola el CN del bootstrap con el CN solicitado en la CSR. Si necesitas que un solicitante solo pueda pedir su propio Device ID, añade un control que vincule credencial e ID, por ejemplo el webhook combinado, y prueba una solicitud con otro CN. En reenrolamiento con certificado sí se compara su CN con el de la CSR; las comprobaciones posteriores utilizan la identidad activa registrada.

Modos por operación

Los cuatro modos se seleccionan independientemente para enrolamiento y reenrolamiento en DMS. La credencial utilizada al renovar depende de ese bloque; no presupongas que siempre será el bootstrap o que el webhook desaparezca.

Un token OIDC de administración no es un modo EST nativo. Un webhook puede interpretar una cabecera de credencial que acuerdes con él; en ese caso la autorización la realiza ese servicio. En NO_AUTH, enviar un token no añade autenticación al DMS.

Contrato del webhook

El DMS envía el contexto de la operación al servicio configurado. El método procede de la configuración; acuerda su contrato antes de seleccionar POST o PUT. La espera de autorización tiene un valor inicial de 10 segundos, sustituido por un timeout positivo configurado. El DMS verifica el certificado del receptor salvo que se active insecure_skip_verify en la configuración del webhook — por defecto se verifica — y no sigue redirecciones, así que la URL configurada debe ser la final. La respuesta de autorización debe ser JSON de como máximo 1 MiB. Con la autenticación de Lamassu hacia el webhook configurada sobre http://, la API key o el bearer token viajan en texto claro, y mTLS no tiene efecto porque no hay handshake TLS, así que el certificado de cliente nunca se presenta; prefiere https://. Configura esas opciones en los ajustes del webhook externo de la guía DMS.

Ejemplo de cuerpo:

{
  "csr": "BASE64_OF_PEM_CSR",
  "aps": "DMS_ID",
  "device_cn": "est-device-001",
  "http_request": {
    "headers": { "X-Enrollment-Credential": "REDACTED" },
    "url": "/.well-known/est/DMS_ID/simpleenroll"
  }
}

csr contiene base64 del PEM, a diferencia del cuerpo EST, que contiene base64 del DER. http_request recoge URL y primeras entradas de cabeceras del contexto HTTP disponible. El campo operation no se envía en este cuerpo; distingue enroll y reenroll mediante la ruta y la política configurada.

El webhook debe verificar la credencial, su relación con device_cn, DMS, operación y política de admisión. Las cabeceras transportadas no son por sí mismas evidencia de confianza. La autenticación de Lamassu hacia el webhook es otra relación distinta que se configura en el cliente HTTP del servidor.

La continuación requiere respuesta HTTP satisfactoria y JSON:

{ "authorized": true }

Un 204 sin cuerpo no cumple el contrato. Rechazo, error de transporte, respuesta no interpretable o timeout abortan la autorización. En modo combinado, primero se valida el certificado y después se consulta el webhook. Consulta la especificación del webhook.

Revocación y comprobaciones

El DMS busca primero el certificado en Lamassu; para uno externo intenta OCSP y CRL. Si no logra comprobar revocación, los validadores pueden continuar tratándolo como no revocado. El código tampoco permite asumir que todo estado externo distinto de Good se rechace. Verifica el comportamiento requerido con tu credencial y endpoint reales; no presentes esta comprobación como una política estricta garantizada para todas las fuentes.

Prueba certificado permitido, certificado incorrecto, CN ajeno, webhook denegado, timeout y reenrolamiento bajo su propia política. Conserva el resultado y programa la retirada de las credenciales bootstrap cuando corresponda. Continúa con Cliente EST.