Métodos de enrollment

Por tanto, una propiedad esencial de los protocolos de enrollment de certificados es cómo autentican a quien solicita el certificado. Según para qué se use el certificado, resultará más ventajoso un protocolo u otro.

Otra propiedad importante es su adopción real. Tanto la CA como el lado cliente deben admitir el método o el protocolo de enrollment para el caso de uso previsto.

Los protocolos de enrollment más habituales son:

• SCEP
• ACME
• EST
• RPC/DCOM de Microsoft
• SOAP de Microsoft
• Enrollment manual en la página web de la CA
• Otros protocolos propietarios

SCEP

Historia y especificación

El Simple Certificate Enrollment Protocol (SCEP) lo inventó Cisco. Aunque entonces no existía ningún estándar, se adoptó de forma masiva en los sistemas MDM. Cisco llegó incluso a diseñar un protocolo sucesor, Enrollment over Secure Transport (EST), para sustituir a SCEP. Por eso EST se convirtió en estándar público en el RFC 7030 mucho antes que SCEP, que se estandarizó en el RFC 8894 bastante más tarde, cuando ya era el estándar de facto para el enrollment de certificados en sistemas MDM.

Tecnología

SCEP se basa en HTTP. Una SCEP Request es un PKCS#7 cifrado y firmado que se envía al servicio SCEP mediante una petición GET o POST. El servicio responde con una SCEP Response, de nuevo un PKCS#7 cifrado y firmado. La petición contiene una solicitud de firma de certificado PKCS#10 y la respuesta contiene el certificado X.509 emitido.

Autenticación

La petición PKCS#10 contiene un "SCEP Challenge" que autentica y autoriza la solicitud de firma mediante algún método fuera de banda, según cuál sea el servicio SCEP concreto. Hoy se usan en la práctica tres tipos de SCEP Challenge:

SCEP Challenge estático

La posibilidad más sencilla es una contraseña estática. Si el SCEP Challenge del PKCS#10 coincide con un valor predefinido almacenado en el servicio SCEP, el certificado se emite; en caso contrario, la solicitud se rechaza. El problema de este método es que apenas permite comprobar si las propiedades solicitadas del certificado se corresponden con quien lo pide. De hecho, existe un CVE para este problema.

Estos métodos se pueden diferenciar aún más:

1. En un enrollment SCEP directo, la entidad para la que se va a emitir el certificado se comunica directamente con el servicio SCEP. Por ejemplo, un sistema MDM indica a un teléfono Android que realice un enrollment SCEP usando el SCEP Challenge "SecurePassword". El teléfono Android genera una CSR, con suerte con los valores correctos, y añade "SecurePassword" como SCEP Challenge. Después envía la CSR al servicio SCEP y recibe a cambio el certificado emitido.
2. Un proxy SCEP transparente funciona igual que un proxy inverso HTTP. Como SCEP va cifrado y firmado, no puede examinar las peticiones ni las respuestas SCEP, y tampoco modificarlas, pero sí puede controlar quién solicita certificados y cuándo, en función de los perímetros de red.
3. Un proxy SCEP adaptador de protocolo es un sistema que solicita certificados mediante SCEP en nombre de otro sistema. Por ejemplo, un sistema MDM como JAMF podría solicitar un certificado a un servicio SCEP en nombre de algún iPhone. Una vez que tiene el certificado y la clave privada, puede desplegar el certificado mediante otro protocolo. Así, solo el sistema MDM tiene acceso al SCEP Challenge y además puede controlar el contenido del certificado.

SCEP Challenge dinámico

En este caso, cada SCEP Challenge solo es válido para una única solicitud de certificado. Esto permite al servicio SCEP identificar la petición SCEP y verificar que las propiedades del certificado solicitado coinciden con las permitidas para esa solicitud concreta.

En la práctica hay dos formas habituales de que un sistema MDM y una CA con SCEP acuerden el SCEP Challenge que se usará en una solicitud:

1. El sistema MDM solicita al servicio SCEP un código de un solo uso para una SCEP Request cuando lo necesita.
   1. Un ejemplo es Microsoft NDES. NDES dispone de una página de "admin" independiente que se autentica con credenciales de AD. Cada vez que se accede a esa página, se crea y se muestra un nuevo código de un solo uso que sirve para una única petición SCEP. En esta configuración, sin embargo, NDES no comprueba ninguna propiedad del certificado, porque el código de un solo uso es genérico.
2. El sistema MDM genera un código de un solo uso cuando indica a un sistema gestionado que solicite un certificado por SCEP. Cuando la SCEP Request llega al servicio SCEP, el servicio debe obtener el código de un solo uso del sistema MDM, normalmente mediante un web hook, y comprobar si coincide con el SCEP Challenge de la petición. No existe ningún estándar para este protocolo, así que el sistema MDM y el servicio SCEP tienen que acordar algún formato, y depende de la implementación que se compruebe alguna propiedad de la solicitud.

Metadatos firmados

Prácticamente no hay límite de longitud para el SCEP Challenge. No tiene por qué ser una "contraseña" legible para una persona, también puede ser un BLOB.

Intune utiliza como SCEP Challenge un XML firmado y cifrado. Crea ese XML en el servidor y lo envía al dispositivo cliente cuando quiere emitir un certificado y crear la SCEP Request.

El servicio SCEP debe enviar la petición PKCS#10 completa a un servicio de SCEP Challenge de Intune. El servicio de SCEP Challenge tiene la clave privada para descifrar el XML y la clave pública para comprobar que lo creó un servicio de Intune legítimo.

El XML contiene metadatos sobre la solicitud, como el aspecto que debe tener el Subject. Esto se deriva, por un lado, del perfil de configuración de SCEP y, por otro, de los datos concretos del objeto del usuario o del dispositivo para el que se va a emitir el certificado.

Por ejemplo, el perfil de configuración de SCEP podría configurar CN={{DeviceId}} como subject. Cuando el dispositivo con el id xyz solicita un certificado, el XML indica entonces que el subject debe ser CN=xyz. El servicio de SCEP Challenge compara la información del XML con el subject de la petición PKCS#10. La validación fallará si los subjects difieren y será correcta si este y el resto de propiedades coinciden.

El servicio SCEP solo emitirá el certificado si la validación es correcta.

Microsoft publica un artículo en el que explica esta verificación.

Microsoft NDES lo admite con un módulo de directivas adicional de NDES; otras CA con SCEP pueden admitirlo de forma nativa o no.

Microsoft RPC/DCOM

Historia

Los Microsoft Active Directory Certificate Services (ADCS), a veces llamados simplemente "CA de Microsoft", son el software de autoridad de certificación integrado en Windows Server. El software se desarrolló originalmente a finales del milenio pasado y siguió recibiendo algunas incorporaciones durante los diez o quince años siguientes.

Una alternativa es el SOAP de Microsoft o SCEP, a los que Microsoft llama Web Enrollment y NDES, respectivamente.

Especificación y adopción

No nos consta que otros sistemas de CA implementen este protocolo, aunque entretanto Microsoft ha publicado la especificación en Microsoft OpenSpec. En el lado cliente, Windows admite el protocolo de forma nativa; el resto de plataformas no están soportadas.

Tecnología

Su método principal de enrollment es un protocolo propietario basado en RPC o DCOM.

El autoenrollment también utiliza este protocolo. Para que el autoenrollment funcione hacen falta

• un dispositivo unido al dominio.
• una directiva de grupo que habilite el autoenrollment,
• una CA de empresa (a diferencia de una CA independiente)
• que emita una plantilla de certificado para la que
• el usuario o el dispositivo tengan los permisos de enrollment y autoenrollment.

El intervalo predeterminado para comprobar si hay autoenrollments es de 8 horas, aunque se puede forzar con certutil -pulse o, a menudo mejor, con gpupdate -force.

Autenticación

Este protocolo usa los protocolos de autenticación integrados en Active Directory, es decir, los usuarios y los equipos se autentican con sus credenciales de AD.