AI authorship note: I created this article with AI assistance. I provided the experience and source material, directed the research and drafting, checked the technical claims and approved the final text.
Summary: The confirmed fault was missing Let’s Encrypt Generation Y intermediate certificates, YR2 and the cross-signed Root YR, from the Windows machine certificate stores on two tenant-side components. Installing them and restarting the relevant services restored operation. The investigation did not establish the Veeam 13.1 upgrade as the cause.
After upgrading a Veeam Cloud Connect environment and a tenant Veeam Backup & Replication server from version 13 to 13.1, backup copy jobs continued to run normally for six days. They then started failing overnight, without a certificate renewal, configuration change or network change at the time of failure.
The upgrade shaped my initial investigation, but the evidence did not establish it as the cause. I have included the timing because it explains what I checked and why.
The tenant could no longer establish a connection to either of two independent Cloud Connect gateways. The logs reported:
The remote certificate was rejected by the provided
RemoteCertificateValidationCallback.
(System.Security.Authentication.AuthenticationException)
Failed to establish a connection to the Cloud Provider.
Stepping through the Service Provider properties produced a more specific warning:
Remote certificate chain errors:
RevocationStatusUnknown
(The revocation function was unable to check revocation for the certificate.)
The certificate chain
The affected gateway used a Let’s Encrypt certificate issued through the Generation Y hierarchy. Its chain was:
Gateway certificate
-> Let's Encrypt YR2
-> ISRG Root YR, cross-signed by ISRG Root X1
-> ISRG Root X1
At the time of the investigation, Let’s Encrypt listed Root YR as not yet included in root-program trust stores and showed the default YR2 chain terminating at ISRG Root X1.[1] Validation therefore depended on the cross-signed Root YR certificate linking the chain back to the trusted ISRG Root X1.
The warning pointed towards revocation checking, so that is where I started. I checked the obvious causes before changing Veeam’s certificate-validation behaviour:
- The certificate was current and its subject alternative name matched the gateway.
- ISRG Root X1 was trusted and the Windows disallowed store was empty.
- The YR2 certificate, cross-signed Root YR and certificate revocation list URLs were reachable, including from the SYSTEM context used by Veeam services.
- The certificate revocation list was current.
- Both Cloud Connect gateways showed the same failure, which pointed towards a tenant-side factor rather than one incorrectly configured gateway.
- Both Generation Y certificates were already present in the machine intermediate store on the service-provider side.
I also renewed the certificate on one gateway as a remediation attempt. It did not help.
Windows and Veeam disagreed
The confusing part was that Windows validated the certificate successfully on the affected tenant server at the same time Veeam rejected it.
certutil -urlcache * delete
certutil -verify -urlfetch C:\temp\gateway.cer
The four chain elements all returned dwErrorStatus=0, and the leaf certificate’s revocation check passed. The Windows certificate dialog also reported This certificate is OK, while the Veeam wizard displayed RevocationStatusUnknown for the same certificate.
That result ruled out a simple expired, mismatched or generally untrusted certificate. It also meant I was dealing with a difference in service context, chain construction or validation policy rather than accepting the warning at face value.
I worked through the investigation with Claude. It helped me organise the hypotheses, interpret the certificate output and keep track of what each test did or did not exclude. I still ran the commands in the affected environment, checked the certificate stores under the correct service context and decided which changes were safe to make.
One important trap was that certutil -verify -urlfetch can fetch missing certificates and populate the current user’s cache. A successful interactive test does not prove that a service running as SYSTEM already has the same certificate material available. I cleared the URL cache before checking the store state and repeated network tests in the SYSTEM context.
The first half of the fix
The tenant VBR server’s LocalMachine\CA store did not contain YR2 or the cross-signed Root YR certificate. I downloaded the two certificates from Let’s Encrypt, checked their fingerprints and installed them in the machine Intermediate Certification Authorities store.
Invoke-WebRequest `
https://letsencrypt.org/certs/gen-y/int-yr2.der `
-OutFile C:\temp\int-yr2.der
Invoke-WebRequest `
https://letsencrypt.org/certs/gen-y/root-yr-by-x1.der `
-OutFile C:\temp\root-yr-by-x1.der
certutil -dump C:\temp\int-yr2.der |
Select-String 'Cert Hash\(sha1\)'
certutil -dump C:\temp\root-yr-by-x1.der |
Select-String 'Cert Hash\(sha1\)'
The SHA-1 certificate fingerprints I verified on 12 August 2026 were:
YR2
2D74D6DFD96EEA55AD7BAAFA0D3C6552B2DADC37
Root YR, cross-signed by ISRG Root X1
AB9D0263244DD0326EB67015705A667E79CFE998
Certificate fingerprints and download locations can change when certificate authorities rotate their hierarchy. Check them against Let’s Encrypt’s current certificate information before using these commands.
I then installed both certificates in CA, not Root:
certutil -addstore -f CA C:\temp\root-yr-by-x1.der
certutil -addstore -f CA C:\temp\int-yr2.der
Restart-Service VeeamBackupSvc
The cross-signed Root YR belongs in the intermediate store in this chain because ISRG Root X1 signs it. Installing it as a trusted root would change the intended trust relationship.
After this change, the Certificate Security Alert no longer appeared when I stepped through the Service Provider properties. Chain construction on the VBR server was fixed.
The Service Provider rescan still failed with the same callback exception.
The component the logs did not identify
The tenant also had a separate repository/proxy server. Its LocalMachine\CA store was empty too.
The failure trace on the backup server showed only backup-server threads connecting to the gateway. It did not name the repository/proxy, and no separate log appeared during that rescan window. Based on the logs, I initially concluded that the repository was not involved.
That conclusion was wrong.
I installed the same YR2 and cross-signed Root YR certificates in LocalMachine\CA on the repository/proxy and restarted the Veeam services there.
After that:
- The Service Provider properties completed without the certificate warning.
- The Service Provider rescan succeeded against both Cloud Connect environments.
- The Cloud Connect repository rescan succeeded.
Installing the certificates on the VBR server alone was not enough. The repository/proxy connected to the gateway and performed TLS validation using its own machine certificate stores, even though the exception surfaced through the backup server without naming that host.
Cached connections masked the fix
The successful rescans showed that certificate validation was working, but one backup copy job still failed with the original callback exception. At first this made it look as though part of the certificate problem remained.
The logs showed that the job was using a cached cloud connection established before the certificates were installed. Its connection attempt had been running for more than 45 minutes and eventually failed as a TCP timeout rather than performing a fresh certificate validation.
I restarted the Veeam services on the tenant backup server to clear the cached cloud connection, then confirmed that no sessions were left running before retrying the job.
Get-Service Veeam* | Stop-Service -Force
Get-Service Veeam* | Start-Service
Get-VBRSession |
Where-Object { $_.State -ne 'Stopped' } |
Select-Object JobName, State, CreationTime
After the restart, the backup copy job completed successfully. Both copy jobs, the Service Provider rescans and the Cloud Connect repository rescans were then confirmed working with revocation checking still enabled.
For this fault, installing the certificates fixed the underlying validation problem, but restarting the Veeam services on the backup server was still a required final step. A reboot would also clear the cached connections.
A log timestamp trap
One other detail slowed the investigation. Searching for recently modified Veeam logs returned nothing even while Svc.VeeamBackup.log was receiving new entries.
Veeam holds log files open and buffers writes, so filesystem LastWriteTime can lag behind the timestamps of entries already visible in the file. I read the log contents directly and checked the per-job folders under C:\ProgramData\Veeam\Backup rather than relying on file modification times to locate the active log.
What I would check first next time
For the same error, I would start by identifying every tenant-side component that can connect directly to a Cloud Connect gateway. I would then check Cert:\LocalMachine\CA on each one, under the service context where practical.
Get-ChildItem Cert:\LocalMachine\CA |
Where-Object Subject -match "Let's Encrypt|ISRG" |
Format-List Subject, Issuer, Thumbprint
I would also keep these points in mind:
RevocationStatusUnknowndid not clearly describe the fault in this case. The corrective action was to provide the missing intermediate chain certificates locally.- A clean
certutil -verify -urlfetchresult can hide the original condition because the command actively downloads certificate material. - The VBR server is not necessarily the only machine performing validation. Check repositories and proxies as well, even if their hostnames do not appear in the visible exception.
- Restart the Veeam services on the tenant backup server after changing the certificate stores on all connecting components. Otherwise, cached cloud connections may continue returning the original error.
- Read active Veeam logs directly. Do not depend on
LastWriteTimeto identify which log is receiving entries. - Do not disable revocation checking before proving whether chain construction, service context or network access is the real problem.
The confirmed cause in this environment was the absence of YR2 and the cross-signed Root YR certificates from the machine intermediate stores on both tenant-side components. Installing them on both machines and restarting the Veeam services cleared the warning, restored the rescans and allowed both backup copy jobs to complete successfully.
The corrective action was in the Windows machine certificate stores. It did not require a Veeam version change, rollback or certificate-validation workaround. This investigation therefore did not establish Veeam 13.1 as the cause of the failure.
I still cannot prove why AIA-based chain construction worked for six days and then stopped. A cached AIA result expiring would fit the timing, but that remains a possible explanation rather than a demonstrated cause.