The Veeam Admin's Guide to DNS, Internal CAs, and TLS Certificate Management

DNS failures and certificate errors are the two most misdiagnosed problems in Veeam environments. Not because they're subtle -- they're not -- but because the error messages they produce point at the wrong layer. A bad PTR record breaks NBD transport, and the log says "transport failed." A cert with the wrong SAN breaks VSPC management agent auth, and the log says "connection refused." Knowing what each component expects from DNS and from the certificate store, before something breaks, is what keeps 2 AM incidents from turning into 4 AM incidents. This article maps that out for every major component in a Veeam environment.

DNS Comes Before Certificates -- Every Time

Certificates authenticate identity, and identity in TLS is tied to names, not IP addresses. Before a certificate can do its job, the name on the certificate has to resolve -- forward and, for several Veeam components, reverse as well. If your DNS isn't right, your certificate trust chain doesn't matter. You'll be chasing TLS errors that are actually DNS errors.

Veeam's own best practices documentation is direct about this: all infrastructure components must be resolvable by FQDN. That means every VBR server, every proxy, every repository host, every hypervisor host, every vCenter, every VSPC server, every cloud gateway. Forward (A) records are mandatory. Reverse (PTR) records aren't mandatory everywhere, but several transport modes and authentication flows depend on them and will fail silently without them.

DNS Requirements by Component

Split DNS for MSP and Multi-Tenant Environments

If you're running Cloud Connect, VSPC, or a managed backup service for multiple tenants, you almost certainly need split DNS -- different answers to the same query depending on where the query originates. Your Cloud Connect gateway FQDN (say cc.yourdomain.com) needs to resolve to your public IP from the tenant's site, and to the gateway's internal IP from within your own infrastructure. Without split DNS, internal components trying to reach the gateway hit your public IP, traverse your firewall NAT, and often fail because hairpin NAT isn't configured or the firewall drops the return traffic.

On Windows Server, split DNS is implemented by creating a primary forward lookup zone for the public domain inside your internal DNS server. Any records you create in that internal zone shadow the public DNS records for clients using your internal resolvers. You only need to create the specific records you want to override -- everything else falls through to your external resolver via forwarders.

# Create internal zone shadowing your public domain
Add-DnsServerPrimaryZone -Name "yourdomain.com" -ZoneFile "yourdomain.com.dns"

# Add internal A record for Cloud Connect gateway
# This shadows the public DNS entry for internal resolvers
Add-DnsServerResourceRecordA -ZoneName "yourdomain.com" `
  -Name "cc" -IPv4Address "10.0.1.50"

# Add internal A record for VSPC
Add-DnsServerResourceRecordA -ZoneName "yourdomain.com" `
  -Name "vspc" -IPv4Address "10.0.1.55"

Certificate Map: What Each Component Uses

Veeam environments use TLS certificates in at least five distinct contexts, and each has different requirements for the signing authority, the key usage extensions, and the SAN fields. Getting one wrong doesn't break everything -- it breaks exactly the component that uses that certificate, in ways that are hard to trace.

Using an Internal CA for Veeam Certificates

An internal Windows Server Certificate Authority is the right choice for environments that don't want to buy public certificates for internal-only components like VBR, repositories, or VSPC in a private network. It lets you issue and renew certificates without cost, with full control over the chain. The tradeoff is that you have to distribute the CA root certificate to every host that needs to trust it.

What the Internal CA Certificate Needs

Veeam's internal CA certificate requirements are specific, and they've caught people out when using default Windows CA templates. The certificate must meet all of the following:

1. 1The Subject (CN) must equal the FQDN of the server the cert is for. Example: vbr01.corp.local.
2. 2The Subject Alternative Name must include both the FQDN and the NetBIOS (short) name, formatted as DNS:vbr01.corp.local,DNS:vbr01. Missing the NetBIOS name causes console connection failures from Windows clients that resolve the short name.
3. 3Minimum 2048-bit RSA key. Veeam won't import a cert with a smaller key.
4. 4Key usage extensions must include: Digital Signature, Key Encipherment. Enhanced key usage must include Server Authentication (1.3.6.1.5.5.7.3.1).
5. 5The Path Length Constraint in Basic Constraints must be 0, and Subject Type must be CA. In the Windows CA template MMC, base your template on the Subordinate Certification Authority template and enable "Do not allow subject to issue certificates to other CAs" on the Extensions tab.
6. 6The CA root certificate must be in the Trusted Root Certification Authorities store on the VBR server (Local Computer, not Current User). It must also be in the same store on every host that needs to trust VBR-issued certs -- proxies, repositories, agent-managed hosts.

Distributing the CA Root via Group Policy

For domain-joined infrastructure, distribute the CA root through GPO. This is faster than touching every machine manually and ensures new machines get the trust anchor automatically.

Computer Configuration
  Windows Settings
    Security Settings
      Public Key Policies
        Trusted Root Certification Authorities
          # Import your root CA certificate here
          # Applies on next gpupdate cycle to all computers in scope

For non-domain-joined systems -- which includes some Linux repositories, cloud appliances, and isolated Veeam components -- you need to push the CA root manually or via a configuration management tool.

# RHEL / Rocky / AlmaLinux
sudo cp corp-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Ubuntu / Debian
sudo cp corp-root-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# Verify the CA is now trusted
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt your-server.crt

VSPC Certificate Requirements in Depth

VSPC's certificate requirements are the strictest in the Veeam product family, and they're a common source of production incidents for new deployments. The default VSPC self-signed certificate works for the web UI. It does not work for management agent connections. If you deploy VSPC with its default cert and then try to push management agents to tenant VBR servers, those agents will connect, then immediately drop and log a certificate trust error.

The requirement is explicit in Veeam's documentation: management agent connections require a CA-signed certificate, either public or internal. Self-signed certificates are not supported for agent-to-VSPC communication. This is a hard requirement, not a recommendation.

For the SAN field, VSPC offers two valid approaches:

Multi-domain certificate: The SAN includes the VSPC server FQDN and all cloud gateway FQDNs explicitly. Example: DNS:vspc.corp.local, DNS:gw01.corp.local, DNS:gw02.corp.local. You add new entries to this cert whenever you add a new gateway, which means a re-issue.

Wildcard certificate: The SAN includes a wildcard covering the VSPC domain. Example: DNS:vspc.corp.local, DNS:*.corp.local. New gateways on the same domain are covered without re-issuing the cert. This is the lower-maintenance option for environments with multiple gateways or frequent gateway changes.

Let's Encrypt for Veeam Components: Where It Works and Where It Doesn't

Let's Encrypt is free, widely trusted, and automatable. It's a reasonable choice for Veeam components that are publicly reachable. It has two significant constraints that make it the wrong choice for some roles.

Where it works: Cloud Connect gateways with public FQDNs, VSPC servers with public FQDNs, Enterprise Manager web UIs exposed to the internet or to tenants. Any component that has a public DNS record can use Let's Encrypt for domain validation and get a trusted cert at no cost. The 90-day cert lifetime requires automation -- Certbot or Posh-ACME with auto-renewal configured -- but that's manageable.

Where it doesn't work: Any component with only an internal DNS name (e.g. vbr01.corp.local). Let's Encrypt can't validate .local domains or any private namespace that isn't registered in public DNS. For internal components, you need an internal CA or a purchased certificate with an internal SAN (which some public CAs will issue for specific private domains, but not .local).

The 90-day lifetime is the other consideration for Veeam environments. Veeam imports certificates into the Windows certificate store and applies them via the management wizard. That's a manual action that has to happen every 90 days if you're using Let's Encrypt. The PowerShell path for automating this with Posh-ACME is well-documented and the Veeam Cloud Connect Reference Architecture covers it in detail. If you're going to use Let's Encrypt for Cloud Connect, commit to automating the renewal and import -- don't rely on a calendar reminder.

Certificate Renewal Sequences That Don't Break Running Jobs

Renewing a certificate on a live Veeam environment needs to be done in the right order. Do it wrong and you'll drop active backup sessions, lose management agent connectivity, or force a re-auth across all connected tenants. Here's the safe sequence for each component.

Cloud Connect Gateway Certificate Renewal

VSPC Certificate Renewal

Diagnostic Commands for DNS and Certificate Problems

When something breaks and you suspect DNS or certificates, these are the commands that tell you what's actually happening rather than what you think is happening.

# Forward lookup -- run from each component that needs to resolve the target
nslookup vbr01.corp.local
Resolve-DnsName vbr01.corp.local -Type A

# Reverse lookup -- run from the VBR server for each infrastructure component
nslookup 10.0.1.20
Resolve-DnsName 10.0.1.20

# Check what DNS server a Windows host is actually using
ipconfig /all | findstr "DNS Servers"
Get-DnsClientServerAddress

# Linux forward and reverse from a proxy or repository host
dig vbr01.corp.local A
dig -x 10.0.1.20

# Check cert in Windows store -- find by FQDN
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*vbr01*" } | Select Subject, Thumbprint, NotAfter

# Check all certs expiring within 60 days
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.NotAfter -lt (Get-Date).AddDays(60) } | Select Subject, NotAfter, Thumbprint

# Verify a cert's SAN fields (PowerShell)
$cert = Get-Item Cert:\LocalMachine\My\<thumbprint>
$cert.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Subject Alternative Name" } | Select -ExpandProperty Format($false)

# Test TLS connection to Cloud Connect gateway from tenant side
Test-NetConnection -ComputerName cc.yourdomain.com -Port 6180

# Linux -- inspect remote certificate chain
openssl s_client -connect vspc.corp.local:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -A5 "Subject Alternative"

# Check cert expiry on a remote endpoint
echo | openssl s_client -connect cc.yourdomain.com:6180 2>/dev/null | openssl x509 -noout -dates

Building a Certificate Inventory

If you don't have a running record of what certs are deployed where, and when they expire, you will get surprised. The right time to find out a cert expires tomorrow is not tomorrow. Build a simple inventory -- even a spreadsheet -- that records each certificate, the component it's deployed on, the issuer, the thumbprint, the expiry date, and who's responsible for renewal. Review it quarterly and set calendar alerts at 60 days and 30 days before each expiry.

The PowerShell command above to find certs expiring within 60 days is a good basis for an automated check. Run it on each Windows host in your environment as a scheduled task and output to a log. Feed that log into whatever monitoring stack you already use. An expiring certificate that generates an alert 60 days out is a planned maintenance window. An expired certificate found during an incident investigation is an outage with a root cause that makes everyone look bad.