Bug #101892 mysqlsh does not support all SSL modes for group replication
Submitted: 7 Dec 2020 12:38 Modified: 25 Feb 2021 14:17
Reporter: Eduardo Ortega Email Updates:
Status: Closed Impact on me:
None 
Category:Shell AdminAPI InnoDB Cluster / ReplicaSet Severity:S4 (Feature request)
Version:8.0.22 OS:CentOS
Assigned to: CPU Architecture:Any

[7 Dec 2020 12:38] Eduardo Ortega
Description:
We have an InnoDB cluster. We recently changed its ssl config settings from not being explicitly set to these:

root@ohost2-6002 [(none)]> show global variables like 'group_replication%ssl%';
+---------------------------------------------------+------------------------------------+
| Variable_name                                     | Value                              |
+---------------------------------------------------+------------------------------------+
| group_replication_recovery_ssl_ca                 | /etc/ssl/certs/ca-bundle.crt       |
| group_replication_recovery_ssl_capath             |                                    |
| group_replication_recovery_ssl_cert               | /etc/ssl/example/mysql.crt         |
| group_replication_recovery_ssl_cipher             |                                    |
| group_replication_recovery_ssl_crl                |                                    |
| group_replication_recovery_ssl_crlpath            |                                    |
| group_replication_recovery_ssl_key                | /etc/ssl/example/private/mysql.key |
| group_replication_recovery_ssl_verify_server_cert | ON                                 |
| group_replication_recovery_use_ssl                | ON                                 |
| group_replication_ssl_mode                        | VERIFY_IDENTITY                    |
+---------------------------------------------------+------------------------------------+
10 rows in set (0.01 sec)

root@ohost2-6002 [(none)]> 

Now we cannot add members to the cluster:

 MySQL  ohost2-2001.lhr4.example.com:33060+ ssl  Py > c=dba.get_cluster()
 MySQL  ohost2-2001.lhr4.example.com:33060+ ssl  Py > c.add_instance('gr_admin@ohost2-6004.fra3.example.com:3306')
ERROR: Failed to erase the password: Unknown or unsupported command: erase
Please provide the password for 'gr_admin@ohost2-6004.fra3.example.com:3306': ********************
Save password for 'gr_admin@ohost2-6004.fra3.example.com:3306'? [Y]es/[N]o/Ne[v]er (default No): N
Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: RuntimeError: Cluster.add_instance: Unsupported Group Replication SSL Mode for the cluster: 'VERIFY_IDENTITY'. If the cluster was created using adoptFromGR:true make sure the group_replication_ssl_mode variable is set with a supported value (DISABLED or REQUIRED) for all cluster members.

 MySQL  ohost2-2001.lhr4.example.com:33060+ ssl  Py >

This link seems to confirm mysqlsh does not support VERIFY_CA or VERIFY_IDENTITY: https://dev.mysql.com/doc/dev/mysqlsh-api-javascript/8.0/classmysqlsh_1_1dba_1_1_cluster.h...

Can you please extend it so that it matches what mysql server actually offers? Thanks.

How to repeat:
1. Provision an InnoDB cluster with default settings
2. Set the 'group_replication%ssl%' variables to the values shown abovo
3. Try to add a member to the cluster with mysqlsh
[10 Dec 2020 12:28] MySQL Verification Team
Sure Eduardo,let me request concern team to fix this.

regards,
Umesh
[25 Feb 2021 14:17] David Moss
Thank you for your feedback, this has been fixed in upcoming versions and the following was added to the 8.0.24 change log:
The memberSslMode option did not support the VERIFY_CA and VERIFY_IDENTITY modes for the following operations:

dba.createCluster()

Cluster.addInstance()

Cluster.rejoinInstance()

Now, the memberSslMode option supports these modes, and when they are used there is a validation to ensure that the CA certificates are supplied. If you choose to use the VERIFY_CA or VERIFY_IDENTITY mode, on each cluster instance you must manually supply the CA certificates using the ssl_ca and/or ssl_capath option. For more information, see Securing your Cluster.

Thanks to Daniƫl van Eeden for the contribution.