QuicListener Not Including Intermediary Certificates Without Explicit ServerCertificateContext

[pepone]

When using a certificate that contains an intermediary present in the system store, a Quic server doesn't include the intermediary in the TLS handshake.

You have to manually set ServerCertificateContext in the SslServerAuthenticationOptions pass to the QuicListener.

With SslStream if the intermediary is present in the system store, it is also send without need to explicitly set ServerCertificateContext.

That is with Ubuntu 22.04, dotnet 8.0.3

Is this expected? It would be better if they work the same way as they are configured using the same SslServerAuthenticationOptions.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[rzikm]

I think it's because we don't explicitly pass the intermediates to MsQuic

runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Internal/MsQuicConfiguration.cs

Lines 97 to 110 in e12e2fa

	// the order of checking here matches the order of checking in SslStream
	if (authenticationOptions.ServerCertificateSelectionCallback is not null)
	{
	certificate = authenticationOptions.ServerCertificateSelectionCallback.Invoke(authenticationOptions, targetHost);
	}
	else if (authenticationOptions.ServerCertificateContext is not null)
	{
	certificate = authenticationOptions.ServerCertificateContext.TargetCertificate;
	intermediates = authenticationOptions.ServerCertificateContext.IntermediateCertificates;
	}
	else if (authenticationOptions.ServerCertificate is not null)
	{
	certificate = authenticationOptions.ServerCertificate;
	}

In SslStream, we build the SslStreamCertificateContext under the covers so we manage to find the intermediates, we should do that in Quic as well.

Note that using SslStreamCertificateContext is the recommended way to pass certificates in .NET 8+ because it avoids the need to build the X509 chain for each connection separately for the same certificate.