Hyper V Replica Cross Site Cross Domain certificate issue RRS feed

  • Question

  • Hello, I've issued SAN certificates for both my primary server (domain1) and replica server (domain2) from my enterprise CA and replication with these certificates works just fine if I use the internal name of my replica server when enabling replication on a specific VM.  If I change the name of the replica server to the public address though "servername.dyndns.org"  (using dyn for some cheap external access testing) in order to try replication over the WAN then I get the following errors.  This is with the same certificates and configuration that work just fine with the local name.  I have all of the internal and external names on the certificate as well as Subject Alternative Names, I've imported the CA certificate into the trusted root store of the Primary server, have the hyper v replica open on the firewall, and am forwarding 443 through my external firewall as well.  Thanks for any help!


    Enabling replication failed.

    Hyper-V failed to enable replication.

    Hyper-V received a digital certificate that is not valid from Replica server

    Hyper-V failed to enable replication for virtual machine New Virtual Machine’:
    The specified certificate is self signed.

    (Virtual Machine ID OBF44cBD-O8AF-4430-BSBF-FBFc3EO13F8D)

    Hyper-V received a digital certificate that is not valid from the Replica server
    ‘servername.dyndns.org’. Error: The specified certificate is self signed. (0x80092007).

    • Edited by mbiver Monday, November 5, 2012 10:40 PM
    Monday, November 5, 2012 10:40 PM

All replies

  • Hi,

    According to your description, this seems a certificate issue.

    Check whether you have configured the certificate correctly:

    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.)


      • 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.


      • 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.

    For more information please refer to following MS articles:

    Hyper-V Replica - Prerequisites for certificate based deployments
    Hyper-V Replica–Certificate Based Authentication in Windows Server 2012
    Requesting Hyper-V Replica Certificates from an Enterprise CA

    Hope this helps!

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    TechNet Community Support

    Tuesday, November 6, 2012 2:45 AM
  • Perhaps this guide may help if no VPN and using no domain or trust relationship between the sites:


    Philip Elder SBS MVP Blog: http://blog.mpecsinc.ca

    Tuesday, November 6, 2012 5:08 AM
  • Thanks for the info so far, I'm definitely checking my certificates to be sure.  Why would the same certificates work though using my local replica server name and then trigger the above error when I change the replica server to it's external name?  If there was a problem with the certs, wouldn't they just not work at all regardless of the name of the replica server entered into the wizard? 
    Tuesday, November 6, 2012 2:48 PM
  • So I was still getting the same error so Instead of using 'servername.dyndns.org' as the replica name I just did a ping of that address and got my public IP.  I then took that into my hosts file on the primary server and pointed the ip address to 'servername.internaldomain.com' which is the actual FQDN of the replica server in my internal domain.  Using the exact same certificates (that have both the ''servername.dyndns.org' and a wildcard of '*.dyndns.org' as a subject alternative name) everything works fine and the vm gets replicated without issue across the WAN.  Any ideas?  does the certificate need to be signed by a signing certificate or something?  I assumed that as long as the root CA cert was installed in the trusted root folder of the local machine and the SAN cert being used for encryption was in the personal folder of the local machine everything would be trusted.  thanks.
    Tuesday, November 6, 2012 4:48 PM
  • Not quite. I just ran into this myself. The name on the certificate must match the name of the server its talking or else you get an error; the same thing if you browse to the IP address of a secure site instead of the name.

    In my enviroment, I used makecert.exe to create certificates with the correct name and then edited the hosts file on both machines so they had proper name resolution.

    Here is the doc I used:


    Make sure to read the community content at the bottom, some of the microsoft syntax is incorrect.


    Thursday, November 29, 2012 3:26 PM
  • Hi,

    Could you please follow Trent's suggestion to check the result? Thanks.

    Kevin Ni

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, November 30, 2012 8:43 AM