Replace the SQL Server TLS Certificate

The SQL Server Database Engine selects a TLS certificate per instance. The certificate must be in the Local Computer store on the host, readable by the SQL Server service account, selected for the instance, and activated by restarting the instance.

Before you beginCopy Anchor Link

• Get a certificate that meets Microsoft's requirements for SQL Server: Server Authentication EKU, a private key, and the names clients connect with (server FQDN, availability group listener, failover cluster virtual name) in the subject or SAN.
• Record the instance, its service account, the current certificate thumbprint, the Force Encryption setting, availability group listeners and cluster nodes.
• Find the service account in SQL Server Configuration Manager > SQL Server Services (column Log On As). The default is a virtual account such as NT Service\MSSQLSERVER.
• Keep the old certificate in the store until the new one is verified - it is your rollback.
• Schedule a failover or a maintenance window: restarting the Database Engine disconnects clients.

How SQL Server picks a certificateCopy Anchor Link

SQL Server uses, in this order:

1. The certificate selected in SQL Server Configuration Manager (stored as a thumbprint in the instance's SuperSocketNetLib\Certificate registry value).
2. If none is selected: a certificate from the Local Computer store whose subject contains the machine FQDN and whose private key the service account can read - even if nobody selected it.
3. Otherwise a self-generated certificate.

So select the new certificate explicitly. Leaving the selection empty and relying on step 2 can make SQL Server pick a certificate you did not intend.

Step-by-step certificate replacementCopy Anchor Link

With SQL Server Configuration Manager 2019 or laterCopy Anchor Link

From SQL Server 2019, Configuration Manager has integrated certificate management: it imports the certificate, grants the service account access to the key and selects it for the instance - for a single instance, a failover cluster instance or an availability group. Microsoft describes the screens in Certificate management (SQL Server Configuration Manager) (linked under Sources). This Configuration Manager also works for older SQL Server versions; Microsoft suggests installing it from a SQL Server 2019 or later Express setup if needed. Restart the instance afterwards (for a failover cluster instance, see below).

Manually (any version)Copy Anchor Link

1. Import the PFX into Certificates (Local Computer) > Personal on every node that can host the instance or an availability group replica.

2. In certlm.msc (the Local Computer certificates console), right-click the certificate > All Tasks > Manage Private Keys and give the SQL Server service account Read. Without it, the service can fail to start.

3. In SQL Server Configuration Manager, open SQL Server Network Configuration > Protocols for <instance> > Properties > Certificate and select the new certificate.

4. Restart only that SQL Server service, in the maintenance window:

   Copy Text

   Restart-Service MSSQLSERVER        # default instance
   # Restart-Service 'MSSQL$INSTANCE' # named instance

5. Availability groups only: repeat on every replica. Microsoft's procedure starts with the primary replica; fail the availability group over before restarting a replica that is currently primary.

Force Encryption (on the Flags tab) is a separate decision: it makes the server require encryption from every client. From SQL Server 2022 there is also Force Strict Encryption (TDS 8.0). Neither belongs in a routine renewal unless you plan the client impact.

Failover cluster instances and wildcardsCopy Anchor Link

Two cases need the registry value HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\<instance>\MSSQLServer\SuperSocketNetLib\Certificate set by hand - the certificate's thumbprint, without spaces:

• Failover cluster instance (manual path): Microsoft notes that this value is empty on cluster nodes even though the certificate is in the store. Install the certificate (with key permission) on every node, then on each node in turn: set the value, fail the SQL Server role over to another node, and restart the node where you changed the registry. The certificate must carry the cluster's virtual server name. Start and stop a clustered instance through Failover Cluster Manager, not with Restart-Service.
• Wildcard certificate: Configuration Manager cannot select a wildcard certificate. Import it and grant the key permission as in steps 1-2, then set its thumbprint in the registry value instead of step 3.

Read the thumbprint without spaces with:

Get-ChildItem Cert:\LocalMachine\My | Format-Table Thumbprint,Subject,NotAfter

<instance> in the path is the instance ID, for example MSSQL16.MSSQLSERVER. Before SQL Server 2022 CU22 and SQL Server 2025, Configuration Manager only shows a certificate set through the registry if the thumbprint's upper/lower case matches the store exactly; SQL Server still uses it.

Verify the new certificateCopy Anchor Link

1. Check that the selection (Configuration Manager, or the registry value) shows the new thumbprint.
2. After the restart, check the SQL Server error log (in SSMS under Management > SQL Server Logs). The message "A self-generated certificate was successfully loaded for encryption" means your certificate was not used.
3. Connect from a client with encryption and certificate validation - for example SSMS with Encrypt set to Mandatory and Trust server certificate cleared, using the exact server or listener name. That only succeeds if the server presents a valid certificate for that name, so it proves your certificate is in use.
4. Check that connections are encrypted:

SELECT DISTINCT encrypt_option
FROM sys.dm_exec_connections
WHERE net_transport <> 'Shared memory';

TRUE means encrypted. On its own this does not prove which certificate is used - a self-generated one also encrypts - so step 3 is the real test. Never test with TrustServerCertificate=True, which hides name and trust problems.

If the service does not startCopy Anchor Link

Check the SQL Server error log file and the Windows Application event log for the reason. The most common cause is a missing key permission: grant it (step 2) and start the service again. To get the instance running immediately, clear the certificate selection (Configuration Manager, or empty the registry value) - it then starts with a self-generated certificate - and fix the certificate afterwards.

RollbackCopy Anchor Link

Select the old certificate again in Configuration Manager (or restore the old thumbprint in the registry value), check its key permission, and restart the instance. This only works while the old certificate is still in the store and valid. In a high-availability setup, fail back only after the restored node passes a client test.

Common problemsCopy Anchor Link

• The service account cannot read the private key, so the instance does not start.
• The SAN lacks the availability group listener, cluster name or client alias.
• The certificate is in the Current User store instead of Local Computer.
• Only the current primary replica or one cluster node was updated.
• No certificate was selected, and SQL Server picked another certificate from the store.
• Clients hide trust or name failures with TrustServerCertificate=True.

Automating certificate replacement with aethercertCopy Anchor Link

The aethercert SQL Server target imports the certificate, can grant the configured SQL service account private-key read access, writes the instance certificate selection, and can restart the service when explicitly enabled.

See Deploy targets for the fields this preset takes, what it needs on the host, and how far it has been verified.

SourcesCopy Anchor Link

• Microsoft Learn: encrypt connections by importing a certificate
• Microsoft Learn: certificate requirements for SQL Server
• Microsoft Learn: certificate management in SQL Server Configuration Manager