How to: Configure Hyper-V Replica using certificate-based authentication (https)
How to: Configure Hyper-V Replica using certificate-based authentication (https)
Disclaimer: Before you get too deep into the article I have not been able to do this for a Hyper-V Core Windows Server Installation (the free Hyper-V version you download off of Microsoft). I get the certificate and everything to show up but last-minute it throws and error indicating that the specified certificate and its key cannot be found/read. My guess is that I need to give the service account some sort of special right to access the certificate store or use that certificate but I gave up… Internal unsecured traffic won’t kill me, I hope.
Hyper-V Server 2012 as well as any other Windows 2012 Server running the Hyper-V role has a new cool feature called Replica. One of the aspects you can configure is the method of communication between servers to replicate/sync a particular Virtual Server Replica. This communication allows you to use a secure protocol that utilizes machine level mutual authentication, which requires you to install the certificate in the Personal certificate store of the local computer / target hyper-v server.
View/Import Certificates
To view or to import the certificates
- Launch mmc from the command prompt.
- Click File->Add/Remove Snap-in… and choose Certificates from the available list of snap-ins.
- Choose ‘Computer Account‘ in the Certificate snap-in pop up
- Open the Certificates store under the Personal store.
Primary Server Certificate Requirements
To setup a replication relationship, the certificate in the primary server must meet the following conditions:
- Enhanced Key Usage must support both Client and Server authentication
- Set the Subject field or the Subject Alternative Name using one of the following methods:
- Set the Subject field to the primary server name (e.g.: primary1.contoso.com). If the primary server is part of a cluster, ensure that the subject field is set to the FQDN of the HVR Broker (install this certificate on all the nodes of the cluster).
(or)
- Subject field can contain a wildcard (e.g.: *.department.contoso.com).
(or)
- For a SAN certificate, set the Subject Alternative Name’s DNS Name to the primary server name (e.g.: primary1.contoso.com). If the primary server is part of a cluster, the Subject Alternative Name of the certificate should contain the FQDN of the HVR Broker (install this certificate on all the nodes of the cluster).
- Ensure that the valid X.509v3 certificate is not revoked.
- Check if the root of this certificate is present in the “Trusted Root Certification Authorities” of the replica server certificate store.
Replica Server Certificate Requirements
To enable a server to receive replication traffic, the certificate in the replica server must meet the following conditions
- Enhanced Key Usage must support both Client and Server authentication
- Set the Subject field or the Subject Alternative Name using one of the following methods:
- For a SAN certificate, set the Subject Alternative Name’s DNS Name to the replica server name (e.g.: replica1.contoso.com). If the replica server is part of cluster, the Subject Alternative Name of the certificate must contain the replica server name *and* FQDN of the HVR Broker (install this certificate on all the nodes of the cluster.)
(or)
- Set the Subject field to the replica server name (e.g.: replica1.contoso.com). If the replica server is part of cluster, ensure that a certificate with the subject field set to the FQDN of the HVR Broker is installed on all the nodes of the cluster.
(or)
- Subject field can contain a wildcard (e.g.: *.department.contoso.com)
- Ensure that the valid X.509v3 certificate is not revoked.
- Check if the root of this certificate is present in the “Trusted Root Certification Authorities” of the replica server certificate store.
Validate using certutil
After the certificate is installed, run the following command from the command prompt on both the primary and replica server:
certutil –store my
At least one of the certificates in your output should resemble the following sample output such that the Encryption test (not just Signature) has passed.
Using a CA inside your AD Domain
I personally recommend creating a new certificate template for your Hyper-V needs. In my particular case I created a duplicate off of the Web Server template and added the Client Authentication by default. I found out that if you don’t use the template the Client Authentication it won’t put it on the certificate even if you try to add it manually… Maybe I did something wrong but this way I don’t forget to add it. Also, I increased the validity of the certificate, 2 years for an internal server seems too little. So there you have it, better make those things the defaults and set up a template based on that. I had a few servers to configure but if you only have one I can understand doing a template might be too much trouble.
Using a self signed certificate
Look for the UTG here and on Appendix C you will find how to generate a self signed certificate. Although that is a lot of help, the real important part is the command you need to execute in order to have Hyper-V not check for the CRL of the certificate (revocation, etc that is provided when you use a CA).
Quick Summary:
I. Create a Self Signed Certificate Authority (if that makes any sense):
makecert -pe -n “CN=PrimarySampleRootCA” -ss root -sr LocalMachine -sky signature -r “PrimarySampleRootCA.cer”
II. Create a Self Signed Certificate using the CA crated above:
makecert -pe -n “CN=ServerName.domain.local” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “PrimarySampleRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 PrimarySampleCert.cer
III. Do the same for the destination failover replica server (create a self signed CA and Certificate)
IV. Add the Self Signed CAs you created to the trusted roots of the servers that are going to connect to that host using this command:
certutil -addstore -f Root “PrimarySampleRootCA.cer”
V. Disable the certificate revocation check:
reg add “HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
Enjoy!
Love
Can we use Let's Encrypt, the free and open certificate authority?
Hola! gracias por la info, me sirvió el comando sacandole el nombre del server. En mi caso, fue una migración…
Yes 3rd option helped me too. I removed the WC key Values from config file then started working.
I know this is from 2014. But really, thank you!