The infrastructure team renews the certificates on all servers, just like every year, and removes the old ones. Nobody knew that SQL Server was using one of them. At the next restart, the service fails to start. The System log says only "Cannot find object or property", and the application goes down.

That's what happened at a customer, and it can happen anywhere certificates exist but nobody owns them: Those who roll them out don't know who uses them, and those who use them only notice the change when something breaks. This session is about changing that, with the tools a DBA has at hand.

First, the fundamentals, as far as a DBA needs them: Who does the client actually trust, what does TrustServerCertificate really mean, and why do connections that have worked for years suddenly fail with newer drivers such as Microsoft.Data.SqlClient, ODBC Driver 18 or OLE DB Driver 19? Then the practical part: Which certificate is suitable, including for an availability group? How do you find out which one the instance is currently using, and how do you check that regularly? And how do you replace it? On a standalone instance, that requires a restart; in an availability group, a failover with just a few seconds of interruption. Plus the failure patterns: The certificate is missing, the service account can't read the private key, the certificate has expired. The first two end with the same error code, the third is only noticed by the client. I'll show how to tell them apart anyway.

And because I prefer to verify claims rather than take them at face value: According to Microsoft's documentation, certificates whose key is stored in a Key Storage Provider aren't compatible with SQL Server. Such certificates are created, for example, from certificate templates based on CNG. In the lab, SQL Server 2019, 2022 and 2025 used them without complaint. The widely used check code, however, including Microsoft's own example, silently classifies exactly these certificates as unusable. If you check your certificates with your own PowerShell scripts, you should know this. I've already fixed it in dbatools.

The session is aimed at DBAs who run SQL Server and at the colleagues who provide them with certificates. After this session, you'll know which certificate your instances use, check it regularly, find the cause of a startup failure in the event log and coordinate the next certificate change with the people who roll out the certificates, before it causes an outage. All scripts will be available on GitHub afterwards.