SSLStream AuthenticateAsServerAsync with skipped intermediate certificates on Linux

[pg94au]

I have a question related to hosting a TLS endpoint from a .net 8 application that will run on Linux,
with respect to providing the necessary intermediate certificate chain to clients.

In the situation I am facing, I have a certificate that was obtained from Sectigo, where there is a
cross-signed certificate and thus two chains that can be built to separate trusted roots. The issue is,
it appears that either the .NET framework or OpenSSL are determining independently which chain will be
utilized.

There is a chain in which USERTrust is an intermediate:
OURS / Sectigo RSA Organization Validation Secure Server CA / USERTrust RSA Certification Authority / AAA Certificate Services (ROOT)

There is also another shorter chain in which USERTrust is a self-signed root:
OURS / Sectigo RSA Organization Validation Secure Server CA / USERTrust RSA Certification Authority (ROOT)

I'm looking to support clients that will not have the self-signed USERTrust root present, which means sending the USERTrust intermediate during connection negotiation. I've got these certificates in a PEM file and load them into an X509Certificate2Collection which is set in the SslStreamCertificateContext that is passed as ServerCertificateContext to AuthenticateAsServerAsync, but when doing so I observe that only my certificate and the Sectigo one are sent as intermediates.

This service is running in Docker and is based on an alpine-derived image which has the USERTrust root certificate. I've observed that if I disable this certificate in /etc/ca-certificates.conf when building the image, when TLS negotiation occurs, the intermediate USERTrust that I've specified in the chain in my code does get sent to the client.

I've been searching and seen some references to how SSLStream is expected to behave, and the changes that have been made to support intermediates, notably:

#37933
#35844
#17550 (comment)

It appears to me that the intermediates that I provide are not simply accepted as is and sent, but that a determination may be made that a chain can be built without all of the certificates provided which results in their exclusion. Removing the USERTrust root necessitates the inclusion of all intermediates I provide, and so only then it is included. Is this essentially what is happening, and if so, is there any other means to work around this than to do what I have done, which is to remove a root from my container image? In this case I can do that, though this might be a much less workable solution had this been running un-containerized on a server that needed that root for some other purpose.

[bartonjs]

On Linux, at least, you can force the longer path to be involved by bypassing your system trust entirely:

SslCertificateTrust trust = SslCertificateTrust.CreateForX509Collection(
    new X509Certificate2Collection() { aaaCertificateServicesRoot });

SslStreamCertificateContext certContext = SslStreamCertificateContext.Create(
    serverCert,
    collectionThatIncludesYourIntermediates,
    trust: trust);

// and then use certContext instead of serverCert when doing AuthenticateAsServer

By controlling the list of trusted roots via the optional SslCertificateTrust parameter you prevent the shorter chain from counting as trusted, and a longer trusted chain will be preferred over a shorter untrusted chain.

The same code is available to Windows, but since the OS is "more involved" in the decision of what to present on the handshake I don't know that it ends up mattering.

[Clockwork-Muse]

As a side note;
There can be reasons to burn custom roots into the image, but generally I'd mount the entire trust store (including "standard" roots) as a volume or secret into the container. For one thing, then you don't have to update your container when roots change (although generally they're going to rev less than your application).

How you do this depends on how/where you're deploying your container, but there are often helpers to make it easier at scale.

[pg94au]

Initially, I tried this change to no effect, but it turned out it was because the company I work for mandates that we base on their own internally built images, where that image was built with dotnet 8.0.4. This issue was resolved when I obtained a newer approved base image that contained 8.0.15. (This behavior is actually correct with respect to honoring an explicitly provided root store since 8.0.8.)

(Additionally, to respond to the other comment regarding injection of trusted roots at runtime, in my case right now, our designated base image already has the ca-certificates-bundle package added when it is built.)