Verschlüsseln von Verbindungen mit SQL Server für Linux

  • Artikel

Gilt für:SQL Server – Linux

SQL Server für Linux kann Transport Layer Security (TLS) zum Verschlüsseln der Daten verwendet werden, die über ein Netzwerk zwischen einer Clientanwendung und einer Instanz von SQL Server übertragen werden. SQL Server unterstützt unter Windows und Linux die gleichen TLS-Protokolle: TLS 1.2, 1.1 und 1.0. Die Schritte zum Konfigurieren von TLS sind jedoch spezifisch für das Betriebssystem, auf dem SQL Server ausgeführt wird.

Anforderungen an Zertifikate

Bevor Sie beginnen, müssen Sie sicherstellen, dass Ihre Zertifikate den folgenden Anforderungen entsprechen:

  • Die aktuelle Systemzeit muss nach der Eigenschaft „Gültig ab“ und vor der Eigenschaft „Gültig bis“ des Zertifikats liegen.
  • Das Zertifikat muss für die Serverauthentifizierung vorgesehen sein. Dazu muss für die Eigenschaft „Erweiterte Schlüsselverwendung“ des Zertifikats „Serverauthentifizierung (1.3.6.1.5.5.7.3.1)“ angegeben sein.
  • Das Zertifikat muss mit der KeySpec-Option von AT_KEYEXCHANGE erstellt werden. Normalerweise enthält die Schlüsselverwendungseigenschaft (KEY_USAGE) des Zertifikats auch die Schlüsselverschlüsselung (CERT_KEY_ENCIPHERMENT_KEY_USAGE).
  • Mit der Eigenschaft „Antragsteller“ des Zertifikats muss angegeben werden, dass der allgemeine Name (Common Name, CN) mit dem Hostnamen oder dem vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Servercomputers übereinstimmt. Hinweis: Platzhalterzertifikate werden unterstützt.

Konfigurieren der OpenSSL-Bibliotheken zur Verwendung (optional)

Sie können symbolische Verknüpfungen im /opt/mssql/lib/-Verzeichnis erstellen, die darauf verweisen, welche libcrypto.so- und libssl.so-Bibliotheken für die Verschlüsselung verwendet werden sollen. Dies ist hilfreich, wenn Sie erzwingen möchten, dass SQL Server eine bestimmte andere OpenSSL-Version als die vom System bereitgestellte Standardversion verwendet. Wenn diese symbolischen Verknüpfungen nicht vorhanden sind, lädt SQL Server die standardmäßig auf dem System konfigurierten OpenSSL-Bibliotheken.

Diese symbolischen Verknüpfungen sollten mit libcrypto.so und libssl.so benannt und in das /opt/mssql/lib/-Verzeichnis eingefügt werden.

Übersicht

TLS wird zum Verschlüsseln von Verbindungen einer Clientanwendung mit SQL Server verwendet. Bei ordnungsgemäßer Konfiguration bietet TLS sowohl Datenschutz als auch Datenintegrität für die Kommunikation zwischen dem Client und dem Server. TLS-Verbindungen können entweder vom Client oder vom Server initiiert werden.

Vom Client initiierte Verschlüsselung

  • Generieren des Zertifikats („/CN“ sollte mit dem vollqualifizierten Domänennamen des SQL Server-Hosts identisch sein)

Hinweis

In diesem Beispiel verwenden wir ein selbstsigniertes Zertifikat, das nicht für Produktionsszenarien verwendet werden sollte. Sie sollten Zertifizierungsstellenzertifikate verwenden.
Stellen Sie sicher, dass die Ordner, in denen Sie Ihre Zertifikate und privaten Schlüssel speichern, für die MSSQL-Benutzer/-Gruppe zugänglich sind und die Berechtigung auf „700 (drwx-----)“ festgelegt ist. Sie können Ordner manuell erstellen, die Berechtigung auf „700 (drwx-----)“ festlegen und die MSSQL-Benutzer/-Gruppe als Besitzer festlegen. Alternativ können Sie die Berechtigung auf „755 (drwxr-xr-x)“ und einen anderen Benutzer als Besitzer festlegen, sodass die Ordner dennoch für die MSSQL-Benutzergruppe zugänglich sind. Beispielsweise können Sie einen Ordner namens „sslcert“ unter dem Pfad „/var/opt/mssql/“ erstellen und dann das Zertifikat und den privaten Schlüssel mit den Berechtigungen für die Dateien festgelegt auf „600“ speichern (siehe unten).

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 
# in this case we are 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 
# in this case we are 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/
  • Konfigurieren von 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

  • Registrieren des Zertifikats auf dem Clientcomputer (Windows, Linux oder macOS)

    • Wenn Sie ein von der Zertifizierungsstelle signiertes Zertifikat verwenden, müssen Sie das Zertifizierungsstellenzertifikat (Certificate Authority, CA) anstelle des Benutzerzertifikats auf den Clientcomputer kopieren.
    • Wenn Sie das selbstsignierte Zertifikat verwenden, kopieren Sie einfach die PEM-Datei in die folgenden Ordner bzw. in die Distribution, und führen Sie die Befehle aus, um sie zu aktivieren.
      • Ubuntu: Kopieren Sie das Zertifikat in /usr/share/ca-certificates/, ändern Sie die Erweiterung in „.crt“, und verwenden Sie dpkg-reconfigure ca-certificates, um dieses als Zertifizierungsstellenzertifikat für das System zu verwenden.
      • RHEL: Kopieren Sie das Zertifikat in /etc/pki/ca-trust/source/anchors/, und verwenden Sie update-ca-trust, um dieses als Zertifizierungsstellenzertifikat für das System zu verwenden.
      • SUSE: Kopieren Sie das Zertifikat in /usr/share/pki/trust/anchors/, und verwenden Sie update-ca-certificates, um dieses als Zertifizierungsstellenzertifikat für das System zu verwenden.
      • Windows: Importieren Sie die PEM-Datei als Zertifikat unter „Aktueller Benutzer -> Vertrauenswürdige Stammzertifizierungsstellen -> Zertifikate“.
      • macOS:
        • Kopieren Sie das Zertifikat in /usr/local/etc/openssl/certs.
        • Führen Sie den folgenden Befehl aus, um den Hashwert zu erhalten: /usr/local/Cellar/openssl/1.0.2l/openssl x509 -hash -in mssql.pem -noout.
        • Benennen Sie das Zertifikat in den Wert um. Beispiel: mv mssql.pem dc2dd900.0. Stellen Sie sicher, dass dc2dd900.0 sich in /usr/local/etc/openssl/certs befindet.

  • Exemplarische Verbindungszeichenfolgen

    • SQL Server Management Studio
      SSMS-Verbindungsdialogfeld

    • SQLCMD

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

    • ADO.NET

      "Encrypt=True; TrustServerCertificate=False;"

    • ODBC

      "Encrypt=Yes; TrustServerCertificate=no;"

    • JDBC

      "encrypt=true; trustServerCertificate=false;"

Vom Server initiierte Verschlüsselung

  • Generieren des Zertifikats („/CN“ sollte mit dem vollqualifizierten Domänennamen des SQL Server-Hosts identisch sein)
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   
sudo mv mssql.pem /etc/ssl/certs/ 
sudo mv mssql.key /etc/ssl/private/
  • Konfigurieren von 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 1
systemctl restart mssql-server

  • Exemplarische Verbindungszeichenfolgen

    • SQLCMD

      sqlcmd -S <sqlhostname> -U sa -P '<YourPassword>'

    • ADO.NET

      "Encrypt=False; TrustServerCertificate=False;"

    • ODBC

      "Encrypt=no; TrustServerCertificate=no;"

    • JDBC

      "encrypt=false; trustServerCertificate=false;"

Hinweis

Legen Sie für TrustServerCertificate „True“ fest, wenn der Client keine Verbindung mit der Zertifizierungsstelle herstellen kann, um die Authentizität des Zertifikats zu überprüfen.

Häufige Verbindungsfehler

Fehlermeldung Fix
Die Zertifikatkette wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt. Dieser Fehler tritt auf, wenn Clients die Signatur des Zertifikats, das von SQL Server während des TLS-Handshakes angezeigt wird, nicht überprüfen können. Stellen Sie sicher, dass der Client entweder direkt dem SQL Server-Zertifikat vertraut, oder der Zertifizierungsstelle, die das SQL Server-Zertifikat signiert hat.
Der Zielprinzipalname ist falsch. Stellen Sie sicher, dass das Feld „Allgemeiner Name“ auf dem SQL Server-Zertifikat mit dem in der Verbindungszeichenfolge des Clients angegebenen Servernamen übereinstimmt.
An existing connection was forcibly closed by the remote host. Dieser Fehler kann auftreten, wenn der Client die für SQL Server erforderliche TLS-Protokollversion nicht unterstützt. Wenn SQL Server beispielsweise für die Verwendung von TLS 1.2 konfiguriert ist, müssen Sie sicherstellen, dass Ihre Clients auch das TLS 1.2-Protokoll unterstützen.

Ubuntu 20.04 und andere aktuelle Linux-Distributionsversionen

Symptom

Wenn eine SQL Server für Linux-Instanz ein Zertifikat lädt, das mit einem Signaturalgorithmus mit weniger als 112 Bits Sicherheit erstellt wurde (z. B. MD5, SHA-1), kann ein Verbindungsfehler auftreten, wie in diesem Beispiel:

A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - An existing connection was forcibly closed by the remote host.) (Microsoft SQL Server, Error: 10054)

Der Fehler ist darauf zurückzuführen, dass unter Ubuntu 20.04 und höher standardmäßig die OpenSSL-Sicherheitsstufe 2 aktiviert ist. Die Sicherheitsstufe 2 verhindert die Einrichtung von TLS-Verbindungen mit weniger als 112 Bits Sicherheit.

Lösung

Installieren Sie ein Zertifikat mit einem Signaturalgorithmus mit mindestens 112 Bits Sicherheit. Signaturalgorithmen, die diese Anforderung erfüllen: SHA-224, SHA-256, SHA-384 und SHA-512.