TLS and Microsoft SQL Server 2022

Transport Layer Security (TLS) for SQL Server 2022 has numerous benefits. TLS enhances SQL Server security by providing authentication, encrypting data in transit, ensuring regulatory compliance, and following security best practices. It helps prevent unauthorized access, protects sensitive information, and mitigates interception attacks, making it a critical component of a secure database environment.

Self-Signed Certificates

When installing Microsoft SQL Server 2022 on-premises, a self-signed certificate is automatically created to support Transport Layer Security (TLS) connections to the database. From a security perspective, using unmanaged, self-signed certificates is never a good idea.

Risk

Self-signed certificates are insecure because they are not issued by a trusted Certification Authority (CA), making it impossible to verify the legitimacy of the server. This lack of trust enables attackers to intercept and manipulate data through interception attacks. Additionally, since operating systems do not automatically trust self-signed certificates, users may ignore security warnings, increasing the risk of connecting to malicious or compromised servers.

Enterprise PKI Certificates

For production workloads, security best practices dictate using enterprise PKI-issued and managed certificates, which provide many security benefits.

Authentication

TLS with managed certificates provides a mechanism for server authentication, ensuring that clients connect to a legitimate server and not an impostor. TLS authentication helps mitigate interception attacks where an attacker could potentially impersonate the server. Managed TLS certificates can also be revoked in the event of key compromise.

Data Encryption

Microsoft SQL Server 2022 database servers often store sensitive data, including personal details, financial records, and other confidential business information. TLS ensures that data in transit between the client and the server is encrypted using modern cryptography, which enhances privacy and confidentiality while preventing unauthorized interception and eavesdropping.

Compliance Requirements

Many regulatory frameworks and compliance standards, such as GDPR, HIPAA, or PCI-DSS, require or strongly recommend encrypting data in transit. Enabling TLS on SQL Server helps meet these compliance standards, strengthens internal security protections, and avoids potential penalties.

Security Best Practice

Implementing TLS is considered a fundamental security best practice in network and data communication. It reduces the risk of data breaches and enhances the overall network security posture in the enterprise.

TLS and SQL Server 2022

Microsoft SQL Server 2022 includes critical new options for administrators. The “Force Encryption” and “Force Strict Encryption” flags control how encryption is enforced for client connections, but their behavior and compatibility requirements differ.

Force Encryption

When this setting is enabled, the SQL server will encrypt communication between the client and server using TLS. However, contrary to what the name of the setting implies, it is possible for the server to accept unencrypted connections in some cases. If the client does not support encryption, the connection may still succeed without encryption. Enabling Force Encryption prioritizes encryption but does not strictly enforce it, meaning older clients that do not support encryption can still connect. Administrators can use this setting to ensure backward compatibility for applications that may not support strict encryption policies. However, upgrading applications to support encryption is strongly advised.

Force Strict Encryption

This setting is subtly different than the previous setting. It also ensures that all communication between the client and the server is encrypted without exception. If a client does not support encryption, the connection will be rejected. In addition, this setting enforces enhanced security parameters for the connection, such as certificate validation, more secure TLS cipher suites, and the use of TLS 1.3* when available. Force Strict Encryption is designed for modern security compliance. It is the preferred setting and should be used when all clients are known to support encryption.

* Note: TLS 1.3 is supported with SQL Server 2022 cumulative update 1 or later installed.

Key Differences

The following table summarizes the key differences between Force Encryption and Force Strict Encryption.

Force EncryptionEncourages but does not require encryption. Unencrypted connections may still be allowed.
Force Strict EncryptionRequires encryption for all connections. Clients that do not support encryption will be rejected.

Summary

By securing your Microsoft SQL Server with TLS, you significantly enhance the security, reliability, and trustworthiness of your data management systems. In the next post, I’ll provide detailed step-by-step guidance for enabling and configuring TLS on Microsoft SQL Server 2022 using best security practices.

Additional Information

Step-by-Step Guide: Enable TLS in Microsoft SQL Server 2022

VIDEO: Enable TLS in Microsoft SQL Server 2022

Microsoft SQL Server 2022

Always On VPN Security Updates February 2025

After a few months without any security updates directly affecting Microsoft Always On VPN administrators, the February 2025 security updates include fixes for two vulnerabilities in Windows Server Routing and Remote Access Service (RRAS) servers, commonly deployed to support Always On VPN.

RRAS Updates

This month’s updates for Windows Server RRAS cover the following publicly announced CVEs.

Importance

Both updates are for heap-based buffer overflow Remote Code Execution (RCE) vulnerabilities. These vulnerabilities are rated as important and require user interaction to execute, making exploitation less likely.

KB5014754

Importantly, this month’s release enables full enforcement of strong certificate mapping on Windows domain controllers by default. Full enforcement for strong certificate mapping was first introduced with Microsoft security update KB5014754. I’ve written about this recently, so hopefully, everyone is prepared! If your Always On VPN connections begin to fail after applying the February 2025 security updates to your domain controllers, your certificates may not be strongly mapped. Fortunately, there’s a workaround. You can learn more here.

Additional Information

Microsoft February 2025 Security Updates

Strong Certificate Mapping Enforcement February 2025

KB5014754 Certificate-based Authentication Changes on Windows Domain Controllers

Always On VPN Windows Server 2025 Binding Handle is Invalid Error

Microsoft released Windows Server 2025 late last year. I’ve been doing extensive testing with the Routing and Remote Access (RRAS) role, commonly deployed to support Always On VPN client connections. I heavily use automation to deploy VPN servers in my lab and for large customer deployments, and after deploying some new Windows Server 2025 machines, I encountered the “binding handle is invalid” error message when running specific commands.

VPN Ports

By default, Windows Server RRAS enables IKEv2 for Remote Access (RAS) and SSTP for RAS and Routing. Each is provisioned with 128 ports. Often, these settings are updated because there are not enough ports to support expected concurrent connections. Also, SSTP should not be enabled for Routing as it is not required, and PPPoE is enabled for Routing, which is also not required. The best practice is to disable any protocols and services that are not being used.

Although updating these settings can be updated in the GUI (rrasmgmt.msc), automating these changes requires command line configuration.

Netsh

Here’s the command to configure additional SSTP ports and disable Routing using netsh.exe.

netsh.exe ras set wanports device = “WAN Miniport (SSTP)” rasinonly = enabled ddinout = disabled ddoutonly = disabled maxports = 500

However, running this command returns the following error message.

“The binding handle is invalid.”

PowerShell

You might be wondering why we don’t use PowerShell for these tasks. Sadly, not all these settings are exposed via PowerShell. For example, with the native Set-VpnServerConfiguration PowerShell command, you can set the number of ports for IKEv2, SSTP, L2TP, and GRE. However, you cannot turn these protocols on or off entirely as you can with netsh.exe commands.

Here’s an example of setting up VPN server port configuration using PowerShell.

Set-VpnServerConfiguration -SstpPorts 500 -Ikev2Ports 500 -PassThru

Note: You must restart the server (not just the RemoteAccess service) when increasing the number of ports beyond the default setting of 128.

Set-VpnServerConfiguration does not support configuration for PPTP. However, PPTP is disabled by default on Windows Server 2025.

Backup and Restore

This issue will also impede the ability to back and restore the RRAS configuration using netsh.exe. You can back up the RRAS configuration by running the following command.

netsh.exe ras dump | Out-File rasconfig.txt -Encoding ascii

You can restore the configuration by running the following command.

netsh.exe exec .\rasconfig.txt

However, you will receive “binding handle is invalid” error when running this command.

AovpnTools

Be advised that the following functions in my AovpnTools PowerShell module use netsh.exe commands that will return the “binding handle is invalid” error message when configuring Windows Server 2025 servers.

Workaround

Until Microsoft resolves this issue, administrators must use a combination of the native PowerShell commands and manual configuration using the Routing and Remote Access management console (rrasmgmt.msc) to implement these settings changes. When backing up and restoring the RRAS configuration, additional configuration will be required after configuration import to ensure the VPN server port configuration is configured correctly.

Additional Information

Always On VPN PowerShell Module on GitHub