Forum Discussion
Hyper-V VMConnect failing after hardening crypto
I run Hyper-V locally on my laptop for testing and evaluation of various systems and services for my company. The laptop is running Win10, AMD Ryzen processor, 40GB RAM.
The Hyper-V install had been running fine for a long while, but I just recently updated my crypto settings on my laptop (stopped the use of legacy/insecure ciphers, locked to TLS 1.2 and disabled older versions, etc.) and suddenly I can't connect using the Hyper-V VMconnect console to my VM's anymore.
Reference: https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12
A sample of the error I'm getting - pop up window as the VMConnect console is being spun up:
An authentication error has occurred
One or more of the parameters passed to the function was invalid
My local EventViewer / Custom Views / ServerRoles / Remote Desktop Services1 channel has the follow error message crop up:
RDPClient_SSL: An error was encountered when transitioning from TsSslStateHandshakeInProgress to TsSslStateDisconnecting in response to TsSslEventHandshakeContinueFailed (error code 0x80004005).
Seems to indicate that the VMConnect service is relying on some kind of SSL/TLS handshake to negotiate a secure connection but that it can't agree on the terms?
Any ideas? Other than the obvious reversion back to the weaker crypto state :)
1 Reply
So I reset my crypto settings back to default, then took a copy of the hardening script, disabled everything and then, section by section, re-enabled individual stanzas and rebooted/retested each time to figure out the setting/change that was causing the issue. It apparently was this line:
"New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS" -name 'ClientMinKeyBitLength' -value '2048' -PropertyType 'DWord' -Force | Out-Null"
Commenting that line out and applying the rest of the script seems to work and I can now resume using VMConnect to get back to my Hyper-V console.
This being said, I still wanted to figure out why that line was causing was failure. The new registry entry for PKCS seems to relate to a minimum bit length for what I assume is the client side portion of a session key. The entry in the script is hardcoding the min value to 2048 bits.
It does look like Hyper-V creates some local machine certs under the Service Account cert store for Hyper-V Virtual Machine Management (mmc -> File -> Add/Remove Snap-in -> Certificates (Add) -> Service Account -> Local Computer -> Hyper-V Virtual Machine Management). Under "vmms\Personal\Certificates" and "vmms\Trusted Root Certification Authorities\Certificates", there seems to be a locally generated self-signed cert with my Hyper-V enabled laptop's machine name. The cert parameters seem to be set for a 1024 bit key, using sha1RSA for the algorithm.
Since the local Hyper-V service account cert had a key size of 1024 bits, I tested by changing the 'ClientMinKeyBitLength' of that problem line from "2048" to "1024". After a reboot, the setting seems to be accepted - I can still use VMConnect to get to the console with that reduced keybitlength in place.
I'm making an assumption that it was that 2048 bit setting that was conflicting with the Hyper-V cert key size of 1024 bits. Does anyone know how to manipulate the Hyper-V cert generation parameters in order to have it generate a cert with a key size of 2048 bits or higher?
