Autenticación de red basada en certificados

Recomendamos usar nuestro RADIUS-como-servicio como Controlador de Acceso a la Red (NAC) para implementar la autenticación basada en certificados para WiFi, LAN o VPN, ya que permite una configuración con un clic. En general, los certificados de SCEPman funcionan con todos los NAC que admiten la autenticación basada en certificados 802.1x estándar, sin embargo.

Este artículo describe características notables de algunos de los NAC más comunes.

RADIUS-como-servicio

Consulte la documentación de RADIUS-como-servicio para ver cómo usar los certificados de SCEPman en RADIUS-como-servicio.

Cisco ISE

Esto ya no es necesario para Cisco

• ISE Release 3.2 Patch 8 o posterior,

• ISE Release 3.3 Patch 5 o posterior,

• ISE Release 3.4 Patch 2 o posterior

Cisco ISE comúnmente no admite HTTP 1.1 sino solo HTTP 1.0 para solicitudes OCSP. Esto requiere un Proxy de Aplicación adicional delante de SCEPman. Consulte nuestro artículo de solución de problemas para ISE para más detalles.

Al menos algunas versiones de Cisco ISE 3.x requieren una extensión de Uso de Clave Extendida que contenga el Uso de Clave Extendida del Respondedor OCSP para aceptar respuestas OCSP, incluso si provienen de una CA donde no es requerido según la RFC. Las versiones de SCEPman hasta la 1.7 no añadían por defecto un Uso de Clave Extendida al certificado de su CA. La versión 1.8 permite agregar esta extensión mediante una configuración. En SCEPman 1.9, el valor predeterminado de la configuración ya añade el Uso de Clave Extendida. Si ya tiene un certificado de CA sin una extensión de Uso de Clave Extendida y tiene problemas con Cisco ISE 3.x, puede que necesite crear un nuevo certificado SCEPman Root CA con la extensión de Uso de Clave Extendida.

Aruba ClearPass

Extensión ClearPass de Microsoft Intune

En caso de que esté usando la Extensión ClearPass de Microsoft Intune dentro del ClearPass Policy Manager, se le exige añadir los identificadores de dispositivo al plantilla de certificado SCEP en un cierto formato. Para asegurar compatibilidad con SCEPman, a continuación se requieren los atributos SAN en el siguiente orden:

• (URI) Valor: DeviceId:{{DeviceId}}

• (URI) Valor: AAD_Device_ID:{{AAD_Device_ID}}

• (URI) Valor: IntuneDeviceId://{{DeviceId}}

Las dos primeras entradas son usadas por ClearPass, mientras que la tercera entrada es usada por SCEPman.

Problema de OCSP HTTP 1.0

Esto ya no es necesario para ClearPass 6.9.6 o posterior.

De manera análoga a Cisco ISE, Aruba ClearPass utiliza HTTP 1.0 para solicitudes OCSP y por lo tanto requiere pasos de configuración adicionales que agreguen un Proxy de Aplicación para funcionar con SCEPman.

Microsoft Network Policy Server (NPS)

NPS asigna certificados a entidades de dispositivo o usuario en AD (no en AAD). Como no existe una sincronización de dispositivos lista para usar entre AAD y AD, generalmente no es posible usar NPS con certificados de dispositivo distribuidos vía Intune con SCEPman u otra PKI. Los certificados de usuario pueden funcionar para usuarios sincronizados entre AAD y AD. Los certificados deben contener los UPN de los usuarios, que NPS usa para mapear a objetos de usuario de AD con el mismo UPN.

Otros

En general, debe agregar el certificado SCEPman Root CA como una CA de confianza en el NAC.

Posiblemente, deba agregar manualmente la URL OCSP de SCEPman. Puede encontrar la URL OCSP en la extensión Authority Information Access (AIA) de cualquier certificado de cliente.