Use this workflow for SQL Server on a Windows Server that you administer. Inventory the SQL Server release, instance name, service identity, client drivers and every hostname applications use. Reserve a maintenance window for the SQL service restart and prepare an authorized recovery route. Hosted shared databases may require the service administrator to perform the server changes.

1. Check compatibility and the required names. Choose encryption settings supported by the installed engine and all client drivers. Include the actual DNS names and applicable aliases in the certificate SAN. Availability-group listeners, replicas and cluster instances need their documented multi-node certificate design; do not treat a single-server procedure as a complete cluster rollout.
2. Obtain a suitable certificate. Use a trusted issuing authority and the Server Authentication purpose. Verify the validity dates and private key. Microsoft currently documents AT_KEYEXCHANGE with a legacy cryptographic service provider for Windows SQL Server certificates. Check these requirements against your installed version instead of assuming that every certificate suitable for IIS is suitable for SQL Server.
3. Install and authorize the private key. Install the certificate in the appropriate local computer certificate store using the supported certificate-management route. Give the SQL Server service identity the required read access to its private key. Protect any exported PFX and its password; do not place them in the website directory or send them in an ordinary support message.
4. Prepare trust and select the certificate. Ensure each client trusts the issuing chain and will connect through a name present in the certificate. Configure its supported driver to request encryption and validate the certificate using the documented settings. Open the version-appropriate SQL Server Configuration Manager. Under SQL Server Network Configuration, inspect Protocols for the intended instance and its Certificate setting. Select the validated certificate and record the previous selection. If it is missing, investigate certificate requirements and key access rather than entering an unverified registry thumbprint. Restart the SQL Server service during the planned window before testing the new certificate. The new selection requires this restart even when Force Encryption remains off.
5. Test validating client connections. After the restart, test representative applications with certificate validation enabled before making encryption mandatory for all clients. Driver upgrades can change encryption defaults, so inspect the effective connection behavior.
6. Apply server-wide enforcement deliberately. If the service policy requires all clients to encrypt, enable Force Encryption for the instance after compatibility testing, then restart the SQL Server service again during the approved window if that setting changes. Strict encryption is an additional version-dependent option, introduced with SQL Server 2022, and requires compatible clients. TLS 1.3 support also depends on engine, OS and driver versions.
7. Verify a real network connection. Connect from an application host using the production-style DNS name and a validating client configuration. An authorized administrator can inspect encrypt_option in sys.dm_exec_connections for the relevant network session. Exclude a local shared-memory connection from this network test. Confirm both successful encryption and the expected certificate identity.
8. Test the application and monitor. Exercise connection pooling, scheduled jobs and integrations that use different drivers or service identities. Review SQL startup and application connection logs. Add certificate-expiry monitoring and record the instance, certificate thumbprint, covered names and renewal owner.

Run this query in the SQL client connection you want to test. It inspects the current session only and requires permission to view the relevant connection data on your SQL Server version. It does not modify encryption policy or certificate configuration.

SELECT session_id, net_transport, encrypt_option, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Read the result: An encrypted connection reports the corresponding encryption state for this session. It does not prove that the client validated the server hostname or trusted chain, because clients can be configured to accept an unverified certificate. A shared-memory local connection also differs from the remote TCP path your application uses.

Review the actual driver settings, such as its encryption and certificate-validation options, alongside the server certificate requirements. Retest using the application's hostname and connection path. Avoid presenting a successful encrypted session with certificate trust bypassed as a complete production security check.

Encryption and certificate validation are separate checks. The client may lack the issuing CA chain, use a hostname absent from the certificate, have an incorrect clock or see an expired certificate. Repair the specific trust or naming problem. Do not keep TrustServerCertificate enabled as the permanent substitute for a correctly validated server identity.

Use the maintenance recovery route and read the SQL error log. Revert the certificate selection or enforcement setting to the documented working configuration if required, then investigate private-key permissions and certificate compatibility. Avoid repeated blind restarts. Keep the previous valid certificate until the replacement and all dependent clients have been verified.

• Replacing an expiring Windows Server certificate without breaking bindings
• Diagnosing SQL Server application login failures
• Verifying Windows Server time synchronization
• Responding to unexpected SQL Server transaction-log growth

• SQL Server certificate requirements
• Configure SQL Server encryption
• Strict encryption
• TLS 1.3 support

• Microsoft: SQL Server connection properties