Partager via

Chiffrer les connexions à SQL Server sur Linux

  • Article

S’applique à : SQL Server - Linux

SQL Server sur Linux peut utiliser le protocole TLS pour chiffrer des données transmises sur un réseau entre une application cliente et une instance de SQL Server. SQL Server prend en charge les mêmes protocoles TLS sur Windows et sur Linux : TLS 1.2, 1.1 et 1.0. Toutefois, les étapes de configuration de TLS sont spécifiques au système d’exploitation sur lequel SQL Server s’exécute.

Conditions requises pour les certificats

Vérifiez que vos certificats respectent les exigences suivantes :

  • L'heure actuelle du système doit être postérieure à la propriété Valid from du certificat et antérieure à la propriété Valid to du certificat.

  • Le certificat doit être destiné à une authentification serveur. Cela nécessite la propriété Enhanced Key Usage du certificat pour spécifier Server Authentication (1.3.6.1.5.5.7.3.1).

  • Le certificat doit être créé à travers l’utilisation de l’option KeySpec de AT_KEYEXCHANGE. Habituellement, la propriété d’utilisation de la clé du certificat (KEY_USAGE) inclut également un chiffrement de clé (CERT_KEY_ENCIPHERMENT_KEY_USAGE).

  • La propriété Subject du certificat doit indiquer que le nom courant (CN) est le même que le nom de domaine ou le nom de domaine complet (FQDN, Fully Qualified Domain Name) de l'ordinateur serveur.

    Remarque

    Les certificats utilisant des caractères génériques sont pris en charge.

Configurer des bibliothèques OpenSSL en vue de leur utilisation (facultatif)

Vous pouvez créer dans le répertoire /opt/mssql/lib/ des liens symboliques qui référencent les bibliothèques libcrypto.so et libssl.so à utiliser pour le chiffrement. C’est utile si vous souhaitez forcer SQL Server à utiliser une version spécifique d’OpenSSL autre que la valeur par défaut fournie par le système. En l’absence de ces liens symboliques, SQL Server charge les bibliothèques OpenSSL configurées par défaut sur le système.

Ces liens symboliques doivent être nommés libcrypto.so et libssl.so et placés dans le répertoire /opt/mssql/lib/.

Remarque

Pour obtenir un exemple d’utilisation de Let’s Encrypt pour générer un certificat, consultez le billet de blog Déverrouiller la puissance des données dans Azure avec SQL Server sur Linux machines virtuelles Azure et recherche Azure AI.

Vue d’ensemble

Le protocole TLS est utilisé pour chiffrer des connexions d'une application cliente vers SQL Server. Lorsqu’il est configuré correctement, le protocole TLS garantit la confidentialité et l’intégrité des données pour les communications entre le client et le serveur. Les connexions TLS peuvent être lancées par le client ou par le serveur.

La section suivante décrit la configuration du chiffrement initié par le client.

Génération du certificat

/CN doit correspondre au nom de domaine complet de votre hôte SQL Server.

Attention

Cet exemple utilise un certificat auto-signé. Les certificats auto-signésne doivent pas être utilisés dans des scénarios de production. Vous devez utiliser des certificats d’autorité de certification.

Vérifiez que le ou les dossiers dans lesquels vous enregistrez vos certificats et vos clés privées sont accessibles au groupe/à l’utilisateur mssql et que l’autorisation est définie avec la valeur 700 (drwx-----). Vous pouvez créer des dossiers manuellement avec une autorisation égale à 700 (drwx------) et détenue par le groupe/l’utilisateur mssql, ou définir une autorisation égale à 755 (drwxr-xr-x), détenue par un autre utilisateur, mais elle encore accessible au groupe/utilisateur mssql. Par exemple, vous pouvez créer un dossier appelé sslcert sous le chemin d’accès /var/opt/mssql/ et enregistrer le certificat et la clé privée avec des autorisations sur les fichiers définis sur 600, comme illustré dans l’exemple suivant.

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/

Configurer 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

Inscrire le certificat sur votre ordinateur client (Windows, Linux ou macOS)

  • Si vous utilisez un certificat signé par une autorité de certification, vous devez copier le certificat d’autorité de certification au lieu du certificat utilisateur sur l’ordinateur client.

  • Si vous utilisez le certificat auto-signé, copiez le fichier .pem dans les dossiers de distribution suivants et exécutez les commandes pour les activer :

  • Ubuntu : copier le certificat dans /usr/share/ca-certificates/, renommer son extension dans .crt et utiliser dpkg-reconfigure ca-certificates pour l’activer en tant que certificat d’autorité de certification système.

  • RHEL : copier le certificat dans /etc/pki/ca-trust/source/anchors/ et utiliser update-ca-trust pour l’activer en tant que certificat d’autorité de certification système.

  • SUSE : copier le certificat dans /usr/share/pki/trust/anchors/ et utiliser update-ca-certificates pour l’activer en tant que certificat d’autorité de certification système.

  • Windows : importer le fichier .pem en tant que certificat sous utilisateur actuel> autorités de certification racines de confiance > certificats.

  • macOS :

    • Copiez le certificat sur /usr/local/etc/openssl/certs

    • Exécutez la commande suivante pour récupérer la valeur de hachage :

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

    • Renommez le certificat à la valeur. Par exemple : mv mssql.pem dc2dd900.0. Assurez-vous que dc2dd900.0 se trouve dans /usr/local/etc/openssl/certs

Exemples de chaîne de connexion

Attention

Utilisez toujours un mot de passe fort. Pour plus d'informations, consultez Password Policy.

  • SQL Server Management Studio

    Capture d’écran de la boîte de dialogue de connexion de 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;"

Erreurs de connexion courantes

Message d’erreur Fix
The certificate chain was issued by an authority that is not trusted. Cette erreur se produit lorsque des clients ne peuvent pas vérifier la signature sur le certificat présenté par SQL Server pendant la négociation TLS. Assurez-vous que le client approuve directement le certificat SQL Server ou l’autorité de certification qui a signé le certificat SQL Server.
The target principal name is incorrect. Assurez-vous que le champ Nom commun sur le certificat de SQL Server correspond au nom de serveur spécifié dans la chaîne de connexion du client.
An existing connection was forcibly closed by the remote host. Cette erreur peut se produire lorsque le client ne prend pas en charge la version du protocole TLS requise par SQL Server. Par exemple, si SQL Server est configuré pour exiger TLS 1.2, assurez-vous que vos clients prennent également en charge le protocole TLS 1.2.

Ubuntu 20.04 et autres versions récentes de la distribution Linux

Symptôme

Lorsqu’une instance SQL Server sur Linux charge un certificat qui a été créé avec un algorithme de signature utilisant moins de 112 bits de sécurité (exemples : MD5, SHA-1), vous pouvez observer une erreur d’échec de connexion, comme dans cet exemple :

Une connexion a été établie avec le serveur, mais une erreur s’est ensuite produite pendant le processus de connexion. (fournisseur : Fournisseur SSL, erreur : 0 - Une connexion existante a été fermée de force par l’hôte distant.) (Microsoft SQL Server, Erreur : 10054)

L’erreur est due à l’activation par défaut du niveau de sécurité OpenSSL 2 sur Ubuntu 20.04 et versions ultérieures. Le niveau de sécurité 2 interdit l’établissement de connexions TLS qui ont moins de 112 bits de sécurité.

Solution

Installez un certificat avec un algorithme de signature utilisant au moins 112 bits de sécurité. Les algorithmes de signature qui répondent à cette exigence incluent SHA-224, SHA-256, SHA-384 et SHA-512.