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

Azure SQL Database enforces a minimum TLS version for client connections and presents an X.509 certificate issued for the *.database.windows.net namespace. Client drivers such as Microsoft ODBC Driver 18 default to Encrypt=true with TrustServerCertificate=false, making certificate chain and hostname validation mandatory at connection time.

The design goal is to maintain consistent, validated encrypted connectivity across a heterogeneous client fleet while respecting the TLS 1.2 compatibility boundary and the requirement that DNS resolution returns the logical server name for SAN validation.

Operational uncertainty remains around certificate revocation checking when outbound CRL or OCSP endpoints are unreachable. Behavior diverges across client libraries and OS trust stores, creating a decision point between network access for revocation and client revocation policy configuration. DNS caching in resolvers or connection pools can also retain stale addresses after failover, which is relevant because validation is bound to the hostname.

What client library and OS trust store behavior is expected when CRL or OCSP endpoints are unreachable for Azure SQL Database certificates with TrustServerCertificate=false? Does the Encrypt=true default allow configurable revocation checking modes without disabling chain validation? What documented compatibility boundary exists for the TLS minimum and driver defaults across supported versions?