Runtime: SSLStream should support taking a pre-validated immutable full certificate chain

[davidfowl]

In server scenarios on Linux it's important to support scenarios where the full certificate chain is provided outside of the certificate store (like a PEM file with the full chain). SSlStream should support this so that Kestrel can provide an API for providing the full certificate chain.

As an example, using Lets Encrypt with certbot generates both the SSL cert and a full chain cert. The latter is usually fed into Apache/nginx/haproxy (servers) which avoids the need for any need to retrieve the full chain on demand.

It also works well in container scenarios where the disk cache becomes ephemeral.

See https://github.com/dotnet/aspnetcore/issues/21183 for the latest issue on an example where it was problematic.

[msftbot[bot]]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[msftbot[bot]]

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[davidfowl]

This fits in with https://github.com/dotnet/runtime/issues/31944

[iamcarbon]

We've done our own ACME implementation for a reverse proxy and were also given a lot of grief figuring out how to include the full chain. We finally figured it out but also ran into issues loading 5K+ certificates from memory and moved our front proxy to Caddy.

We'd love to see time invested in making the certificate selection async and ability to load 50K+ certificates with chains into memory (either at startup or lazily during certificate selection).

[mholt]

@iamcarbon I'd like to know more about your deployment. Can I ask details? :smiley: (So as not to derail this issue, could I email you? Or vice-versa?)

[wfurt]

Should SslStreamCertificateContext.Create throw if we cannot construct full chain or guarantie operation (on Windows)?
Or should we proceed as best-effort and possibly send incomplete chain and let client deal with it?
First option seems invasive but it would make issues more visible.
(In either case I will add tracing)

[vcsjones]

throw if we cannot construct full chain or guarantie operation

My two cents: no. Clients can still potentially build a valid chain by performing their own AIA fetching, perhaps to a place where a server cannot fetch from. As I have expressed concern before, there is no “singular chain”. A client may end up building a different path, anyway.

Agree tracing is a useful though.

[bartonjs]

As @vcsjones said, even if we're sending a sensible-looking chain there's no guarantee that the other side agrees it's sensible looking... and just because we send something partial doesn't mean it wasn't complete-enough for the remote, so throwing seems bad.

And, like everyone else, I think tracing seems valuable.

[karelz]

Fixed by #39818