Windows 11 Pro – Hyper-V vTPM : erreur 0x80090016 (NTE_BAD_KEYSET) lors de la création du protecteur local

Question

Windows 11 Pro – Hyper-V vTPM : erreur 0x80090016 (NTE_BAD_KEYSET) lors de la création du protecteur local

Zahir AKHENAK 0

Bonjour,

Je recherche une assistance technique spécialisée pour résoudre un dysfonctionnement du TPM virtuel (vTPM) d'Hyper-V sur un ordinateur Windows 11 Pro.

Après plusieurs journées de diagnostic, je n'ai pas réussi à identifier de procédure de réparation adaptée à mon environnement.

1. Configuration

Système hôte : Windows 11 Pro, build 26300.9711.

Processeur : AMD Ryzen 7 5700X.

Mémoire : 32 Go.

Hyper-V activé et fonctionnel.

Machine virtuelle de génération 2, nouvellement créée.

Démarrage sécurisé activé.

TPM physique fonctionnel.

Configuration Host Guardian Service (HGS) en mode Local.

Aucun serveur HGS distant ni cluster Windows Server.

La VM est arrêtée et le système invité Windows 11 n'est pas encore installé.

2. Problème rencontré

La commande suivante échoue systématiquement :

Set-VMKeyProtector -VMName 'BOT-TRADING-LAB' -NewLocalKeyProtector -ErrorAction Stop

Message d'erreur :

Échec de la définition du protecteur de clé.

Échec de la signature d'un certificat dans l'encapsulation.
Tentative de signature du certificat : « Signing ».

Les journaux CAPI2 ont également enregistré :

0x80090016 — NTE_BAD_KEYSET
Le jeu de clés n'existe pas.

Le paramètre -NewLocalKeyProtector a été vérifié avec Get-Command Set-VMKeyProtector -Syntax. Il est bien reconnu.

3. Diagnostics déjà effectués

Les vérifications suivantes ont réussi :

TPM physique : présent et opérationnel.

Services Hyper-V : fonctionnels.

Intégrité du magasin de composants Windows : aucune corruption détectée par DISM après réparation du système.

Création d'une clé RSA CNG temporaire : réussie.

Création et réouverture d'une clé RSA persistante de machine avec Microsoft Software Key Storage Provider : réussies.

Signature et vérification RSA avec cette clé : réussies.

Création de deux nouveaux certificats RSA dédiés : réussie.

Signature RSA avec le premier certificat : réussie.

Chiffrement et déchiffrement RSA avec le second certificat : réussis.

Cependant, les opérations suivantes échouent :

Set-VMKeyProtector -NewLocalKeyProtector.

New-HgsGuardian -GenerateCertificates.

Création d'un Guardian avec les empreintes des nouveaux certificats.

Création d'un Guardian à partir de fichiers PFX contenant les nouveaux certificats et leurs clés privées.

Toutes les tentatives de création du Guardian échouent malgré les tests RSA indépendants réussis.

4. Configuration HGS

La commande :

Get-HgsClientConfiguration

retourne notamment :

Mode              : Local
AttestationStatus : Passed
IsHostGuarded     : False

La commande :

Get-HgsGuardian

ne retourne aucun Guardian enregistré.

5. Observations sur les certificats

Le magasin Shielded VM Local Certificates contenait plusieurs certificats issus des tentatives de génération automatique.

Un certificat Shielded VM Signing Certificate (UntrustedGuardian) a été identifié comme présentant une clé privée inaccessible.

Le fournisseur déclaré est :

Microsoft Software Key Storage Provider

La tentative d'ouverture de son conteneur avec certutil renvoyait :

0x80090016 — NTE_BAD_KEYSET

Le fichier correspondant existait dans le stockage CNG de Windows. Les autorisations NTFS accordaient le contrôle total à SYSTEM.

Cependant, le fournisseur ne parvenait pas à charger cette clé.

Des événements CAPI2 ont également montré des échecs d'accès à des clés privées dans le processus WmiPrvSE.exe.

6. Tentative de réparation déjà réalisée

Après inventaire des VM et sauvegarde des certificats publics et des informations du magasin, j'ai supprimé uniquement le certificat UntrustedGuardian dont l'échec d'accès à la clé avait été confirmé.

La suppression a réussi.

Cependant, une nouvelle tentative de :

Set-VMKeyProtector -VMName 'BOT-TRADING-LAB' -NewLocalKeyProtector

a reproduit exactement la même erreur de signature cryptographique.

Je n'ai supprimé aucun autre certificat.

7. Précisions importantes

Une seule VM est actuellement enregistrée dans Hyper-V.

Cette VM est arrêtée, de génération 2, avec vTPM désactivé.

Le problème existait avant la mise à niveau récente de Windows.

Les tests RSA/CNG indépendants ont été effectués dans une session PowerShell administrateur.

Le bon fonctionnement du même mécanisme cryptographique sous tous les contextes de service Hyper-V n'a pas été démontré.

Les journaux CAPI2, HGS et Hyper-V sont disponibles.

8. Assistance recherchée

Je souhaiterais obtenir l'avis d'un spécialiste Hyper-V / Host Guardian Service / cryptographie CNG sur les questions suivantes :

Quelle pourrait être la cause de l'erreur de signature Signing lorsque les tests RSA/CNG indépendants réussissent ?

Comment identifier précisément le certificat ou le conteneur cryptographique utilisé par Set-VMKeyProtector -NewLocalKeyProtector ?

Existe-t-il une procédure Microsoft documentée permettant de réparer les composants locaux HGS/vTPM sous Windows 11 Pro ?

Peut-on réparer ce mécanisme sans réinitialiser le TPM physique ni supprimer l'ensemble des clés cryptographiques système ?

Je souhaite privilégier une réparation ciblée qui préserve les données et les protections cryptographiques existantes.

Toute recommandation technique documentée serait appréciée.

Merci pour votre aide.Bonjour,

Je recherche une assistance technique spécialisée pour résoudre un dysfonctionnement du TPM virtuel (vTPM) d'Hyper-V sur un ordinateur Windows 11 Pro.

Après plusieurs journées de diagnostic, je n'ai pas réussi à identifier de procédure de réparation adaptée à mon environnement.

1. Configuration

Système hôte : Windows 11 Pro, build 26300.9711.

Processeur : AMD Ryzen 7 5700X.

Mémoire : 32 Go.

Hyper-V activé et fonctionnel.

Machine virtuelle de génération 2, nouvellement créée.

Démarrage sécurisé activé.

TPM physique fonctionnel.

Configuration Host Guardian Service (HGS) en mode Local.

Aucun serveur HGS distant ni cluster Windows Server.

La VM est arrêtée et le système invité Windows 11 n'est pas encore installé.

2. Problème rencontré

La commande suivante échoue systématiquement :

Set-VMKeyProtector -VMName 'BOT-TRADING-LAB' -NewLocalKeyProtector -ErrorAction Stop

Message d'erreur :

Échec de la définition du protecteur de clé.

Échec de la signature d'un certificat dans l'encapsulation.
Tentative de signature du certificat : « Signing ».

Les journaux CAPI2 ont également enregistré :

0x80090016 — NTE_BAD_KEYSET
Le jeu de clés n'existe pas.

Le paramètre -NewLocalKeyProtector a été vérifié avec Get-Command Set-VMKeyProtector -Syntax. Il est bien reconnu.

3. Diagnostics déjà effectués

Les vérifications suivantes ont réussi :

TPM physique : présent et opérationnel.

Services Hyper-V : fonctionnels.

Intégrité du magasin de composants Windows : aucune corruption détectée par DISM après réparation du système.

Création d'une clé RSA CNG temporaire : réussie.

Création et réouverture d'une clé RSA persistante de machine avec Microsoft Software Key Storage Provider : réussies.

Signature et vérification RSA avec cette clé : réussies.

Création de deux nouveaux certificats RSA dédiés : réussie.

Signature RSA avec le premier certificat : réussie.

Chiffrement et déchiffrement RSA avec le second certificat : réussis.

Cependant, les opérations suivantes échouent :

Set-VMKeyProtector -NewLocalKeyProtector.

New-HgsGuardian -GenerateCertificates.

Création d'un Guardian avec les empreintes des nouveaux certificats.

Création d'un Guardian à partir de fichiers PFX contenant les nouveaux certificats et leurs clés privées.

Toutes les tentatives de création du Guardian échouent malgré les tests RSA indépendants réussis.

4. Configuration HGS

La commande :

Get-HgsClientConfiguration

retourne notamment :

Mode              : Local
AttestationStatus : Passed
IsHostGuarded     : False

La commande :

Get-HgsGuardian

ne retourne aucun Guardian enregistré.

5. Observations sur les certificats

Le magasin Shielded VM Local Certificates contenait plusieurs certificats issus des tentatives de génération automatique.

Un certificat Shielded VM Signing Certificate (UntrustedGuardian) a été identifié comme présentant une clé privée inaccessible.

Le fournisseur déclaré est :

Microsoft Software Key Storage Provider

La tentative d'ouverture de son conteneur avec certutil renvoyait :

0x80090016 — NTE_BAD_KEYSET

Le fichier correspondant existait dans le stockage CNG de Windows. Les autorisations NTFS accordaient le contrôle total à SYSTEM.

Cependant, le fournisseur ne parvenait pas à charger cette clé.

Des événements CAPI2 ont également montré des échecs d'accès à des clés privées dans le processus WmiPrvSE.exe.

6. Tentative de réparation déjà réalisée

Après inventaire des VM et sauvegarde des certificats publics et des informations du magasin, j'ai supprimé uniquement le certificat UntrustedGuardian dont l'échec d'accès à la clé avait été confirmé.

La suppression a réussi.

Cependant, une nouvelle tentative de :

Set-VMKeyProtector -VMName 'BOT-TRADING-LAB' -NewLocalKeyProtector

a reproduit exactement la même erreur de signature cryptographique.

Je n'ai supprimé aucun autre certificat.

7. Précisions importantes

Une seule VM est actuellement enregistrée dans Hyper-V.

Cette VM est arrêtée, de génération 2, avec vTPM désactivé.

Le problème existait avant la mise à niveau récente de Windows.

Les tests RSA/CNG indépendants ont été effectués dans une session PowerShell administrateur.

Le bon fonctionnement du même mécanisme cryptographique sous tous les contextes de service Hyper-V n'a pas été démontré.

Les journaux CAPI2, HGS et Hyper-V sont disponibles.

8. Assistance recherchée

Je souhaiterais obtenir l'avis d'un spécialiste Hyper-V / Host Guardian Service / cryptographie CNG sur les questions suivantes :

Quelle pourrait être la cause de l'erreur de signature Signing lorsque les tests RSA/CNG indépendants réussissent ?

Comment identifier précisément le certificat ou le conteneur cryptographique utilisé par Set-VMKeyProtector -NewLocalKeyProtector ?

Existe-t-il une procédure Microsoft documentée permettant de réparer les composants locaux HGS/vTPM sous Windows 11 Pro ?

Peut-on réparer ce mécanisme sans réinitialiser le TPM physique ni supprimer l'ensemble des clés cryptographiques système ?

Je souhaite privilégier une réparation ciblée qui préserve les données et les protections cryptographiques existantes.

Toute recommandation technique documentée serait appréciée.

Merci pour votre aide.

0 commentaires

4 réponses

Votre réponse

Answer 1

Bonjour Zahir AKHENAK,

D’après les diagnostics que vous avez fournis, le constat le plus important est que les commandes Set-VMKeyProtector -NewLocalKeyProtector et New-HgsGuardian -GenerateCertificates échouent toutes les deux, alors que les opérations RSA/CNG indépendantes fonctionnent correctement. Cela laisse penser que le problème est probablement circonscrit à l’infrastructure des machines virtuelles protégées (Shielded VMs) Hyper-V, au mode local de HGS (Host Guardian Service) ou au processus de gestion des certificats, plutôt qu’à une défaillance générale du TPM ou du sous-système cryptographique.

L’erreur 0x80090016 (NTE_BAD_KEYSET) indique généralement qu’un certificat ou un conteneur de clés référencé par l’infrastructure Shielded VM est présent dans la configuration, mais que le fournisseur cryptographique ne parvient plus à y accéder dans le contexte de sécurité utilisé par les services Hyper-V.

Le certificat « Shielded VM Signing Certificate (UntrustedGuardian) » auquel vous ne parvenez pas à accéder mérite une attention particulière. Sa présence peut indiquer que d’autres certificats liés aux guardians, des conteneurs de clés ou des métadonnées présentent encore des incohérences, même après la suppression du certificat concerné.

Je vous recommande d’examiner conjointement les journaux opérationnels de Hyper-V VMMS, du Host Guardian Service et de CAPI2 afin d’identifier précisément l’empreinte du certificat ou le conteneur de clés référencé au moment de l’échec de l’opération de signature.

Étant donné que le problème existait déjà avant la mise à niveau de Windows et que le TPM physique semble fonctionner correctement, je privilégierais dans un premier temps la réparation ou la reconstruction de la configuration locale HGS/Guardian, plutôt que la réinitialisation du TPM ou une intervention plus large sur le sous-système cryptographique.

Cette approche ciblée offre les meilleures chances de préserver les ressources cryptographiques existantes tout en corrigeant l’incohérence du jeu de clés qui semble empêcher le provisionnement du vTPM.

J’espère que ces informations vous aideront à mieux comprendre le problème et à orienter vos investigations. Si cette réponse vous a été utile, veuillez cliquer sur « Accept Answer » afin de confirmer qu’elle répond à votre question.

Jason

Answer 2

Hello Jason,

Thank you for your previous response and your recommendations regarding the local Hyper-V Guardian and cryptographic infrastructure.

I would like to provide additional diagnostic findings. Unfortunately, the issue remains unresolved.

1. Reproduced on two independent virtual machines

The error was reproduced on my main Generation 2 VM (BOT-TRADING-LAB) and on a newly created diagnostic Generation 2 VM (HYPERV-VTPM-DIAGNOSTIC).

The diagnostic VM had no virtual hard disk, network adapter or guest operating system.

Running:

Set-VMKeyProtector -VMName "HYPERV-VTPM-DIAGNOSTIC" -NewLocalKeyProtector -ErrorAction Stop

failed with the same certificate-signing error.

The temporary VM was subsequently deleted.

This suggests a host-level issue rather than a problem specific to the original VM.

2. Local Guardian creation fails with 0x80090016

I tested the creation of a local Guardian using two existing RSA 2048-bit certificates.

Both certificates successfully passed private-key operations, including digital signature verification and encryption/decryption.

However, executing:

New-HgsGuardian -Name "BOT-TRADING-LAB-RECOVERY-GUARDIAN" -SigningCertificateThumbprint <SIGNING_THUMBPRINT> -EncryptionCertificateThumbprint <ENCRYPTION_THUMBPRINT> -AllowUntrustedRoot -ErrorAction Stop

fails with:

HRESULT 0x80090016 — NTE_BAD_KEYSET

After the failure, Get-HgsGuardian returns no registered Guardian.

3. Certificate findings

The local Shielded VM certificate store contains 15 certificates.

Two older Guardian certificates fail private-key access with:

0x80090014 — NTE_BAD_PROV_TYPE

Two separately created RSA 2048-bit certificates work correctly when tested from elevated PowerShell.

All four certificates report the Microsoft Software Key Storage Provider.

The working certificates use self-issued certificates, and their private keys have been exported into password-protected PFX backups.

4. WMI investigation

The Windows WMI Activity log contains the following events:

Event 5857

Provider: HgsClientWmi

Host process: wmiprvse.exe

Provider DLL: HgsClientWmi.dll

Provider initialization result: 0x0

Event 5858

Operation: MSFT_HgsGuardian::NewByCertificateThumbprints

Result: 0x80041001

The PowerShell command simultaneously reports 0x80090016.

Inspection of HgsClient.psm1 confirms that New-HgsGuardian calls the CIM method NewByCertificateThumbprints.

5. Additional checks

Windows 11 Pro with Hyper-V enabled.

HGS client configuration: Local mode.

Hyper-V VMMS service starts successfully.

CryptSvc, KeyIso and VaultSvc are running.

No Guardian is registered.

The original VM's key protector returns only four bytes.

The vTPM remains disabled.

CAPI2 records some unrelated or not-yet-correlated certificate revocation errors (0x80092013).

No CAPI2 events were found within 10 seconds before or after the recorded WMI failure.

6. Data preservation

Before investigating further, I exported the original VM.

A second copy was stored on a separate internal BitLocker-protected drive.

All six exported files were compared using SHA-256, and their hashes matched.

A full restoration test has not yet been performed.

7. Request for a targeted Microsoft repair procedure

Could you please advise on the following?

Why might HgsClientWmi report NTE_BAD_KEYSET when the same certificates can perform RSA operations successfully in elevated PowerShell?

Could the issue involve the security context of wmiprvse.exe, CNG key-container permissions or the local HGS configuration?

Which additional ETW traces or Microsoft diagnostic tools would help identify the failing cryptographic operation?

Is there a supported procedure to repair or reconstruct the local Guardian registration without deleting existing certificates or cryptographic keys?

Is there a Windows 11 Pro-specific recovery procedure that avoids clearing the physical TPM, resetting cryptographic key stores or reinstalling Windows?

I would appreciate a documented, targeted and reversible procedure.

For safety reasons, I have suspended further modifications to the Guardian configuration until the underlying issue has been identified.

Thank you again for your assistance.

Answer 3

Hello Jason,

Thank you for your previous response and your recommendations regarding the local Hyper-V Guardian and cryptographic infrastructure.

I would like to provide additional diagnostic findings. Unfortunately, the issue remains unresolved.

1. Reproduced on two independent virtual machines

The error was reproduced on my main Generation 2 VM (BOT-TRADING-LAB) and on a newly created diagnostic Generation 2 VM (HYPERV-VTPM-DIAGNOSTIC).

The diagnostic VM had no virtual hard disk, network adapter or guest operating system.

Running:

Set-VMKeyProtector -VMName "HYPERV-VTPM-DIAGNOSTIC" -NewLocalKeyProtector -ErrorAction Stop

failed with the same certificate-signing error.

The temporary VM was subsequently deleted.

This suggests a host-level issue rather than a problem specific to the original VM.

2. Local Guardian creation fails with 0x80090016

I tested the creation of a local Guardian using two existing RSA 2048-bit certificates.

Both certificates successfully passed private-key operations, including digital signature verification and encryption/decryption.

However, executing:

New-HgsGuardian -Name "BOT-TRADING-LAB-RECOVERY-GUARDIAN" -SigningCertificateThumbprint <SIGNING_THUMBPRINT> -EncryptionCertificateThumbprint <ENCRYPTION_THUMBPRINT> -AllowUntrustedRoot -ErrorAction Stop

fails with:

HRESULT 0x80090016 — NTE_BAD_KEYSET

After the failure, Get-HgsGuardian returns no registered Guardian.

3. Certificate findings

The local Shielded VM certificate store contains 15 certificates.

Two older Guardian certificates fail private-key access with:

0x80090014 — NTE_BAD_PROV_TYPE

Two separately created RSA 2048-bit certificates work correctly when tested from elevated PowerShell.

All four certificates report the Microsoft Software Key Storage Provider.

The working certificates use self-issued certificates, and their private keys have been exported into password-protected PFX backups.

4. WMI investigation

The Windows WMI Activity log contains the following events:

Event 5857

Provider: HgsClientWmi

Host process: wmiprvse.exe

Provider DLL: HgsClientWmi.dll

Provider initialization result: 0x0

Event 5858

Operation: MSFT_HgsGuardian::NewByCertificateThumbprints

Result: 0x80041001

The PowerShell command simultaneously reports 0x80090016.

Inspection of HgsClient.psm1 confirms that New-HgsGuardian calls the CIM method NewByCertificateThumbprints.

5. Additional checks

Windows 11 Pro with Hyper-V enabled.

HGS client configuration: Local mode.

Hyper-V VMMS service starts successfully.

CryptSvc, KeyIso and VaultSvc are running.

No Guardian is registered.

The original VM's key protector returns only four bytes.

The vTPM remains disabled.

CAPI2 records some unrelated or not-yet-correlated certificate revocation errors (0x80092013).

No CAPI2 events were found within 10 seconds before or after the recorded WMI failure.

6. Data preservation

Before investigating further, I exported the original VM.

A second copy was stored on a separate internal BitLocker-protected drive.

All six exported files were compared using SHA-256, and their hashes matched.

A full restoration test has not yet been performed.

7. Request for a targeted Microsoft repair procedure

Could you please advise on the following?

Why might HgsClientWmi report NTE_BAD_KEYSET when the same certificates can perform RSA operations successfully in elevated PowerShell?

Could the issue involve the security context of wmiprvse.exe, CNG key-container permissions or the local HGS configuration?

Which additional ETW traces or Microsoft diagnostic tools would help identify the failing cryptographic operation?

Is there a supported procedure to repair or reconstruct the local Guardian registration without deleting existing certificates or cryptographic keys?

Is there a Windows 11 Pro-specific recovery procedure that avoids clearing the physical TPM, resetting cryptographic key stores or reinstalling Windows?

I would appreciate a documented, targeted and reversible procedure.

For safety reasons, I have suspended further modifications to the Guardian configuration until the underlying issue has been identified.

Thank you again for your assistance.

Answer 4

Supprimé

Cette réponse a été supprimée en raison d’une violation de notre Code de conduite. La réponse a été signalée manuellement ou identifiée via la détection automatisée avant que l’action ne soit entreprise. Pour obtenir plus d’informations, veuillez consulter notre Code de conduite.

Les commentaires ont été désactivés. En savoir plus