Change Kestrel's HTTPS endpoint defaults to improve developer experience

[DamianEdwards]

Related to [EPIC] Revisiting HTTPS defaults in ASP.NET Core

Background

Today, when Kestrel is starting, if no endpoint configuration is provided, e.g. via the ASPNETCORE_URLS env (docs), then Kestrel will fallback to a set of default endpoint configuration. These defaults are "http://localhost:5000" and "https://localhost:5001".

In the case of the default HTTPS binding (https://localhost:5001) Kestrel will eagerly bind using the ASP.NET Core HTTPS developer certificate if it's found in the default personal certificate store. This occurs without regard to the configured environment and can lead to experience issues on developer machines when the certificate has not yet been trusted (i.e. trusted as root cert authority because it's self-signed). Clients often produce poor UX when hitting an HTTPS endpoint with an untrusted certificate, e.g. silent failure, scary error/warning screen, etc.

Example flow that can lead to experience issues:

1. Create a new web project: MyApp$ dotnet new webapp
2. Build the project: MyApp$ dotnet build
3. Execute the produced app executable: MyApp$ ./bin/Debug/net7.0/MyApp
4. In another prompt issue a curl request to the http endpoint: $ curl http://localhost:5000
5. Result is an empty response as curl does not follow redirects by default and the default template is setup to redirect from HTTP to HTTPS

Changes

• Change Kestrel to no longer bind to https://localhost:5001 as a default endpoint
• Log a warning when Kestrel does bind to a localhost HTTPS address (due to configured URLs, e.g. via the launchSettings.json in the project templates) and the developer certificate is used, and the developer certificate is not trusted as a root authority
• Update relevant docs (example)

These changes will not impact the experience when using dev inner-loop focused launch tools like VS or dotnet run as they utilize the URLs configuration in the launchSettings.json file.

It's likely this behavior change could break some of our tests that assume the app will be launched at https://localhost:5001 and emit a message to console out, e.g. example.

@davidfowl @Tratcher @javiercn