Fix: Inconsistent certificate chain handling between endpoint and default configuration

[jnjudge1]

Fix: Inconsistent certificate chain handling between endpoint and default configuration

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Changes Kestrel configuration to process default certificate loading configurations the same as per endpoint configurations. With this change, certificates specified in the default configuration section will have their chains presented on the server even if their intermediates are not present in the system certificate store.

Description

IHttpsConfigurationService.cs:

• Changed to add the CertificateChain property onto the internal CertificateAndConfig struct, necessary for passing cert chain from TlsConfigurationLoader to KestrelConfigurationLoader.

TlsConfigurationLoader.cs:

• Changed to use the certificate chain from the loaded default certificate to return a CertificateAndConfig object with the chain specified if the chain is not null.

KestrelConfigurationLoader.cs:

• Changed to add an internal DefaultCertificateChain property for specifying the default certificate chain to load on endpoints in KestrelServerOptions.ApplyDefaultCertificate.

KestrelServerOptions.cs:

• Changed to get the default certificate chain specified in KestrelConfigurationLoader and set the ServerCertificateChain property on the httpsOptions for an endpoint.

Fixes #60709

[jnjudge1]

@jnjudge1 please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@dotnet-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@dotnet-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@dotnet-policy-service agree company="Microsoft"

Contributor License Agreement

@dotnet-policy-service agree

[martincostello]

FYI changing something like certificate handling this is almost certainly going to need tests to get accepted, particularly as it's a bug fix.

[jnjudge1]

FYI changing something like certificate handling this is almost certainly going to need tests to get accepted, particularly as it's a bug fix.

Thanks for your feedback @martincostello ! I've added a test that fails on main but succeeds with this change.

[BrennanConroy]

Nice find and appreciate the fix as well! Comments are just code cleanup nits.

It looks like it was probably an oversight when the cert chain work was done, don't see any reference as to why we ignored the chain which makes me think it was meant to be temporary and then forgotten about.

[jnjudge1]

Nice find and appreciate the fix as well! Comments are just code cleanup nits.

It looks like it was probably an oversight when the cert chain work was done, don't see any reference as to why we ignored the chain which makes me think it was meant to be temporary and then forgotten about.

Thanks @BrennanConroy ! That makes sense, happy to help here. I've gone back and resolved those nits, if all looks good please merge when possible. Thank you!

[adityamandaleeka]

Great work @jnjudge1!