How to solve Veeam "WinHttpSendRequest: 12017" error

Problem Description

Veeam Backup & Replication (v12) or Veeam Agent jobs targeting an S3 repository at the endpoint:
eu-central-2.storage.impossibleapi.net 
may fail intermittently with one of the following messages:

Exception from server: HTTP exception:
WinHttpSendRequest: 12017: The operation has been canceled, error code: 12017

Or (German localized):

Exception from server: HTTP exception:
WinHttpSendRequest: 12017: Der Vorgang wurde abgebrochen

The numeric code 12017 corresponds to a Windows WinHTTP cancellation event. In affected environments Veeam aborts the request during (or just after) the TLS negotiation phase.

Root Cause

The eu-central-2 regional S3 endpoint is backed by several independent orchestration sites (physically separate datacenters). A DNS round‑robin policy returns different public IP addresses for the same hostname on successive resolutions. Each site terminates TLS with its own (valid) certificate. Under certain environment conditions Veeam v.12 does not gracefully handle encountering different certificates for the same hostname across closely spaced HTTPS connections and cancels the operation, resulting in WinHttp error 12017.

Important: All presented certificates are valid and correctly bound to the hostname. The issue is environmental / client-side behavior in specific Veeam deployments and is not a service outage.

Affected Scope

• Endpoint: eu-central-2.storage.impossibleapi.net
• Veeam versions: Observed with Backup & Replication 12.x and related agents
• Not universal: Many deployments function normally; only some environments face the cancellation behavior

Solution Overview

Force resolution of the hostname to a single IP address so that all connections consistently reach the same orchestration site (and therefore the same TLS certificate). This is done by adding a static entry to the operating system hosts file on the Veeam machine.

Trade-offs:

• Slightly reduced availability (no automatic failover to other orchestration sites while the static mapping is in place)
• Possible minor performance variance if the chosen IP corresponds to a datacenter different from where your bucket’s data physically resides
• Easily reversible by removing or changing the hosts IP entry

Step-by-Step

1. Pick ONE of the available public IPs for eu-central-2.storage.impossibleapi.net:
   • 94.103.168.3
   • 89.35.53.39
2. On the Veeam server or agent host, open the system hosts file with administrative privileges:
   • Windows: C:\Windows\System32\drivers\etc\hosts
   • Linux: /etc/hosts
3. Add exactly one line (do NOT add both) mapping the hostname to the chosen IP, for example:
   • 94.103.168.3 eu-central-2.storage.impossibleapi.net
4. Save the file.
5. Flush any DNS / resolver caches if applicable:
   • Windows (elevated PowerShell): ipconfig /flushdns
   • Linux (if using systemd-resolved): sudo systemd-resolve --flush-caches (or restart the nscd / dnsmasq service if in use)
6. Restart (or re-run) the failing Veeam job.
7. If performance is suboptimal, replace the IP in the hosts file with the alternative address and repeat steps 4–6.
8. Once a future product update removes the sensitivity to certificate rotation, you can delete the hosts entry to restore multi-site availability.

Verification

After applying the mapping, re-run the backup / repository sync job. The error should no longer appear.

Permanent Solution

The permanent solution is to update Veeam to v.13 once it is available. The fix should be included into that version.