[MXS-3982] Support TLS certificate reload at runtime Created: 2022-02-02  Updated: 2022-10-27  Resolved: 2022-03-10

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 2.4.19, 2.5.18, 6.1.4, 6.2.1
Fix Version/s: 22.08.0

Type: New Feature Priority: Major
Reporter: Hartmut Holzgraefe Assignee: markus makela
Resolution: Fixed Votes: 2
Labels: None

Issue Links:
Issue split
split to MXS-4041 Support reloading of the REST API TLS... Closed
Relates
relates to MXS-3128 Cannot refresh SSL Certificates witho... Closed

 Description   

Since MariaDB 10.4.1 the server supports run time reloading of TLS certificates with FLUSH SSL, and since 10.6.0 also with mysqladmin flush-ssl, which comes in handy when a certificate needs to renewed before reaching its expire date without server downtime, and especially with short lived certificates like e.g. those issued by LetsEncrypt.

Maxscale currently seems to be missing this capability, server and listener certificates may be reloaded explicitly one by one using maxctrl, but for the admin REST API itself there does not seem to be any such mechanism at all, so this can only be changed with a maxscale restart, and so with a little bit of downtime.

So the main feature request would be to have an equivalent to the servers "FLUSH SSL" that would reload all certificate files currently in use by maxscale.

In addition to this certificate reloads should maybe also be part of SIGHUP signal handling, as in case of an already expired REST API certificate that may be the only way to still trigger a certificate reload without restart/downtime while REST API access may no longer be possible with an expired admin certificate.

 Comments   
Comment by markus makela [ 2022-03-09 ]

Adding a small helper REST API endpoint for reloading all listener and server certificates is relatively easy. The hard part is reloading the TLS certificates for the REST API itself.

Comment by markus makela [ 2022-03-10 ]

I created MXS-4041 for the REST API part now that the maxctrl reload tls command was added for version 7. This should at least help with the case where the certificates for the actual traffic are rotated frequently (e.g. LetsEncrypt) and a separate set of self-signed certificates are used for the REST API. The actual validity of the TLS certificates for the REST API is possibly less important if used with MaxCtrl as it mainly cares that the traffic is encrypted and it is usually used from the same machine where MaxScale is installed. For the GUI it is more important to have valid certificates as browsers will warn about self-signed certificates and it is probably more common to expose the GUI via some secure remote tunnel.

Comment by Hartmut Holzgraefe [ 2022-07-14 ]

What version is 22.08.0?

Can we keep such tickets open instead of closed until the actual release number is clear? I now have a customer case that is waiting in this closed ticket, but I can't tell the customer "this is now fixed and will be part of upcoming release number x.y.z"; and I can't really change the case status to "Waiting on new release" either as it's not clear what actual release it would be waiting on ...

Comment by markus makela [ 2022-07-14 ]

It'll be the 22.08.0 release of MaxScale, the next major release. That is the actual version number.

Generated at Thu Feb 08 04:25:21 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.