[MXS-3931] Check certificates with extendedKeyUsage options set for correct purpose flags Created: 2022-01-04 Updated: 2022-03-07 Resolved: 2022-03-04 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Core |
| Affects Version/s: | 2.5.17, 6.1.4, 6.2.0 |
| Fix Version/s: | 2.5.20, 6.2.3 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Hartmut Holzgraefe | Assignee: | markus makela |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Sprint: | MXS-SPRINT-152 |
| Description |
|
When having certificates with extendedKeyUsage extension set we need the clientAuth (aka TLS Web Client Authentication) set on certificates used in type=server sections, and serverAuth for those in type=listener sections. We now already had at least two cases where users used a certificate that only had either the server or client auth purpose flag set for both server and listener entries as they either thought "Maxscale is a server" or opposite "Maxscale is not a server". Right now this only leads to problems at actual connect time. When only the serverAuth flag is set it becomes clear what's wrong pretty quick as the monitor will already run into "unsupported cert purpose" right after startup on trying to connect to backend servers. Listeners will start up just fine though with a certificate that only has the clientAuth purpose set, and the problem only becomes apparent when actual clients try to connect and TLS handshake fails with "unsupported cert purpose" upon receiving and verifying the server certificate. Would be nice if maxscale would check the listner certificate(s) right on router startup to check whether the certificate(s) is(are) valid for intended purpose. |
| Comments |
| Comment by markus makela [ 2022-03-03 ] |
|
I'll change this to a bug since it's something that should be checked during configuration time as it prevents the service from working correctly. However this can only be prevented with systems that use OpenSSL 1.1 or newer as the required X509v3 functions seem to only be defined there. |
| Comment by markus makela [ 2022-03-04 ] |
|
MaxScale now checks that the certificate purpose is suitable for the intended use. This means that if a certificate for a listener has clientAuth but not serverAuth, the certificate is rejected as invalid. The same applies for servers: a certificate with only serverAuth will not be accepted. If the certificate has both purposes or neither, they are accepted as valid. This should help detect errors much earlier and also retain the old good configuration in case this is done at runtime. |