.NET 6 preview 6.0.100-rc.1.21416.1 DevCerts Requiring Escalated Privileges With Every New WebApp

Running the SDK version 6.0.100-rc.1.21416.1 I notice that each ASP.NET Core application requires administrative escalation privileges.

I’ve run the following commands to try and fix it, but it continues even after wards.

> dotnet dev-certs https --clean
> dotnet dev-certs https
> dotnet dev-certs https --trust

When I Deny the request to escalate permissions, I get these warnings.

warn: Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer[5]
      The ASP.NET Core developer certificate is in an invalid state. To fix this issue, run the following commands 'dotnet dev-certs https --clean' and 'dotnet dev-certs https' to remove all existing ASP.NET Core development certificates and create a new untrusted developer certificate. On macOS or Windows, use 'dotnet dev-certs https --trust' to trust the new certificate.
fail: Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer[4]
      The ASP.NET Core developer certificate is in an invalid state. To fix this issue, run the following commands 'dotnet dev-certs https --clean' and 'dotnet dev-certs https' to remove all existing ASP.NET Core development certificates and create a new untrusted developer certificate. On macOS or Windows, use 'dotnet dev-certs https --trust' to trust the new certificate.

The instructions are the same as what I’ve attempted previously.

Workaround

If I give the application access to the certs then it works, but I have to do this for every new web application.

[richlander]

I believe that nightly builds DO NOT go through any of our signing process (notarization or otherwise). That’s probably it. This is a problem for me as well. We could consider signing nightly builds with a .NET Foundation (as opposed to MS) cert if this becomes a challenge. We may arrive at that point.

Microsoft policy requires us is to sign release/supported builds only. It is super easy for non-release builds to be used in scenarios where they should not and be used in ways they should not. MS signing certs are trusted on Windows, which is meaningful.

[richlander]

You are right that the code would be trusted. The key thing we want to avoid is someone seeing “Microsoft Corporation” in a UAC prompt and making a choice based on the publisher. If we were to sign nightly builds, we’d want the UAC prompt to make clear that the code shouldn’t be trusted.

Also, we could decide not to sign everything but do the minimum to provide better notarization UX on macOS.