The simplest way to configure Hyper-V Replica (HVR) authentication and transport is to use HTTP. HTTP uses Active Directory Kerberos authentication and replication over TCP port 80. However, this is only useful in a demo or between trusted domains on a secure network. What if you want to replicate between untrusted forests (customer-to-service provider) or over an untrusted network? You’ll need to venture into the murky world of x.509 certificates and configure Hyper-V Replica to authenticate using SSL and replicate over HTTPS. Today I’ll walk you through the Hyper-V Replica certificate requirements, how to choose a certificate, and how to enable per-VM replication.
Hyper-V Replica Certificate Requirements
If you want to use HTTPS authentication and replication, then you will need to create certificates for the hosts/clusters in both the primary and secondary sites. The certificate must be configured for server authentication and client authentication. The certificate must also be issued to the FQDN of the host or HVR Broker, and it must include the exportable private keys for traffic decryption.
Note that the computer template included in Active Directory Certificate Services can be copied and used for this purpose. You will need to configure the template to grant administrators rights to enroll the certificate type and to permit the encryption keys to be exported (a requirement of the HVR certificate).
The required Enhanced Key Usage of the certificate.
If you are creating a certificate for a non-clustered host, then make sure the certificate is created for the fully qualified domain name (FQDN) of the host in question (for example, demo-host1.demo.internal). This certificate will be installed just on this host.
In the case of a Hyper-V cluster, each clustered host will have two certificates for HVR:
- Its own certificate: Issued and installed as if this host was not clustered (for example, demo-host3.demo.internal).
- A certificate for the HVR Broker: This certificate is created for the cluster’s HVR Broker and installed on each node in the cluster (for example, demo-HVC1-brkr.demo.internal).
You must ensure that both the primary and secondary site hosts trust the issuing certificate authority (CA). Without this trust, the certificates cannot be validated or used. This trust of a common root CA means that a certificate issued to a host in the primary site can be trusted by a host in the secondary site. Ensure that the public certificate of the root CA is in the Trusted Root Authorities certificate store of the hosts in the primary and secondary sites. This is easy enough if you have used a well-known root CA such as Verisign or Digicert. If you have created a CA of your own then you need to manually verify this:
- Standalone CA: The CA’s public certificate will have to be manually installed into the Trusted Root Authorities store of the hosts in all sites.
- Enterprise CA: A group policy update on the hosts that are in the same domain as the CA will update the store. Other domains or forests will require the same treatment as if you had used a Standalone CA.
Verifying the trust chain of the certificate.
Install the certificates on each your hosts as follows:
- Right-click on the certificate file (must contain the exported private keys) that you have retrieved from the CA and choose Install Certificate.
- Select the Local Machine as the Store Location.
- Place the certificate in the Personal certificate store (a subset of Local Machine).
- Repeat this for every host that will be involved in HTTPS-enabled HVR.
Tip: Certificates have an expiration date. Note the date and set a reminder in a team/department calendar to request new certificates at least a month in advance of the expiration date to avoid interruptions to replication.
It should go without saying, that these certificates should be treated as if they were passwords. Do not lose the files or share these files.
Choosing a Certificate In Hyper-V Replica
At this point you have installed certificates that are ready to be used by HVR. Now it’s just a matter of using the certificates. The first step in configuring HVR is to configure the host or HVR Broker replication settings in the secondary site.
- Choose to enable inbound replication (shown in the image below is a HVR Broker), and select the option to Use Certificate-Based Authentication (HTTPS).
Select HTTPS authentication in the secondary site
- Click the Select Certificate button and select your certificate. The below image depicts the certificate of the HVR Broker being chosen for a Hyper-V cluster in a secondary site.
Select the required certificate.
- Configure your inbound replication policy. The below example shows an authorized Hyper-V cluster in a primary site. The replica virtual machines will be stored in CSV3.
The complete replication settings in the secondary site.
- Complete the configuration by configuring firewalls and verifying communications, as you would with a basic HVR configuration.
Enabling Per-VM Replication
You will configure per-VM replication in the primary site just as if you were doing a basic replication.
- Specify the destination host or HVR Broker in the secondary site.
Select the replica host or HVR Broker in the secondary site.
- The key thing now is to select HTTPS for authentication and transport. Click Select Certificate and choose the appropriate certificate for the primary site host or HVR Broker.
Configure the certificate for VM replication.
- Complete the wizard and now your VM should replicate to the secondary site over secure HTTPS.