Durante despliegues de inscripción masiva con Microsoft Active Directory Certificate Services (ADCS) y un hardware security module YubiHSM 2 conectado por USB, algunos administradores encuentran el mensaje de error:
“The device that is required by this cryptographic provider is not ready for use” (0x880090030 / NTEDEVICENOT_READY)
Este artículo desglosa por qué aparece, cómo aislar la causa exacta y qué medidas prácticas aplicar para que tu infraestructura de clave pública (PKI) vuelva a emitir certificados de forma fiable.
Resumen rápido
El código 0x880090030 suele indicar que el proveedor criptográfico (KSP/CNG) no puede abrir una sesión con el HSM en el momento en que ADCS necesita firmar la solicitud. En la mayoría de los ambientes se origina por:
- Saturación del límite de 16 sesiones simultáneas del YubiHSM 2.
- Cortes transitorios de energía USB (ahorro de energía, picos de corriente, hot‑plug).
- Firmware o controlador antiguo con fugas de sesión.
- Interferencia de otro proceso que toma el HSM en exclusiva.
Arquitectura típica y puntos de fallo
Una PKI empresarial moderna suele constar de:
- Una CA raíz sin conexión que genera la clave maestra.
- Una o más sub‑CAs en línea que almacenan su clave de firma en un YubiHSM 2.
- Clientes que usan plantillas de certificados y directivas de grupo (GPO) para autoinscribirse.
La ruta crítica se resume así:
- Cliente envía CSR ➝ sub‑CA.
- Servicio ADCS invoca al proveedor KSP del YubiHSM.
- KSP abre una sesión segura (canal USB + conector).
- HSM calcula la firma; ADCS completa la emisión.
Si cualquier paso se interrumpe, la solicitud se mueve a Failed Requests y el sistema reintenta más tarde, generando retrasos aleatorios de “horas”.
Matriz de acciones recomendadas
| Área | Acciones recomendadas | Objetivo |
|---|---|---|
| Conectividad física | • Retirar e insertar el YubiHSM 2. • Cambiar a otro puerto USB o un hub alimentado. • Desactivar la suspensión selectiva de USB (plan de energía “Rendimiento alto”). | Confirmar alimentación y enlace estables. |
| Controladores & firmware | • Instalar el SDK y controlador más recientes. • Firmware ≥ 2.4.0 corrige pérdidas de sesión. • Re‑flashear sólo con respaldo verificado de objetos. | Eliminar incompatibilidades conocidas. |
| Carga y concurrencia | • Monitorizar “session count” con yubihsm-shell.• Escalonar la autoinscripción con políticas GPO. • Distribuir la carga a un segundo HSM (pooling). | Evitar alcanzar las 16 sesiones. |
| Registro y diagnóstico | • certutil –setreg CA\AuditFilter 0xFFFF y reinicio del servicio.• Ejecutar yubihsm-connector -vv en modo servicio.• Revisar “Microsoft‑Windows‑CAPI2/Operational”. | Aportar trazas minuto a minuto del fallo. |
| Pruebas aisladas | • certreq –submit con una sola CSR.• certutil –key para comprobar acceso a la clave.• Deshabilitar antivirus de forma temporal. | Diferenciar problema sistémico vs. carga. |
| Sistema operativo y CA | • Aplicar los CU de Windows Server. • Verificar que Pending Requests no rebasa 10 000. • Asegurar rol “Certificate Authority” aislado de otros servicios pesados. | Descartar cuellos de botella externos al HSM. |
| Buenas prácticas | • Mantener un HSM de repuesto. • Documentar procedimiento de reinicio (parada ADCS ➝ quitar HSM ➝ reinicio OS ➝ insertar HSM ➝ arrancar ADCS). • Revisar la capacidad de disipación térmica del puerto USB. | Reducir tiempo de recuperación y fallas repetitivas. |
Profundizando en las causas más frecuentes
Saturación de sesiones
El YubiHSM 2 sólo soporta 16 sesiones simultáneas. Cada CSR genera al menos una sesión; si la autoinscripción dispara cientos de peticiones por minuto, el HSM responde con ERRSESSIONFULL y el KSP lo traduce a NTEDEVICENOT_READY.
- Cómo medirlo:
yubihsm-shell --statuscada 5 s y registrar «openSessions». - Cómo corregirlo: escalonar las GPO o ampliar la ventana de validez de las plantillas para evitar picos.
Suspensión selectiva de USB
Windows Server puede apagar puertos USB inactivos. Aunque el HSM envía pulsos de mantenimiento, un plan de energía “Equilibrado” puede cortar brevemente la alimentación y provocar un re‑enumeration. Configurar “Rendimiento alto” y desactivar USB selective suspend mitiga el problema.
Firmware anterior a 2.4.0
Versiones 2.0.x–2.3.x presentaban pérdidas de referencia interna a las sesiones, especialmente bajo reconexiones rápidas. La actualización a 2.4.0 o superior elimina fugas y mejora la autonegociación USB 3.0.
Interferencia de software
Agentes de inventario, soluciones EDR o antivirus que inyectan DLLs en cada proceso pueden abrir handles al dispositivo e impedir que el connector mantenga la tubería abierta. Para descartar interferencias:
- Configura exclusión de la ruta del conector (
C:\Program Files\Yubico\YubiHSM). - Ejecuta
Process Explorery busca “yubihsm” en la columna “Handle”.
Metodología de diagnóstico paso a paso
- Captura simultánea de eventos
- Habilita Auditing completo en la CA.
- En otra ventana, corre
yubihsm-connector -vv --logfile connector.log.
- Fuerza una CSR manual con
certreq -newy analiza los tiempos de respuesta. - Correlaciona marcas de tiempo (Event Viewer vs.
connector.log). Si el error aparece antes de “HSM Response”, la causa apunta al USB/SO; si es después, al HSM. - Inspecciona la cola Failed Requests con
certutil –view –restrict "Disposition=3".- Si el patrón es aleatorio, probablemente carga; si es secuencial por segundo, sospecha firmware.
Guía de solución rápida
- Actualiza firmware y SDK.
- Aplica “Rendimiento alto” y deshabilita suspensión USB.
- Reinicia ADCS y el conector tras reinsertar el HSM.
- Reduce la ráfaga de CSR a < 10 solicitudes/s.
- Monitoriza sesiones durante 24 h.
Prevención a largo plazo
- Alta disponibilidad: empareja dos YubiHSM 2 en modo de copia de seguridad y distribuye la carga con DNS RR.
- Auditoría continua: reenvía eventos CAPI2 y logs de conector a tu SIEM para alerta temprana.
- Gestión de cambios: documenta cada actualización de firmware y valida con un CSR de prueba.
- Procedimientos escritos: ten guías de fail‑over impresas para entornos sin conexión.
Preguntas frecuentes (FAQ)
¿El error implica daño permanente del HSM?
No. Es un estado transitorio; al restaurarse la alimentación o liberarse las sesiones, el mismo dispositivo vuelve a funcionar.
¿Puedo aumentar el límite de 16 sesiones?
No. Es una restricción de diseño del chip. La única estrategia es balancear la carga con otro HSM o reducir la simultaneidad.
¿Qué registros enviar a Yubico al abrir un ticket?
connector.logcon-vvactivado.- Exportación del visor de eventos (Application y CAPI2).
- Salida de
certutil -v -verify requestID.
Conclusión
El código 0x880090030, pese a su apariencia crítica, casi siempre apunta a una combinación de saturación de sesiones y microcortes USB. Mantener firmware actualizado, vigilar el contador de sesiones y desactivar la suspensión selectiva son las palancas más eficaces para devolver la CA a un estado saludable sin reemplazar hardware ni reinstalar ADCS.