ASP.NET Core: 'Unable to configure HTTPS endpoint. No server certificate was specified'

Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date. means Kestrel was told to listen on HTTPS and had no certificate to do it with. On a development machine, create the developer certificate with dotnet dev-certs https and start the app again.

On Windows and macOS also run dotnet dev-certs https --trust so the browser accepts it. In a container or on a server, do not rely on the developer certificate: give Kestrel a real certificate, or listen on plain HTTP behind a proxy that handles TLS.

The error

fail: Microsoft.Extensions.Hosting.Internal.Host[11]
      Hosting failed to start
      System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date.
      To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'.
      For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

Why it happens

When an ASP.NET Core app binds an https:// address and no certificate is configured for it, Kestrel falls back to the ASP.NET Core developer certificate, a self-signed certificate stored in the current user's certificate store. If that certificate does not exist, or has expired, there is nothing to fall back to and the host stops before it serves a single request.

On a desktop where you have worked with ASP.NET Core before, the certificate usually exists already, so the error tends to appear somewhere fresh: a new container, a CI agent, a new user account, or a server where someone set ASPNETCORE_URLS or --urls to an HTTPS address. In the test below it appeared in a clean mcr.microsoft.com/dotnet/sdk:10.0 container, which has no developer certificate.

The fix

+ dotnet dev-certs https
The HTTPS developer certificate was generated successfully.
+ timeout 40 dotnet run --urls https://+:15490
warn: Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer[8]
      The ASP.NET Core developer certificate is not trusted. For information about trusting the ASP.NET Core developer certificate, see https://aka.ms/aspnet/https-trust-dev-cert
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://[::]:15490

After the certificate was generated, the same command started the app on HTTPS (timeout 40 only stopped it after 40 seconds). The warning about trust is expected on Linux: the error text itself says trusting works on Windows and macOS only. For anything that is not your own development machine, configure a real certificate instead, for example through ASPNETCORE_Kestrel__Certificates__Default__Path and ASPNETCORE_Kestrel__Certificates__Default__Password, or keep the app on HTTP and let nginx or a load balancer terminate TLS. Removing the HTTPS address from the URLs also makes the error go away, which is the right answer when HTTPS was never needed there.

How it was reproduced

In the cached mcr.microsoft.com/dotnet/sdk:10.0 image (SDK 10.0.302 inside) on Windows 11 with Docker 29.8.2: dotnet new web -n FixWeb (ASP.NET Core Empty, net10.0), then dotnet run --urls https://+:15490, which failed with the exception above. In the same container session, dotnet dev-certs https and the same run command brought the app up. The container name fix4-https is the test's own and it was removed on exit; the host's certificate was not touched.

Frequently asked

How do I fix Unable to configure HTTPS endpoint in ASP.NET Core?

On a development machine run dotnet dev-certs https, and on Windows or macOS dotnet dev-certs https --trust, then start the app again. On a server or in a container configure a real certificate or serve HTTP behind a TLS proxy.

Why does my ASP.NET Core app fail with HTTPS in Docker?

A fresh container has no developer certificate, so an https URL has no certificate to use. Mount a real certificate and point Kestrel at it, or listen on HTTP inside the container and terminate TLS outside it.

Can I trust the dev certificate on Linux with dotnet dev-certs?

The error message says the --trust option is for Windows and macOS only. On Linux the certificate is generated and the app runs, but Kestrel logs a warning that the certificate is not trusted.

If the HTTPS address is fine but the port is taken, see Failed to bind to address: address already in use. More decoded errors are in the Fixes category.