MySQL 5.1.66 SSL-Verbindungsfehler FEHLER 2026 (HY000)

37

UPDATE2

Mit WireShark habe ich den Problemstring herausgefunden (ich hoffe ich habe es getan):

28 | 9.582638 | 192.168.18.128 | 192.168.18.129 | MySQL Response Error 1043

Und der Fehler ist (laut docs ):

Error: 1043 SQLSTATE: 08S01 (ER_HANDSHAKE_ERROR)
Message: Bad handshake

Hier sind die Screenshots von WireShark in zwei Fällen:

Verbindung von Windows 8 (Erfolg):

Bildbeschreibung hier eingeben

Verbindung von CentOS (Fail):

Bildbeschreibung hier eingeben

Warum passiert das?

AKTUALISIEREN

Ein interessanter Hinweis:
Ich habe unter Windows 8 erfolgreich eine Verbindung zur Master- (192.168.18.1)Datenbank hergestellt, indem ich die ssluser-Einstellung auf dem Master für den 192.168.18.1Host geändert habe - eine Änderung vorgenommen: von REQUIRE SSLnach REQUIRE X509. Dies funktioniert in unserem Fall jedoch nicht mit einer Slave-zu-Master-Verbindung.

Ich habe ein Problem mit der SSL-Replikation in CentOS-6.3. Ich verwende OpenSSL, um sowohl Client- als auch Serverzertifikate zu erstellen, und sowohl Client- als auch Serverzertifikate werden von derselben Zertifizierungsstelle signiert.

Server IP: 192.168.18.128
Slave  IP: 192.168.18.129
MySQL version 5.1.66 SSL

Alle Zertifikate, die ich über den Abschnitt "Einrichten von SSL-Zertifikaten und -Schlüsseln für MySQL" auf den MySQL-Hilfeseiten erhalte .

Die my.cnf- Datei des Servers :

[mysqld]
ssl-key=/etc/mysql/certs/server-key.pem
ssl-cert=/etc/mysql/certs/server-cert.pem
ssl-ca=/etc/mysql/certs/ca-cert.pem

Client my.cnf Datei:

[client]
ssl-ca=/etc/mysql/ssl/ca-cert.pem
ssl-key=/etc/mysql/ssl/client-key.pem
ssl-cert=/etc/mysql/ssl/client-cert.pem

Auf dem Master richte ich einen Slave-Benutzer mit SSL wie folgt ein:

CREATE USER 'ssluser'@'192.168.18.129' IDENTIFIED BY 'sslpass';
GRANT REPLICATION SLAVE ON *.* TO 'ssluser'@'192.168.18.129' REQUIRE SSL;

Um Slave zu aktualisieren verwende ich den folgenden Befehl (laut show master statusBefehl):

SLAVE STOP;
CHANGE MASTER TO \
             MASTER_HOST='192.168.18.128',                      \
             MASTER_USER='sslreplicant',                        \
             MASTER_PASSWORD='db.sslreplicantprimary',          \
             MASTER_LOG_FILE='mysql-bin.000026',                \
             MASTER_LOG_POS=106,                                \
             MASTER_SSL=1,                                      \
             MASTER_SSL_CA='/etc/mysql/certs/ca-cert.pem',      \
             MASTER_SSL_CAPATH='/etc/mysql/certs/',             \
             MASTER_SSL_CERT='/etc/mysql/certs/client-cert.pem',\
             MASTER_SSL_KEY='/etc/mysql/certs/client-key.pem';
SLAVE START;

Die Replikation selbst funktioniert einwandfrei:

mysql> SHOW VARIABLES LIKE '%ssl%';

have_openssl  = YES
have_ssl      = YES
ssl_ca        = /etc/mysql/certs/ca-cert.pem
ssl_capath    =
ssl_cert      = /etc/mysql/certs/server-cert.pem
ssl_cipher    =
ssl_key       = /etc/mysql/certs/server-key.pem

Dies gilt sowohl für den Master als auch für den Slave.

Aber wenn ich die Verbindung vom Slave zum Master manuell überprüfe, erhalte ich eine Fehlermeldung.

Hier sind die Optionen, die ich bisher ausprobiert habe (das gleiche Ergebnis von allen):

[gahcep@localhost  ~]$ mysql -u ssluser -h 192.168.18.128 -p

[gahcep@localhost  ~]$ mysql --ssl --ssl-ca=/etc/mysql/certs/ca-cert.pem \
                             -u ssluser -h 192.168.18.128 -p

[gahcep@localhost ~]$ mysql --ssl-ca=/etc/mysql/certs/ca-cert.pem \
                            --ssl-cert=/etc/mysql/certs/client-cert.pem \
                            --ssl-key=/etc/mysql/certs/client-key.pem \
                            -u ssluser -h 192.168.18.128 -p

Enter password:
ERROR 2026 (HY000): SSL connection error

Schritte zum Reproduzieren:

  1. Richten Sie sowohl Clients als auch Server-Zertifikate ein, die von denselben signiert sind.
  2. Richten Sie sowohl my.cnf-Dateien auf Clients als auch auf Servern ein, wie in diesem Thread erwähnt
  3. erstelle ssluser auf master für slave
  4. mysql -u ssluser -h 192.168.18.128 -p

Bitte beachten Sie, dass ich in der Tat für alle Zertifikate unterschiedliche Common Names verwendet habe: für CA, Client und Server.

ZUSÄTZLICHE INFORMATION

Überprüfungsergebnisse:

[gahcep@localhost ~]$ sudo openssl verify -purpose sslclient \
           -CAfile /etc/mysql/certs/ca-cert.pem /etc/mysql/certs/client-cert.pem
/etc/mysql/certs/client-cert.pem: OK

[gahcep@localhost ~]$ sudo openssl verify -purpose sslserver \
           -CAfile /etc/mysql/certs/ca-cert.pem /etc/mysql/certs/server-cert.pem
/etc/mysql/certs/server-cert.pem: OK

Zertifikatsinformationen:

CA:

[gahcep@localhost ~]$ sudo openssl x509 -noout -subject -issuer -dates \
           -serial -hash -fingerprint -in /etc/mysql/certs/ca-cert.pem
subject= /C=RU/L=Vladivostok/O=Default Company Ltd/CN=PriSec
issuer= /C=RU/L=Vladivostok/O=Default Company Ltd/CN=PriSec
notBefore=Jan  4 06:27:46 2013 GMT
notAfter=Nov 13 06:27:46 2022 GMT
serial=B45D177E85F99578
c2c5b88b
SHA1 Fingerprint=5B:07:AA:39:28:24:CE:1A:CF:35:FA:14:36:23:65:8F:84:61:B0:1C

Client-Zertifikat:

[gahcep@localhost ~]$ sudo openssl x509 -noout -subject -issuer -dates \
           -serial -hash -fingerprint -in /etc/mysql/certs/client-cert.pem
subject= /C=RU/L=Vladivostok/O=Default Company Ltd/CN=Secondary
issuer= /C=RU/L=Vladivostok/O=Default Company Ltd/CN=PriSec
notBefore=Jan  4 06:29:07 2013 GMT
notAfter=Nov 13 06:29:07 2022 GMT
serial=01
6df9551f
SHA1 Fingerprint=F5:9F:4A:14:E8:96:26:BC:71:79:43:5E:18:BA:B2:24:BE:76:17:52

Server-Zertifikat:

[gahcep@localhost ~]$ sudo openssl x509 -noout -subject -issuer -dates \
            -serial -hash -fingerprint -in /etc/mysql/certs/server-cert.pem
subject= /C=RU/L=Vladivostok/O=Default Company Ltd/CN=Primary
issuer= /C=RU/L=Vladivostok/O=Default Company Ltd/CN=PriSec
notBefore=Jan  4 06:28:25 2013 GMT
notAfter=Nov 13 06:28:25 2022 GMT
serial=01
64626d57
SHA1 Fingerprint=39:9E:7A:9E:60:9A:58:68:81:2F:90:A5:9B:BF:E8:26:C5:9D:3C:AB

Verzeichnisse Berechtigungen:

Am Meister:

[gahcep@localhost ~]$ ls -la /etc/mysql/certs/
drwx------. 3 mysql  mysql  4096 Jan  3 23:49 .
drwx------. 3 mysql  mysql  4096 Jan  3 07:34 ..
-rw-rw-r--. 1 gahcep gahcep 1261 Jan  3 22:27 ca-cert.pem
-rw-rw-r--. 1 gahcep gahcep 1675 Jan  3 22:27 ca-key.pem
-rw-rw-r--. 1 gahcep gahcep 1135 Jan  3 22:28 server-cert.pem
-rw-rw-r--. 1 gahcep gahcep 1679 Jan  3 22:28 server-key.pem
-rw-rw-r--. 1 gahcep gahcep  976 Jan  3 22:28 server-req.pem

Auf Slave:

[gahcep@localhost ~]$ ls -la /etc/mysql/certs/
drwx------. 3 mysql mysql 4096 Jan  3 22:57 .
drwx------. 3 mysql mysql 4096 Jan  3 07:50 ..
-rw-r--r--. 1 root  root  1261 Jan  3 22:56 ca-cert.pem
-rw-r--r--. 1 root  root  1139 Jan  3 22:57 client-cert.pem
-rw-r--r--. 1 root  root  1675 Jan  3 22:57 client-key.pem

Wenn jemand die Lösung vorschlagen kann, würde ich das wirklich begrüßen!

mysql  replication  ssl 
— gahcep
quelle
Kommentare sind nicht für eine längere Diskussion gedacht. Diese Unterhaltung wurde in den Chat verschoben .
— Paul White sagt GoFundMonica

Antworten:

2

Versuchen Sie, Zertifikatsdateien zu erstellen, die MySQL-Benutzern gehören und für andere nicht lesbar sind.

Sie können es auch mit einer festen Chiffre versuchen:

mysql ... --ssl-cipher=AES128-SHA

Und für den Change Master:

CHANGE MASTER TO ... MASTER_SSL_CIPHER='AES128-SHA'

— Antonio Bardazzi
quelle
1

Mögliche Lösungen:

So stellen Sie fest, ob MySQL Server yaSSL oder OpenSSL verwendet

Dies zeigt eine Problemumgehung für das Fehlen eines geeigneten globalen Statuswerts. Die Idee ist, nach der Rsa_public_keyStatusvariablen zu suchen:

mysql> show status like '%rsa%';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| Rsa_public_key |       |
+----------------+-------+
1 row in set (0.00 sec)

Wenn OpenSSL verwendet wird, ist diese Variable vorhanden. sonst ist es yaSSL.

Andere Möglichkeit:

MySQL- und SSL-Verbindung fehlgeschlagen. FEHLER 2026 (HY000) ( Stapelüberlauf )

— skinfrakki
quelle
1

Wenn Sie alles versucht haben, aber SSL nicht funktioniert und Sie gleichzeitig mysqld in chroot ausführen, ist die Ursache für die Fehler folgende:

ERROR 2026 (HY000): SSL connection error: error:00000001:lib(0):func(0):reason(1)

oder

ERROR 2026 (HY000): SSL connection error: protocol version mismatch

Möglicherweise haben Sie vergessen, dev / random- und dev / urandom-Geräte in der chroot-Umgebung zu erstellen (und openssl lib kann keine Entropie abrufen - diese Geräte werden nach chroot geöffnet ). Sie können dies folgendermaßen beheben (ersetzen Sie es /srv/mysqlddurch Ihr Chroot- mysqldVerzeichnis und durch den Benutzer, unter dem mysqld ausgeführt wird):

sudo install -d -o mysqld -g mysqld -m 500 /srv/mysqld/dev
sudo mknod -m 444 /srv/mysqld/dev/random c 1 8
sudo mknod -m 444 /srv/mysqld/dev/urandom c 1 9
— Anatoli
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.