MSSQL Archives

Info

Lately when I set up a Microsoft SQL server I’ll always implement SSL and a gMSA account to run SQL from.
Why? Convince yourself reading this blog post.

Because this post focuses on a specific issue, I’ll not explain implementing SSL as such. Here’s the Microsoft documentation I follow for my implementations:
https://support.microsoft.com/en-us/help/316898/how-to-enable-ssl-encryption-for-an-instance-of-sql-server-by-using-mi
This is initially made for SQL 2000, but all buttons and clicks are still the same.

However, the first time I’ve tried combining a gMSA for SQL and configure SSL, SQL wouldn’t start anymore.

The problem

Windows and SQL were friendly enough to provide me with some error messages:

The error number ‘0x80009030d’ suggested (according to a search on Google) an issue with the ‘common name’ used in my certificate.

In my troubleshooting process I’ve tried the following:

Remove the SSL configuration from SQL: SQL started
Tried a whole bunch of certificates since the suggestion the ‘common name’ in the certificate was wrong.
Grant the gMSA account the Windows Administrator role: SQL started with SSL configuration.

After this last step I’ve concluded that the issue must be rights related. Which was actually a good thing. Rights can be added, I knew where to look.
A few troubleshooting hours later I came up with the solution.

Solution

Here’s what you need to do:
Give the gMSA account read acces on the private key of your certificate stored in the certificate store of the computer account.

Here’s how you do it:
1. Open the certificate store for the local computer (when logged in to the SQL server):