Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2.41, 10.3.32, 10.4.22, 10.5.13, 10.6.5, 10.7.1
-
None
Description
Based on a discussion with sysprg, the SST script changes from MDEV-26360 allow users to configure a CA directory by setting ssl_ca, like this:
[mariadb]
|
...
|
wsrep_ssl_mode = SERVER_X509
|
|
ssl_ca = /certs/ca-cert/
|
ssl_cert = /certs/server-cert.pem
|
ssl_key = /certs/server-key.pem
|
This implementation is likely to result in problems. ssl_ca is a system variable owned by MariaDB Server. MariaDB Server expects the ssl_ca system variable to refer to an absolute path to a single PEM file:
ssl_ca
Description: Defines a path to a PEM file that should contain one or more X509 certificates for trusted Certificate Authorities (CAs) to use for TLS. This system variable requires that you use the absolute path, not a relative path. This system variable implies the ssl option.
https://mariadb.com/kb/en/ssltls-system-variables/#ssl_ca
If a Galera user tries to set the ssl_ca system variable to a path to a directory, MariaDB Server is likely to encounter an error during startup when it tries to treat the value as a path to a PEM file.
However, there is an easy solution. MariaDB Server provides the ssl_capath system variable to refer to a directory:
ssl_capath
Description: Defines a path to a directory that contains one or more PEM files that should each contain one X509 certificate for a trusted Certificate Authority (CA) to use for TLS. This system variable requires that you use the absolute path, not a relative path. The directory specified by this variable needs to be run through the openssl rehash command. This system variable implies the ssl option.
https://mariadb.com/kb/en/ssltls-system-variables/#ssl_capath
If we would like Galera users to be able to specify a path to a directory of CA certificates, we should probably use ssl_capath for this--not ssl_ca.
Attachments
Issue Links
- causes
-
MDEV-28170 missing '$' in variable check in wsrep_sst_common script
-
- Closed
-
- is caused by
-
MDEV-26360 Using hostnames for MariaBackup SSTs breaks certificate validation with encrypt=3
-
- Closed
-
- relates to
-
MDEV-23747 socket.ssl_ca argument being ignored.
-
- Closed
-
Activity
Field | Original Value | New Value |
---|---|---|
Link |
This issue is caused by |
Status | Open [ 1 ] | In Progress [ 3 ] |
Description |
Based on a discussion with [~sysprg], the SST script changes from {code:ini} [mariadb] ... wsrep_ssl_mode = SERVER_X509 ssl_ca = /certs/ca-cert/ ssl_cert = /certs/server-cert.pem ssl_key = /certs/server-key.pem {code} This implementation is likely to result in problems. {{ssl_ca}} is a system variable owned by MariaDB Server. MariaDB Server expects the {{ssl_ca}} system variable to refer to an absolute path to a single PEM file: {quote} ssl_ca Description: Defines a path to a PEM file that should contain one or more X509 certificates for trusted Certificate Authorities (CAs) to use for TLS. This system variable requires that you use the absolute path, not a relative path. This system variable implies the ssl option. {quote} https://mariadb.com/kb/en/ssltls-system-variables/#ssl_ca If a Galera user tries to set the {{ssl_ca} system variable to a path to a directory, MariaDB Server is likely to encounter an error during startup when it tries to treat the value as a path to a PEM file. However, there is an easy solution. MariaDB Server provides the {{ssl_capath}} system variable to refer to a directory: {quote} ssl_capath Description: Defines a path to a directory that contains one or more PEM files that should each contain one X509 certificate for a trusted Certificate Authority (CA) to use for TLS. This system variable requires that you use the absolute path, not a relative path. The directory specified by this variable needs to be run through the openssl rehash command. This system variable implies the ssl option. {quote} https://mariadb.com/kb/en/ssltls-system-variables/#ssl_capath If we would like Galera users to be able to specify a path to a directory of CA certificates, we should probably use {{ssl_capath}} for this--not {{ssl_ca}}. |
Based on a discussion with [~sysprg], the SST script changes from {code:ini} [mariadb] ... wsrep_ssl_mode = SERVER_X509 ssl_ca = /certs/ca-cert/ ssl_cert = /certs/server-cert.pem ssl_key = /certs/server-key.pem {code} This implementation is likely to result in problems. {{ssl_ca}} is a system variable owned by MariaDB Server. MariaDB Server expects the {{ssl_ca}} system variable to refer to an absolute path to a single PEM file: {quote} ssl_ca Description: Defines a path to a PEM file that should contain one or more X509 certificates for trusted Certificate Authorities (CAs) to use for TLS. This system variable requires that you use the absolute path, not a relative path. This system variable implies the ssl option. {quote} https://mariadb.com/kb/en/ssltls-system-variables/#ssl_ca If a Galera user tries to set the {{ssl_ca}} system variable to a path to a directory, MariaDB Server is likely to encounter an error during startup when it tries to treat the value as a path to a PEM file. However, there is an easy solution. MariaDB Server provides the {{ssl_capath}} system variable to refer to a directory: {quote} ssl_capath Description: Defines a path to a directory that contains one or more PEM files that should each contain one X509 certificate for a trusted Certificate Authority (CA) to use for TLS. This system variable requires that you use the absolute path, not a relative path. The directory specified by this variable needs to be run through the openssl rehash command. This system variable implies the ssl option. {quote} https://mariadb.com/kb/en/ssltls-system-variables/#ssl_capath If we would like Galera users to be able to specify a path to a directory of CA certificates, we should probably use {{ssl_capath}} for this--not {{ssl_ca}}. |
Priority | Major [ 3 ] | Critical [ 2 ] |
Status | In Progress [ 3 ] | In Testing [ 10301 ] |
Status | In Testing [ 10301 ] | Stalled [ 10000 ] |
Status | Stalled [ 10000 ] | In Testing [ 10301 ] |
Status | In Testing [ 10301 ] | Stalled [ 10000 ] |
Assignee | Julius Goryavsky [ sysprg ] | Jan Lindström [ jplindst ] |
Status | Stalled [ 10000 ] | In Review [ 10002 ] |
Assignee | Jan Lindström [ jplindst ] | Ramesh Sivaraman [ JIRAUSER48189 ] |
Link | This issue causes MENT-1377 [ MENT-1377 ] |
Assignee | Ramesh Sivaraman [ JIRAUSER48189 ] | Julius Goryavsky [ sysprg ] |
issue.field.resolutiondate | 2021-12-14 13:08:20.0 | 2021-12-14 13:08:20.495 |
Fix Version/s | 10.2.42 [ 26803 ] | |
Fix Version/s | 10.3.33 [ 26805 ] | |
Fix Version/s | 10.4.23 [ 26807 ] | |
Fix Version/s | 10.5.14 [ 26809 ] | |
Fix Version/s | 10.6.6 [ 26811 ] | |
Fix Version/s | 10.7.2 [ 26813 ] | |
Fix Version/s | 10.2 [ 14601 ] | |
Fix Version/s | 10.3 [ 22126 ] | |
Fix Version/s | 10.4 [ 22408 ] | |
Fix Version/s | 10.5 [ 23123 ] | |
Fix Version/s | 10.6 [ 24028 ] | |
Fix Version/s | 10.7 [ 24805 ] | |
Resolution | Fixed [ 1 ] | |
Status | In Review [ 10002 ] | Closed [ 6 ] |
Link |
This issue relates to |
Link |
This issue causes |
In my opinion this is ok to push.