Hyper-V replica certificate authentication

Ayu Pratama 0 Reputation points
2026-08-26T01:52:49.45+00:00

I just configured Hyper-V Replica with HTTPS authentication for a client, but the connection is failing with error 0x8009030d, “The function intended to authenticate failed.” I need to verify the certificates on both replica hosts, or really, I need to make sure the SAN names and EKU extensions are correct for Hyper-V Replica. Do I need to replace the certificates if the SAN or EKU is missing, or can I audit the existing certificates and revocation check settings to find out what is causing the authentication failure ?

Windows for business | Windows 365 Enterprise
0 comments No comments

2 answers

Sort by: Most helpful
  1. Hoang Le 2,010 Reputation points Independent Advisor
    2026-08-26T04:05:05.2666667+00:00

    Hello Ayu Pratama,

    The error 0x8009030d in Hyper‑V Replica with HTTPS authentication almost always points to a certificate mismatch in either the Subject Alternative Name (SAN) or the Enhanced Key Usage (EKU) extensions. Hyper‑V Replica requires that the certificate used on each host has the Server Authentication EKU (1.3.6.1.5.5.7.3.1) and that the SAN field contains the exact FQDN of the host as it is configured in the Replica settings. If either is missing, the TLS handshake fails with the authentication error you are seeing.

    You should audit the certificates on both hosts with certutil -store my and confirm the thumbprint, SAN entries, and EKU values. Also verify that the certificate chain is trusted and that revocation checking is not blocked by firewall rules. If the SAN or EKU is missing, the certificate must be replaced—there is no supported way to modify an existing certificate to add these extensions. Once the correct certificate is installed in the LocalMachine\My store, reconfigure the Replica settings to use its thumbprint. This ensures that HTTPS authentication succeeds and replication can be established.

    If my answer is useful for you, please hit Accept the answer to support me.

    Thank you,

    HL.

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-08-26T01:53:04.4533333+00:00

    Yes. Existing certificates can be audited first, and replacement is required if the certificate does not meet Hyper-V Replica requirements.

    For Hyper-V Replica with certificate-based authentication, the certificate on each sending and receiving host must:

    • Not be expired.
    • Have both Client Authentication and Server Authentication EKU attributes.
    • Have an associated private key.
    • Chain to a valid root certificate.
    • Have the subject CN or SAN that matches the FQDN of the host.
    • If replication involves a cluster, the certificate must match the FQDN of the Hyper-V Replica Broker role.

    If the SAN or subject name does not match the required FQDN, or if the EKUs are missing, that certificate does not meet the documented requirements and should be replaced with one that does.

    Revocation checking can also affect certificate-based authentication. Hyper-V Replica validates whether the issuing CA has revoked the certificate. If the CRL distribution point is inaccessible, that validation can fail. A server-level registry setting named DisableCertRevocationCheck exists under: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication

    Supported values:

    • 0 = certificate revocation check enabled
    • 1 = certificate revocation check disabled

    This setting can be configured on both primary and replica servers as required. Note that changing registry settings is a riskier operation and should be tested carefully, especially in production.

    A practical audit path is:

    1. Check whether the certificate is expired.
    2. Verify the certificate has both Client Authentication and Server Authentication EKUs.
    3. Verify the certificate has a private key.
    4. Verify the subject CN or SAN matches the host FQDN, or the Hyper-V Replica Broker FQDN for clustered replication.
    5. Verify the certificate chains to a valid root certificate.
    6. If certificate revocation validation might be failing because the CRL endpoint is unreachable, review the DisableCertRevocationCheck setting on both hosts.

    When configuring the replica server, Hyper-V settings allow selecting the certificate used for Use certificate-based authentication (HTTPS). Only a certificate that matches these requirements should be selected.


    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.