Automated SSL certificate renewal for SQL Server

SQL Server binds its TLS certificate by thumbprint in the registry. CertKit keeps it current.

SQL Server loads its TLS certificate from a thumbprint stored in the instance's SuperSocketNetLib registry key. When the certificate renews, the thumbprint changes but the registry doesn't, so encrypted connections keep riding on the old certificate until someone rebinds and restarts the instance. Every 47 days. And now that ODBC 18 and current .NET drivers encrypt by default, an expired or untrusted certificate isn't cosmetic. Applications fail to connect.

CertKit centralizes certificate issuance and renewal, then pushes the renewed certificate to your SQL Servers via the CertKit Agent, updates the thumbprint binding, and restarts the service in a window you choose.

Start free trial Watch demo

Built for SQL Server

The pre-built SQL Server deployment template ships in your CertKit account. No scripting required.

The CertKit Agent imports the renewed PFX into the Windows Certificate Store, writes the new thumbprint into the instance's SuperSocketNetLib registry key, and restarts the SQL Server service so encrypted connections come back on the current certificate. The same registry binding that works when the Configuration Manager dropdown shows nothing.

The pre-built SQL Server template ships with your CertKit account. Set the instance key once. CertKit handles every renewal after that.

How to install an SSL certificate on SQL Server

The manual process, if you want to do it yourself:

Get a certificate matching the server's FQDN. The name clients put in their connection strings. A wildcard certificate works.
Import the PFX into the computer store. Local Machine → Personal on the SQL Server, with the private key.
Grant the service account access to the private key. In certlm.msc, Manage Private Keys → add read access for the SQL Server service account. Skip this and the service refuses to start after you bind.
Bind the certificate. Select it on the Certificate tab in SQL Server Configuration Manager. When the list is blank, which is normal for wildcard certificates or any name mismatch, write the thumbprint into the instance's SuperSocketNetLib registry key instead.
Restart and verify. Restart the SQL Server service, confirm clients connect encrypted with Encrypt=yes and no trust errors, then repeat on every instance and every server.

Every one of these steps is manual, and SQL Server won't repeat any of them for you when the certificate renews. With lifetimes shrinking to 47 days, installation stops being an annual chore and becomes a recurring task: eight times a year, on every instance. Miss one and every application with an encrypted connection string starts throwing "certificate chain not trusted" at once.

At 47 days, automation is the only sustainable way to run SQL Server certificates. Here's how CertKit does it.

How it works

 Your SQL Server           CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └───────────┬────│DNS│
│ Cert store  ◄─┘ │ │                 │    └───┘
│ [x] Updated     │ │                 │
│                 │ │                 │
│ Registry bind ◄─┘ │ ◄───────────────┘
│ [x] Rebound       │       Verify
└───────────────────┘

CertKit manages issuance and renewal centrally using delegated DNS validation. You create a one-time CNAME record and CertKit handles every ACME challenge after that. Your database servers never run an ACME client and never hold DNS credentials. The agent imports the certificate and rebinds the instance locally.

CertKit is an invaluable tool for administrators managing public TLS certificates in Microsoft environments like Always On VPN (SSTP) and DirectAccess (IP-HTTPS), as it simplifies and fully automates Let's Encrypt certificate issuance and renewal. CertKit eliminates the security risks and complexities of manual DNS challenges or API key exposure.

Richard Hicks, Consultant and Microsoft MVP

Stop shipping TrustServerCertificate=true

When drivers started encrypting by default, the first thing most teams hit was "the certificate chain was issued by an authority that is not trusted." The quick fix that spread everywhere is TrustServerCertificate=true in the connection string, which turns off certificate validation entirely. The connection is still encrypted, but any server that answers can impersonate yours. A publicly trusted certificate that renews itself is the version of this that passes a security review.

This page covers the TLS certificate for encrypted client connections. It is not the TDE certificate, the backup encryption certificate, or CREATE CERTIFICATE objects inside a database. Those live in the database engine, and errors like "cannot find server certificate with thumbprint" during a restore are about them, not TLS.

What CertKit handles

Issue certificates via ACME, centrally. A publicly trusted certificate for the server's FQDN. Your database servers have no ACME configuration, no open ports, no credentials to manage.
Renew automatically before expiry. That one-time CNAME covers every renewal challenge going forward. No intervention required on any server.
Import the PFX into the Windows Certificate Store. The CertKit Agent imports the renewed certificate with its private key on every renewal.
Rebind the instance by thumbprint in the registry. The agent writes the new thumbprint into the instance's SuperSocketNetLib key, the same binding that works when the Configuration Manager list is blank. Wildcard certificates included. Named instances are one change to the instance key in the template.
Restart the SQL Server service. The binding loads at service start, so the agent restarts the instance and the renewed certificate takes over.
Deploy in a window you control. Restarting SQL Server drops client connections, so it shouldn't fire mid-workday. Schedule a deployment window per server and CertKit applies the rebind and restart at 2am Sunday instead of whenever the certificate renews.
Verify the deployment, not just the script. After each renewal, CertKit connects and confirms the new certificate is actually being presented. It checks the serial number, SANs, and expiry. If something is wrong, you find out before your applications do.
Alert on failure. Rebind failures, service restart errors, verification mismatches, and upcoming expirations all generate alerts before they become incidents.
Audit every change. Every issuance, renewal, and deployment is logged with timestamp, certificate, and server. With certificate lifetimes heading to 47 days, that log is your compliance record.

Setup takes about ten minutes

Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit. Every renewal challenge after that is automatic.
Install the CertKit Agent on the SQL Server. One command on the Windows Server running the instance. The agent runs as a Windows service and needs no inbound firewall rules.
Add the SQL Server deployment script. The pre-built template is in your account. Set the instance key if you're not on the default instance, and confirm the SQL service account can read the certificate's private key. CertKit runs the rebind and restart on every renewal.

See the full architecture →

Why importing the certificate isn't enough

SQL Server doesn't pick up whatever certificate is in the store, and the Configuration Manager dropdown makes that worse by filtering hard: a wildcard certificate or any subject that doesn't exactly match the machine name simply doesn't appear, which is why "certificate not showing" is one of the most-searched SQL Server TLS problems. The binding that actually matters is the thumbprint in the registry, and it still points at the old certificate after every renewal.

Scripting it yourself means getting the instance key right per version and instance (MSSQL16.MSSQLSERVER is not universal), formatting the thumbprint the way SQL expects, handling the private key permissions that otherwise stop the service from starting, and restarting the right service name for default versus named instances. We built and tested the deployment so you don't have to. CertKit issues the certificate via delegated DNS validation, then the agent handles the import, the registry rebind, and the restart as one verified step, with no ACME client on the server.

SQL Server is just one part of your Windows stack

Most Windows environments have more than one place where certificates live: IIS, Exchange, SQL Server Reporting Services, and Network Policy Server, plus Azure Key Vault for what runs in Azure. CertKit automates all of it from one account.

See all integrations

Start automating SQL Server certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing