[Feature]: wolfSSL doesn't support multiple certificates in the same server SSL_CTX

[gkodinov]

Contact Details

joro@mariadb.org

Version

v5.9.1-stable

Description

MariaDB/server#5178 (comment)

We are trying to implement multiple simultaneously active certificate/key pairs with different key types support for the server that are selected by the client negotiation outcome.

In the process of prototyping that we've detected that there's no WolfSSL support for the scenario, whereas it works well with OpenSSL.

Please find details about the project and what is missing to make it run against wolfSSL in the link above. Copying it here for completeness:

• SSL_CTX_set_current_cert() — does not exist in WolfSSL. Needed for cert type enumeration (Ssl_server_cert_types). Guarded with #ifndef HAVE_WOLFSSL, falls back to reporting only the primary cert type.

• Multiple SSL_CTX_use_certificate_chain_file() calls — WolfSSL does have this function, but does not support multiple key types per SSL_CTX (one slot per context, not per key type like OpenSSL 1.0.2+). Loading a second cert replaces the first rather than adding alongside it.

Reproduction steps

Fetch the above PR and try to remove the #ifdef WOLFSSL added.

Relevant log output

[embhorn]

Hello @gkodinov

Thanks for contacting wolfSSL Support. I've requested a review of this issue by our engineers. How urgent is this feature for your project?

Kind regards,

[gkodinov]

it's not urgent. I'd rather you take your time and look properly into this.

[LinuxJedi]

Hi @gkodinov,

Thanks for the detailed write-up and the link to the MariaDB PR.

You're correct on both counts. Today a WOLFSSL_CTX holds a single certificate/key slot, so a second wolfSSL_CTX_use_certificate_chain_file() call replaces the first rather than adding a second slot keyed by algorithm, and SSL_CTX_set_current_cert() is not part of our OpenSSL compatibility layer. So the OpenSSL 1.0.2+ "load one cert per key type and auto-select during the handshake" model isn't supported natively at the SSL_CTX level yet.

The good news is that the underlying capability, serving both an RSA and an ECDSA cert from one server and selecting based on the client's negotiation, is achievable today using our certificate setup callback, SSL_CTX_set_cert_cb() (wolfSSL_CTX_set_cert_cb). It's invoked after the ClientHello is parsed but before cipher-suite selection, and we provide helpers (wolfSSL_get_client_suites_sigalgs, wolfSSL_get_ciphersuite_info, wolfSSL_get_sigalg_info) to inspect what the client offered. Inside the callback you install the matching cert/key onto the connection with wolfSSL_use_certificate_chain_file() / wolfSSL_use_PrivateKey_file() (chain file pulls in intermediates, same as the OpenSSL chain loader). This works for both TLS 1.2 and TLS 1.3, and we have a regression test covering exactly this RSA-vs-ECDSA case (test_wolfSSL_cert_cb_dyn_ciphers).

I've attached a sample callback that maps cleanly onto your --ssl-cert-add/--ssl-key-add array model. One thing to watch: the cipher suites a context advertises are derived from the cert loaded at config time, so load one pair into the CTX as a default to keep both auth types on the table for the callback to choose from.

For the Ssl_server_cert_types enumeration: since your server already knows which cert types it loaded (your own array), you can report from that directly rather than querying the context, which sidesteps the missing SSL_CTX_set_current_cert().

I hope this gets you unblocked. Please let us know if it helps.

multi_cert_cb_sample.c

[gkodinov]

Thanks, Andrew! I will keep that in mind. The example probably works, but it will also re-read and re-parse the cert on every accept it seems. So this makes it a workaround at best.
I've mostly filed this for good measure. And to establish the state of things.