TLS-verschlüsselte MySQL-Verbindungen konfigurieren: Server, Client und Zertifikate

1. Warum TLS bei MySQL-Verbindungen im Magento-Kontext relevant ist

MySQL-Verbindungen laufen standardmäßig zwar bereits opportunistisch verschlüsselt, aber ohne erzwungene Prüfung: Ein Client, der TLS nicht anbietet, oder ein Angreifer, der eine Verbindung aktiv herunterstuft, kann die Sitzung weiterhin unverschlüsselt aufbauen. In einem typischen Magento-Setup mit getrenntem Datenbankserver, mehreren Web- und Cronservern und gegebenenfalls einer Cloud-Umgebung mit mehreren Verfügbarkeitszonen ist der Netzwerkpfad zwischen Anwendung und Datenbank kein geschlossenes System mehr, sondern durchquert Switches, Load Balancer und manchmal sogar geteilte Netzsegmente.

Wer hier mitliest, sieht nicht nur Bestellungen und Kundendaten, sondern unter Umständen auch das Datenbankpasswort selbst, sofern Authentifizierungsdetails über einen unverschlüsselten Kanal übertragen werden. Für Shops mit Zahlungsdaten, personenbezogenen Daten im Sinne der DSGVO oder PCI-DSS-Pflichten ist eine konsequent erzwungene TLS-Verschlüsselung deshalb keine Kür, sondern eine grundlegende Absicherung, die sich mit überschaubarem Aufwand einrichten lässt und in Audits regelmäßig explizit abgefragt wird.

2. Server-seitige TLS-Konfiguration: require_secure_transport und SSL-Variablen

MySQL bringt seit einigen Jahren bereits beim ersten Start automatisch selbstsignierte Zertifikate im Datenverzeichnis mit, sodass TLS grundsätzlich sofort verfügbar ist. Für eine erzwungene, produktionstaugliche Konfiguration reicht das aber nicht: Die eigentliche Durchsetzung erfolgt über die globale Systemvariable require_secure_transport, die seit MySQL 8.0.21 verhindert, dass sich Clients über TCP ohne Verschlüsselung verbinden. Unix-Socket-Verbindungen auf demselben Host bleiben davon unberührt, da sie ohnehin nicht über das Netzwerk laufen.

Zusätzlich sollten eigene Zertifikate statt der automatisch generierten Standardzertifikate eingesetzt werden, sobald mehrere Server im Spiel sind, da die automatische Generierung pro Instanz unabhängig erfolgt und sich nicht für eine unternehmensweite Zertifikatskette eignet. Die relevanten Variablen ssl_ca, ssl_cert und ssl_key werden im Abschnitt [mysqld] der Konfigurationsdatei gesetzt und verweisen auf die eigene Certificate Authority, das Serverzertifikat und den privaten Schlüssel.

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
ssl_ca   = /etc/mysql/tls/ca.pem
ssl_cert = /etc/mysql/tls/server-cert.pem
ssl_key  = /etc/mysql/tls/server-key.pem

# ab MySQL 8.0.21: TCP-Verbindungen ohne TLS grundsaetzlich verweigern
require_secure_transport = ON
tls_version = TLSv1.2,TLSv1.3

3. Zertifikate erzeugen und verwalten: eigene CA statt Ad-hoc-Zertifikaten

Für kleinere Setups liefert MySQL mit mysql_ssl_rsa_setup ein Kommandozeilenwerkzeug, das eine eigene, minimale Certificate Authority samt Server- und Client-Zertifikaten in wenigen Sekunden erzeugt. Für produktive Umgebungen mit mehreren Datenbankservern und Anwendungsservern lohnt sich stattdessen eine eigene, dokumentierte PKI-Struktur, bei der eine zentrale interne CA die Zertifikate für alle Datenbankinstanzen signiert, damit Clients einer einzigen, konsistenten Zertifikatskette vertrauen können.

Wichtig ist, dass das Serverzertifikat einen Subject Alternative Name mit allen relevanten Hostnamen und gegebenenfalls der internen IP-Adresse enthält, da moderne Clients nicht mehr nur den Common Name prüfen. Der private Schlüssel des Servers gehört mit restriktiven Dateirechten versehen (0600, Besitzer mysql) und darf niemals außerhalb des Datenbankservers landen, auch nicht in einem Backup ohne zusätzliche Verschlüsselung.

# Eigene, minimale CA mit openssl aufbauen (Kurzfassung)
openssl genrsa -out ca-key.pem 4096
openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca.pem -subj "/CN=Mironsoft Internal DB CA"

# Serverzertifikat erzeugen und mit der CA signieren
openssl genrsa -out server-key.pem 2048
openssl req -new -key server-key.pem -out server-req.pem -subj "/CN=db-primary.internal"
openssl x509 -req -in server-req.pem -days 825 -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile server-ext.cnf

# server-ext.cnf enthaelt: subjectAltName=DNS:db-primary.internal,DNS:db.internal,IP:10.0.1.10

4. Client-seitige Konfiguration: REQUIRE SSL und REQUIRE X509 pro Nutzer

Neben der globalen Erzwingung durch require_secure_transport lässt sich TLS auch pro Datenbanknutzer feingranular vorschreiben, was für gestaffelte Sicherheitsanforderungen sinnvoll ist. Mit der Klausel REQUIRE SSL in CREATE USER oder ALTER USER wird eine verschlüsselte Verbindung erzwungen, ohne dass ein Client-Zertifikat vorgelegt werden muss. Für höhere Anforderungen sorgt REQUIRE X509, das zusätzlich ein gültiges, von der bekannten CA signiertes Client-Zertifikat verlangt und damit eine echte gegenseitige Authentifizierung ermöglicht.

Auf Client-Seite steuert der Parameter ssl-mode das Verhalten der Verbindung, wobei die Werte von DISABLED über PREFERRED und REQUIRED bis zu VERIFY_CA und VERIFY_IDENTITY reichen. Nur die beiden letztgenannten Modi prüfen tatsächlich, ob das vom Server präsentierte Zertifikat von der erwarteten CA stammt und, im Fall von VERIFY_IDENTITY, ob der Hostname der Verbindung mit dem Zertifikat übereinstimmt, was Man-in-the-Middle-Angriffe wirksam verhindert.

-- Anwendungsnutzer, der zwingend TLS verwenden muss
CREATE USER 'magento_app'@'10.0.2.%' IDENTIFIED BY 'ein-starkes-passwort' REQUIRE SSL;

-- Migrationsnutzer mit gegenseitiger Zertifikatsprüfung
CREATE USER 'ci_migration'@'10.0.3.%' IDENTIFIED BY 'anderes-passwort' REQUIRE X509;

-- Vorhandenen Nutzer nachträglich auf TLS-Pflicht umstellen
ALTER USER 'reporting'@'%' REQUIRE SSL;

5. Magento-Integration: SSL-Parameter in env.php korrekt setzen

Damit Magento selbst TLS für die Datenbankverbindung nutzt, müssen die entsprechenden PDO-Optionen im Abschnitt db von app/etc/env.php hinterlegt werden. Magento reicht die dort definierten driver_options unverändert an den PDO-MySQL-Treiber durch, sodass sich die gleichen Konstanten wie in jeder anderen PHP-PDO-Anwendung nutzen lassen, etwa PDO::MYSQL_ATTR_SSL_CA für den Pfad zur CA-Datei und PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT, um die Hostnamen-Prüfung analog zu VERIFY_IDENTITY zu aktivieren.

Ein häufiger Fehler in Multi-Server-Deployments ist, dass die CA-Datei nur auf einem der Anwendungsserver aktualisiert wird, während andere Server noch auf ein abgelaufenes Zertifikat verweisen, was zu sporadischen, schwer reproduzierbaren Verbindungsfehlern führt. Die env.php sollte deshalb konsequent über den Deployment-Prozess verteilt werden, und der Pfad zur CA-Datei sollte auf allen Servern identisch sein, idealerweise über ein zentrales Konfigurationsmanagement statt manueller Kopien.

// app/etc/env.php (Ausschnitt)
'db' => [
    'connection' => [
        'default' => [
            'host' => 'db-primary.internal',
            'dbname' => 'magento',
            'username' => 'magento_app',
            'password' => 'ein-starkes-passwort',
            'driver_options' => [
                PDO::MYSQL_ATTR_SSL_CA => '/etc/magento/tls/ca.pem',
                PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT => true,
            ],
        ],
    ],
],

6. Zertifikatsrotation: Ablaufüberwachung und Rollover ohne Downtime

Zertifikate haben eine begrenzte Gültigkeit, und ein unbemerkt abgelaufenes Serverzertifikat legt im schlimmsten Fall alle Anwendungsverbindungen gleichzeitig lahm, sobald Clients mit VERIFY_CA oder VERIFY_IDENTITY arbeiten. Ein einfacher, täglich laufender Check über openssl x509 -enddate -noout gegen jedes eingesetzte Zertifikat, kombiniert mit einer Warnschwelle von etwa dreißig Tagen vor Ablauf, verhindert diesen Ausfall zuverlässig und sollte in ein bestehendes Monitoring-System einlaufen.

Für den eigentlichen Rollover muss der Datenbankserver seit MySQL 8.0.16 nicht mehr neu gestartet werden: Der Befehl ALTER INSTANCE RELOAD TLS lädt neue Zertifikats- und Schlüsseldateien aus den konfigurierten Pfaden neu ein, ohne bestehende Verbindungen zu unterbrechen. In der Praxis bedeutet das einen Ablauf von neuem Zertifikat auf Platte kopieren, ALTER INSTANCE RELOAD TLS ausführen, und erst danach die alten Dateien entfernen, sodass zu keinem Zeitpunkt ein ungültiges Zertifikat aktiv ist.

7. Praktische Fallstricke bei Multi-Store-Setups mit mehreren Anwendungsservern

Sobald mehrere Anwendungsserver oder mehrere Magento-Websites hinter einem Load Balancer auf dieselbe Datenbank zugreifen, treten typische Konfigurationsfehler auf: Der häufigste ist ein Serverzertifikat, dessen Subject Alternative Name nur einen einzigen internen Hostnamen enthält, während einige Anwendungsserver über eine andere DNS-Bezeichnung oder eine IP-Adresse verbinden. Mit VERIFY_IDENTITY führt das zu abgelehnten Verbindungen, die auf einzelnen Servern auftreten und auf anderen nicht, was die Fehlersuche erheblich erschwert.

Ein zweiter typischer Fallstrick sind unterschiedliche CA-Bundle-Versionen auf verschiedenen Anwendungsservern nach einer Zertifikatsrotation, etwa weil ein neuer Server im Rahmen einer Skalierung mit einer älteren Deployment-Version aufgesetzt wurde. Eine zentrale Zertifikatsverteilung über Configuration-Management-Werkzeuge oder ein gemeinsames, versioniertes Artefakt im Deployment-Prozess verhindert dieses Auseinanderdriften und stellt sicher, dass alle Server jederzeit dieselbe CA-Kette verwenden.

# Verbindung von einem einzelnen Anwendungsserver gezielt testen
mysql --host=db-primary.internal --ssl-mode=VERIFY_IDENTITY --ssl-ca=/etc/magento/tls/ca.pem -u magento_app -p -e "SHOW STATUS LIKE 'Ssl_cipher';"

# CA-Fingerprint auf allen Anwendungsservern vergleichen
md5sum /etc/magento/tls/ca.pem

8. Monitoring und Troubleshooting: Statusvariablen und typische Fehlercodes

Ob eine konkrete Verbindung tatsächlich verschlüsselt ist, zeigt die Sitzungsvariable Ssl_cipher, die bei einer unverschlüsselten Verbindung leer bleibt und bei einer erfolgreichen TLS-Verbindung die verwendete Cipher-Suite ausgibt. Für einen dauerhaften Überblick eignet sich eine periodische Abfrage über performance_schema.status_by_thread oder performance_schema.status_by_account, die zeigt, welche Nutzerkonten tatsächlich verschlüsselt verbinden und welche noch nicht.

Der häufigste Client-seitige Fehlercode bei TLS-Problemen ist Errno 2026, der sowohl bei einem tatsächlichen Zertifikatsproblem als auch bei einer schlicht falschen Pfadangabe zur CA-Datei auftritt und deshalb wenig aussagekräftig ist. In diesem Fall hilft ein manueller Verbindungsversuch mit dem CLI-Client und explizit gesetztem ssl-mode, da die Fehlermeldung dort detaillierter ausfällt als über den PDO-Treiber in der Anwendung.

-- Aktuelle Verbindung auf TLS-Nutzung prüfen
SHOW STATUS LIKE 'Ssl_cipher';

-- Serverweite Übersicht über verschlüsselte vs. unverschlüsselte Sitzungen
SELECT VARIABLE_VALUE AS aktueller_cipher
FROM performance_schema.session_status
WHERE VARIABLE_NAME = 'Ssl_cipher';

9. Performance-Auswirkungen von TLS und begründete Ausnahmen

Der Rechenaufwand für TLS beschränkt sich im Wesentlichen auf den initialen Handshake, während die eigentliche Datenübertragung dank moderner CPU-Beschleunigung für AES praktisch keinen messbaren Overhead mehr verursacht. Bei kurzlebigen Verbindungen ohne Connection Pooling kann der wiederholte Handshake dennoch spürbar werden, weshalb Connection Pooling auf Anwendungsseite ohnehin empfehlenswert ist und den TLS-Overhead zusätzlich reduziert, da der Handshake seltener stattfindet.

Eine begründete Ausnahme von der Verschlüsselungspflicht sind reine Unix-Socket-Verbindungen zwischen Anwendung und Datenbank auf demselben Host, da hier kein Netzwerkpfad existiert, der abgehört werden könnte. Für alle Verbindungen über TCP, insbesondere zwischen getrennten Servern oder über eine Cloud-VPC hinweg, bleibt eine konsequent erzwungene TLS-Verschlüsselung jedoch der Standard, den auch aktuelle Compliance-Rahmenwerke wie PCI-DSS 4.0 explizit voraussetzen.

10. Zusammenfassung

11. FAQ: TLS-verschlüsselte MySQL-Verbindungen: das Wichtigste auf einen Blick