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.
Related
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/
I have written a very simple add-in that adds a button to the ribbon of outlook (C#).
I have spent days trying to get this very simple add-in to install on another machine using the clickonce method.
I have published clickonce to ftp using Visual Studio. All fine so far.
Upon running the resulting vsto (or setup.exe) on a different machine I am getting the error:
'System.Security.SecurityException: Customized functionality in this application will not work because the certificate used to sign the deployment manifest for Add-In or its location is not trusted. Contact your administrator for further assistance.'
I understand the idea behind a certificate being required to remove rogue add-ins being added to Outlook. I have signed the clickonce deployment using a test certificate on my machine.
Simply is it possible, without paying for a third-party certificate, to give a user the clickonce url and them install it without me having to do anything to their machine? (and/or domain etc.) This is ideally to be used by lots of enterprise users. Altering their environment isn't practical.
Many thanks.
Check your certificate chain. Most likely you need to place a copy of the certificate into:
Certificates - Current User\Trusted Root Certification Authorities
...so your "issuer" is trusted in order for your certificate to be trusted.
I have created several applications, these are deployed on the server and will be opend by the user from the network.
Each time a user opens a application they get confronted with a security warning:
Open File - security warning
We can't verify who created this file. Are you sure you want to run this file?
Is it possible to supress this message by code?
I found an article that says I need to Sign the application but unfortunately this is not help. Another article I found says I need to manual change the security level, but that is not what I want.
I just want Windows to trust my applications.
You have to sign your application with an so called "Microsoft Authenticode Certificate". Furthermore you need to register the Certificate as Trusted Publisher on all affected machines (easy if you are in an business environment with an Active Directory).
You could use the Windows Certificate Snapin (press CTRL + R and type Certmgr.msc) to display all installed certificates on your machine. There you will find a folder named trusted puplisher. However this is only possible in business environments where you have some kind of control over the network (active directory etc.). If you're distributing your application over the internet you will have a hard time ;)
Remember, certificates are about trust and there is a reason for this warning because an *.exe file could indeed harm your computer.
EDIT:
helpful post about Microsoft Authenticode Certificates
I have a ClickOnce application that I built for a client, and I need it to be from a trusted publisher. How do I go about acquiring an Authenticode certificate and sign my application with it? So that when the application is launched, it's from a trusted publisher?
How do I install the certificate? Do I have to install it on my development server or does it matter where I install it?
How does the whole process work? I don't want to spend 3-5 hundred dollars on a certificate, and install something wrong and be out of luck.
Are there good tutorials on purchasing and installing a certificate and signing a ClickOnce application?
I recently went through this process. A certificate is not that expensive - we got a code-signing certificate for less than a $100.
After you have the certificate, follow the FAQ HOWTO: Code signing how-to* to sign your code (binaries).
After that, you have to go to project properties -> Signing and upload your certificate there as well (it's for ClickOnce). You can skip code signing though and sign ClickOnce only.
ClickOnce requires a certificate for code signing, and others will not work, see ClickOnce Deployment and Authenticode:
For ClickOnce applications, you must have an Authenticode certificate
that is valid for code signing; if you attempt to sign a ClickOnce
application with another type of certificate, such as a digital e-mail
certificate, it will not work.
Jan'18 UPDATE:
StartSSL is not trusted anymore, and I did NOT find any free (or similar to what StartSSL was offering) code signing certificates. At the end of the day, I went with ksoftware.net - $84/year for Comodo code-signing certificate (but you need to have DUNS record available for them to check!)
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 ;)