[MXS-4169] Listeners created at runtime require ssl_ca_cert when it should not be required Created: 2022-06-18 Updated: 2022-06-23 Resolved: 2022-06-23 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Core |
| Affects Version/s: | 6.2.4 |
| Fix Version/s: | 6.4.1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Assen Totin (Inactive) | Assignee: | markus makela |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
It seems MaxScale is seriously confused about configuring the encryption. I've only tested the Listener side on the mentioned version, but likely all other versions are affected - and the Server entry may also need checking. First, MaxScale confuses encryption (ssl=true) with authentication (ssl_cert=..., ssle_key=...). These are two independent and different things. Certificates are never used for encryption, they only certify the identity of the remote part. Encryption is based on Diffie-Hellman Key Exchange and can (and should) be allowed without the extra authentication that a certificate provides. So, "ssl=true" should not require neither "ssl_key" nor "ssl_cert". Second, the static configuration of a Listner comes up and works as expected (i.e. only encrypted connections allowed) when "ssl=ture" is given together with "ssl_key=..." and "ssl_cert=...". However, attempting to add a listener with these three params via the API (maxctrl) into the dynamic configuration, returns an error: "SSL configuration for listeners requires 'ssl_key', 'ssl_cert' and 'ssl_ca_cert' parameters" This is bad two times: first, we have a discrepancy between required minimal static and dynamic config; second, a CA should not be required, because it is only useful to validate client certificates and is, hence optional; the SQL client is the one expected to have the MaxScale's chain of trust in order to validate the MaxScale's certificate (like your browsers do with an HTTPS server). Third, continuing from the previous, a Listener should be allowed to use a self-signed certificate, which is currently impossible; if you try to put the self-signed certificate also as the CA one, it again produces an error: "Failed to set Certificate Authority file: error:0B084088:x509 certificate routines:X509_load_cert_crl_file:no certificate or crl found" While the check is OK per se, the requirement to always have a CA should be removed. |
| Comments |
| Comment by markus makela [ 2022-06-20 ] |
|
For server objects in MaxScale you only need to provide ssl=true for it to work with the installed certificates (e.g. with the trust tool on RHEL systems). For listeners, you must provide a public certificate and a private key (MariaDB requires the CA also). I believe most cipher suites authenticate the server's certificate and the ones that don't either require a pre-shared key or are considered weak due to MITM possibilities. For this reason MaxScale requires the ssl_cert and ssl_key parameters for listeners and we haven't had any requests for anonymous ciphersuites. I did confirm that the runtime creation of listeners checks for ssl_ca_cert when using it but defining the same listener in the configuration files does not require it. This is most likely a remnant from the time before the CA cert requirement was dropped for listeners. A workaround to this is to first create the listener and then enable encryption on it. |