Add support for SslStreamCertificateContext in SslOption #1864
Description
Currently, the user can specify a client certificate via RabbitMQ's SslOption when mTLS is desired. However, there is no way to explicitly specify the certificate chain along with the client certificate. This means the intermediates must already be known to the server, or must be discoverable through the certificate store or similar, or else the TLS handshake will fail. Note that it cannot generally be assumed that the server is aware of intermediates. It is usually the client that receives the intermediates from the PKI when the client certificate is issued and it is expected/good practice for the client to send them to the server during the TLS handshake.
Today, RabbitMQ .NET client's SslHelper creates SslClientAuthenticationOptions and copies the ClientCertificates from the SslOption:
var o = new SslClientAuthenticationOptions
{
CertificateRevocationCheckMode = certificateRevocationCheckMode,
ClientCertificates = opts.Certs,
EnabledSslProtocols = opts.Version,
TargetHost = opts.ServerName,
};
The ClientCertificates can only contain leaf certificates, not the chain. Starting with .NET 8+, it is possible to also supply the chain explicitly using the ClientCertificateContext property on SslClientAuthenticationOptions. RabbitMQ client libraries should support it as well.
Problem:
When providing certificates programmatically, there is currently no way to also provide the intermediate chain explicitly. If intermediates are missing, .NET will try to resolve them by searching the local certificate stores or by fetching them via AIA from the internet. Not all scenarios can assume that this is possible (e.g. no internet connectivity, no prior installation of app-specific intermediates in the certificate store).
Describe the solution you'd like
Extend RabbitMQ SslOption with a ClientCertificateContext that gets mapped to SslClientAuthenticationOptions.ClientCertificateContext or a configuration callback to allow a custom configuration of SslClientAuthenticationOptions.
Describe alternatives you've considered
No response
Additional context
A workaround that exists today is to programmatically add intermediates CAs to the intermediate store prior to using RabbitMQ client libraries. However, this "pollutes" the system's intermediate store.