aspnetcore icon indicating copy to clipboard operation
aspnetcore copied to clipboard
verified publisher icon dotnet

Blazor WebAssembly DevServer fails to use development HTTPS certificate after NuGet package upgrade

Open LongJohnBlackbeard opened this issue 3 weeks ago • 5 comments

Is there an existing issue for this?

  • [x] I have searched the existing issues

Describe the bug

After upgrading NuGet packages (including Microsoft.AspNetCore.Components.WebAssembly.DevServer) in a Blazor WebAssembly app targeting net10.0 (from 8), the WebAssembly dev server fails to configure the HTTPS endpoint, even though:

  • ASPNETCORE_ENVIRONMENT=Development

  • dotnet dev-certs https --check reports a valid, trusted HTTPS development certificate

  • The same project worked before updating NuGet packages on the same machine

  • Other ASP.NET Core apps on the same machine can use HTTPS with the development certificate (.net 8)

The only ways to make the dev server start over HTTPS are:

  • Run HTTP-only, or

  • Explicitly configure a Kestrel certificate via ASPNETCORE_Kestrel__Certificates__Default__Path and Password (bypassing the “default developer certificate” logic).

Expected Behavior

In ASPNETCORE_ENVIRONMENT=Development, if a valid HTTPS development certificate exists and is trusted, the Blazor WebAssembly dev server should automatically use it to configure the HTTPS endpoint.

This is what happens before the NuGet package upgrade.

Steps To Reproduce

  1. Create a new Blazor WebAssembly app (no hosting .NET 8):
dotnet new blazorwasm -n DevCertRepro

Or create new project through UI.

  1. Open the generated .csproj and change:
<TargetFramework>net8.0</TargetFramework>

to:

<TargetFramework>net10.0</TargetFramework>

  1. Do not update any NuGet packages yet.

  2. Ensure a dev cert exists:

dotnet dev-certs https --clean
dotnet dev-certs https --trust
dotnet dev-certs https --check

Output: valid CN=localhost dev cert (IsHttpsDevelopmentCertificate: true).

  1. Run the project with the default Development profile:
dotnet run --project DevCertRepro/DevCertRepro.csproj --launch-profile Development

✅ Result: dev server starts, HTTPS endpoint is configured correctly, app runs on https://localhost:.

  1. Now update NuGet packages (either via IDE or CLI). For example:
dotnet list DevCertRepro/DevCertRepro.csproj package --outdated
# Then update, either with `dotnet add package` or "Update all" in the IDE

Before upgrade, Microsoft.AspNetCore.Components.WebAssembly.DevServer version was:

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="8.0.15" PrivateAssets="all"/>

After upgrade, it becomes:

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="10.0.1" PrivateAssets="all" />
  1. Run again with the same command:
dotnet run --project DevCertRepro/DevCertRepro.csproj --launch-profile Development

Exceptions (if any)

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.
   at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.UseHttps(ListenOptions listenOptions, Action`1 configureOptions)
   at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.UseHttps(ListenOptions listenOptions)
   at Microsoft.AspNetCore.Server.Kestrel.Core.HttpsConfigurationService.UseHttpsWithDefaultsWorker(ListenOptions listenOptions)
   at Microsoft.AspNetCore.Server.Kestrel.Core.HttpsConfigurationService.UseHttpsWithDefaults(ListenOptions listenOptions)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken)
   at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__14_1(IHostedService service, CancellationToken token)
   at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation)
   at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>g__LogAndRethrow|14_3(<>c__DisplayClass14_0&)
   at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
   at Microsoft.AspNetCore.Components.WebAssembly.DevServer.Program.Main(String[] args)

.NET Version

10.0.100

Anything else?

OS: Windows 11 x64 .NET SDK: 10.0.100 Project type: Blazor WebAssembly (hosted: false) Dev server: Microsoft.AspNetCore.Components.WebAssembly.DevServer

Workarounds

  1. Explicit Kestrel certificate configuration

Adding the following environment variables to the launch profile makes the dev server start successfully with HTTPS:

"ASPNETCORE_Kestrel__Certificates__Default__Path": "C:\\Users\\<user>\\.aspnet\\https\\blazor-dev.pfx",
"ASPNETCORE_Kestrel__Certificates__Default__Password": "<password>"

where blazor-dev.pfx is exported via:

dotnet dev-certs https -ep %USERPROFILE%\.aspnet\https\blazor-dev.pfx -p <password>
dotnet dev-certs https --trust

This bypasses the “default developer certificate” lookup and works reliably.

I have done this process for two different apps/solutions where upgrading to .NET 10 from 8 breaks local https server.

LongJohnBlackbeard avatar Dec 11 '25 00:12 LongJohnBlackbeard

Cheers LongJohnBlackbeard for the workaround!

Hitting this as well, was working few days ago with 10.0,0 breaks moving to 10.0.1. In the default Blazor WebAssembly template if you create a project it runs in 10.0.0 but not 10.0.1.

Zelif avatar Dec 11 '25 05:12 Zelif

Cheers

Can confirm, rolling back the devserver nuget package to 10.0.0 fixes this

LongJohnBlackbeard avatar Dec 11 '25 14:12 LongJohnBlackbeard

Can confirm, rolling back the devserver nuget package to 10.0.0 fixes this

@dotnet/aspnet-blazor-eng could you take a first pass at this? Not sure if a networking issue or Blazor.

BrennanConroy avatar Dec 11 '25 17:12 BrennanConroy

@LongJohnBlackbeard would re-creating fresh cert before step 7 fix it ?

dotnet dev-certs https --clean
dotnet dev-certs https --trust
dotnet dev-certs https --check

pavelsavara avatar Dec 11 '25 17:12 pavelsavara

@pavelsavara

Yes, I have ran those in my testing and replication process. I'll update my original post accordingly.

LongJohnBlackbeard avatar Dec 11 '25 18:12 LongJohnBlackbeard

I'm experiencing the same issue. Generating local certificates and trusting them is a tricky situation when working as a team...

victorioustr avatar Dec 12 '25 08:12 victorioustr

Can confirm, rolling back the devserver nuget package to 10.0.0 fixes this

@dotnet/aspnet-blazor-eng could you take a first pass at this? Not sure if a networking issue or Blazor.

We haven't changed anything in 10.0 in this area and the fact that it works in 10.0 and regressed in 10.1 likely points at something else causing this.

The underlying issue is likely Kestrel not picking up the default dev cert for some reason.

@DamianEdwards has anything happened in this area recently?

javiercn avatar Dec 12 '25 12:12 javiercn

Can confirm, rolling back the devserver nuget package to 10.0.0 fixes this

@dotnet/aspnet-blazor-eng could you take a first pass at this? Not sure if a networking issue or Blazor.

We haven't changed anything in 10.0 in this area and the fact that it works in 10.0 and regressed in 10.1 likely points at something else causing this.

The underlying issue is likely Kestrel not picking up the default dev cert for some reason.

@DamianEdwards has anything happened in this area recently?

I did not upgrade from 10.0 to 10.1. I upgraded from 9.0 to the latest version. I am migrating all my projects from .NET 9 to .NET 10.

victorioustr avatar Dec 12 '25 13:12 victorioustr

Maybe https://github.com/dotnet/aspnetcore/pull/64268

pavelsavara avatar Dec 12 '25 13:12 pavelsavara

@javiercn I just checked it myself. There's no problem with 10.0.0. When I upgrade to 10.0.1, the trust is lost.

victorioustr avatar Dec 12 '25 13:12 victorioustr

The cert was updated in 10.0.1 and this needs to be trusted again. Run dotnet dev-certs https --trust using the 10.0.101 SDK.

DamianEdwards avatar Dec 12 '25 15:12 DamianEdwards

I tried all options, including dotnet dev-certs clean. The problem persists.

victorioustr avatar Dec 12 '25 15:12 victorioustr

I'm thinking that possibly the old version of the dev-certs is used on your box.

On my machine I have d:\.dotnet\sdk\10.0.101\DotnetTools\dotnet-dev-certs\10.0.1-servicing.25569.105\tools\net10.0\any\, but I don't have 10.0.0 SDK installed.

What does your dotnet --info say ?

pavelsavara avatar Dec 12 '25 16:12 pavelsavara

@pavelsavara

➜ dotnet --info
.NET SDK:
 Version:           10.0.100
 Commit:            b0f34d51fc
 Workload version:  10.0.100-manifests.5fb86115
 MSBuild version:   18.0.2+b0f34d51f

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100\

.NET workloads installed:
 [maui-windows]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    10.0.0/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maui\10.0.0\WorkloadManifest.json
   Install Type:              Msi

 [maccatalyst]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    26.1.10494/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maccatalyst\26.1.10494\WorkloadManifest.json
   Install Type:              Msi

 [ios]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    26.1.10494/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.ios\26.1.10494\WorkloadManifest.json
   Install Type:              Msi

 [android]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    36.1.2/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.android\36.1.2\WorkloadManifest.json
   Install Type:              Msi

 [wasm-tools-net6]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    10.0.100/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net6\10.0.100\WorkloadManifest.json
   Install Type:              Msi

 [wasm-tools-net7]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    10.0.100/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net7\10.0.100\WorkloadManifest.json
   Install Type:              Msi

 [wasm-tools-net8]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    10.0.100/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net8\10.0.100\WorkloadManifest.json
   Install Type:              Msi

 [wasm-tools-net9]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    10.0.100/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net9\10.0.100\WorkloadManifest.json
   Install Type:              Msi

 [wasm-tools]
   Installation Source: VS 18.0.11222.15
   Manifest Version:    10.0.100/10.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.current\10.0.100\WorkloadManifest.json
   Install Type:              Msi

Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
  Version:      10.0.0
  Architecture: x64
  Commit:       b0f34d51fc

.NET SDKs installed:
  8.0.412 [C:\Program Files\dotnet\sdk]
  9.0.303 [C:\Program Files\dotnet\sdk]
  9.0.308 [C:\Program Files\dotnet\sdk]
  10.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  DOTNET_CLI_UI_LANGUAGE                   [en-US]
  DOTNET_GCHeapCount                       [2]
  DOTNET_GCNoAffinitize                    [1]
  DOTNET_MULTILEVEL_LOOKUP                 [0]
  DOTNET_STARTUP_HOOKS                     []
  DOTNET_TC_CallCountThreshold             [1000]
  DOTNET_ThreadPool_UnfairSemaphoreSpinLimit [0]
  DOTNET_gcConcurrent                      [0]
  Detected COMPlus_* environment variable(s). Consider transitioning to DOTNET_* equivalent.

global.json file:
  C:\Users\---\RiderProjects\---\---\global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

I see that path to dev-certs has 10.0.0 C:\Program Files\dotnet\sdk\10.0.100\DotnetTools\dotnet-dev-certs\10.0.0-rtm.25523.111\tools\net10.0\any

Is this the issue? Why would it not be updated to 10.0.100 when installiing the 10.0.100 SDK?

LongJohnBlackbeard avatar Dec 12 '25 16:12 LongJohnBlackbeard

@pavelsavara So I went a grabbed the 10.0.101 sdk and installed that so there is now 10.0.100 and 10.0.101 installed on my machine. In the 10.0.100 SDK it is showing dev-certs 10.0.0-rtm (dev-certs version 10.0.0). In the 10.0.101 SDK it is showing dev-certs 10.0.1-rtm: C:\Program Files\dotnet\sdk\10.0.100\DotnetTools\dotnet-dev-certs\10.0.0-rtm.25523.111\tools\net10.0\any C:\Program Files\dotnet\sdk\10.0.101\DotnetTools\dotnet-dev-certs\10.0.1-servicing.25569.105\tools\net10.0\any

After updating the sdk to 10.0.101 and doing changing the dev-cert package back to 10.0.1, i was able to start it with out the error showing up.

My question though is, why does the 10.0.100 SDK not ship with dev-cert 10.0.1?

LongJohnBlackbeard avatar Dec 12 '25 17:12 LongJohnBlackbeard

I guess that dev-cert dependency one of the things that 10.0.101 fixes over 10.0.100 And that 10.0.101 would arrive with next VS patch 18.1.0.

https://dotnet.microsoft.com/en-us/download/dotnet/10.0

pavelsavara avatar Dec 12 '25 17:12 pavelsavara

Yes. After updating the dotnet SDK to 10.0.101 and trusting devcert, it worked without any issues. Thank you.

victorioustr avatar Dec 14 '25 10:12 victorioustr

Yes. After updating the dotnet SDK to 10.0.101 and trusting devcert, it worked without any issues. Thank you.

Does not work for me even doing all new with clean, trust.

Had to use 'Explicit Kestrel certificate configuration workaround' to get it to work. Seems like a major bug to me for an update.

b-straub avatar Dec 15 '25 11:12 b-straub

@pavelsavara So I went a grabbed the 10.0.101 sdk and installed that so there is now 10.0.100 and 10.0.101 installed on my machine. In the 10.0.100 SDK it is showing dev-certs 10.0.0-rtm (dev-certs version 10.0.0). In the 10.0.101 SDK it is showing dev-certs 10.0.1-rtm: C:\Program Files\dotnet\sdk\10.0.100\DotnetTools\dotnet-dev-certs\10.0.0-rtm.25523.111\tools\net10.0\any C:\Program Files\dotnet\sdk\10.0.101\DotnetTools\dotnet-dev-certs\10.0.1-servicing.25569.105\tools\net10.0\any

After updating the sdk to 10.0.101 and doing changing the dev-cert package back to 10.0.1, i was able to start it with out the error showing up.

My question though is, why does the 10.0.100 SDK not ship with dev-cert 10.0.1?

LongJohnBlackbeard avatar Dec 15 '25 14:12 LongJohnBlackbeard