Cifrado y validación de certificados en Microsoft.Data.SqlClient

Descargar ADO.NET

Utiliza la Seguridad de la Capa de Transporte (TLS) para cifrar el tráfico entre tu aplicación y SQL Server. Mantén activada la validación del certificado del servidor para verificar la identidad del servidor. El cifrado sin validación de identidad no protege contra un adversario intermedio que se hace pasar por el servidor.

Microsoft.Data.SqlClient usa Encrypt=Mandatory y TrustServerCertificate=false de forma predeterminada. Encrypt=true es un sinónimo de Mandatory. Para una conexión remota, solicita explícitamente estos ajustes y proporciona un certificado de servidor que el cliente pueda validar:

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

Sustituye los marcadores de posición y utiliza un método de autenticación compatible con el entorno de tu servidor y aplicación. Para Azure SQL o base de datos SQL en Microsoft Fabric, véase Microsoft Entra authentication.

Elige un modo de cifrado

Encrypt Controla si el cliente necesita cifrado. Un servidor también puede requerir cifrado. Esta tabla describe el comportamiento actual sin fijación de certificado:

Úsalos Mandatory para conexiones cifradas a servidores que no soportan TDS 8.0. Úsalo Strict cuando tu endpoint soporte TDS 8.0, incluyendo SQL Server 2022 (16.x) y versiones posteriores. TDS 8.0 soporta TLS 1.2 y TLS 1.3; no requiere TLS 1.3. La versión negociada de TLS también depende del cliente, servidor y configuración del sistema operativo.

Optional No es una solución para errores de certificado. Puede dejar los datos de la aplicación sin cifrar cuando el servidor no requiere cifrado.

Configurar un certificado de servidor verificable

Para la validación normal de certificados:

1. Provisiona un certificado que cumpla con los requisitos de certificado de SQL Server.
2. Incluye el nombre que los clientes utilizan para conectarse en el nombre alternativo del sujeto (SAN) del certificado.
3. Haz que la autoridad certificadora emisora y cualquier certificado intermedio requerido sean confiables en cada host o contenedor cliente.
4. Configure SQL Server para usar el certificado y mantener TrustServerCertificate=false en los clientes.
5. Renovación del certificado de plan antes de la expiración, incluyendo cualquier cambio en los nombres o en las autoridades emisoras.

Un certificado de una autoridad pública o de certificación empresarial puede cumplir estos requisitos. Un certificado empresarial no es automáticamente confiable dentro de un contenedor Linux ni en un ordenador desarrollador separado.

Conéctate mediante un alias

Si la conexión utiliza un alias del Sistema de Nombres de Dominio (DNS) que no está en el certificado, primero considera emitir un certificado que incluya el alias. Alternativamente, se establece HostNameInCertificate al nombre esperado en el certificado:

Server=tcp:sql-alias.contoso.com,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=sql-server.contoso.com;MultiSubnetFailover=true;

HostNameInCertificate cambia el nombre que SqlClient espera durante la validación del certificado. No cambia el destino de la red ni evita las comprobaciones de cadena de confianza y caducidad. Déjalo sin configurar cuando el nombre del servidor ya coincide con el certificado.

Fijar un certificado de servidor específico

ServerCertificate proporciona un archivo de certificado local para la comparación exacta con el certificado del servidor. Los formatos soportados son Privacy-Enhanced Mail (PEM) y Reglas de Codificación Distinguida (DER), incluyendo .cer archivos de certificados. Úsalo con Encrypt=Mandatory o Encrypt=Strict, y mantén TrustServerCertificate=false.

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=Strict;TrustServerCertificate=false;ServerCertificate=C:\certificates\sql-server.cer;MultiSubnetFailover=true;

Distribuye el certificado esperado a través de un canal de confianza y protege el archivo de la sustitución. Una coincidencia exacta de un certificado es una alternativa a la validación normal de la cadena y del nombre, no una comprobación adicional además de esta. Los bytes del certificado deben coincidir; el mismo nombre de asunto o clave pública por sí solo no es suficiente. Un archivo PIN perdido, ilegible, inválido o desajustado no valida la validación.

Acoplar el despliegue del cliente a la rotación de certificados. Actualiza el PIN cuando cambie el certificado del servidor, incluyendo la renovación. No consigas un PIN aceptando un certificado no verificado de la red.

SqlClient no expone una devolución de llamada pública para validación arbitraria del certificado de servidor TLS. AccessTokenCallback controla la adquisición de tokens de autenticación, no la validación TLS.

Certificados de desarrollo y resolución de problemas

Utiliza un certificado de desarrollo confiable con el nombre correcto del servidor. Si usas TrustServerCertificate=true temporalmente con Encrypt=true en un entorno de desarrollo aislado, la conexión se cifra pero el cliente no autentica el certificado del servidor.

Para la configuración del lado del servidor, véase Resumen del Certificado.

Cambios en el cifrado y comportamiento de la validación de certificados

Estas notas de compatibilidad explican los cambios de comportamiento al actualizar aplicaciones antiguas. Las nuevas aplicaciones deben utilizar la configuración actual descrita en este artículo.

Contenido relacionado

• Cadenas de conexión en ADO.NET
• Sintaxis de la cadena de conexión
• Recomendaciones de seguridad