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 1043Et 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:
- installer / créer les certificats client et serveur signés par le même ca.
- configurer les deux fichiers my.cnf sur les clients et les serveurs, comme indiqué dans ce fil de discussion
- créer un utilisateur sur maître pour esclave
- 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!
la source
Réponses:
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-SHAEt pour le maître du changement:
CHANGE MASTER TO ... MASTER_SSL_CIPHER='AES128-SHA'la source
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: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)
la source
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:
ou
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 etmysqldpar l'utilisateur mysqld qui s'exécute sous):la source