Problem description
During the activation of the Hyper-V Backup Proxy or Enterprise Workloads Agent on a Hyper-V host, the activation process fails and throws the following SSL/TLS certificate verification error:
x509: certificate signed by unknown authority
This issue prevents the proxy from establishing a secure communication channel with Druva cloud management endpoints during the initial setup or re-registration process.
Cause
This issue occurs when the Hyper-V Backup Proxy server is unable to validate the SSL/TLS certificate presented by Druva cloud services (*.druva.com). Common root causes include:
SSL Inspection / Interception: A network security appliance (firewall, proxy, or web security gateway) is performing Deep Packet Inspection (DPI) on outbound HTTPS traffic and replacing Druva’s public SSL certificate with a custom internal CA certificate.
Missing Root/Intermediate Certificates: The Hyper-V host does not have the required root or intermediate Certificate Authority (CA) certificates installed in its local trusted root certificate store.
Network Security Policies: Outbound HTTPS traffic on TCP port 443 is being redirected through an unauthorized proxy.
Traceback
Review the agent installation and activation logs located on the Hyper-V host (e.g., under C:\Program Files\Druva\EnterpriseWorkloads\logs or C:\Program Files\Druva\Phoenix HyperV Proxy\) for errors similar to the following:
level=warn ts=2026-07-09T05:33:11.9586549Z filename=localhost_cert.go:86 method=IsSetupRequired message="Failed to read local root certificate file. Need to setup the certificates" Error="open C:\Program Files\Druva\EnterpriseWorkloads\lib\root-ca.crt: The system cannot find the file specified." level=error ts=2026-07-09T06:05:10.6410407Z filename=bl_activate.go:139 layer=bl method=Activate message="Failed to activate device" Error="Post \"https://devicemgmt-reverseproxy-ap1-dcp.druva.com:443/deviceconfig/v2/devices/activate\": tls: failed to verify certificate: x509: certificate signed by unknown authority"
Resolution
Depending on your network infrastructure, use one of the following methods to resolve the issue:
Option 1: Configure Firewall / Proxy Exclusion (Recommended)
Configure your firewall, proxy server, or SSL inspection appliance to bypass SSL decryption/inspection for Druva endpoints. Add *.druva.com to the SSL inspection exclusion/bypass list.
Option 2: Import Internal Root Certificate
If SSL inspection cannot be disabled due to organizational security policy:
Export the root and intermediate CA certificates from your firewall or security appliance.
Log in to the Hyper-V Backup Proxy server as an Administrator.
Import the internal root and intermediate certificates into the Trusted Root Certification Authorities store for the local computer (
certlm.msc).
Option 3: Verify Direct Outbound Connectivity
Ensure outbound port 443 (HTTPS) is opened directly to Druva cloud endpoints.
Ensure no intermediate web proxy is intercepting or rewriting outbound headers without proper proxy authentication configured in the Druva agent.
After completing the resolution steps, retry the Hyper-V Backup Proxy activation command.
Verification
To verify whether SSL inspection is occurring or if the certificate chain is trusted by the proxy server:
Log in to the Hyper-V Backup Proxy server.
Open Command Prompt or PowerShell as an Administrator.
Navigate to the agent installation folder:
cd "C:\Program Files\Druva\Phoenix HyperV Proxy\"
Run the OpenSSL diagnostic command to inspect the certificate chain returned by the server:
openssl s_client -showcerts -connect devicemgmt-reverseproxy-dcp.druva.com:443
Review the
issuer=line in the command output:Expected: The certificate issuer belongs to a recognized public CA (e.g., DigiCert, Let's Encrypt, or Amazon).
SSL Inspection Detected: The certificate issuer matches your internal corporate CA or security vendor (e.g., Fortinet, Palo Alto, Zscaler, Sophos). If so, apply Option 1 or Option 2 from the Resolution section.