[MXS-4041] Support reloading of the REST API TLS certificates Created: 2022-03-10 Updated: 2024-02-07 Resolved: 2022-04-29 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | REST-API |
| Affects Version/s: | None |
| Fix Version/s: | 22.08.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | markus makela | Assignee: | markus makela |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Sprint: | MXS-SPRINT-156 | ||||||||||||||||
| Description |
|
With The hardest part will most likely be the fact that we don't directly control the network layer of the HTTP daemon as libmicrohttpd handles that. There are also some concurrency issues if the websocket interface is being used to stream the logs. |
| Comments |
| Comment by markus makela [ 2022-04-28 ] |
|
Turns out this was easier than expected as libmicrohttpd has a facility for selecting which TLS certificate is presented to the client. This simplifies the problem to only updating the certificates to use the GnuTLS format that is needed for it. The reloading will affect all future connections and all existing ones will still use the old certificates. This isn't a problem if the only intention is to allow new certificates to be taken into use. If the certificate rotation is done to avoid using old, compromised certificates, MaxScale should still be restarted. In the end, the traffic between the MaxScale REST API and clients has a short lifetime which should make this less of a practical problem and more of a theoretical one. |
| Comment by markus makela [ 2022-04-29 ] |
|
The maxctrl reload tls command now also reloads the certificates for the REST API. |