Enablement of certificate_authorities TLS extension via openssl.cnf not working

[martinschmatz]

Intro
OpenSSL has support to add certificate_authorities as TLS extension in TLS ClientHello. See here (and here). This is relevant for a client to have a means to indicate to the server which CAs it would support.

Issue
However, when adding requestCAFile = <path/to/ca-cert-file-selection/pem-format> to openssl.cnf in the relevant ssl_conf sesction (see below), no such extension is sent in the ClientHello. This can easily be verified by monitoring a the content of the ClientHello with e.g. WireShark.

The reason is believed to be caused by this line which seemingly is not parsed as intended during an OpenSSL context configuration.

Remediation
When inserting a single line with SSL_CONF_CMD_STRING(RequestCAFile, "requestcafile", 0), right below this line, the certificate_authorities extension is created in the ClientHello as expected, obviously only when also adding a requestCAFile = <path/to/ca-cert-file> line to openssl.cnf (IOW, it is not created when no such line is in openssl.cnf).

It is further suggested to check for client or server mode flags here. Not 100% sure whether this is required or has a benefit.

Additional info
Remediation checked with OpenSSL v3.3.0 (commit 4cb3112), via s_client and cURL as client applications.
For completeness, example excerpt of `openssl.cnf':

ssl_conf = ssl_module

[ ssl_module ]
system_default = tls_system_default

[ tls_system_default ]
TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProtocol = DTLSv1.2
DTLS.MaxProtocol = DTLSv1.2
Groups = secp521r1:secp384r1:X25519:prime256v1:X448
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256
CipherString = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
requestCAFile = /etc/pki/tls/certs/ca-bundle.crt

[t8m]

When the system default configuration support for SSL_CTX was added it was determined that the SSL_CONF_FLAG_CERTIFICATE options are not to be applied from the system_default configuration as applying certificate configuration options globally is something unintended and potentially breaking.

They will be applied only if non-default configuration is being applied to a SSL_CTX.

We should document it better though.

[martinschmatz]

I would argue that adding certificate_authorities to a ClientHello has nothing to do with certificate configuration options. From my perspective, it's in the same class as specifying Sigalgs, Groups, or Ciphers via the `openssl.cnf' file.

[t8m]

No, IMO it is something that is closely related to individual application settings. There could be different acceptable CAs for an application connecting to some private internal server and different for public internet web access.

The intent for the system_default configuration is for system-wide policy settings such as minimal protocol versions, minimal security level, etc.

[martinschmatz]

I understand your point.

My motivation was two-fold (sequence is [strong] priority):

1. Enable the likes of cURL without the need to change application code, where per request control can readily be achieved by using $ENV::currentValue in openssl.cnf. Absence of the ENV variable automatically results in not generating/sending the extension, at which point it "hurts" nobody else.
2. Have a means to simplify experiments with "fake" root certs added to the certificate_authorities extension. The term "fake" in this context means "pack information about trust stores" in the certificate_authorities extension by using carefully tailor made values for CN etc. This to find out whether a new extension trust_expressions is really required in the context of this discussion.

Given the former, I still think enabling control over the certificate_authorities extension via openssl.cnf makes sense.
For the latter, I have my own build which I can use. And others can see above how to enable the feature.

Somewhat related to this (don't know whether I should start a fresh issue): The client can at least indicate to the server which root cert type it would support via the signature_algorithms and signature_algorithms_cert extensions.
The TLSv1.3 standard (RFC8446 in section 4.2.3) states that

If no "signature_algorithms_cert" extension is present, 
then the "signature_algorithms" extension also applies 
to signatures appearing in certificates.

Given that generating signature_algorithms_cert extension is not supported, I made an experiment specifying exactly one entry in the signature_algorithms extension, but had to notice that the cert-chain - which had certs with different algs - was successfully verified. This seems to indicate deviation from the standard ?!?
Specifically, I used the OQS provider, specified dilithium5 as the one-and-only signature algorithm, and issued a cURL request against https://test.openquantumsafe.org:6156/. Result: Verification succeeded against the OQS interop server root cert (RSA4k).
Same successful verification when limiting to ECDSA sigalgs against an RSA root cert.