I am currently working on a scripted program which tracks changes in the operating system by taking snapshots of certain things. One of these are the certificates. The goal being to see what changes an installed program makes to the system. The current issue is that I keep seeing certificates being added that the program did not add, Windows did. My goal was to prevent Windows from downloading certificates during the test. By installing a brand new Trust Root Authority certificates store using the commands:
CertUtil -GenerateSSTFromWU <filename>
Followed by:
updroots.exe <filename>
The issue is that after installing this new store, while I do see fewer certificates being added, I continue to see a number of time-stamp certificates being added to the CurrentUser/CA store. I was hoping someone knew where these certificates we coming from and how I could perhaps pre-install them so they do not appear during the test. Thank you for your advice.
Edit:
Examples of certificates include,
Microsoft Time-Stamp PCA 2010
Microsoft Code Signing PCA 2010
Microsoft Time-Stamp PCA
GlobalSign Timestamping CA - G2
Microsoft Code Signing PCA
Edit 2.0:
Was looking around, I had mentioned that it installed the certificates in the Current User/CA store, which appears to correspond to the Intermediate Certificate Authorities store in certmgr. I believe that AuthRootAutoUpdate applies to the Trusted Root Certificate Authorities store. The question I am looking into now, is there a separate service responsible for updating Intermediate Certificate Authorities?
Windows try to get certificates from ctldl.windowsupdate.com. Firstly it try to get following files:
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
And then it can take root certificates if it needs them to check identity of certificates from folder:
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/
Related
I'm trying to deploy and distribute a C++ app on Windows.
I've managed to create an MSI installer with Visual Studio (with the Microsoft Visual Studio Installer Project extension). When I run it on my computer, everything is fine. But if I run it on someone's else computer, Windows Defender displays a SmartScreen warning:
We are still in beta, so we don't have a lot of money or any certificates, but we want to make the beta available without this warning to allow users to test the product and give us feedback (we want to setup a build-measure-learn method).
I've seen that I can use EV certificates to remove this warning (but they are too expensive, so it's not an option).
How can I remove this warning for every user who downloads my installer from my website (without any cost, if possible)?
You need an officially code sign or and code sign EV certificate, it will cost some money, and sign with signtool or build events your output (dll, msi, exe) with that certificates. Then your setup, is from a known publisher (you / your brand).
You can use a self-signed cert, but then you need to install the cert on every machine ... that use case is useful for "internal" usage. In your case, when you offer a download from your Website, you need to inform the user, that you used a self-sign cert and you can offer the CA of your cert and ask the user to install it ... or you just mention that the cert is self-signed and share the Fingerprints / MD5 Hashes so your customers can verify the content on there own.
So I had a certificate from Comodo and bought via KSoftware that I use to sign my software so it does not generate a warning when users download it, this has been working fine but the 2 year certificate expired last month. I purchased a new certificate last week and applied to a new version of my application but now when I download it warns me unknown publisher, and wierdly when I click on more info it shows my full address instead of just my company name JThink.
I have looked at my old and new certificate in browser and noticed I had Jthink ltd in old certificate and JThink in new one, would this cause an issue ?
Update
Comodo tell me there is a period of time before Microsoft start accepting new certificates and it would still be a problem even if the company information was identical because the certicate no is different.
Is this true, and what length of timescale are we talking about here ?
You need to just wait some time. Windows collects different data for your new certificate (total downloads count, etc.) and in some near future (depends on downloads rate) it will mark it as white listed (if it's all OK). And all your downloads signed using this new certificate will not be blocked anymore.
The same mechanism applies (as I think) on downloads without certificates at all. Windows collects the file reputation and after some critical amount of "good-experience" downloads it marks the file as OK. The same logic applies to certificates. Thus you do not need to wait anymore if your certificate has a "good reputation".
You need to use Extended Validation Code signing certificate which provides more trusted security certificate for your Windows binary. Regular code signing certificates are not validated by Windows smart screen protection.
I had the similar issue when Windows 10 was released with Windows smart screen protection with more advanced security features.
https://www.digicert.com/code-signing/ev-code-signing.htm
Scenario: I create my own root certificate for Authenticode (used to sign executable only). Easy. Unfortunately, it will only work on computers where I have installed the certificate!
So, I want to become an official CA (the root certificate will be present on all Windows of the world). As a bonus, I can sell this service to others :)
TL;DR: I want to become a official CA recognized by Microsoft for signing executables only (Authenticode, not SSL/TLS).
Questions: is it possible to submit its root certificate to Microsoft for they integrate with Windows? What are the costs? Is it possible for an individual and/or small business?
Thank you in advance!
I distribute a Windows desktop app which has all executable files digitally signed by a Verisign Class 3 Code Signing certificate. For the vast majority of users, this seems to work fine.
However a small number of users report the certificate is invalid. They say it comes up with the message "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider". This corresponds to error code CERT_E_UNTRUSTEDROOT (0x800B0109). This has also been reported on a fully-updated Windows 7 machine. So presumably my certificate is OK, but Windows sometimes doesn't trust VeriSign certificates.
Why does Windows sometimes not trust VeriSign? Is there anything I can add to my installer (also signed) which will tell Windows to trust the certificate?
There are frequent updates of the Root Certificates which Microsoft rolls out via Windows Update, but which are tagged as "optional update". Hence not all users may have them installed and may need to install them manually. This also holds for "fully updated" machines, as the automatic installation is often set to only install "important updates", which the Root Certificate updates are not.
Depending on the type of desktop application, you may have to follow certain rules when signing, too. For example applications interacting with the Windows Security Center require essentially the same signing method as drivers. That is, the certificate chain gets embedded along with the signature (/ac switch to signtool). You can get the MSCV-VSClass3.cer applicable to VeriSign certificates here.
The process is often called cross-signing, which seems to be a misnomer. While this is one step in getting your driver binary or catalog cross-signed, the vital step is that Microsoft signs the driver (or more usually the catalog file these days), which is the actual cross-signing.
I've followed the guidelines and configured fine my desktop for Ad-Hoc distribution (requested certificate from the CA, created the main Certificate with my name, created a provisioning associated to devices, and so on).
Now I have my laptop and I need to configure it with the same account (not creating a team development account, but an admin one). I didn't recreate the certificate from the CA because I already have my valid certificate online (the one associated with the provisioning), and I downloaded it and installed it in my keychain. But if I open Xcode and look for a valid provisioning, it says "profile doesn't match any valid certificate/private key pair in the default keychain".
Do I need to recreate my own certificate every time I switch from my workstation to the one in my office?
When you create a CA it uses a private key on your system. You need to copy that to your laptop in order for XCode to use the CA.
http://developer.apple.com/ios/manage/certificates/team/howto.action (need to be logged in)
Here is a helpful article on the topic:
http://www.buggyprogrammer.co.uk/2010/12/13/sharing-ios-distribution-certificate/
I'm in the process of doing this myself, so I'm not sure if this works, but seems like it should.