I am unable to trust dev-certs on my machine. The error I am getting when I run the command is "There was an error trusting HTTPS developer certificate". I am running Windows 10 version 1803 (OS Build 17134.191).
@javiercn
@rodrickmakore Can you try running dotnet dev-certs https --clean
and then running dotnet dev-certs https --trust
and see if that solves your problem?
@javiercn I am still getting an error.
@rodrickmakore Hmmm. I can think of several possibilities:
* Check on CurrentUser\Trusted Root Certification Authorities
If there is a certificate like that in any of those two places. Can you remove them manually and try again?
Hi. We're closing this issue as no response or updates have been provided in a timely manner and we have been unable to reproduce it. If you have more details and are encountering this issue please add a new reply and re-open the issue.
This is still an issue - I am seeing the error that @rodrickmakore described in his screenshot. I removed the localhost certificate from Certificates - Current User Personal/Certificates and retried, but was blocked by the same error as described above. I checked the other certificate location and a localhost certificate was not present there.
What is the next step that I can try to get unblocked on this?
@njebert Maybe the prompt where you are running the command on doesn't have permissions to modify the certificate store?
I'll try to give you a powershell script when I'm back in the office that generates an identical certificate to the one used by the tool and see if you are able to create it using that.
@javiercn Could be it - I am running the commands from an administrator instance of PowerShell. Much appreciated - I will retest once I have your script.
@njebert Hi,
I've created a powershell script to help diagnose issues with the tool. https://gist.github.com/javiercn/9f2657f88498ce1b0b8c99d326131b54
Read through the script to ensure you are ok running it, run it with .\cert-diag.ps1, evaluate the output for anything that you want to censor and paste the output here.
The script also contains a switch -TryCreateCertificate that will create a certificate equivalent to the one the tool generates using powershell. You can try and run it at your own risk and see if that fixes the issue.
@javiercn Hi,
I am getting this same issue.
Visual Studio 2017
Version: 15.9.9
.NET Core: 2.1
ASP.NET Core: 2.1
When I execute your cert-diag.ps1
script, it says:
Certificates with the ASP.NET Core Oid trust root for the current user:
Specific checks:
Certificates with our OID on CurrentUser\My: 1
Certificates with our OID on CurrentUser\Root: 0
The number of certificates in the store looks correct. You could try running this script with -TryCreateCertificate to generate a certificate equivalent to the one 'dotnet dev-certs https' creates. Use this flag at your own risk
So I tried with the -TryCreateCertificate
option. The last lines were:
Certificates with the ASP.NET Core Oid trust root for the current user:
Specific checks:
Certificates with our OID on CurrentUser\My: 1
Certificates with our OID on CurrentUser\Root: 0
The number of certificates in the store looks correct. You could try running this script with -TryCreateCertificate to generate a certificate equivalent to the one 'dotnet dev-certs https' creates. Use this flag at your own risk
0
PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My
Thumbprint Subject
---------- -------
AD7F22917F0BC3727E0B8F098A2F858256CB2024 CN=localhost
So it appears to successfully add the certificate because when I run it again, it complains about there being 2 certificates.
However, when I try running my ASP.NET core app again, I am still prompted to trust the certificate, and it still fails.
I am getting this issue as well - with basically exactly the same results as @mwhouser
Running on Visual Studio 2019, .Net Core SDK 2.2.203
Still having issues with this...
certdiag.ps1
Certificates with the ASP.NET Core Oid trust root for the current user:
Specific checks:
Certificates with our OID on CurrentUser\My: 1
Certificates with our OID on CurrentUser\Root: 0
The number of certificates in the store looks correct. You could try running this script with -TryCreateCertificate to generate a certificate equivalent to the one 'dotnet dev-certs https' creates. Use this flag at your own risk
cert-diag.ps1 -TryCreatCertificate
Certificates with the ASP.NET Core Oid trust root for the current user:
Specific checks:
Certificates with our OID on CurrentUser\My: 1
Certificates with our OID on CurrentUser\Root: 0
The number of certificates in the store looks correct. You could try running this script with -TryCreateCertificate to generate a certificate equivalent to the one 'dotnet dev-certs https' creates. Use this flag at your own risk
0
PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My
Thumbprint Subject
---------- -------
26188E62163F03A83C8EBBE64B05CC6A6653AABF CN=localhost
Visual Studio 2019, .NET Core SDK 2.2.202
@psyvision Could you try and run donet dev-certs https --clean?
(run the script later) and then run dotnet dev-certs https --trust?
Interesting. Have same issue (VS 2017 tough). I tried your steps with same results.
However, when I look on the certicicate details I can see following problem:
(Ob both mine and created by script)
Can this be cause of the issue? Can it be due to some control of Registry by the Organization?
@javiercn I had tried that as I had seen it mentioned prior, sadly it leads to the same issue.
@Sebastian-Gruchacz almost definitely for us, our computers are very locked down due to the industry we're in.
@psyvision @Sebastian-Gruchacz I'm not sure what is going on in your environments. The way the certificate works is as follows:
You get certificate + key installed into CurrentUser\My (Personal certificate store) and then the certificate is copied to CurrentUser\Root (Trusted Root Certification authorities).
You can verify that the certificate is in both places. (and if not, copy it from CurrentUser\My to CurrentUser\Root). You can close all browsers and reopen them and then it should be trusted.
Make sure that there is only one localhost certificate with the friendly name ASP.NET Core HTTPS development certificate
on both places (remove all localhost certificates with ASP.NET Core HTTPS development certificate
friendly name if you want and create it with the tool).
If still doesn't work, can you provide more details about the environment, (like OS, etc.) There might be domain policies playing a role in there, but its out of the scope of my knowledge.
@javiercn Thanks for the further information. I can confirm the certificate was installed in Personal
but not Trusted Root Certificate Authorities
. I exported it and attempted to import it but received a message stating The import failed because the store was read-only, the store was full, or the store did not open correctly.
.
As I say, our computers are quite restricted so I will take this up with our internal IT.
@psyvision I'm glad we were able to find the issue. Unfortunately we can't do anything in our end.
I'm having the same issue like @rodrickmakore. I've made a fresh install of my machine running:
Win 10 Enterprise, Version 1809, Build 17763.503
The following SDKs are installed:
VS Community 2019 Version 16.1.1
When I tried to run the script cert-diag.ps1 the script wouldn't run because the ExecutionPolicy on my machine was set to "Undefined". So I set the policy to "Unrestricted" and the script would run. But even when using the "-TryCreateCertificate" option there was no certificate in the Trusted Root Certification Authorities:
I can clean up using "dotnet dev-certs https --clean". What works to a certain degree is exporting the certificate from CurentUserPersonal to a file and importing it to LocalComputer\Trusted Root Certification Authorities and then deleting from Personal. However this solution is only temporary:
Creating a new localhost certificate using the Repair function in Programs and Features produces this in LocalComputerPersonal:
After having imported this into Trusted Root and running the web application I get this error:
However this error doesn't prevent the web application to get displayed in the browser (but the next time I start the application again the same dialog will appear).
Also what I've experienced is that after manually having got the self signed certificate to be accepted - after making some changes to the web application (e.g. adding a controller and a view) the certificate isn't accepted any longer and I have to undergo that process again. I also realized that using the Repair function will install the certificate in LocalComputer whereas the dotnet dev-certs https will install in CurrentUser.
Unlike @Sebastian-Gruchacz I'm not locked down by some industry regulation. I've been struggeling with this for over a week now. Can you give me some guidance on this please?
Latest Update: I had the feeling that this odd behaviour has something to do with security settings in Win 10. So out of curiosity I made a fresh install of Win 7 and installed Visual Studio Community 2019. This got me the following setting:
First I ran the "dotnet dev-certs http --trust" command from the commandline as a normal user and I got an error saying that the permission to change the folder "C:\Program Files\dotnet\sdk\NuGetFallbackFolder" was missing. So I ran the commandshell again with administrator permission, did a --clean and ran the command again and this time the behaviour was quite different: I got a popup with a security warning regarding the installation of a localhost certificate and after aproving the certificate was successfully installed:
After this success I tried the same approach using a clean install with Win 8.1 - and this also worked out nicely.
So I guess the whole problem has something to do with different default security/permission settings in Win 10. But at present I have no idea how to remedy this in Win 10.
Most helpful comment
I'm having the same issue like @rodrickmakore. I've made a fresh install of my machine running:
Win 10 Enterprise, Version 1809, Build 17763.503
The following SDKs are installed:
VS Community 2019 Version 16.1.1
When I tried to run the script cert-diag.ps1 the script wouldn't run because the ExecutionPolicy on my machine was set to "Undefined". So I set the policy to "Unrestricted" and the script would run. But even when using the "-TryCreateCertificate" option there was no certificate in the Trusted Root Certification Authorities:
I can clean up using "dotnet dev-certs https --clean". What works to a certain degree is exporting the certificate from CurentUserPersonal to a file and importing it to LocalComputer\Trusted Root Certification Authorities and then deleting from Personal. However this solution is only temporary:
Creating a new localhost certificate using the Repair function in Programs and Features produces this in LocalComputerPersonal:
After having imported this into Trusted Root and running the web application I get this error:
However this error doesn't prevent the web application to get displayed in the browser (but the next time I start the application again the same dialog will appear).
Also what I've experienced is that after manually having got the self signed certificate to be accepted - after making some changes to the web application (e.g. adding a controller and a view) the certificate isn't accepted any longer and I have to undergo that process again. I also realized that using the Repair function will install the certificate in LocalComputer whereas the dotnet dev-certs https will install in CurrentUser.
Unlike @Sebastian-Gruchacz I'm not locked down by some industry regulation. I've been struggeling with this for over a week now. Can you give me some guidance on this please?
Latest Update: I had the feeling that this odd behaviour has something to do with security settings in Win 10. So out of curiosity I made a fresh install of Win 7 and installed Visual Studio Community 2019. This got me the following setting:
First I ran the "dotnet dev-certs http --trust" command from the commandline as a normal user and I got an error saying that the permission to change the folder "C:\Program Files\dotnet\sdk\NuGetFallbackFolder" was missing. So I ran the commandshell again with administrator permission, did a --clean and ran the command again and this time the behaviour was quite different: I got a popup with a security warning regarding the installation of a localhost certificate and after aproving the certificate was successfully installed:
After this success I tried the same approach using a clean install with Win 8.1 - and this also worked out nicely.
So I guess the whole problem has something to do with different default security/permission settings in Win 10. But at present I have no idea how to remedy this in Win 10.