MDEV-39857: Add ssl-alt-cert/ssl-alt-key for dual RSA+ECDSA certificate support#5178
MDEV-39857: Add ssl-alt-cert/ssl-alt-key for dual RSA+ECDSA certificate support#5178rmetrich wants to merge 2 commits into
Conversation
|
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces dual RSA and ECDSA certificate support by adding the --ssl-alt-cert and --ssl-alt-key configuration options. It updates the SSL initialization logic to load these alternate credentials into the same SSL context and includes integration tests to verify that clients can connect using either RSA or ECDSA ciphers. The feedback suggests adding validation to ensure that if either the alternate certificate or key is provided, both must be specified, preventing the configuration from being silently ignored.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
gkodinov
added
the
External Contribution
MariaDB currently supports only a single SSL certificate, configured via --ssl-cert and --ssl-key. Services like httpd, nginx, and haproxy can serve both RSA and ECDSA certificates simultaneously, selecting the appropriate one based on the cipher suite negotiated with the client. This adds --ssl-alt-cert and --ssl-alt-key options that load a second certificate/key pair into the same SSL_CTX. OpenSSL natively supports one certificate per key type (RSA, ECDSA, EdDSA) and automatically selects the matching certificate during the TLS handshake. Example configuration: [mysqld] ssl-cert=/path/to/server-rsa.crt ssl-key=/path/to/server-rsa.key ssl-alt-cert=/path/to/server-ecdsa.crt ssl-alt-key=/path/to/server-ecdsa.key
rmetrich
changed the title
rmetrich
changed the title
The server must refuse to start if only one of the two alternate SSL options is specified, since a certificate without its key (or vice versa) cannot be used. Add an explicit check and error message, and add MTR tests covering all four error scenarios: missing key, missing cert, invalid cert file, and invalid key file.
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
Thank you for your contribution! This is a preliminary review.
I believe this needs to be designed well first. So please consider adding a Jira about it, as mentioned by the community contributions guidelines.
Also, please keep 1 commit per "feature". I believe in your case that should be 1 in total: makes it easier to merge later.
Now on the substance of the issue:
First of all: Great analysis! This is something we've missed for so many years. So, again, thanks for bringing this up!
Now on the execution: You are saying that OpenSSL (currently) supports 3 certificate chains (so far). And it's picking which one to use based on the cipher.
now, you're adding --ssl-alt-cert and --ssl-alt-key. Singular. This makes 2 cert/key pairs. What about the 3d? Or future ones?
Now, one thing you're not saying is that these certs need to come from the same cert chain. https://linux.die.net/man/3/ssl_ctx_use_certificate_file says that
SSL_CTX_use_certificate_file() loads the first certificate stored in file into ctx.
The first!
So you might end up needing --ssl-alt-ca etc.
And, finally, you have exactly the same issue on the client. Do you want to support multiple certificate chains on it too?
This is where some forethought and a good design would have been handy!
I have no strong preference here (it's the preliminary review too). But I'll pitch in some thoughts:
- make all tools take multiple --ssl-cert --ssl-key options. It solves the "multiple" design problem. But then you may need to somehow match the keys to the certs. Define that. I'd use positional matching: first cert matches with the first key etc. Not really needed by openssl, but it'd be nice to define for future use.
- keep all tools in lock-step: people by now are used to having the same options on the client and on the server.
- Consider switching to SSL_CTX_use_certificate_chain_file() when processing these files so you could keep the cert chain out of the --ssl-ca list.
- Consider exposing the current cert selected and/or the list of certs/keys available as status vars for observability. This will help with writing more meaningful tests too.
- Consider the effects on other SSL libraries mariadb supports. Will it work on e.g. wolfSSL? How exactly? Ditto GnuTLS. You might need to have a status variable for this alone. E.g. so that automated configs somehow know if this is supported or not.
Looking forward to the Jira with a good design that has all of these questions answered.
|
Regarding 2 certificates only, it's true OpenSSL can load up to 3, but I believe it's totally overkill for now, because Regarding |
|
What do you mean by file a JIRA btw? it's the first time I contribute. I have an internal JIRA for Red Hat people but I guess it's a different one you need :-) |
https://jira.mariadb.org is the place to keep all features and bug reports. |
|
gkodinov
changed the title
Well, in design IMHO there's one or many. But that's just me. Anyway, I said my peace. But to do a best-effort preliminary review. So I am not here to debate the choices. All I asked is to document these decisions intо the design (jira). |
3 participants
MariaDB currently supports only a single SSL certificate, configured via
--ssl-certand--ssl-key.Services like httpd, nginx and haproxy can serve both RSA and ECDSA certificates simultaneously, selecting the appropriate one based on the cipher suite negotiated with the client.
This adds
--ssl-alt-certand--ssl-alt-keyoptions that load a second certificate/key pair into the same SSL_CTX. OpenSSL natively supports one certificate per key type (RSA, ECDSA, EdDSA) and automatically selects the matching certificate during the TLS handshake.Example configuration: