Compartir por

Cifrado de las conexiones a SQL Server en Linux

  • Artigo

Se aplica a: SQL Server - Linux

SQL Server en Linux puede usar Seguridad de la capa de transporte (TLS) para cifrar los datos transmitidos a través de una red entre una aplicación cliente y una instancia de SQL Server. SQL Server admite los mismos protocolos TLS en Windows y Linux: TLS 1.2, 1.1 y 1.0. Aun así, los pasos para configurar TLS son específicos del sistema operativo en el que se ejecuta SQL Server.

Requisitos de los certificados

Asegúrese de que los certificados siguen estos requisitos:

  • La hora actual del sistema debe ser posterior a la propiedad Valid from del certificado y anterior a la propiedad Valid to del certificado.

  • El certificado debe estar destinado a la autenticación del servidor. Esto requiere que la propiedad Enhanced Key Usage del certificado especifique Server Authentication (1.3.6.1.5.5.7.3.1).

  • El certificado se debe crear mediante la opción KeySpec de AT_KEYEXCHANGE. Por lo general, la propiedad de uso de clave del certificado (KEY_USAGE) incluye también el cifrado de clave (CERT_KEY_ENCIPHERMENT_KEY_USAGE).

  • La propiedad Subject del certificado debe indicar que el nombre común (CN) es el mismo que el nombre del host o nombre de dominio completo (FQDN) del equipo servidor.

    Nota:

    Se admiten certificados comodín.

Configuración de bibliotecas OpenSSL para su uso (opcional)

Puede crear vínculos simbólicos en el directorio /opt/mssql/lib/ que hagan referencia a qué bibliotecas libcrypto.so y libssl.so que se deben usar para el cifrado. Esto resulta útil si quiere forzar SQL Server a usar una versión específica de OpenSSL distinta del valor predeterminado que proporciona el sistema. Si estos vínculos simbólicos no están presentes, SQL Server carga en el sistema las bibliotecas configuradas predeterminadas de OpenSSL.

Estos vínculos simbólicos deben denominarse libcrypto.so y libssl.so y colocarse en el directorio /opt/mssql/lib/.

Nota:

Para ver un ejemplo del uso de Let's Encrypt para generar un certificado, consulte la entrada de blog Desbloqueo de la eficacia de los datos en Azure con SQL Server en Linux máquinas virtuales de Azure y búsqueda de Azure AI.

Información general

TLS se usa para cifrar las conexiones de una aplicación cliente a SQL Server. Cuando se configura correctamente, TLS proporciona privacidad e integridad de datos para las comunicaciones entre el cliente y el servidor. Tanto el cliente como el servidor pueden iniciar conexiones TLS.

En la sección siguiente se describe cómo configurar el cifrado iniciado por el cliente.

Generar certificado

/CN debe coincidir con el nombre de dominio completo del host de SQL Server.

Precaución

En este ejemplo se usa un certificado autofirmado. Los certificados autofirmados no se deben usar para escenarios de producción. Debe usar certificados de CA.

Asegúrese de que el grupo o usuario mssql pueda acceder a las carpetas donde se guardan los certificados y claves privadas, y que tiene el permiso establecido en 700 (drwx-----). Puede crear carpetas manualmente con el permiso establecido en 700 (drwx------) y que sean propiedad del usuario o grupo mssql, o bien establecer el permiso en 755 (drwxr-xr-x) y que sean propiedad de otro usuario, pero todavía accesibles para el grupo de usuarios mssql. Por ejemplo, puede crear una carpeta denominada sslcert en la ruta de acceso /var/opt/mssql/ y guardar el certificado y la clave privada con permisos en los archivos establecidos en 600, como se muestra en el ejemplo siguiente.

openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=mssql.contoso.com' -keyout mssql.key -out mssql.pem -days 365
sudo chown mssql:mssql mssql.pem mssql.key
sudo chmod 600 mssql.pem mssql.key
#Saving the certificate to the certs folder under /etc/ssl/ which has the following permission 755(drwxr-xr-x)
sudo mv mssql.pem /etc/ssl/certs/ drwxr-xr-x
#Saving the private key to the private folder under /etc/ssl/ with permissions set to 755(drwxr-xr-x)
sudo mv mssql.key /etc/ssl/private/

Configuración de SQL Server

systemctl stop mssql-server
sudo cat /var/opt/mssql/mssql.conf
sudo /opt/mssql/bin/mssql-conf set network.tlscert /etc/ssl/certs/mssql.pem
sudo /opt/mssql/bin/mssql-conf set network.tlskey /etc/ssl/private/mssql.key
sudo /opt/mssql/bin/mssql-conf set network.tlsprotocols 1.2
sudo /opt/mssql/bin/mssql-conf set network.forceencryption 0
systemctl restart mssql-server

Registro del certificado en el equipo cliente (Windows, Linux o macOS)

  • Si usa un certificado firmado de CA, debe copiar en el equipo cliente el certificado de la entidad de certificación (CA), en lugar del certificado de usuario.

  • Si usa el certificado autofirmado, copie el archivo .pem en las siguientes carpetas correspondientes a la distribución y ejecute los comandos para habilitarlas:

  • Ubuntu: copie el certificado en /usr/share/ca-certificates/, cambie su extensión a .crt y use dpkg-reconfigure ca-certificates para habilitarlo como certificado de CA del sistema.

  • RHEL: copie el certificado en /etc/pki/ca-trust/source/anchors/ y use update-ca-trust para habilitarlo como certificado de CA del sistema.

  • SUSE: copie el certificado en /usr/share/pki/trust/anchors/ y use update-ca-certificates para habilitarlo como certificado de CA del sistema.

  • Windows: importe el archivo .pem como certificado en Usuario actual > Entidades de certificación raíz de confianza > Certificados.

  • macOS:

    • Copie el certificado a /usr/local/etc/openssl/certs

    • Ejecute el comando siguiente para obtener el valor hash:

      /usr/local/Cellar/openssl/1.0.2l/openssl x509 -hash -in mssql.pem -noout

    • Cambie el nombre del certificado al valor. Por ejemplo: mv mssql.pem dc2dd900.0. Asegúrese de que dc2dd900.0 está en /usr/local/etc/openssl/certs

Ejemplos de cadena de conexión

Precaución

Use siempre una contraseña segura. Para obtener más información, vea Password Policy.

  • SQL Server Management Studio

    Captura de pantalla del cuadro de diálogo de conexión para SQL Server Management Studio.

  • sqlcmd

    sqlcmd -S <sqlhostname> -N -U sa -P '<password>'

  • ADO.NET

    "Encrypt=True; TrustServerCertificate=False;"

  • ODBC

    "Encrypt=Yes; TrustServerCertificate=no;"

  • JDBC

    "encrypt=true; trustServerCertificate=false;"

Errores de conexión comunes

Mensaje de error Fix
The certificate chain was issued by an authority that is not trusted. Este error se produce cuando los clientes no pueden comprobar la firma del certificado que ha presentado SQL Server durante el protocolo de enlace de TLS. Asegúrese de que el cliente confía directamente en el certificado SQL Server o en la CA que firmó el certificado de SQL Server.
The target principal name is incorrect. Asegúrese de que el campo Nombre común del certificado de SQL Server coincide con el nombre de servidor especificado en la cadena de conexión del cliente.
An existing connection was forcibly closed by the remote host. Este error puede producirse si el cliente no admite la versión del protocolo TLS que requiere SQL Server. Por ejemplo, si SQL Server está configurado para requerir TLS 1.2, asegúrese de que los clientes también admitan el protocolo TLS 1.2.

Ubuntu 20.04 y otras versiones de distribuciones de Linux recientes

Síntoma

Cuando una instancia de SQL Server en Linux carga un certificado creado con un algoritmo de firma con menos de 112 bits de seguridad (ejemplos: MD5, SHA-1), es posible que observe un error de conexión, como en este ejemplo:

Se estableció correctamente una conexión con el servidor, pero luego se produjo un error durante el proceso de inicio de sesión. (proveedor: proveedor SSL, error: 0: la conexión existente se cerró forzadamente por el host remoto). (Microsoft SQL Server, Error: 10054)

El error se debe a que el nivel de seguridad 2 de OpenSSL está habilitado de forma predeterminada en Ubuntu 20.04 y versiones posteriores. El nivel de seguridad 2 prohíbe que se establezcan conexiones TLS que tengan menos de 112 bits de seguridad.

Solución

Instale un certificado con un algoritmo de firma con al menos 112 bits de seguridad. Los algoritmos de firma que cumplen este requisito incluyen SHA-224, SHA-256, SHA-384 y SHA-512.