Creating self signed certificate using powershell — specifically for Hyper-V Replication

Background
This article was written on 14-Nov-24

References
This one is for Windows 2016 and above
- http://woshub.com/how-to-create-self-signed-certificate-with-powershell/
These ones are for Windows 2012
- https://nerddrivel.com/2016/03/07/hyper-v-replication-in-a-workgroup-or-across-domains-using-a-self-signed-certificate/
- https://adamtheautomator.com/new-selfsignedcertificate/

Tools used are exclusively of Microsoft. Since I am using Microsoft technologies, then I feel more confident that by using Microsoft own tools it will be fully compatible.
And less risk of installing other software.

Hyper-V replication between domain requires kerberos authentication.
I use self signed certificate because I use VPN between my domains, so all traffic is internal, not public.
If you do not have VPN, then (maybe) you need to use Certificate Authority (CA).
You can create a free Let’s Encrypt certificate for this.

Creating root certificate
First we need to create a self signed root certificate which in turn we will use to sign our system certificate.

Open a new remote powershell console to the hyper-v server.
And I use below commands:

$todaydt = Get-Date
$7years = $todaydt.AddYears(7)
$rootCert = New-SelfSignedCertificate -Subject 'CN=[use your fqdn],O=[use your company name],OU=[use your department]' -KeyExportPolicy Exportable  -KeyUsage CertSign,CRLSign,DigitalSignature -KeyLength 2048 -KeyUsageProperty All -KeyAlgorithm 'RSA'  -HashAlgorithm 'SHA256'  -Provider 'Microsoft Enhanced RSA and AES Cryptographic Provider' -notafter $7years

My root certificate is designed to be valid for 7 years. You may change as required.

CN, O and OU are certificate’s Distinguished Name (DN), which uniquely identifies the certificate. Here are the key components:

• CN (Common Name): This is typically the fully qualified domain name (FQDN) of the server. For example, if your server’s domain is example.com, the CN would be example.com.
• O (Organization): This field represents the name of your organization. For example, if your organization is “Tech Solutions Inc.”, you would enter Tech Solutions Inc..
• OU (Organizational Unit): This specifies a division or department within your organization. For example, if the certificate is for the IT department, you might enter IT Department.

As this is a root certificate, for the CN I add “RootCA” into the fqdn.
You can see your root certificate using certificate manager, under “Personal” folder.

Root certificate in certificate manager

Creating system certificate
Once root certificate is generated you can use it to sign your system certificate.
I use below command to generate my system self signed certificate:

$6years = $todaydt.AddYears(6)
$SelfSignCert=New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\My -dnsname [use your dns] -notafter $6years -Signer $rootCert -KeyUsage KeyEncipherment,DigitalSignature

My system certificate is designed to be valid for 6 years (less than the root certificate — which is 7 years). You may change as required.

You can see your system certificate using certificate manager, under “Personal” folder (same as your root certificate).

System certificate in certificate manager

Exporting your certificate
We need to export our certificate as file which we will import in the destination replica server.

You need to do this one by one.
Select your certificate, right click and select export.

Exporting certificate

I did not change any option and save the certificate in the hypervisor folder.

Saved certificates

You need to copy these root and system certificate files to the destination replica server and vice versa.

Importing certificate to trusted root folder
Once copied to the destination replica server, you need to import these certificates to the “Trusted Root Certification Authorities” folder.

*for unknown, unjustifiable reason, I also copy my certificates to the trusted root folder on the source replica server.

Importing certificates

Double check that the certificate is imported to the trusted root certificate folder.

Destination folder

You should then be able to see your certificate in the trusted root certification folder using certificate manager.

Certificates in trusted root

Remember that you should see both source and destination replica server certificates in this folder. One root and one system certificates, total 4 certificates.

Disabling certificate revocation
You need to disable certificate revocation (don’t ask me why :) )

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Defining certificate for hyper-v replication
Using Hyper-V Manager, select Hyper-V Setting.

Hyper-V Manager

Enable “Use certificate-based Authentication (HTTPS) and select certificate.

Selecting certificate

Automatically your self signed certificate will show up, and press OK.

Self signed certificate

Certificate is ready for replication authentication

If all is well, you should see firewall setting warning as below:

Firewall configuration warning

As I am not using windows firewall (disabled) as I am using hardware firewall, then I do not need to configure windows firewall.
Do not forget to do this for both source and replica hyper-v servers.

Starting Replication
In my case, I am “extending” my replication but should be the same for the usual replication.
Using hyper-v manager, right click on the virtual machine and select replication.

Configuring VM replication

Choose your target replica hypervisor (use fqdn)

Press Select Certificate

Automatically your certificate is selected and press OK

Select frequency

Select recovery points option

choose initial replication method

Connecting to replica server

Upon successful connection, a confirmation window will appear.

Replication is enabled successfully

Using Hyper-V Manager, you can monitor replication progress.

Monitoring replication

For my case, virtual machine size is 340 GB and VPN speed is somehow only 10 mbps.

To calculate time required for transfer, we should break down the numbers. Convert the file size into megabits (Mb) and then divide it by your network speed:

1. **Convert gigabytes (GB) to megabits (Mb):**
— 1 GB = 1024 megabytes (MB)
— 1 MB = 8 megabits (Mb)
— So, 340 GB = 340 x 1024 x 8 = 2,796,160 Mb

2. **Calculate the time to transfer the file:**
— Transfer speed = 10 Mbps
— Time = File size (Mb) / Transfer speed (Mbps)
— Time = 2,796,160 Mb / 10 Mbps = 279,616 seconds

Now, let’s convert seconds into hours and minutes:

- 279,616 seconds = 279,616 / 60 minutes ≈ 4,660.27 minutes
- 4,660.27 minutes = 4,660.27 / 60 hours ≈ 77.67 hours

So, it will take approximately **77 hours and 40 minutes** to transfer your 340GB file at a network speed of 10 Mbps. That’s a bit over three days, assuming there’s no network interruption. 🕔

Okay, while waiting, just pray that your replication will succeed !