Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
6.2.4
-
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.