Important update

This is an ongoing issue in the latest SDK version (3.1.102) that we are still investigating. To workaround this issue follow these steps:

• Make sure you open Keychain Access and delete all the localhost certificates in the login keychain and in the system keychain that were created by ASP.NET Core.
• Open bash in the terminal.
• Create a temporary folder and cd into it.
• Run the following script https://gist.github.com/javiercn/d04855b7a3581bf97d1ab9597935413f#file-generate-sh

I was facing the issue as well. Found out that the issue started with the installation of ASP Net Core SDK 3.1.102. I’m using Mac OS 10.15.3 Beta.

After I removed the SDK 3.1.102, the issue went away.

Use this to remove SDK 3.1.102 sudo rm -rf /usr/local/share/dotnet/sdk/3.1.102 sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.2 sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/3.1.2 sudo rm -rf /usr/local/share/dotnet/host/fxr/3.1.2

What I notice while investigating between SDK 3.1.101 and SDK 3.1.102 for the localhost cert is that 3.1.102 is missing the localhost self-signed on System and the login localhost self-signed cert is not marked as always trusted whereas SDK 3.1.101 had both login and System localhost self-signed cert and both are set at always trust for all of the trust level.

I was facing the issue as well. Found out that the issue started with the installation of ASP Net Core SDK 3.1.102. I’m using Mac OS 10.15.3 Beta.

After I removed the SDK 3.1.102, the issue went away.

For me, everything was fine until I updated the SDK, but this solved the problem. I just removed that SDK version and re-generated my certificates:

sudo rm -rf /usr/local/share/dotnet/sdk/3.1.102 sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.NETCore.App/3.1.2 sudo rm -rf /usr/local/share/dotnet/shared/Microsoft.AspNetCore.App/3.1.2 sudo rm -rf /usr/local/share/dotnet/host/fxr/3.1.2

• dotnet dev-certs https --clean
• dotnet dev-certs https -t

Thank you @frozenfroze!!

Hi @rmarinho I’m going through the exact same error, with the exact same dev stack. I’ve gone through all the pages suggesting to remove the certificate from system key, run the --clean and --trust commands but nothing works.

Does anyone have further ideas on what to try next? It’d be greatly appreciated. Thank you.

Followed the steps from this link fixed the issue troubleshoot-certificate-problems

OS X - certificate not trusted

• Open KeyChain Access.
• Select the System keychain.
• Check for the presence of a localhost certificate.
• Check that it contains a + symbol on the icon to indicate it’s trusted for all users.
• Remove the certificate from the system keychain.
• Run the following commands: dotnet dev-certs https --clean dotnet dev-certs https --trust

@rmarinho thanks for contacting us.

Could you check a few things? Do you have any “localhost” certificate on your keychain? (If so, assuming that it is an asp.net core generated one) Can you remove it manually? Also check on the system certificates for the same certificate and remove it from there too.

Can you run dotnet dev-certs https --check and report the exit code?

This should be considered as part of looking at making the dev experience of certs better.

cc @ldillonel

What I noticed is that no matter how many times I run dotnet dev-certs https --clean; dotnet dev-certs https --trust it wouldn’t fix the issue until I re-installed the dotnet core sdk. So I’m doing active development for two client projects - one using dotnet core 2.2 and another using dotnet core 3.1. It seems that a valid trusted localhost certificate installed using one sdk won’t work in another. Re-issuing the certificate, restarting the machine, doesn’t do anything. The only thing that helps was to re-install the relevant sdk each time I switch projects. It seems that Microsoft has some bug in that the sdks can’t share the dotnet-dev-certs tool, and installing one sdk overwrites some files in dotnet-dev-certs. It doesn’t seem very robustly built.

@aspnetde we are working on a solution to this problem.

The latest SDK 5.0-preview4 SDK contains an updated version of the tool that fixes this issue. We have plans to patch the current LTS SDK once we have enough confidence that the new approach doesn’t introduce additional issues.

I’m also running into this issue. Just started happening somewhat randomly. I installed dotnet 6 preview 6, ran into issues when trying to run a project and uninstalled it (by doing rm -rf /usr/local/share/dotnet). Then I reinstalled dotnet 6 preview 2 (which seems to be the most stable version on my M1 MacBook with Big Sur).

Then when I tried to run an aspnet core project, and I got the error:

Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date.

I tried all the above steps ./generate.sh and --clean then --trust, manually deleting certificates. Nothing worked.

I’ve gone as far as building AspNetCore locally to be able run the dotnet-dev-certs project in debug mode to see what’s going on.

State 1

When I run --trust and my login AND System keychain have no localhost certificate I get the exception:

Interop+AppleCrypto+AppleCommonCryptoCryptographicException: The specified item already exists in the keychain.
   at Interop.AppleCrypto.X509CopyWithPrivateKey(SafeSecCertificateHandle certHandle, SafeSecKeyRefHandle privateKeyHandle, SafeKeychainHandle targetKeychain)
   at Internal.Cryptography.Pal.AppleCertificatePal.CopyWithPrivateKey(SecKeyPair keyPair)
   at Internal.Cryptography.Pal.AppleCertificatePal.CopyWithPrivateKey(RSA privateKey)
   at System.Security.Cryptography.X509Certificates.RSACertificateExtensions.CopyWithPrivateKey(X509Certificate2 certificate, RSA privateKey)
   at System.Security.Cryptography.X509Certificates.CertificateRequest.CreateSelfSigned(DateTimeOffset notBefore, DateTimeOffset notAfter)
   at Microsoft.AspNetCore.Certificates.Generation.CertificateManager.CreateSelfSignedCertificate(X500DistinguishedName subject, IEnumerable`1 extensions, DateTimeOffset notBefore, DateTimeOffset notAfter) in /Users/tylermichael/source/repos/aspnetcore/src/Shared/CertificateGeneration/CertificateManager.cs:line 647
   at Microsoft.AspNetCore.Certificates.Generation.CertificateManager.CreateAspNetCoreHttpsDevelopmentCertificate(DateTimeOffset notBefore, DateTimeOffset notAfter) in /Users/tylermichael/source/repos/aspnetcore/src/Shared/CertificateGeneration/CertificateManager.cs:line 560
   at Microsoft.AspNetCore.Certificates.Generation.CertificateManager.EnsureAspNetCoreHttpsDevelopmentCertificate(DateTimeOffset notBefore, DateTimeOffset notAfter, String path, Boolean trust, Boolean includePrivateKey, String password, CertificateKeyExportFormat keyExportFormat, Boolean isInteractive) in /Users/tylermichael/source/repos/aspnetcore/src/Shared/CertificateGeneration/CertificateManager.cs:line 229

Debugging locally was the only way I was able to track down this down. Passing the --verbose flag seems to have no effect for me and doesn’t make it print more things.

State 2

After running ./generate.sh then running --check in debug shows me that the certificate doesn’t have a corresponding private key in my keychain.

This explains why I get this error when running a project after running ./generate.sh.

Seem’s like there’s something really weird going on with my keychain. I think I may bite the bullet and hit the ‘Reset Default Keychains’ in Keychain Access (after unchecking the Keychains item in the iCloud sync setting in the preferences, and making a backup of them).

---

Side note: I also noticed in the generate script that there is a typo in the certificate sentinel filename. https://gist.github.com/javiercn/d04855b7a3581bf97d1ab9597935413f#file-generate-sh-L33

It should be ~/.dotnet/certificates.${certificateSha256Hash}.sentinel rather than ~/.dotnet/certificate.${certificateSha256Hash}.sentinel. Seems like the cert tool expects it to be ‘certificates’.

See: https://github.com/dotnet/aspnetcore/blob/3accbd6abe9701c431855a5c4ab5b6098841cf5d/src/Shared/CertificateGeneration/MacOSCertificateManager.cs#L92

To workaround this issue follow these steps:

• Open Keychain Access

• Delete all the localhost certificates in the login and system keychain (that were created by ASP.NET Core).

• Download the following script generate.sh

• Open a bash terminal. chmod 555 generate.sh ./generate.sh

If it’s not working make sure to delete all the localhost certificates in the login keychain. Then on bash terminal dotnet dev-certs https --trust

@ardaozceviz I’m not exactly sure how to do that without risking removing other localhost certificates, that’s why I didn’t do it. On the same gist there are instructions to remove the certs manually using keychain.

@jdelano does the script described here not fix the issue for you? https://gist.github.com/javiercn/d04855b7a3581bf97d1ab9597935413f#file-generate-sh

Hi all,

I was just having this same issue. I managed to get around it by allows trusting the localhost certificate that is generated after trying to run the application.

You still have to enter your keychain password everytime you try to run, and the terminal will still says that the app fails, but it will actually run in the browser as expected.

run the script by @javiercn in his batch file and the problem will go away. then just wait for a proper fix.

@XiaroanZhang the step that is failing is the last one, the set-key-partition-list one, so you should be fine if you try to run an app (you’ll have to close and reopen the browser)

There are many reports on this thread, so I’m going to try and give some manual steps on how to potentially address/mitigate this issue while we investigate: See here for instructions on how to remove, make accessible across partitions and trust certificates manually.

For those affected, I suggest you do as follows:

• Clean up your certificates manually.
• Create a new certificate with dotnet dev-certs https
  • If this step fails to make the certificate accessible across partitions, make it accessible across partitions try and make it accessible across partitions manually following the instructions in the gist provided above.
  • If the instructions for making the certificate accessible across partition fail, follow the instructions below.
  • To unblock yourself, get the SHA256 signature of the certificate (you can do so in keychain access by inspecting the certificate)
• Create a file with the name certificate.<<sha256>>.sentinel inside ~/.dotnet/
• Trust the certificate manually by exporting the certificate from Keychain Access and trusting it security add-trusted-cert as described in the document.

Important details for this issue

In order for us to help investigate this issue, the following information will help us:

• OS Version
• List of installed SDKs
  • If you remember the order in which they got installed, include that.
  • Did you run a binary distribution side by side (from a downloaded .tar.gz)?
  • Were all the SDKs you installed notarized?
    • Hint: If the installer was not notarized Mac OS would have blocked the installation and you would have had to manually unblock it.
  • Does following the steps described above fix your issue?
    • If it does not, can you provide details of what manual step fails and the output of the command.
    • If it does, please provide the concrete set of steps that you followed as that will help us narrow down the issue and help other people workaround it.