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:
- Create a new web project:
MyApp$ dotnet new webapp
- Build the project:
MyApp$ dotnet build
- Execute the produced app executable:
MyApp$ ./bin/Debug/net7.0/MyApp
- In another prompt issue a curl request to the http endpoint:
$ curl http://localhost:5000
- 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
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
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_URLSenv (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:
MyApp$ dotnet new webappMyApp$ dotnet buildMyApp$ ./bin/Debug/net7.0/MyApp$ curl http://localhost:5000Changes
launchSettings.jsonin the project templates) and the developer certificate is used, and the developer certificate is not trusted as a root authorityThese changes will not impact the experience when using dev inner-loop focused launch tools like VS or
dotnet runas they utilize the URLs configuration in thelaunchSettings.jsonfile.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