🔧 SSRS Troubleshooting

Visual Studio & SSL-Zertifikatsfehler bei Shared Datasets

Deine Datenquelle verbindet sich, aber das Shared Dataset schlägt fehl? Das mysteriöse SSL-Problem und seine Lösung.

Phänomen Fehlerbild Ursache Connection String Lösung Tipps Fazit

🧩 Das Phänomen

Du hast eine freigegebene Datenquelle (.rds-Datei) in Visual Studio angelegt. Der Test-Button sagt: ✅ Erfolgreich verbunden. Aber sobald du versuchst, ein Shared Dataset auf dieser Datenquelle zu erstellen, bricht das Projekt zusammen. Die Fehlermeldung spricht von einem SSL-Zertifikat – obwohl du bereits TrustServerCertificate=True gesetzt hast!

Dieses Verhalten ist keine Konfigurationsfehler von dir, sondern eine dokumentierte Eigenheit von Visual Studio und SSDT (SQL Server Data Tools) bei der Behandlung von Metadatenabrufen im 32-Bit-Designer-Prozess.

❌ Das Fehlerbild

Szenario

Die freigegebene Datenquelle (.rds) ist angelegt
Verbindungstest via „Test Connection"-Button funktioniert
Der Connection-String enthält bereits TrustServerCertificate=True (und manchmal Encrypt=False)
Die Datenquelle wird im Berichtsprojekt akzeptiert

📋 Typische Fehlermeldung

Fehler beim Abrufen der Felder
„A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - Die Zertifikatskette wurde von einer nicht vertrauenswürdigen Quelle ausgestellt.)"

oder als Klartext:
„Der Zertifikatsfehler wurde vom Server zurückgegeben. Stellen Sie sicher, dass TrustServerCertificate=True in der Verbindungszeichenfolge enthalten ist."

Das Paradoxe: Die Verbindungszeichenfolge enthält bereits TrustServerCertificate=True – aber der Fehler tritt trotzdem auf!

🔍 Warum passiert das?

Unterschiedliche Treiber-Prozessebenen

Der Test-Button in der .rds-Datei nutzt die .NET Framework-Datenanbieter innerhalb der Visual Studio-Oberfläche (meist 64-Bit).

Der Dataset-Designer hingegen läuft in einem separaten 32-Bit-Prozess (z.B. Microsoft.DataTools.DataSetDesigner) und verwendet mitunter eine eigene, strengere TLS-/SSL-Implementierung.

⚠️ Das Problem

Das TrustServerCertificate=True wird von diesem 32-Bit-Prozess nicht immer korrekt an den zugrundeliegenden Treiber weitergereicht – oder der Treiber erzwingt trotz der Einstellung eine vollständige Zertifikatsvalidierung.

Zusätzlich können Namensauflösungsprobleme (Named Pipes vs. TCP/IP) die Fehler verstärken.

Beispiel: Der Server heißt dev02 (oder localhost), das Zertifikat ist entweder selbstsigniert oder stammt von einer nicht vertrauenswürdigen CA. Der Designer meckert, obwohl die Datenquelle selbst die Zertifikatsprüfung deaktiviert hat.

Connection String: Falsch vs. Richtig

❌ FALSCH (erzeugt den Fehler)

Data Source=dev02; Initial Catalog=amazon; Integrated Security=SSPI; TrustServerCertificate=True;

Warum falsch?
• Verwendet Kurzname (dev02) statt FQDN
• Keine explizite Port-Angabe
• Dataset-Designer ignoriert TrustServerCertificate
• Namensauflösung im 32-Bit-Modus unreliabel

✅ RICHTIG (funktioniert zuverlässig)

Data Source=tcp:dev02,1433; Initial Catalog=amazon; Integrated Security=SSPI; TrustServerCertificate=True; Encrypt=False;

Warum richtig?
• Erzwingt TCP/IP-Protokoll
• Explizite Port-Angabe
• Umgeht Named Pipes-Probleme
• Verschlüsselung deaktiviert

Erklärung der Parameter

Parameter	Wert	Bedeutung
`Data Source`	`tcp:dev02,1433`	Erzwingt TCP/IP-Protokoll und gibt den Port an (Standard 1433). Umgeht Probleme mit Named Pipes/SQL Browser.
`TrustServerCertificate`	`True`	Akzeptiert selbstsignierte oder nicht vertrauenswürdige Zertifikate (nur für Entwicklung!)
`Encrypt`	`False` oder `Optional`	Verhindert, dass der Treiber eine verschlüsselte Verbindung erzwingt, was bei fehlerhaften Zertifikaten zusätzliche Fehler auslösen kann.
`Integrated Security`	`SSPI`	Windows-Authentifizierung (Standard für Entwicklung)

🛠️ Schritt-für-Schritt Lösung

Öffne die .rds-Datei im XML-Editor

Rechtsklick auf die .rds-Datei → „Öffnen mit…" → „XML-Editor"

Ersetze den ConnectionString

Suche das <ConnectionString>-Element und ersetze den Wert durch:

Data Source=tcp:dev02,1433;Initial Catalog=amazon;Integrated Security=SSPI;TrustServerCertificate=True;Encrypt=False;

(Passe dev02 und amazon an deine Umgebung an!)

Speichere und schließe die Datei

Ctrl+S → Datei schließen

Authentifizierung in der GUI bestätigen

In den Properties der Datenquelle: Setze die Authentifizierung explizit auf „Windows-Authentifizierung (integrierte Sicherheit) verwenden"

Visual Studio Cache leeren (optional aber empfohlen)

Schließe Visual Studio → Öffne den Projektordner → Lösche das Verzeichnis .vs → Starte Visual Studio neu

Shared Dataset erneut erstellen

Versuche jetzt, ein neues Shared Dataset anzulegen. Der Fehler sollte nicht mehr auftreten.

💡 Zusätzliche Tipps & Best Practices

TCP-Präfix immer setzen

Verwende tcp:Servername,Port auch wenn der Port 1433 ist. Das ist der Schlüssel zur Zuverlässigkeit.

Für Produktivumgebungen

Installiere ein gültiges SSL-Zertifikat auf dem SQL Server
Setze TrustServerCertificate=False (nicht True)
Verwende Encrypt=True für volle Sicherheit
Die obige Lösung ist nur für Entwicklungs-/Testumgebungen gedacht!

Treiber-Updates

Aktualisiere deine SQL Server-Treiber: Microsoft OLE DB Driver, ODBC Driver 17/18, .NET Framework-Updates
Ältere Treiber sind fehleranfälliger bei SSL-Problemen

Cache leeren bei Problemen

Manchmal hilft es, die temporären Dataset-Dateien manuell zu löschen: *.xsd, *.xss, *.rdl.data
Lösche auch .vs Verzeichnis und das bin/obj Verzeichnis

Windows Event Log prüfen

Öffne die Windows-Ereignisanzeige: Applications & Services Logs → Microsoft → Windows → CertServices
Dort findest du manchmal die exakte Ursache des Zertifikatsfehlers

🧠 Fazit

Das Problem ist keine Konfigurationsfehler!

Es ist eine dokumentierte Eigenheit des Visual Studio-Dataset-Designers, der sich bei der Metadatenabrufe anders verhält als der einfache Verbindungstest.

Die Kombination aus den folgenden drei Punkten löst das Problem in den allermeisten Fällen:

TCP-Erzwingung: tcp:Server,Port
Explizites Vertrauen: TrustServerCertificate=True
Verschlüsselung deaktivieren: Encrypt=False

Wenn der Fehler trotzdem noch auftritt, prüfe die Windows-Ereignisanzeige auf zusätzliche Zertifikatswarnungen – dort findest du oft die exakte technische Ursache.

Noch Fragen?

Falls du weitere ähnliche Probleme in SSDT erlebt hast oder zusätzliche Workarounds kennst, teile sie in den Kommentaren – wir sammeln die besten Lösungen!

📊 Zu ReportServerCheck auf GitHub