Aspnetcore: ASP.NET Core developer certificate is in an invalid state - .NET 5 RC2 SDK - macOS - .NET Core 3.1 app

Created on 30 Sep 2020  路  2Comments  路  Source: dotnet/aspnetcore

Describe the bug

Certificate is invalid after using 'dotnet dev-certs https --trust' the certificate with .NET 5 RC2 on macOS 10.15.2.

'dotnet dev-certs https --check --verbose' does not indicate there is a problem with the certificate.

Running 'dotnet dev-certs https --clean' and 'dotnet dev-certs https --trust' fixes the problem.

To Reproduce

dotnet dev-certs --clean
Uninstall all .NET Core SDKs
Install .NET Core SDK 3.1.402
dotnet dev-certs https --trust
dotnet dev-certs https --check --verbose
A valid certificate was found.
Install .NET Core 5.1 RC2 (tried 5.0.100-rc.2.20466.4 and 5.0.100-rc.2.20479.15 - signed builds)
dotnet dev-certs https --check --verbose
No valid certificate found.
dotnet dev-certs https --trust
dotnet dev-certs https --check --verbose
Prompts to access keychain
A valid certificate was found.
mkdir testapp
cd testapp
dotnet new webapp --framework netcoreapp3.1
dotnet run
Open https://localhost:5001 in browser.
Cannot view page. Errors in macOS terminal.

fail: Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware[3]
      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.
System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
 ---> Interop+AppleCrypto+SslException: Internal error
   --- End of inner exception stack trace ---
   at System.Net.Security.SslStream.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, ExceptionDispatchInfo exception)
   at System.Net.Security.SslStream.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslStream.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslStream.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslStream.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslStream.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslStream.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslStream.ProcessAuthentication(LazyAsyncResult lazyResult, CancellationToken cancellationToken)
   at System.Net.Security.SslStream.BeginAuthenticateAsServer(SslServerAuthenticationOptions sslServerAuthenticationOptions, CancellationToken cancellationToken, AsyncCallback asyncCallback, Object asyncState)
   at System.Net.Security.SslStream.<>c.<AuthenticateAsServerAsync>b__69_0(SslServerAuthenticationOptions arg1, CancellationToken arg2, AsyncCallback callback, Object state)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncImpl[TArg1,TArg2](Func`5 beginMethod, Func`2 endFunction, Action`1 endAction, TArg1 arg1, TArg2 arg2, Object state, TaskCreationOptions creationOptions)
   at System.Threading.Tasks.TaskFactory.FromAsync[TArg1,TArg2](Func`5 beginMethod, Action`1 endMethod, TArg1 arg1, TArg2 arg2, Object state, TaskCreationOptions creationOptions)
   at System.Threading.Tasks.TaskFactory.FromAsync[TArg1,TArg2](Func`5 beginMethod, Action`1 endMethod, TArg1 arg1, TArg2 arg2, Object state)
   at System.Net.Security.SslStream.AuthenticateAsServerAsync(SslServerAuthenticationOptions sslServerAuthenticationOptions, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware.InnerOnConnectionAsync(ConnectionContext context)

Running the following fixes the problem:

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

Exceptions (if any)

See above.

Further technical details

dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.100-rc.2.20479.15
 Commit:    da7dfa8840

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.15
 OS Platform: Darwin
 RID:         osx.10.15-x64
 Base Path:   /usr/local/share/dotnet/sdk/5.0.100-rc.2.20479.15/

Host (useful for support):
  Version: 5.0.0-rc.2.20475.5
  Commit:  c5a3f49c88

.NET SDKs installed:
  3.1.402 [/usr/local/share/dotnet/sdk]
  5.0.100-rc.2.20479.15 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-rc.2.20475.17 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-rc.2.20475.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

Servicing-consider affected-few area-commandlinetools bug feature-devcerts severity-minor

Most helpful comment

This was discussed offline,

The issue only affects 3.1 apps after the 5.0 SDK has been updated.

There is an issue when an exisiting 3.1 certificate and a 5.0 certificate are installed at the same time, the issue gets resolved by running

dotnet dev-certs https --clean;
dotnet dev-certs https --trust;

Long term, this will be fixed by patching 3.1 to follow the same approach as 5.0

All 2 comments

This was discussed offline,

The issue only affects 3.1 apps after the 5.0 SDK has been updated.

There is an issue when an exisiting 3.1 certificate and a 5.0 certificate are installed at the same time, the issue gets resolved by running

dotnet dev-certs https --clean;
dotnet dev-certs https --trust;

Long term, this will be fixed by patching 3.1 to follow the same approach as 5.0

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Was this page helpful?
0 / 5 - 0 ratings