15
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:
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:
Auch mit den Original-Anleitungen von Microsoft passiert das.
Frage: wie installiere ich korrekt ein Zertifikat auf der SQL-Möhre?
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?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6334682782
Url: https://administrator.de/contentid/6334682782
Printed on: June 23, 2024 at 02:06 o'clock
15 Comments
Latest comment
Moin,
https://www.sqlpac.com/en/documents/ms-sql-2019-linux-ssl-setup-connecti ...
Gruß,
Dani
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
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
"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
Moin,
ich habe vorher beim Kaffee mit den SQL Kollegen gesprochen.
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.
Gruß,
Dani
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.
Gruß,
Dani
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
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
Moin,
Gruß,
Dani
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
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
LG, Haimo
"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
LG, Haimo
Moin,
Gruß,
Dani
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. Gruß,
Dani
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.
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.
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 mittelssudo /opt/mssql/bin/mssql-conf set network.forceencryption 0 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.
@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.
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.
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
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
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
Alternativ "other" Zugriff geben (nicht zu empfehlen da Sicherheitsrisiko wenn jeder die private Keys lesen kann)
Und ob der Dienst dann wirklich auf TCP 1433 lauscht zeigt dir nach dem Start ein
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 mssqlchmod 755 /etc/ssl/private
chmod 755 /etc/ssl/certsUnd ob der Dienst dann wirklich auf TCP 1433 lauscht zeigt dir nach dem Start ein
ss -ltn
Vielen Dank! Und auch für die Erklärung, so daß ich es auch verstanden habe 
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...
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...
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 😁
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!
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!