Das Infrastruktur-Team erneuert die Zertifikate auf allen Servern, so wie jedes Jahr, und räumt die alten ab. Dass der SQL Server eines davon benutzt hat, wusste niemand. Beim nächsten Neustart startet der Dienst nicht mehr. Im System-Protokoll steht nur „Cannot find object or property“, und die Anwendung fällt aus.

So war es bei einem Kunden, und so kann es überall passieren, wo Zertifikate zwar vorhanden sind, aber niemand sie betreibt: Wer sie ausrollt, weiß nicht, wer sie benutzt, und wer sie benutzt, merkt den Tausch erst am Ausfall. In diesem Vortrag geht es darum, das zu ändern, und zwar mit den Mitteln, die ein DBA hat.

Zuerst die Grundlagen, soweit ein DBA sie braucht: Wem vertraut der Client eigentlich, was bedeutet TrustServerCertificate wirklich, und warum scheitern mit neueren Treibern wie Microsoft.Data.SqlClient, ODBC Driver 18 oder OLE DB Driver 19 Verbindungen, die jahrelang funktioniert haben? Dann die Praxis: Welches Zertifikat ist geeignet, auch für eine Verfügbarkeitsgruppe? Wie findet man heraus, welches die Instanz gerade benutzt, und wie prüft man das regelmäßig? Und wie tauscht man es aus? Bei einer Einzelinstanz geht das nicht ohne Neustart, in einer Verfügbarkeitsgruppe per Failover mit wenigen Sekunden Unterbrechung. Dazu die Fehlerbilder: Das Zertifikat fehlt, das Dienstkonto darf den Schlüssel nicht lesen, das Zertifikat ist abgelaufen. Die ersten beiden enden mit demselben Fehlercode, das dritte fällt erst dem Client auf. Ich zeige, woran man sie trotzdem auseinanderhält.

Und weil ich Aussagen lieber nachprüfe, als sie zu übernehmen: Laut Microsoft-Dokumentation sind Zertifikate, deren Schlüssel in einem Key Storage Provider liegt, nicht mit SQL Server kompatibel. Solche Zertifikate entstehen zum Beispiel aus Zertifikatvorlagen, die auf CNG setzen. Im Labor haben SQL Server 2019, 2022 und 2025 sie klaglos benutzt. Der verbreitete Prüfcode dagegen, auch Microsofts eigenes Beispiel, stuft genau diese Zertifikate stillschweigend als unbrauchbar ein. Wer seine Zertifikate mit eigenen PowerShell-Skripten prüft, sollte das wissen. In dbatools habe ich das bereits korrigiert.

Der Vortrag richtet sich an DBAs, die SQL Server betreiben, und an die Kolleginnen und Kollegen, die ihnen die Zertifikate bereitstellen. Wer den Vortrag gehört hat, weiß, welches Zertifikat die eigenen Instanzen benutzen, prüft es regelmäßig, findet die Ursache eines Startfehlers im Ereignisprotokoll und spricht den nächsten Tausch mit denen ab, die die Zertifikate ausrollen, bevor er zum Ausfall wird. Alle Skripte gibt es im Anschluss auf GitHub.