Detent PointDomain: SQL Database Engine · Risk: Changes state · Runs on: Windows, PowerShell 5.1 or 7
This is the step that actually points SQL Server at the certificate. It’s a small, precise change — writing the certificate’s fingerprint into the setting SQL Server reads at startup. It behaves the same whether the target is a plain server, a clustered instance, or an Always On availability group, so your team learns it once.
Writes the thumbprint into SuperSocketNetLib in the registry (StrictMode-safe instance-id resolution). Restarting the SQL service to apply is the caller’s responsibility. Never throws. The write is per-instance and identical across topologies — an Always On replica is bound exactly like a standalone instance.
Recipe 01 — Bind the default instance
Set-SqlCertBinding -SqlInstance 'MSSQLSERVER' -Thumbprint $tpRestart the SQL service to apply.
Recipe 02 — Bind a named instance and force encryption
Set-SqlCertBinding -SqlInstance 'HOST\SQL2019' -Thumbprint $tp -ForceEncryptionForce Encryption makes the instance reject unencrypted clients — validate in a test environment first.
Recipe 03 — Bind several instances in one call
Set-SqlCertBinding -SqlInstance 'MSSQLSERVER','HOST\SQL2019' -Thumbprint $tpRecipe 04 — Bind on a remote node
Set-SqlCertBinding -SqlInstance 'MSSQLSERVER' -Thumbprint $tp -Node SQL02 -Credential $credWatchpoint — a restart is required. The registry write is instant; SQL loads the cert on the next service start. Confirm with Test-SqlCertBinding, and confirm the running instance loaded it via the SQL error log line “successfully loaded for encryption.”
SQL Server decides which certificate to use by reading one registry value at startup. This command writes the certificate’s fingerprint into that value. After the next service restart, SQL uses that certificate for encrypted connections.
Two things to remember: the change takes effect on restart, not instantly; and there’s a separate switch, -ForceEncryption, that tells SQL to require encryption. Leave that off until you’ve confirmed clients can still connect.
| Question | Answer |
|---|---|
| Outbound calls? | None. It writes one registry value on the local (or named) machine. |
| What it changes | The Certificate value under the instance’s SuperSocketNetLib key; optionally ForceEncryption. |
| Privileges | Local admin (the key is under HKLM). |
| Reversibility | Fully reversible — clear the value and restart. |
| Dependency | Why | Required? |
|---|---|---|
| Windows + PowerShell 5.1 or 7 | Writes the registry binding. | Yes |
| The certificate installed, with key access granted | SQL must be able to read the key it’s pointed at. | Yes |
| A SQL service restart | The binding loads on the next start. | To go live |
- Force Encryption is opt-in. The switch that rejects unencrypted connections is never set implicitly, so an operator can’t accidentally cut off clients.
- The bound thumbprint is returned for the record, and
Test-SqlCertBindingreads it back independently for verification. - Identical behaviour across standalone / FCI / Always On means one documented, reviewable procedure covers every SQL topology — no special-case scripts to audit.