I just learned that maxscale tls-verify-server-cert is not the same as the ssl-verify-server-cert option of server command line tools.

Server tools always check the CA chain and whether the current datetime is between the "valid from" and "valid until" timestamps, the ssl-verify-server-cert option only activates the extra server name verification step where the server name the client connected to is checked against the SAN (Server Alternative Names) list in the certificate returned by the server, or the CN (Common Name) entry in the certificate Subject field in absence of the x509 v3 SAN extension.

hholzgra could you edit the description of the bug report to describe what you think is not correct and what you think should be done about it? Right now I'm having a hard time understanding exactly what this bug report is about.

Well, the problem is – as so often – that Maxscale does things slightly different than the server and its bundled tools, just enough to be totally confusing and breaking the "principle of least surprise"

On the server/tools side we always have basic certificate verification enabled, the

option only configures whether the server name a client requested to connect to matches the server name certification (either a SAN entry, or Subject/CN if no SAN extension entry exists), and this specific verification option is off by default.

The Maxscale

setting on the other hand seems to be an all-or-nothing setting, it is on by default, and when turned off it will not verify certificates whatsoever, so even certificates with invalid CA chain or outside of their valid date range will be accepted. But there does not seem to be an option that works the same as on the server side that turns off server host name verification only.

And so we have two very similarly named options that do subtly – and actually critically – different things, and the functionality we are used to have on the server side – disabling name verification only – does not even seem to exist on the Maxscale side.

Not sure how to solve this naming issue "after the fact" though, I wished such things would be coordinated between dev teams beforehand ...

Making --tls-verify-server-cert behave identically to how --ssl-verify-server-cert behaves in MariaDB and then adding a --disable-tls-verification seems like a simple solution that gives us two things: the consistent behavior that we want and a more secure behavior for those who also assumed that the parameters behave identically. It'll be a breaking change but I wouldn't consider this to be a problem if the solution is to just opt-in to the old behavior that is "insecure".

Do you think the above would be a sensible approach? From what I've seen, --tls-verify-server-cert=false is nearly always used with self-signed certs and for testing purposes.

I converted this into a subtask of MXS-4958 since there's not a clear idea of what to do in the current releases so it'll be included in the next version where there'll (hopefully) be more fundamental changes to maxctrl.