Details
Description
Now when Galera node can not join the cluster becuase of some problem with certificates we get just this kind of error messages:
2020-02-10 15:01:01 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer 'node1:4567,node2:4567,node3:4567'
|
2020-02-10 15:01:01 0 [ERROR] WSREP: handshake with remote endpoint ssl://a.b.c.d:4567 failed: asio.ssl:336134278: 'certificate verify failed' ( 336134278: 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed')
|
...
|
It would be useful to get more detailed explanation about the problem. All elements of certificates must be checked and if one element fails (wrong CN, something else, in root or in one of intermediate certificates, etc), it must be reported what it is.
This would help a lot in troubleshooting.
As a side note, it would be useful to get node names and not their resolved IP-addresses in the messages.
Attachments
Issue Links
- is part of
-
MDEV-22131 allow transition from unencrypted to TLS cluster communication without cluster downtime
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Seppo Jaakola [ seppo ] |
| Link |
This issue is part of |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
The TLS/SSL error messages have been worked on with the latest Galera 4.8 library, as part of other TLS - Galera interoperability refactoring. According to the actual author, Teemu:
"The error messages are the ones which are returned by SSL library, but the format should now be more human friendly.
And they contain additional information in case of certificate verification failure."
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
Pristine SSL library error messages are now logged with better readable format.
Additionally, certification related errors are logged as separately as well.
| Status | Stalled [ 10000 ] | In Review [ 10002 ] |
| Fix Version/s | 10.5 [ 23123 ] | |
| Fix Version/s | 10.6 [ 24028 ] | |
| Fix Version/s | 10.3 [ 22126 ] |
| issue.field.resolutiondate | 2021-05-27 08:11:56.0 | 2021-05-27 08:11:56.718 |
| Fix Version/s | 10.6.0 [ 24431 ] | |
| Fix Version/s | 10.5.10 [ 25204 ] | |
| Fix Version/s | 10.4.19 [ 25205 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Fix Version/s | 10.5 [ 23123 ] | |
| Fix Version/s | 10.6 [ 24028 ] | |
| Assignee | Seppo Jaakola [ seppo ] | Jan Lindström [ jplindst ] |
| Resolution | Fixed [ 1 ] | |
| Status | In Review [ 10002 ] | Closed [ 6 ] |
| Workflow | MariaDB v3 [ 103944 ] | MariaDB v4 [ 134184 ] |
| Zendesk Related Tickets | 201571 193314 135838 | |
| Zendesk active tickets | 201571 |
I'd emphasize the need to have exactly the name used in the configuration in the messages, and not anything resolved. This will matter in case the CN check fails because the configuration uses the wrong name.
It's also very unclear what checks there are now on the client-side. Since the same configuration parameters are used both for server- and client-authentication, the logs must specify which part failed (was it the client failing to authenticate the server, or the server failing to authenticate the client?).