Visual Studio & SSL Certificate Errors with Shared Datasets

The Symptom

You're building an SSRS report in Visual Studio (Report Designer / SSDT / RDL project) and reference a shared dataset published on the Report Server. The moment you try to preview the report or refresh the dataset's fields, Visual Studio throws something like:

The underlying connection was closed: Could not establish trust relationship
for the SSL/TLS secure channel.

-- or --

The remote certificate is invalid according to the validation procedure.

Confusingly, opening the exact same Report Server URL in Edge or Chrome works without any warning: the browser trusts the certificate just fine. That mismatch is the key clue: this isn't a broken certificate, it's two different trust stores disagreeing with each other.

Why It Happens

Visual Studio doesn't use the browser's certificate trust decisions or the interactively-managed certificate store the way you might expect. Report Designer's data connection to the Report Server runs through .NET's WebRequest/HttpClient stack, which validates the server certificate against the machine's Local Computer certificate store: specifically, it needs the issuing CA's certificate present in Trusted Root Certification Authorities (or Intermediate Certification Authorities for the chain to resolve) for that machine account, not just the current user's store.

Cause	Why the browser doesn't show it, but VS does
Self-signed certificate, never imported to any trust store	Browser may have a prior manual exception cached, or IT pushed a browser-specific trust override
Internal CA root certificate missing from the machine's Local Computer store	Browser trusts it via a separately-deployed root (e.g. group policy targeting browsers only, or user-store import)
Certificate issued to a different name than the URL used to reach it (name mismatch)	Browser may show a warning too, but users click through; VS's data-connection code has no click-through path
Intermediate CA certificate missing, breaking the chain	Browsers often fetch missing intermediates automatically via AIA; the .NET stack's automatic fetch is less reliable
Certificate imported to the current user store, not local machine	Interactive browser session reads the user store; VS's underlying service context may not

Fix 1: Import the CA Certificate to the Local Machine Store

This is the correct, durable fix for an internal/self-signed CA. Export the Report Server's certificate chain, then import the root (and any intermediate) certificate into the local machine's trusted stores on the developer workstation:

# Run as Administrator in PowerShell
# 1. Export the certificate from the Report Server itself, or obtain the CA root .cer from IT

# 2. Import the root CA certificate to Local Machine \ Trusted Root Certification Authorities
Import-Certificate -FilePath "C:\Certs\InternalRootCA.cer" `
    -CertStoreLocation Cert:\LocalMachine\Root

# 3. If there's an intermediate CA, import it separately to Intermediate Certification Authorities
Import-Certificate -FilePath "C:\Certs\InternalIntermediateCA.cer" `
    -CertStoreLocation Cert:\LocalMachine\CA

Verify the chain resolves cleanly afterward:

$cert = Get-PfxCertificate -FilePath "C:\Certs\ReportServerCert.cer"
$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
$chain.Build($cert)
$chain.ChainStatus   # Should be empty if the chain is fully trusted

Restart Visual Studio after importing: the certificate store cache used by the .NET runtime hosting Report Designer is read at process start.

Fix 2: Confirm the Certificate Name Matches the URL

If the certificate's subject or SAN doesn't match the hostname you're actually connecting to (e.g. the cert is issued for reports.company.com but the Report Server project points at reportsrv01 or an IP address), no amount of trust-store fixing will help, because the name mismatch is a separate validation failure. Check the data source URL in the RDL project's shared data source or connection string, and make sure it uses the exact name the certificate was issued for. This is also the point to check in Report Server Configuration Manager that the URL reservation itself uses the matching hostname/binding.

Fix 3: Missing Intermediate Certificate

If the root CA is trusted but an intermediate CA in the chain is missing, the chain fails to build even though the root is fine. Browsers frequently paper over this by fetching the missing intermediate automatically via the certificate's Authority Information Access (AIA) extension; Visual Studio's connection stack does this less reliably, especially on a locked-down workstation without outbound internet access to fetch it. Import the intermediate explicitly as shown in Fix 1, to Cert:\LocalMachine\CA, rather than relying on automatic fetch.

What Not to Do

Do not disable certificate validation to work around this. Setting ServicePointManager.ServerCertificateValidationCallback to always return true, or similarly bypassing TLS validation in application code that talks to the Report Server, silently defeats certificate validation for that connection entirely, including in any exported or reused connection code that ends up in production. The trust-store fix in Fix 1 solves the actual problem: an untrusted root, not an untrustworthy connection.

Verifying the Fix Without Visual Studio

Before reopening Visual Studio, confirm the machine itself now trusts the Report Server's certificate using a plain PowerShell request: if this succeeds, Visual Studio's data connection will too, since they use the same underlying trust store:

Invoke-WebRequest -Uri "https://reportserver.company.com/ReportServer" -UseBasicParsing

# If this throws the same trust error, the certificate/chain issue isn't fixed yet.
# If it succeeds, Visual Studio should now browse the shared dataset without error.

Checklist

Confirm the failure is trust-related, not a name mismatch: check the certificate's subject/SAN against the URL used
Export the Report Server's full certificate chain (root + any intermediates)
Import the root to Cert:\LocalMachine\Root and any intermediates to Cert:\LocalMachine\CA, not the current-user store
Verify the chain builds cleanly with X509Chain.Build() before touching Visual Studio
Restart Visual Studio so it picks up the updated trust store
Never bypass certificate validation in code as a substitute for fixing the trust store

The Bottom Line

A browser trusting a certificate that Visual Studio rejects almost always means the browser and the .NET data-connection stack are consulting different trust stores, not that the certificate itself is broken. Fix it by getting the issuing CA's certificate into the Local Machine trust store on every developer workstation that needs to browse Report Server datasets; that's the fix that holds up, rather than one that quietly disables the check it was meant to enforce.

← Back to Blog