SQL Server Error 772: Encryption Not Supported on the Client

What Is SQL Server Error 772?Error 772 signals that the client failed the TLS handshake because SQL Server is configured with Force Encryption = Yes. The connection is rejected before login completes.SQL Server raises the error during the pre-login handshake. The server demands TLS; the client replies without TLS support, so the session is terminated and error 772 is returned.

What Causes This Error?

Out-of-date drivers trigger the error most often. SQL Native Client 10/11, jTDS, and legacy FreeTDS builds cannot speak modern TLS 1.2.Disabled TLS protocols on the operating system break the handshake. If TLS 1.0/1.1 are disabled and the client can’t do TLS 1.2, error 772 follows.Self-signed or untrusted certificates cause some drivers to refuse encryption, again leading to 772 if TrustServerCertificate is false.

How to Fix SQL Server Error 772

Upgrade the client to Microsoft ODBC Driver 17/18 or the latest MSOLEDBSQL. These drivers fully support TLS 1.2 and certificate validation.If an upgrade is impossible, set Force Encryption = No in SQL Server Configuration Manager, then restart the SQL Server service.As a temporary workaround, keep Force Encryption enabled but add TrustServerCertificate=True or encrypt=true in the connection string to bypass validation.

Common Scenarios and Solutions

PowerShell/Sqlcmd fails: Install ODBC Driver 18 and retry; sqlcmd will automatically negotiate TLS.Java with jTDS: Switch to Microsoft JDBC Driver 12+ and add encrypt=true;trustServerCertificate=false to enforce secure TLS.Linux containers: Copy the root CA chain that signed the server certificate into /etc/pki/ca-trust so the driver accepts it.

Best Practices to Avoid This Error

Standardize on the latest Microsoft-supported client drivers across all hosts and CI/CD images.Monitor driver versions with configuration management tools and alert when outdated packages are detected.Use certificates from a trusted public CA or a well-configured private PKI so clients don’t need to ignore validation.

Related Errors and Solutions

Error 20: Generic network or instance-specific connection error—often accompanies 772. Fixing TLS support resolves both.Error 768: ‘The certificate chain was issued by an untrusted authority.’ Install or trust the issuing CA to clear it.Error 799: ‘Client requested an invalid encryption level.’ Ensure Encrypt=True and TrustServerCertificate=False with valid certs.

Using legacy SQL Native Client 11.0 on Windows 2012 or earlier.

Running Java apps with jTDS that lacks TLS 1.2 support.

Server has Force Encryption enabled after hardening but clients weren’t upgraded.

TLS 1.0/1.1 disabled via OS registry without updating drivers.

Error 20 – Network-related or instance-specific error.Error 768 – Certificate chain not trusted.Error 799 – Invalid encryption level requested.Error 18456 – Login failed (often secondary after 772 is resolved).

Does disabling Force Encryption reduce security?

Yes. Data travels unencrypted. Prefer upgrading clients to TLS-capable drivers instead of disabling encryption.

Can I bypass certificate validation safely?

Use TrustServerCertificate=True only as a stop-gap. Deploy a trusted certificate quickly thereafter.

Which drivers fully support TLS 1.2?

Microsoft ODBC Driver 17/18, Microsoft JDBC Driver 8/9/10/12, and MSOLEDBSQL 19+ support TLS 1.2 out of the box.

How does Galaxy help avoid Error 772?

Galaxy ships with the latest Microsoft drivers and automatically negotiates TLS 1.2, ensuring encrypted connections from the editor without extra setup.