Certificate validation change with TLS 1.2 minimum and ODBC Driver 18 Encrypt default for Azure SQL Database

Answer to the Core Question

With TrustServerCertificate=false, the Microsoft ODBC Driver 18 delegates all certificate chain verification—including hostname matching against the SAN of *.database.windows.net—to the operating system’s TLS stack.

• Windows (Schannel) performs an online revocation check by default. If a CRL or OCSP endpoint cannot be reached, the TLS handshake fails unless the Schannel policy is altered via the registry.
• Linux (OpenSSL) will, by default, accept the certificate if it cannot perform a revocation check. The default can be overridden with OpenSSL configuration options, but the driver itself does not expose a connection‑string switch for this.

Thus, when revocation endpoints are unreachable:

• On Windows, the connection will fail unless you modify the Schannel policy.
• On Linux, the connection will succeed by default, but you can enforce stricter checks via OpenSSL config if desired.

Can Encrypt=true be Tuned for Revocation Policy?

No. Encrypt=true only guarantees that TLS 1.2+ is used and that the server certificate is validated against the OS trust store. The driver does not expose a parameter to change revocation handling; you must rely on OS‑level settings (Schannel registry keys or OpenSSL configuration). The chain validation remains intact regardless of the revocation mode you choose.

Documented TLS/Driver Compatibility

• TLS minimum: Azure SQL Database accepts TLS 1.2 and higher. The driver will negotiate TLS 1.3 if the client OS supports it.
• Supported platforms:
  • Windows 10 (1809+) / Windows Server 2019+ – Schannel with TLS 1.3 support.
  • Linux distributions with glibc 2.17+ and OpenSSL 1.1.1+ – TLS 1.3 support.
  • All platforms use the OS trust store for certificate validation.

Practical Verification Steps

1. Confirm driver version:

   SELECT @@version;

2. On Windows, inspect the registry:

   reg query HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Parameters /v CertificateRevocationCheck
   reg query HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Parameters /v CertificateRevocationCheckFlags

3. On Linux, test a connection with OpenSSL:

   openssl s_client -connect .database.windows.net:1433 -tls1_2 -CAfile /etc/ssl/certs/ca-certificates.crt -verify 2

4. Enable ODBC tracing (e.g., SET ODBC_TRACE=1) and capture the TLS handshake with Wireshark; verify that the server presents the expected SAN and that TLS 1.2/1.3 is negotiated.

What Do You Need to Know Next?

To give you a concrete recommendation, I need to know which OS/TLS stack your application runs on. This determines whether the default revocation behavior will fail the connection or succeed with a warning.

Question for you: Are you running the driver on Windows (Schannel) or Linux (OpenSSL)?