Erreur de connexion SSL MySQL 5.1.66 ERROR 2026 (HY000)

UPDATE2

En utilisant WireShark, j'ai découvert le problème (j'espère l'avoir fait):

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

Et l'erreur est (selon la documentation ):

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

Voici les captures d'écran de WireShark dans deux cas:

Connexion à partir de Windows 8 (succès):

Connexion à partir de CentOS (échec):

Pourquoi cela arrive-t-il?

MISE À JOUR

Une remarque intéressante:
je me suis connecté avec succès à Master DB sous Windows 8 (192.168.18.1)en modifiant le paramètre ssluser sur Master pour 192.168.18.1hôte - modification apportée: de REQUIRE SSLà REQUIRE X509. Cependant, cela ne fonctionne pas dans notre cas avec une connexion esclave-maître.

J'ai rencontré un problème de réplication SSL dans CentOS-6.3. J'utilise OpenSSL pour créer des certificats de client et de serveur. Les certificats de client et de serveur sont signés par la même autorité de certification.

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

Tous les certificats que je reçois à l'aide de la section "Configuration des certificats SSL et des clés pour MySQL" des pages d'aide de MySQL.

Fichier my.cnf du serveur :

[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

Fichier my.cnf du client :

[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

Sur Master, je configure un utilisateur esclave avec SSL comme ceci:

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

Pour mettre à jour Slave, j'utilise la commande suivante (selon la show master statuscommande):

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;

La réplication elle-même fonctionne bien:

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

C'est à la fois - sur maître et sur esclave.

Mais lorsque je vérifie manuellement la connexion d'esclave à maître, un message d'erreur s'affiche.

Voici les options que j'ai essayées jusqu'à présent (le même résultat de tout le monde):

[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

Étapes à suivre pour reproduire:

1. installer / créer les certificats client et serveur signés par le même ca.
2. configurer les deux fichiers my.cnf sur les clients et les serveurs, comme indiqué dans ce fil de discussion
3. créer un utilisateur sur maître pour esclave
4. mysql -u ssluser -h 192.168.18.128 -p

Veuillez noter que j’ai en effet utilisé différents noms communs pour tous les certificats: CA, clien et serveur.

INFORMATION ADDITIONNELLE

Résultats de vérification:

[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

Informations de certification:

CALIFORNIE:

[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

Certificat client:

[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

Certificat de serveur:

[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

Autorisations de répertoires:

Sur le maître:

[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

Sur esclave:

[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

Si quelqu'un peut suggérer la solution, je l'apprécierais vraiment!

Essayez de créer des fichiers de certificat appartenant à l'utilisateur mysql et non lisibles par d'autres.

Vous pouvez aussi essayer avec un chiffre fixe:

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

Et pour le maître du changement:

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

Solutions possibles:

Comment savoir si MySQL Server utilise yaSSL ou OpenSSL

Cela montre une solution de contournement pour l’absence d’une valeur de statut global appropriée. L'idée est de vérifier la Rsa_public_keyvariable d'état:

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

Si OpenSSL est en cours d'utilisation, cette variable existera. sinon c'est yaSSL.

Autre possibilité:

Echec de la connexion MySQL et SSL ERROR 2026 (HY000) (dépassement de capacité de la pile)

Si vous avez tout essayé, mais que SSL ne fonctionne pas et qu'en même temps vous utilisez mysqld dans chroot, alors la cause des erreurs est la suivante:

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

ou

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

vous avez peut-être oublié de créer des périphériques dev / random et dev / urandom dans l’environnement chroot (et openssl lib ne peut pas obtenir d’entropie - il ouvre ces périphériques après le chroot). Vous pouvez le réparer de cette façon (remplacez /srv/mysqldpar votre répertoire chroot et mysqldpar l'utilisateur mysqld qui s'exécute sous):

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