highmoe
Goto Top

Installation SSL-Zertifikat auf SQL Server 2019 unter Ubuntu 20.04

Hallo,

seit 3 Tagen dabei und am Verzweifeln...
Projekt: Stand-alone Server für eine Wordpress-Seite, die neben dem normalen mysql-Server auch auf einen MS SQL-Server zugreifen soll.

Bereits installiert:

  • Ubuntu Server 20.04.5 mit Apache und PHP 8.1 (alles aktuell)
  • MS ODBC-Paket Version 18 (aktuell) mit Tools etc.
  • SQL Server 2019 (Express, aktuell)

Grundsätzlich klappt alles, ich kann von extern auf den MSSQL zugreifen, ich kann vom Server auf andere MSSQL-Instanzen zugreifen mit einem selbst erstellten Connection String inkl. "TrustServerCertificate = yes".

Nur habe ich unter Wordpress ein Tool (wpDataTables), das den Connection String automatisch erstellt und auf die systemisch erstellte Verbindung angewiesen ist.
Egal, was ich als Zertifikat installiere - selbstgeneriert mit OpenSSL, mit Certbot erstellt oder einem "richtigen" Zertifikat - es kann keine Verbindung hergestellt werden.

Es gibt 3 Optionen:

  • Timeout, SQL Server nicht erreichbar
  • error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:unable to get local issuer certificate
  • error: 416F086:SSL routines:tls_process_server_certificate:certificate verify failed

Auch mit den Original-Anleitungen von Microsoft passiert das.

Frage: wie installiere ich korrekt ein Zertifikat auf der SQL-Möhre?

Content-Key: 6334682782

Url: https://administrator.de/contentid/6334682782

Printed on: February 25, 2024 at 11:02 o'clock

Member: Dani
Dani Mar 12, 2023 updated at 17:31:40 (UTC)
Goto Top
Moin,
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:unable to get local issuer certificate
  • Der Microsoft SQL Server kommt mit dem Format des Zertifikats, welches Certbot abruft nicht klar.
  • Hat der Benutzer, welcher den SQL-Server ausführt, auch genügend Berechtigungen, um sowohl Private Key als auch Certificate zuzugreifen?

- error: 416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Kann vom dem Server, auf dem der Microsoft SQL Server installiert ist, auf der OCSP/CRL Adressen aus dem verwendeten Zertifikat, zugreifen?!

Auch mit den Original-Anleitungen von Microsoft passiert das.
https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-encrypted-c ...
https://www.sqlpac.com/en/documents/ms-sql-2019-linux-ssl-setup-connecti ...

Egal, was ich als Zertifikat installiere - selbstgeneriert mit OpenSSL, mit Certbot erstellt oder einem "richtigen" Zertifikat - es kann keine Verbindung hergestellt werden
Wir rufen für die SQL-Server ein Zertifikat (dedizierte Vorlage, welche die Anfoderungen aus den Links erfüllt) in unserer PKI ab und bis dato funktioniert es sowohl unter Windows als auch Linux.


Gruß,
Dani
Member: highmoe
highmoe Mar 12, 2023 at 18:07:49 (UTC)
Goto Top
Hallo Dani,

"Der Microsoft SQL Server kommt mit dem Format des Zertifikats, welches Certbot abruft nicht klar.
Hat der Benutzer, welcher den SQL-Server ausführt, auch genügend Berechtigungen, um sowohl Private Key als auch Certificate zuzugreifen?"

Ist mir bekannt, habe entsprechende Berechtigungen und Dateieigenschaften gesetzt. Die beiden von dir verlinkten Beschreibungen habe ich rauf und runter gelesen und ausprobiert.
Zusätzlch habe ich noch dieses ausprobiert:
https://ollie10.medium.com/how-to-encrypt-connection-on-sql-server-on-li ...

"Kann vom dem Server, auf dem der Microsoft SQL Server installiert ist, auf der OCSP/CRL Adressen aus dem verwendeten Zertifikat, zugreifen?!"
Das habe ich konkret noch nicht ausprobiert, generell gibt es keine Beschränkungen ausgehend. Eingehend sind nur Ports 80 und 443 derzeit aktiviert. Das soll auch so bleiben, der SQL Server ist ja ausschließlich für den "eigenen Bedarf".

Das "echte" Zertifikat, das ich erwähnte, war das Wildcard-Zertifikat für meine Firma. Das ist auf jeden Fall gültig, damit laufen Dutzende Maschinen einwandfrei. Was mir nicht klar ist, ist, wie die Zertifikatskette aufgebaut ist. Ich habe keinen Befehl für ein Chaining gefunden und wenn ein "fullchain"-Zertifikat eingebaut ist, ist da ja auch das Root-Zert dabei.
Ich habe meine Wildcard auch auf einigen Windows-Maschinen. Wäre es eine Idee, mal von der Seite aus zu kommen, das Ganze als PFX mit allen Eigenschaften auszulesen und dann diese Dateien zu verwenden?

LG, Haimo
Member: Dani
Dani Mar 18, 2023 at 14:42:42 (UTC)
Goto Top
Moin,
ich habe vorher beim Kaffee mit den SQL Kollegen gesprochen.

Frage: wie installiere ich korrekt ein Zertifikat auf der SQL-Möhre?
Auslöser für die Fehlermeldung ist, dass der ODBC Driver es nicht schafft, den vollständigen Zertifizierungspfad des verwendeten SSL-Zertifikats zu prüfen.

Abhilfe schafft aktuell nur dass Zertifikat der Issue CA (bei Let's Encrypt R3), welches das SSL-Zertifikat ausgestellt hat, unter Ubuntu/Debian in den Certificate Store aufzunehmen. Danach funktioniert die Verbindung ohne Fehlermeldung.

Es handelt sich hierbei aus Kundensicht um einen Bug, aus Herstellersicht um ein Feature. Da sind wir uns mit Microsoft nicht einig. face-sad


Gruß,
Dani
Member: highmoe
highmoe Mar 18, 2023 at 15:11:31 (UTC)
Goto Top
Hallo Dani,

versucht habe ich das bereits, ohne dass es etwas gebracht hätte. Auch das intermediate certificate habe ich dort untergebracht, ohne Erfolg.

Ich komme jetzt erst einmal weiter. Der Hersteller des SQL-Zugriffs-Plugins unter Wordpress hat mir einen Tip gegeben, wie ich den Connection String beeinflussen kann und ich habe jetzt "Encrypt=false" in den String aufgenommen, damit ich überhaupt erstmal weiter an der Anwendung arbeiten kann.

Ende März ist das Wildcard Certificate meiner Haupt-Domain zur Erneuerung dran, vielleicht versuche ich es dann noch einmal. Prinzipiell brauche ich in diesem Setup eigentlich gar keine Verschlüsselung, denn es ist ein Stand-Alone-System, dass öffentlich nur über Ports 80 und 443 erreichbar ist.

Ich komme ja erstmal weiter undwerde berichten, ob es mit einem anderen Zertifikat dann klappt.

LG, Haimo
Member: Dani
Dani Mar 18, 2023 at 15:32:38 (UTC)
Goto Top
Moin,
versucht habe ich das bereits, ohne dass es etwas gebracht hätte. Auch das intermediate certificate habe ich dort untergebracht, ohne Erfolg.
hast du das Zertifikat anschließend über dpkg-reconfigure ca-certificates aktiviert?

Ich komme ja erstmal weiter undwerde berichten, ob es mit einem anderen Zertifikat dann klappt.
DAs Problem wirst du aktuell mit jedem Zertifikat haben, welches nicht direkt von einer Root CA stammt. Sobald eine Intermediate CA zwischen ist (was heute Standard ist) läuft's du in den Fehler.


Gruß,
Dani
Member: highmoe
highmoe Mar 18, 2023 at 16:20:43 (UTC)
Goto Top
Hallo Dani,

"hast du das Zertifikat anschließend über dpkg-reconfigure ca-certificates aktiviert?"

Beim root ja. Ob ich das das mit dem intermediate auch noch habe laufen lassen, kann ich wirklich nicht mehr genau sagen nach all der Rumprobiererei.

Aber nochmal herzlichen Dank. Ich weiß dann zumindest, dass es nicht ausschließlich eigene Blödheit ist, das ist ja auch was face-wink

LG, Haimo
Member: Dani
Dani Mar 18, 2023 at 22:47:49 (UTC)
Goto Top
Moin,
Beim root ja. Ob ich das das mit dem intermediate auch noch habe laufen lassen, kann ich wirklich nicht mehr genau sagen nach all der Rumprobiererei.
kannst du mit dem Befehl problemlos kontrollieren. Unabhängig davon das nächste Mal ein bisschen dokumentieren, was du wie ausprobiert hast. face-wink


Gruß,
Dani
Member: vafk18
vafk18 Oct 15, 2023 at 14:34:01 (UTC)
Goto Top
Guten Tag,

ich bin nach einigen Jahren wieder zu meinem Wunsch zurückgekehrt, auf einem Ubuntu Server 20.04 in einer VM einen Microsoft SQL-Server zu installieren, um darin evtl. die Warenwirstchaft von JTL zu betreiben.

Da die Installation In meinem Testaufbau nicht auf Anhieb geklappt hat, habe ich die VM auf unterschiedlicher Hardware eingerichtet und dabei Abweichungen festgestellt, die ich mit Euch diskuttieren möchte:

1) Der in einer VMware Workstation 16 HP istallierte Ubuntu Server 20.03 meldet nach Anmeldung am SQL Server folgende Fehler:

Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : SSL Provider: [error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:self signed certificate].
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Client unable to establish connection. For solutions related to encryption errors, see https://go.microsoft.com/fwlink/?linkid=2226722.

Dabei habe ich die hier besfhrieben Anleitung befolgt:

https://learn.microsoft.com/en-us/sql/linux/quickstart-install-connect-u ...

Ich habe den gleichen Server auf einem HP Microserver Gen8 mit TrueNAS 13.0 in einer VM installiert, exakt die gleichen Schritte vorgenommen und eine andere Fehlermeldung erhalten:

Ubuntu 20.04.6 LTS
Capturing core dump and information to /var/opt/mssql/log...
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal' can see all messages.
Pass -q to turn off this notice.
No journal files were opened due to insufficient permissions.
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal' can see all messages.
Pass -q to turn off this notice.
No journal files were opened due to insufficient permissions.
tail: cannot open '/var/log/syslog' for reading: Permission denied
Sun 15 Oct 2023 02:29:56 PM UTC Capturing program information
Dump already generated: /var/opt/mssql/log/core.sqlservr.10_15_2023_14_29_48.1341, moving to /var/opt/mssql/log/core.sqlservr.1341.temp/core.sqlservr.1341.gdmp
Moving logs to /var/opt/mssql/log/core.sqlservr.1341.temp/log/paldumper-debug.log
Sun 15 Oct 2023 02:29:56 PM UTC Capturing program binaries
Sun 15 Oct 2023 02:30:01 PM UTC Compressing the dump files
Core dump and information are being compressed in the background. When
complete, they can be found in the following location:
/var/opt/mssql/log/core.sqlservr.10_15_2023_14_29_52.1341.tbz2
Initial setup of Microsoft SQL Server failed. Please consult the ERRORLOG
in /var/opt/mssql/log for more information.

Da ich zuerst testen möchte, wie schnell ich auf meine bestehende SQL-Datenbank zugreifen kann, reicht es mir vollkommen aus, wenn ich einen frischen Ubuntu 20.04 zum laufen bekomme, dort eine Testdatenbank anlegen und mich von meinem Client verbinden kann, um die Geschwindigkeit zu testen.

Aus den Fehlermeldungen verstehe ich, daß der Server in der VMware ein Problem mit einem Zertifikat hat (wozu wird es im Testaufbau benötigt?) und der Server auf der TrueNAS hat Probleme mit Rechten.

Was mir verwirrt ist, daß nicht beide VM die gleichen Probleme haben, dann könnte ich diese Schritt für Schritt lösen und das nächste Mal, wenn sie wieder das sind, auf das bereist Erschlossene zurückgreifen. Aber so befürchte ich, daß ich in jeder neuen VM ein anderes Problem habe, das vielleicht auf etwas ganz anderes zurückzuführen ist.

Ich bin Euch für Eure Tipps dankbar und wünsche noch einen schönen Sonntag Nachmittag.
Mitglied: 7907292512
7907292512 Oct 15, 2023 updated at 16:06:06 (UTC)
Goto Top
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : SSL Provider: [error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:self signed certificate].
Das Zertifikat des SQL Servers muss immer in die Trusted-Root-Zertifikate am Client kopiert werden, oder mittels
sudo /opt/mssql/bin/mssql-conf set network.forceencryption 0 
dem User die Wahl lassen ob er per TLS oder unverschlüsselt verbinden möchte.

Mehr Details dazu hier
Encrypting Connections to SQL Server on Linux

Klappt hier im Test einwandfrei mit einem Ubuntu 20.04 in einer VM.

Gruß sid.
Member: vafk18
vafk18 Oct 15, 2023 at 17:05:32 (UTC)
Goto Top
@7907292512

Dankeschön für den Link. Ich habe das Zertifikat erstellt, es in die richtigen Verzeichnisse verschoebn und in Windows 11 importiert.

[systemctl status mssql-server --no-pager] zeigt keinen Fehler mehr an.

Aber beim Versuch sich mit dem Server zu verbinden [sqlcmd -S localhost -U sa -P '<YourPassword>'] kommt immer noch der Fehler

Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login timeout expired.
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : TCP Provider: Error code 0x2749.
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to localhost. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..

Ich bin über SSH an der Konsole des Servers. An der Stelle komme ich leider nicht weiter.
Member: vafk18
vafk18 Oct 15, 2023 at 17:33:00 (UTC)
Goto Top
Jetzt sehe ich, daß der Server startet und nach wenigen Sekunden einen Fehler meldet. Im Fehlerlog steht

2023-10-15 19:24:25.48 spid12s Database 'model_replicatedmaster' running the upgrade step from version 928 to version 929.
2023-10-15 19:24:25.52 spid23s Error: 49940, Severity: 16, State: 1.
2023-10-15 19:24:25.52 spid23s Unable to open one or more of the user-specified certificate file(s). Verify that the certificate file(s) exist with read permissions for the user and group running SQL Server.
2023-10-15 19:24:25.54 spid20s 1 transactions rolled forward in database 'model' (3:0). This is an informational message only. No user action is required.
2023-10-15 19:24:25.54 spid23s Error: 49939, Severity: 16, State: 1.
2023-10-15 19:24:25.54 spid23s Unable to initialize user-specified certificate configuration. The server is being shut down. Verify that the certificate is correctly configured. Error[30]. State[51].
2023-10-15 19:24:25.54 spid12s Database 'model_replicatedmaster' running the upgrade step from version 929 to version 930.


Die Datei mssql.pem ist in /etc/ssl/certs und hat Lese- uns Schreibrechte
-rw------- 1 mssql mssql 1127 Oct 15 18:43 mssql.pem

Die Datei mssql.key ist in /etc/ssl/private und hat Lese- uns Schreibrechte
-rw------- 1 mssql mssql 1704 Oct 15 18:43 mssql.key
Mitglied: 7907292512
7907292512 Oct 15, 2023 updated at 18:40:44 (UTC)
Goto Top
Der mssql user muss auch in das Verzeichnis wechseln können in denen die Certs liegen!
Ergo muss mit einem chmod Zugriffsrechte (r und x) auf die Verzeichnisse der certs (/etc/ssl/private und /etc/ssl/certs) gegeben werden, das hast du wohl übersehen ­čśë. Steht übrigens auch in der oben verlinkten Anleitung ...
Per Default wird nämlich der Zugriff auf das "private" Verzeichnis für other unterbunden.
Also entweder den mssql user der Gruppe der dieses Verzeichnis zugeordnet ist hinzufügen (bevorzugt) oder other Zugriff gewähren.
Wenn das Verzeichnis als bspw. der Gruppe "ABC" zugeordnet ist bringt folgendes den mssql user in die Gruppe
usermod -a -G ABC mssql
Alternativ "other" Zugriff geben (nicht zu empfehlen da Sicherheitsrisiko wenn jeder die private Keys lesen kann)
chmod 755 /etc/ssl/private
chmod 755 /etc/ssl/certs

Und ob der Dienst dann wirklich auf TCP 1433 lauscht zeigt dir nach dem Start ein
ss -ltn
Member: vafk18
vafk18 Oct 15, 2023 at 20:08:45 (UTC)
Goto Top
Vielen Dank! Und auch für die Erklärung, so daß ich es auch verstanden habe face-smile
Der Fehler mit dem Zertifikat ist weg. Aber es bleibt noch das Problem mit dem ODBC-Driver:

Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : SSL Provider: [error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:self signed certificate].
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Client unable to establish connection. For solutions related to encryption errors, see https://go.microsoft.com/fwlink/?linkid=2226722.


ss -ltn gibt aus

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 128 127.0.0.1:1431 0.0.0.0:*
LISTEN 0 128 0.0.0.0:1433 0.0.0.0:*
LISTEN 0 128 127.0.0.1:1434 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*
LISTEN 0 128 [::1]:1431 [::]:*
LISTEN 0 128 *:1433 *:*
LISTEN 0 128 [::1]:1434 [::]:*

Es ist schade, daß ich so viel Zeit mit Windows verbracht und am Ende kaum Ahnung von Linux habe...
Mitglied: 7907292512
7907292512 Oct 15, 2023 updated at 21:25:26 (UTC)
Goto Top
Der Fehler sagt immer noch das dem Zertifikat noch nicht vertraut wird, ergo liegt es an den falschen Stelle im Cert-Store! Es muss in den Machine-Store für Vertrauenswürdige Stammzertifierungsstellen abgelegt werden, dann klapped auch mit dem einarmigen Winblows Banditen ­čśë!
Es ist schade, daß ich so viel Zeit mit Windows verbracht und am Ende kaum Ahnung von Linux habe...
Der Winter ist lang in DE ­čśü
Member: vafk18
vafk18 Oct 24, 2023 at 16:02:59 (UTC)
Goto Top
Ich melde mich nach einer Woche. Ich weiß nicht, wie oft ich die Schritte in zwei verschiedenen VM's wiederholt habe. Ich habe mich stetst an die bei MS beschrieben Installationsanleitung des MSSQL 2019 in Ubunto 20.04. Irgendwann hatte ich den MSSQL in der VMware VM am Laufen und konnte von Windows 11 darauf zugreifen. Aber das war ja nur die Gegenkontrolle de Installation auf TrueNAS 13 Core, wo ich dachte, daß die bei mir auf Einzeplatz installierte Version des JTLL-Warenwirtschaftssystems seinen Platz finden könnte. Es war zum Verzweifeln. Ich habe mich nicht mehr getraut hir zu fragen oder Siddius eine PM zu schicken, denn ich dachte, daß man mich ijetzt langsam auslachen würde. Ich habe den Fehler in irgendwelchen nicht vorhandenen Schreib-Leserechten gesucht und habe mich komplett im Kreis gedreht.

Bis ich gestern auf diesen Beitrag gestoßen bin:

https://www.truenas.com/community/threads/issue-installing-mssql-on-bhyv ...

Das Problem lag in der Einstellung Auto beim ZVOL. Wie dort beschrieben, mußte ich die Blockgröße auf 4K setzen und sofort konnte ich den MSSQL starten und ohne Umschweife darauf zugreifen und Datenbanken erstellen.

Leider läuft das Restore auf den MSSQL nicht. Die von JTL eingebaute Routine bemängelt zurecht, daß die Datebank nicht vorhanden ist und nach Bestätigung, daß diese erstellt werden soll, passiert nichts.

Ich glaube nicht, daß man mir hier an diesem Punkt weiterhelfen wird und daher werde ich hier abschließen und die Frage im JTL-Forum stellen. Ich danke Euch allen für die sehr guten Tipps!