Problem Description
Backup or restore jobs fail with an SSL certificate verification error. This typically occurs when the Druva agent cannot establish a secure handshake with the Druva Storage Cloud because the certificate presented during the connection sequence is not recognized or trusted.
Cause
The most common cause is SSL Inspection (Deep Packet Inspection) performed by a network firewall, proxy server, or local antivirus software.
These security utilities intercept encrypted traffic by replacing Druva's legitimate SSL certificate with a "self-signed" or "local" certificate generated by the security appliance itself. Because the Druva agent does not recognize or trust the security tool's internal Certificate Authority (CA), it securely terminates the connection.
Traceback
In the EnterpriseWorkload.log or job logs, look for errors similar to the following:
Plaintext
[ERROR] Error occurred while connecting to storage: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:1108)
Resolution
To confirm if a security appliance is intercepting the connection, use the built-in OpenSSL utility bundled with the Druva agent to inspect the certificate chain.
Step 1: Access the OpenSSL Utility
Open your terminal or command prompt and navigate to the directory based on your host Operating System:
For Windows:
Open Command Prompt as Administrator.
Navigate to the library path:
cd "C:\Program Files\Druva\EnterpriseWorkload\lib"Launch the tool:
openssl.exe
For Linux:
Open your Terminal.
Navigate to the library path:
cd /opt/Druva/EnterpriseWorkload/libLaunch the tool:
./openssl
Step 2: Run the Connectivity Test
At the OpenSSL interactive prompt (OpenSSL>), execute the following command (replace <Storage URL> with your specific cloud storage endpoint instance, e.g., usw2-storage-p01.druva.com):
s_client -connect <Storage URL>:443 -showcerts
Step 3: Analyze the Output
Examine the certificate hierarchy and the Subject/Issuer lines within the payload:
Expected Result: The
O(Organization) attribute should state DigiCert or Amazon, and theCN(Common Name) should match a validated Druva or AWS endpoint.Evidence of Interception: If you locate your firewall vendor name (e.g., Fortinet, Palo Alto, Zscaler, Sophos) or your internal corporate IT infrastructure details in the
OorCNvalues, your traffic is being actively decrypted.
Step 4: Final Fix
Once interception is confirmed, coordinate with your network security team to create a policy rule whitelisting/excluding the target Druva Storage URLs from SSL inspection profiles. This allows the agent-to-cloud payload to pass through unmodified.