NTE_DEVICE_NOT_READY sur Microsoft CA avec YubiHSM 2 : diagnostic, correctifs et bonnes pratiques

Votre AC Microsoft émet en pointillé ? L’erreur 0x880090030 / NTE_DEVICE_NOT_READY sur YubiHSM 2 signale le plus souvent un goulot d’étranglement temporaire. Voici un guide terrain pour diagnostiquer, stabiliser et durcir l’architecture.

Sommaire

Problématique rencontrée

Une infrastructure PKI Microsoft (AD CS) avec racine hors‑ligne et plusieurs sous‑AC en ligne utilise des clés protégées dans des YubiHSM 2 directement enchâssés en USB sur chaque serveur. Lors d’une campagne d’auto‑inscription (auto‑enrollment), la file Failed Requests se remplit ; l’erreur la plus fréquente est 0x880090030 / NTE_DEVICE_NOT_READY. Après plusieurs minutes ou heures, les certificats finissent toutefois par être émis, ce qui pointe vers une indisponibilité transitoire du HSM (surcharge, veille USB, pilotes) plutôt qu’une panne matérielle.

Ce que signifie vraiment NTE_DEVICE_NOT_READY

Dans le pipeline de signature, AD CS s’appuie sur le Key Storage Provider (KSP) YubiHSM, qui dialogue avec le service YubiHSM Connector pour piloter le HSM. Si le HSM ne répond pas dans le délai imparti ou ne peut pas accepter de nouvelle session (par exemple lorsque le seuil de sessions simultanées ~16 est atteint), le KSP renvoie une erreur de type device not ready. Le symptôme apparaît typiquement pendant des pics d’auto‑enroll, quand des dizaines ou centaines de clients déclenchent presque simultanément des signatures côté CA (émission, CRL/AIA, journaux d’audit signés, etc.).

Symptômes typiques côté AC et côté HSM

File Failed Requests qui se remplit par vagues, puis se résorbe d’elle‑même.
Émissions “en dents de scie” : périodes de silence suivies de rattrapages massifs.
Événements d’auto‑inscription côté postes : demandes en attente puis retry réussi.
Journal du YubiHSM Connector montrant des ouvertures/fermetures de sessions très rapprochées.
Événements AD CS montrant des délais d’accès au fournisseur de clés ou des erreurs 0x8010001d, 0x8010006e en cascade.

Check‑list d’intervention rapide

Couche physique : rebrancher le HSM, essayer un autre port USB (de préférence à l’arrière du châssis), désactiver la suspension sélective USB sur le serveur.
Logiciels : mettre à jour le YubiHSM 2 SDK (pilotes, KSP/CSP) et le firmware HSM si < 2.4.x.
Charge : réduire ou échelonner la fréquence d’auto‑enroll, répartir les demandes sur plusieurs sous‑AC/HSM.
Observabilité : activer la journalisation détaillée AD CS et le mode -d de yubihsm-shell pour voir les sessions et les erreurs en temps réel.
Conflits : fermer tout outil tiers susceptible de monopoliser le HSM (ex. yubihsm-shell laissé ouvert, agent SSH utilisant la même clé).

Pistes et solutions proposées

Axe d’investigation	Actions concrètes
Connexion et alimentation USB	– Débrancher / rebrancher le HSM ; – Essayer un port USB différent et désactiver la mise en veille sélective USB dans les Options d’alimentation Windows.
Pilotes et firmwares	– Installer la dernière version du YubiHSM 2 SDK (pilote + KSP/CSP) ; – Mettre à jour le firmware du HSM si < 2.4.x.
Charges et sessions	– Le YubiHSM 2 tolère ~16 sessions simultanées ; lors de pics d’auto‑enroll, ce seuil peut être atteint. → Réduire la fréquence d’auto‑inscription (« Enrollment Refresh Interval » dans la GPO) ou répartir la charge sur plusieurs sous‑AC/HSM.
Journalisation avancée	– Passer le service CertSvc en mode diagnostic : `certutil -setreg ca\loglevel 4` puis redémarrer le service. – Activer le log Microsoft‑Windows‑CertificateServicesClient‑AutoEnrollment/Operational. – Lancer `yubihsm-shell -d` (mode debug) pour surveiller les sessions et les erreurs côté HSM.
Intégrité de l’AC	– Vérifier la santé globale dans PKIView.msc. – Examiner l’EventLog Application & Services Logs → Microsoft → Windows → CertificateServices‑* pour repérer d’autres codes d’erreur (0x8010001d, 0x8010006e, etc.).
Conflits logiciels	Fermer tout outil susceptible de monopoliser le HSM (p. ex. `yubihsm-shell` ou un agent SSH utilisant la même clé).
Redémarrage contrôlé	Si aucune demande n’est traitée, redémarrer proprement le service Active Directory Certificate Services puis, en dernier recours, le serveur.

Architecture et points de contention

Sur une sous‑AC, les chemins critiques sont :

AD CS (CertSvc) → CNG/KSP YubiHSM → YubiHSM Connector (TCP localhost:12345) → YubiHSM&nbsp;2 (USB)

YubiHSM Connector sert d’intermédiaire entre le KSP et le HSM. Il doit démarrer avant AD CS et rester stable. Configurez son service pour redémarrage automatique en cas d’échec.
Sessions : chaque signature peut ouvrir une session. Si de multiples processus (auto‑enroll, CRL, audits, outils d’admin) sollicitent le HSM, on peut atteindre la limite de ~16 sessions.
Tempête d’auto‑enroll : un déploiement GPO, une bascule réseau ou un redémarrage de masse peut déclencher des milliers de demandes quasi simultanées.

Réglages côté Windows pour stabiliser la couche USB

Options d’alimentation

Ouvrez Options d’alimentation > Modifier les paramètres du mode > Modifier les paramètres d’alimentation avancés.
Dans Paramètres USB, mettez Paramètre de suspension sélective USB = Désactivé.

Gestionnaire de périphériques

Dans Contrôleurs de bus USB, ouvrez chaque Concentrateur USB (racine).
Dans l’onglet Gestion de l’alimentation, décochez Autoriser l’ordinateur à éteindre ce périphérique pour économiser l’énergie.

Virtualisation

Si la sous‑AC est virtualisée et le YubiHSM mappé via USB passthrough, désactivez la suspension sur l’hôte et privilégiez des ports USB 2.0 stables. Évitez les hubs ou rallonges non alimentés.

Journalisation et observabilité approfondies

AD CS en mode diagnostic

REM Augmente le niveau de log
certutil -setreg ca\loglevel 4
net stop certsvc &amp;&amp; net start certsvc

Ce réglage rend visibles les délais côté fournisseur de clés et les erreurs de session.

Journaux d’auto‑inscription clients

Activez Microsoft‑Windows‑CertificateServicesClient‑AutoEnrollment/Operational pour suivre les vagues de demandes. Relevez l’horodatage des pics et corrélez‑le aux erreurs KSP côté AC.

Surveillance HSM côté système

REM Mode debug de la shell
yubihsm-shell -d
REM Connexion au connector local (exemple)
connect --host 127.0.0.1 --port 12345
REM Ouvrez une session avec la clé d’auth appropriée (exemple)
session open 1 password: ********

Le mode -d affiche les ouvertures/fermetures de sessions et met en évidence les timeouts. Évitez d’exécuter ces commandes pendant un pic si vous suspectez déjà la saturation ; sinon, vous ajoutez de la contention.

Réduire et lisser la charge d’auto‑inscription

Le principe : moins de rafales, plus de flux.

Échelonnez les déploiements GPO par OU ou par site AD afin d’éviter qu’un trop grand nombre de clients déclenchent l’auto‑enroll dans la même fenêtre.
Ajustez l’intervalle de rafraîchissement de l’auto‑inscription (Enrollment Refresh Interval) afin d’espacer les relances, notamment lors de vagues de renouvellement.
Répartissez les modèles : affectez certains certificate templates à des sous‑AC différentes pour distribuer les signatures.
Planifiez les renouvellements hors heures ouvrées quand c’est possible (renouvellement par seuil plutôt que “dernier jour”).

Bonnes pratiques KSP/CSP et matrice clé‑usage

Réutilisation de session : évitez les scénarios où chaque signature force un nouvel handle/une nouvelle session HSM. Préférez la réutilisation quand le flux le permet, surtout pour la CA.
Signer vs. chiffrement : vérifiez que les modèles utilisent l’algorithme et la taille de clé attendus (ex. RSA 3072/4096 ou ECC), afin d’éviter des chemins logiciels inattendus ou des conversions coûteuses.
Clé unique dédiée à la CA : évitez de partager un même YubiHSM pour des usages “annexes” (agents SSH, signatures de code) sur la même machine que la CA.

Détection et élimination des conflits logiciels

Fermez yubihsm-shell si une session interactive a été laissée ouverte.
Désactivez temporairement tout service tiers consommateur du HSM (ex. agent, script d’inventaire) pendant les fenêtres d’émission.
Vérifiez que vous n’avez pas plusieurs connecteurs pointant sur un même HSM avec des applications distinctes qui s’entre‑choquent.

Durcissement des services

YubiHSM Connector : démarrage automatique différé, stratégie de récupération “redémarrer le service” sur 1^er et 2^e échec, délai raisonnable avant nouvelle tentative.
CertSvc : vérifiez l’ordre de démarrage (dépendance implicite au connector). En cas de besoin, ajoutez une logique de vérification (script de santé) au boot pour garantir que le port local est ouvert avant le démarrage de l’AC.

Plan de test ciblé

Avant pic : capturez 15 à 30 min de base (logs AD CS niveau 4, journaux connector, compteur CPU/IO).
Pic simulé : déclenchez un lot contrôlé de demandes (quelques dizaines) et observez : temps moyen de signature, sessions ouvertes, montée d’erreurs.
Après correctifs : rejouez le test et comparez. L’objectif : temps de réponse stable, aucune erreur NTE_DEVICE_NOT_READY.

Playbook d’incident

T0 : constater la montée d’échecs dans Failed Requests.
T+5 min : vérifier que YubiHSM Connector est Running, port local écouté, aucune session zombie évidente.
T+10 min : basculer CertSvc en loglevel 4, activer le yubihsm-shell -d sur un autre serveur d’admin (pour ne pas ajouter de charge si possible) et observer les sessions.
T+15 min : si erreurs en continu et absence de traitement en cours, redémarrer CertSvc proprement (hors production si possible).
T+20 min : rebrancher le HSM sur un port USB alternatif et verrouiller la configuration d’alimentation.
T+30 min : si récurrence, planifier l’échelonnement des GPO et/ou l’ajout d’un second HSM.

Capacité et dimensionnement

Le dimensionnement se raisonne en signatures par seconde soutenues par une sous‑AC et en sessions ouvertes. Quelques repères pratiques :

Sur YubiHSM 2, ~16 sessions concurrentes est un plafond réaliste ; au‑delà, vous verrez des timeouts.
Un pic court mais intense peut suffire à franchir la limite si l’AC signe en rafale (CRL, lots d’émissions, audits).
Préférez plusieurs sous‑AC avec des HSM distincts plutôt qu’une AC “monolithique” unique.

Scalabilité et haute disponibilité

Deux YubiHSM 2 en miroir : dupliquez les objets clés via fonctionnalités de wrap/miroir pour disposer d’un HSM de secours et/ou partager la charge.
YubiHSM 2 Network : une appliance réseau supprime les limites du bus USB et simplifie la mise en HA active/active.
Sous‑AC passive : gardez une CA prête à basculer avec clés synchronisées, gabarits publiés et CRL/OCSP opérationnels.

Procédures détaillées

Mettre à jour pilotes et KSP

Désinstallez les composants obsolètes du SDK le cas échéant.
Installez la dernière mouture du YubiHSM 2 SDK (KSP/CSP, connector, outils).
Redémarrez le serveur et validez l’énumération des clés :
certutil -csp "YubiHSM Key Storage Provider" -key

Mettre à jour le firmware HSM (< 2.4.x)

Planifiez la fenêtre : aucune demande ne doit être en cours de traitement.
Suivez la procédure de mise à jour fournie avec le SDK. Vérifiez l’intégrité avant/après et testez une signature de contrôle.

Activer/inspecter les journaux pertinents

AD CS : certutil -setreg ca\loglevel 4, redémarrage CertSvc.
Auto‑Enrollment (clients) : journal Operational dédié.
YubiHSM Connector : journal du service (chemin ProgramData) ; recherchez “session”, “timeout”, “disconnect”.

Analyse des erreurs récurrentes

Code	Contexte probable	Action
`0x880090030 / NTE_DEVICE_NOT_READY`	HSM non prêt, saturation ou délai dépassé	Lisser la charge, vérifier sessions, alimentation USB, mises à jour SDK/firmware
`0x8010001d`	Carte/HSM non responsive ou retiré logiquement	Rebrancher, changer de port, vérifier connector
`0x8010006e`	Time‑out d’accès au dispositif ou protocole	Augmenter la stabilité USB, réduire le parallélisme

Sécurité opérationnelle

Anti‑bruteforce : le YubiHSM 2 peut ralentir après n tentatives erronées. Assurez‑vous qu’aucun script d’audit ou d’inventaire n’encombre le HSM pendant les pics.
Droits minimaux : les clés d’authentification HSM utilisées par l’AC doivent être cloisonnées (domaines, capacités) et stockées en coffre.
Journal d’audit : activez l’audit HSM et archivez‑le hors de la machine pour pouvoir corréler charge et événements.

Plan de continuité et reprise

Procédure documentée : séquencez précisément la relève (sous‑AC passive, commutation d’enregistrements AIA/CRL, validation de chaîne).
Clés de secours : conservez une copie sécurisée (wrap/mirror) des clés critiques, avec test périodique de restauration.
Exercices : testez chaque trimestre la bascule contrôlée pour vérifier que l’outillage et l’équipe sont prêts.

Cas réels et tactiques pratiques

Vague de renouvellement à J‑30 : étalez le renouvellement via politiques et OU, et avancez marginalement l’échéance de certains modèles pour lisser le flux.
Montée en charge saisonnière : prévoyez une sous‑AC additionnelle temporaire équipée d’un HSM miroir, puis retirez‑la après la pointe.
Maintenance HSM : placez l’AC en Pause (si votre processus le permet), vidangez la file et exécutez la mise à jour hors pointe.

Procédures de redémarrage contrôlé

Vérifiez qu’aucune demande n’est en cours (Pending Requests vidée ou stable).
net stop certsvc, attendez l’arrêt complet du service.
Redémarrez le YubiHSM Connector si nécessaire, validez l’écoute du port local.
net start certsvc et surveillez immédiatement les journaux pour capturer la phase de ré‑initialisation des sessions.

FAQ rapide

Faut‑il remplacer le HSM ? Rarement. La majorité des cas sont liés à des timeouts dus à la charge ou à l’économie d’énergie USB.

Augmenter la taille de clé aggrave‑t‑il le problème ? Potentiellement : les signatures plus lourdes augmentent le temps de maintien des sessions. Dimensionnez en conséquence ou lissez la charge.

Un second YubiHSM sur le même serveur aide‑t‑il ? Oui, si les clés sont correctement “miroirées” et si le KSP/connector distribue des sessions sur les deux dispositifs. À défaut, positionnez un second HSM sur une sous‑AC dédiée.

Exemples de commandes utiles

REM Vérifier les clés visibles par le KSP
certutil -csp "YubiHSM Key Storage Provider" -key

REM Activer les logs AD CS verbeux et redémarrer
certutil -setreg ca\loglevel 4
net stop certsvc && net start certsvc

REM Démarrer la shell HSM en debug
yubihsm-shell -d

REM Vérifier l’écoute du connector local
netstat -ano | findstr 12345

Compléments utiles

Matrice clé‑usage : assurez‑vous qu’aucune stratégie ne force l’AC à créer un nouveau handle de clé pour chaque signature ; avec un HSM matériel, préférez la réutilisation de la session.
Sécurité : le YubiHSM 2 peut être configuré pour verrouiller ou ralentir les opérations après n tentatives erronées. Vérifiez qu’aucun script d’audit ou d’inventaire n’exécute des commandes HSM parasites pendant les pics.
Scalabilité : sur les sous‑AC à fort trafic, envisagez jusqu’à deux YubiHSM 2 en cluster HA (fonction de miroir) ou migrez vers une appliance réseau (YubiHSM 2 Network) pour éliminer les limites USB.
Plan de continuité : documentez une procédure de relève (clé de secours ou sous‑AC passive) afin d’éviter les interruptions en cas de défaillance matériel.

Checklist de validation après remédiation

Plus aucune occurrence de NTE_DEVICE_NOT_READY en période chargée.
Courbe d’émission régulière (pas de “dents de scie”).
Journaux connector et AD CS propres, sans timeouts.
Échantillon d’auto‑inscriptions terminées sans réessais côté clients.

Synthèse rapide

Le code NTE_DEVICE_NOT_READY indique que le YubiHSM 2 n’a pas pu répondre dans le délai imparti — généralement à cause d’un trop grand nombre de sessions simultanées ou d’un problème de connectique/driver. Mettez à jour le firmware et les pilotes, augmentez la journalisation, réduisez le débit d’auto‑enroll ou répartissez la charge, et surveillez en temps réel les sessions HSM ; ces mesures suffisent dans la majorité des environnements Microsoft CA à éliminer le phénomène ou, à défaut, à identifier la cause précise.

En appliquant ces mesures — du câblage USB jusqu’au dimensionnement de l’architecture — vous transformez un incident récurrent en opportunité d’industrialiser la PKI : plus stable, plus observable, et plus résiliente.

NTE_DEVICE_NOT_READY sur Microsoft CA avec YubiHSM 2 : diagnostic, correctifs et bonnes pratiques