VS 2019 16.5.0 Preview 5
Windows 10
Chrome Version 80.0.3987.163 (Official Build) (64-bit)
I Googled this and am unable to find an answer.
I am trying to run a simple asp.net core MVC app with TLS on localhost.
What I did is I created a new project then in the project settings I enabled SSL and the URL I got I copied as App URL
App starts properly and TLS CA is not trusted? I followed the example here: https://stackoverflow.com/a/48790088/4950215 and I added the certificated Located in Personal/Certificates folder to Trusted Root Certification Authorities - Certificates manage computer certificates now showed that the CA is trusted.
I reloaded the app and I saw that the localhost SSL certificate used by Chrome is different than the one registered on my computer, and therefore the CA is still not trusted.
I have found the issue:
Basically, for whatever reason, I had a localhost installed on my LocalComputer store certificates. This made me think that Visual Studio created it, in reality VS creates certificates in the CurrentUser store, as visible by the open code in the dotnet repo.
Typically the procedure, for generating and TLS certificate by VS, is expected to go as such:
A .NET Project is marked as HTTPS, and you try to run it.
VS checks if a certificate is present in the CurrentUser store, asks to create one if it's not
User clicks YES, to creating a certificate, initially the certificate is installed in the CurrentUser/Personal/Certificates store
VS then sees that you do not have a localhost certificate in CurrentUser/TrustedRootCA/Certificates, and makes a prompt to ask you if you would like to install one, you click YES - everything is done.
Now if for some reason you are like me... and your CurrentUser/Trusted Root Certification Authority/Certificates is read only. Then you end up on the following line of the code:
case EnsureCertificateResult.FailedToTrustTheCertificate:
reporter.Warn("There was an error trusting HTTPS developer certificate.");
Because well step 4 failed...
To mitigate this:
Open the CurrentUser and LocalComputer stores. You can do that by following this microsoft guide, or just type certlm.msc and certmgr.msc in the Start.
Right click Export on the localhost certificate in CurrentUser store and export it as with the default options
Try importing the same certificate in the Trusted Root Certification Authorities/Certificates folder of the CurrentUser store.
If step 3 failed,which it should have because you wouldn't be in this predicament otherwise, import your certificate in the Trusted Root Certification Authorities/Certificates folder of the LocalComputer store.
Now everything should work. Hopefully you wouldn't have spent 6 hours on this, like I did.
In my case this worked:
Clean the old certificate and generate a new trusted one. Run the commands listed below:
dotnet dev-certs https --clean
dotnet dev-certs https --trust
Go to %APPDATA%\Microsoft\UserSecrets and delete all of the directories
Re-run the application. It should now run with no SSL errors
source: https://joeblogs.technology/2021/11/neterr_cert_date_invalid/
Related
I'm trying to replicate what Visual Studio does on F5 debugging in my .net core api application.
It seems that "dotnet run --project" is the trick that I'm looking for except for one thing:
When I run with F5, it runs on https and it is trusted.
When I run with dotnet run, it runs on https and it is NOT trusted.
And I seem to be having problems using the application even though it seems to be running.
Any thoughts? I would like to do the same trick that F5 does just in order to test my application, however dotnet run must be missing some sort of certificate or something?
I really don't want to have to change my source code or to do anything with certs, again, because it is working as designed on F5, just need to do the same trick for dotnet run.
Based on the documentation here, it seems like you need to install and trust the development certificate:
.NET Core SDK includes a HTTPS development certificate. The certificate is installed as part of the first-run experience.
While the certificate is installed at this stage, it goes on to say that:
Installing the .NET Core SDK installs the ASP.NET Core HTTPS development certificate to the local user certificate store. The certificate has been installed, but it's not trusted. To trust the certificate perform the one-time step to run the dotnet dev-certs tool.
To trust it, you should use the following command:
dotnet dev-certs https --trust
This should show a dialog prompting you to trust the certificate. Once this is done, you can start your project running again, and restart your browsers. This should allow you to access the site on https://localhost:portnumber
I am following an online tutorial to create an ASP.NET Core Web application. I followed everything but had trouble with trusting the local HTTPS certificate.
When I first run the application, I got an error saying:
"the access control list (acl) structure is invalid"
I tried googling this error but couldn't find anything related to my ASP.NET application, after cleaning the solution I didn't get this error any longer.
But I was unable to run my application in browser using HTTPS as it always says:
"This site is not secure"
I tried to trust certificate using CMD using this command:
dotnet dev-certs https --trust
It should show me a prompt to trust the certificate but it says "there was an error trusting the HTTPS developer certificate" and the application runs in an unsafe mode on the browser.
Can someone please help me run my application with HTTPS on my local environment? Any help will be greatly appreciated. Thanks
This seems to be a bug in ASP.NET Core 2.1:
what you need to do is go move your added certificates from your certificate manager.
go to start menu > Type "Win + R" type "certlm.msc", this will open your certificate manager.
go to Personal/Certificates
you will find a certificate named "localhost there.
Move that to "Trusted Root Certification Authorities/Certificates"
run the project again, and it should work.
Hope this helps.
I had the same problem in .NET 5. Running the command gave me the same error. After a few iterations I figured it out finally...
I was trying to create certificates manually through certlm.msc (local computer) but apparently the certificate should be created in certmgr.msc (current user). This is the place where the certificate gets saved when you run the command
dotnet dev-certs https --trust.
Windows + R and type certlm.msc
Go to Personal -> Certificates and export the localhost certificate with the same key (asks for password)
Go to Trusted Root Certification Authorities -> Certificates and right-click to click on Import
Browse and select the exported certificate
Place all certificates in the following store is selected and click on Browse again
Mark the checkbox: Show physical stores
Click on Trusted Root Certification Authorities and press on Local Computer
Finish everything
I had this issue in .net 6, solve it with help of this comment.
dotnet dev-certs https --clean
dotnet dev-certs https --trust
(maybe the clean is necessary as a first step...)
I have tried all the suggestions but eventually, The below solution worked for me.
Uninstall IIS Express via Add Remove Program
Run command: dotnet dev-certs https --clean
Re-install IIS Express by downloading it from the Microsoft website
Run the Asp.Net application from Visual Studio
Visual studio will prompt for generating a certificate, click yes.
In my case, it generated the certificate but failed to add the certificate to the trusted root with an error 'Access Denied'
Windows + R and type mmc
File > Add Snap-In
Select Certificates and click add
Select the 'Computer account' option and click finish, then click Ok.
Then expand the certificates(Local Computer) > Personal > Certificates
You will find a local host certificate with the friendly name 'ISS Express Development Certificate'
Select the certificate then cut and paste it into Trusted Root Certification Authorities -> Certificates
We recently updated our applications to make use of SHA-256 code-signing with a new certificate. The assemblies are strong name signed using the Sign the assembly option in Visual Studio 2015. The post build event in Visual Studio runs two signtool.exe processes to sign both in SHA-256 and for the legacy SHA-1 certificate:
call "C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe"
sign /f "<mystrongName.pfx>" /p "<password>" /t
<timestampURL> "$(TargetPath)"
call "C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe"
sign /f "<mystrongName.pfx>" /p "<password>" /fd sha256 /tr
<timestampURL> /td sha256 /as /v "$(TargetPath)"
Finally we use Advanced Installer as the installation packager and that too is code-signed on the Digital Signature page using the certificate and timestamp as per the .exe signature.
The final setup file installs and runs on Internet connected Windows machines as you would expect. You can see the certificate is assigned and valid, as well as the certificate chain through the properties of both the setup.exe and the runtime when installed. Furthermore, Windows recognizes the application as from a trusted source and displays the appropriate verified publisher details.
Our customer-base is largely global 100 companies and most of the deployments will be occurring in air-gapped networks. In one of our fist updated deployments in this environment, the certificate could not be verified preventing the installer from completing.
This made sense, because the Windows (2012 server R2) machines were isolated from the Internet and, due to company policies, had Turn off Automatic Root Certificates set to Enabled. This setting can be found in the Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication Settings folder of the MMC application (you need the certificates plugin installed).
When testing on our local test-bed, even machines not connected to the Internet would install the certificates from the setup utility if the above registry setting was the default (Disabled). We could replicate the issue by changing the policy setting to match the customers' (Enabled).
As a workaround, we manually downloaded the Certificate Authorities root certificate and installed it as a Trusted Root Certificate and the install would proceed normally.
When we presented this workaround to the customer, the installation still failed despite the Certificate Authorities root certificate being present in the Trusted Root Certificates of the machine.
The Certificate Authority customer service team recommended that we drop the timestamp from the signing process to allow the install to proceed - and that's the only help they offered (that's another story). However, this means that once the code-signing certificate expires, the application will either cease to run or will present unverified publisher errors.
I'm not totally convinced that this will fix the problem either, because when we tested locally the certificate was still found by the installer and allowed the installation to proceed when the Certificate Authorities root certificate was installed manually.
What I am unable to do is replicate the customers environment to exactly reproduce the problem (which doesn't help). It is almost as if Windows is bypassing the local machine's Trusted Root Certificates store. I am assuming that if this is possible it would be so that Windows can verify against a central root certificate store.
Is this even possible to set up in Windows? If so, where would I find either documentation on this or how is this done?
Am I missing something in the code-signing steps or in my understanding of what should be happening on the installing machine while it is checking the certificate?
I am at a loss as to what to do to get this installer working. What I can't afford to do is keep going back to the customer to get them to keep testing our installs. First-off it's really not the right process to debug, as the supplying vendor it isn't the customers problem to solve, but more importantly, I need our team to understand what is causing this and how to remedy it correctly.
Ideally I don't what to drop the timestamp if I don't have to because down the road this will cause new problems if the software doesn't get upgraded before the certificate expires.
Any and all help much appreciated.
I think one reason a certificate cannot be validated in an airgapped environment may be that revocation cannot be verified. As you may know, a certificate can be revoked, and there are two different protocols to check if it is, CRL and OCSP. Both require network access to the CA that issued the certificate.
Whether revocations are actually checked is governed by policies as described here, and this may cause your issues.
Does anyone know how to use code signing certificate for ClickOnce manifest applications in TFS Hosted Controller Build?
Scenario:
I am using Team Foundation Service as a code repository and source control. I have created a build definition using team explorer (Visual Studio 2012).
Build "Process" using Default Template configured to Any CPU|Release
The build is set to "Manual trigger" uses Hosted Build Controller.
TFS build is unsuccessful if my project use Code Signing and Code manifests.
In my solution, two projects having "ClickOnce manifests"
Local build dont have any issues with Code signing and ClickOnce manifests - because Code signing certificate available locally for the build.
But for the same build in TFS, i get the error "Unable to find manifest signing certificate in the certificate store."
(just one error blocking the build)
Question
How can I install the code signing certificate into "TFS Build Service Account" or "Build service user account"?
How can I make the code signing certificate to avail in the virtual build machine's certificate store?
Any alternative to get clean TFS build with Code signing and ClickOnce Manifests?
Have not find the solution yet :( anyone helpful here??
Well I have managed to Sign my ClickOnce manifest in TFS auto build. My certificate was password protected and build server was not able to access the certificate because of that reason. The certificate was not in my personal certificate store hence I had the trouble.
I have imported the certificate into my local machine's personal store and from there i have referenced it for signing the clickonce manifest. When you reference the certificate from the personal store, it will not ask for the password. Hence you can cheat the TFS build and that can now access your code signing certificate..
I have a possible alternative to get a clean build for you.
My company produces a product called ClickOnceMore (www.clickoncemore.net) which can be used to build your ClickOnce manifests rather than MSBuild. It's designed to be easily integrated into a continuous integration build using a command line interface.
To integrate into your build:
* Turn off clickonce in your visual studio solution
* Create a ClickOnceMore project
* To sign the manifests you just need to put the signing certificate in a known folder location and then reference it from the ClickOnceMore project
* Add a new build step in TFS to build the ClickOnceMore project
Hope that helps.
I'm working on a project which is packaging the help file to VS 2010. I look for some informations, and I known steps of packaging. As follows:
Composited the help file with the extension name called ".cab"
Constructed a certificate file for current user
Install the certificate to the system.
Signed the .cab file with the certificate.
Install .cab file to VS2010 with help viewer.
I coded an application to realized steps as above. It was failed in step 4 after I installed the certificate as personal certificate. I found that it would be ok when I installed the certificate in root trusted certificate. But when I'm installing the certificate as a root trusted certificate, did the confirm window pop up!
I wana install the root trusted certificate with no confirm window in coding C# console application. What shoud I do?
If I understand you correctly, to do what you want you need to bypass the MS CAPI interface and add your certificate + mark it as trusted for code-signing (you will need to correctly build the certificates involved as well). For help with that you must reach out to the dark side. Perhaps ask Microsoft for some help with this via email - let us know how it turns out ;)