Support certificate aliasing in kestrel config

[Tratcher]

Today kestrel's config supports a top level Certificates list as well as a certificate per endpoint.
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#listenoptionsusehttps

{
  "Kestrel": {
    "Certificates": {
      "Default": {
        "Path": "<path to .pfx file>",
        "Password": "<certificate password>"
      }
    },
    "Endpoints": {
      "HttpsInlineCertFile": {
        "Url": "https://localhost:5001",
        "Certificate": {
          "Path": "<path to .pfx file>",
          "Password": "<certificate password>"
        }
      },
      "HttpsInlineCertStore": {
        "Url": "https://localhost:5002",
        "Certificate": {
          "Subject": "<subject; required>",
          "Store": "<certificate store; required>",
          "Location": "<location; defaults to CurrentUser>",
          "AllowInvalid": "<true or false; defaults to false>"
        }
      },
      "HttpsDefaultCert": {
        "Url": "https://localhost:5003"
      }
    }
  }
}

However, the Certificates list only supports two values, Default and Development.

aspnetcore/src/Servers/Kestrel/Core/src/KestrelConfigurationLoader.cs

Line 351 in f28ef7c

if (configReader.Certificates.TryGetValue("Default", out var defaultCertConfig))

aspnetcore/src/Servers/Kestrel/Core/src/KestrelConfigurationLoader.cs

Line 378 in f28ef7c

if (configReader.Certificates.TryGetValue("Development", out var certificateConfig) &&

#15144 adds support for multiple certs per endpoint via SNI, but doesn't change anything about the top level Certificates collection.

Problem: If a server has multiple endpoints with the same cert, or multiple SNI entries with the same cert, it needs to duplicate that cert in the config for each endpoint or SNI section.

Proposal: Allow the endpoint certificate section (and the new endpoint SNI certificate sections) to reference a cert in the top level Certificates collection by name.

{
  "Kestrel": {
    "Certificates": {
      "Default": {
        "Path": "<path to .pfx file>",
        "Password": "<certificate password>"
      },
      "StoreCert": {
        "Subject": "<subject; required>",
        "Store": "<certificate store; required>",
        "Location": "<location; defaults to CurrentUser>",
        "AllowInvalid": "<true or false; defaults to false>"
      },
      "FileCert": {
        "Path": "<path to .pfx file>",
        "Password": "<certificate password>"
      }
    },
    "Endpoints": {
      "HttpsCertFile": {
        "Url": "https://localhost:5001",
        "Certificate": {
          "Name": "FileCert"
        }
      },
      "HttpsCertStore": {
        "Url": "https://localhost:5002",
        "Certificate": {
          "Name": "StoreCert"
        }
      },
      "HttpsDefaultCert": {
        "Url": "https://localhost:5003"
      }
    }
  }
}

aspnetcore/src/Servers/Kestrel/Core/src/Internal/ConfigurationReader.cs

Lines 213 to 242 in f28ef7c

	internal class CertificateConfig
	{
	public CertificateConfig(IConfigurationSection configSection)
	{
	ConfigSection = configSection;
	ConfigSection.Bind(this);
	}
	public IConfigurationSection ConfigSection { get; }
	// File
	public bool IsFileCert => !string.IsNullOrEmpty(Path);
	public string Path { get; set; }
	public string KeyPath { get; set; }
	public string Password { get; set; }
	// Cert store
	public bool IsStoreCert => !string.IsNullOrEmpty(Subject);
	public string Subject { get; set; }
	public string Store { get; set; }
	public string Location { get; set; }
	public bool? AllowInvalid { get; set; }

@halter73

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.