I’ve been experimenting with vTPM in Hyper-V, particularly around enabling virtualization-based security features (Credential Guard, code integrity, etc.)
In a lab setup I tried the following approach using the following PowerShell scripts. https://github.com/SergeCaron/UntrustedGuardianMove
- On Host A, when I first enabled vTPM on a VM, Hyper-V generated the usual Shielded VM Encryption and Shielded VM Signing certificates.
- I exported these as PFX files
- On Host B, I imported them and created a guardian using the exported certs
New-HgsGuardian -Name $GuardianName -SigningCertificate "$SigningCertificate" -SigningCertificatePassword $CertificatePassword -EncryptionCertificate "$EncryptionCertificate" -EncryptionCertificatePassword $CertificatePassword -AllowExpired -AllowUntrustedRoot
My Observations
- With this setup, both hosts appear to be able to share the same certificate pair.
- Existing vTPM-enabled VMs created on Host A can be migrated to Host B and started successfully.
- In my limited testing, new VMs created on Host B after importing the certs also seem to work under this same shared pair.
I realize this reduces security because it creates a single point of failure: if that certificate pair is ever compromised, any host with those certs could decrypt the vTPM state and run the VMs. There’s no per-host trust boundary.
I know ideally the correct and supported way forward would be to deploy a Host Guardian Service (HGS) but that’s quite an undertaking.
Beyond the obvious single-point-of-failure risk, are there other downsides or hidden pitfalls to this approach? I’m not proposing this as best practice, just exploring the concept and looking for insights into whether sharing a certificate pair across hosts is something Hyper-V is designed to support.