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.
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:
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:
Verifying the trust chain of the certificate.
Install the certificates on each your hosts as follows:
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.
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.
Select HTTPS authentication in the secondary site
Select the required certificate.
The complete replication settings in the secondary site.
You will configure per-VM replication in the primary site just as if you were doing a basic replication.
Select the replica host or HVR Broker in the secondary site.
Configure the certificate for VM replication.