I have thwte certificate to sign my InstallShield setup. When we updated our certificate this year, it now depends on intermediate certificate "thawte code signing ca - g2".
We fear that many of our customers might not have this intermediate root certificate installed (in fact our own build server did not have it and so build had started to fail after renewing the certificate) and thus they will get the "unverified publisher" error.
What is the best practice to distribute that intermediate certificate? Is there any way to change the certification path so that it just depends on more common "thawte code signing ca"?
I would greatly appreciate any help.
Thanks,
Sanjay
I finally figured out the issue. It turns out there is an option to include certificate roots in the pfx file when you export it. Following is what i followed on my Windows machine where I had installed the certificate that i got from thawte.
1. Open certificate store from Start->Run->certmgr.msc
2. Export the certificate.
3. Ensure to select to include private key as well.
4. Then you get an option to include root certificates - this is unchecked by default. Check it.
Micrsoft has a trusted root program that current contains the following memebers:
Windows Root Certificate Program - Members List (All CAs)
For applications distributed to the general public, the best practice is to get a code signing certificate backed up by one of these roots. For internal enterprise applications ( IT, DoD ectera ) you can use others provided that you have a means in place of distributing the roots for your cert. InstallShield cannot currently do this directly but it's possible using custom actions that call CAPI / CAPICOM / .NET X509 classes.
BTW, when you look at the certificate details, look all the way up to the first entry to know who the root is. For example my cert says COMODO Code Signing 2 but then above that it says USERTrust. When I view the USERTrust certificate is says "UTN-UserFirst-Object". That name is then found on the Microsoft web page linked above.
Related
I am trying to verify the integrity of Putty msi from their website ( not to say I don't trust it. Instead, just use it as a case study ).
On the website https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html, there are signature (.gpg file) and public key (.asc file) for release package.
But what tool is available on Windows 10 to sign the msi using their own public key to generate a signature, then compare the generated signature against the one published on their websit.
I was trying to use Kleopatra. Which I just installed last night and generated a pair of keys for myself. Thus I am a bit struggling at how to instruct Kleopatra to sign the putty msi binary using their public key. ( I don't see the option to remove it).
It would be great if someone could point me a right direction or better tool.
Thanks,
Frank
Ok, so I want your opinion on this...
I have this brand new Windows Server 2012 R2 with all the latest updates.
When I use IE or Chrome and visits www.flashback.org, I get warnings about certificate errors.
Please look at what Chrome is telling me:
http://i.imgur.com/3QsNc9p.png?1
Now, I raised the issue on the flashback forums. Everyone just said the problem in on my end.
So...
where exactly lies the problem? On the server, or on my client?
(I don't want to add exception and just ignore the security problem)
Please don't answer unless you have a pretty good idea what the problem is.
The issue is on your side (client). Du to some unknown reasons GoDaddy root certificate (Go Daddy Class 2 Certification Authority) is not installed on your machine's Trusted Root CAs container.
By default, Windows trusts this CA. It is listed in the active authrootstl.cab file.
This may indicate that someone deleted this certificate from certificate store.
it's been since WinXP I don't use the Windows DDK (now WDK) and I've noticed something big is changed.
I'm developing a legacy NT4 filter driver (without .inf and without .cat) with the latest Win7 DDK, my environment is
Windows 7 64bit
Visual Studio 2010
WinDDK v7600.16385.1
VisualDDK plugin for VS (latest version)
I have issue self signing this driver, since I'm still developing it I don't have (and don't know how to get) an appropriate WHQL certificate, therefore I'm following a procedure I've found online.
#echo off
set SIGNTOOL="c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe"
set MAKECERT="c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\makecert.exe"
set PVK2PFX="c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\pvk2pfx.exe"
set CERTPVK="C:\Users\myself\Desktop\testdriver\avtxagent\package\mycompanynametest.pvk"
set CERTPFX="C:\Users\myself\Desktop\testdriver\avtxagent\package\mycompanynametest.pfx"
set CERT="C:\Users\myself\Desktop\testdriver\avtxagent\package\mycompanynametest.cer"
set DRIVER="C:\Users\myself\Desktop\testdriver\avtxagent\package\avtxagent.sys"
set CERTSUBJ="mycompanyname (test)"
del *.cer *.pfx *.pvk
cls
%MAKECERT% -r -n "CN=mycompanyname (test)" -sv %CERTPVK% %CERT%
%PVK2PFX% -pvk %CERTPVK% -spc %CERT% -pfx %CERTPFX%
pause
cls
%SIGNTOOL% sign /v /f %CERTPFX% /t "http://timestamp.verisign.com/scripts/timestamp.dll" %DRIVER%
pause
cls
:: verification
%SIGNTOOL% verify /pa /v %DRIVER%
pause
Basically what I'm doing is generate the certificate each time (I've already tried with a certificate generated only once, still same issue), signing my driver and then trying to verify the signature.
In this last step, the verification, I get the issue:
SignTool Error: A certificate chain processed, but terminated in a
root certificate which is not trusted by the trust provider.
Obviously when I try to install and then start the legacy driver both programmatically and with sc, I get the error:
[SC] CreateService SUCCESS
[SC] StartService FAILED 577:
Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.
If I follow this guide http://technet.microsoft.com/en-us/library/cc754841.aspx and import the certificate inside the Trusted Certification the verification process goes well, but I get the same error from sc.
What am I doing wrong ? And, is there anyone can explain what I have to do to get an appropriate certificate to use in production environment since the documentation is kind of lacky?
You don't need a WHQL signature to sign a kernel-mode driver. What you do need is a code signing certificate purchased from GlobalSign or Verisign (others won't work). When you have one, use this code signing certificate to sign your driver. NOTE: you also need to include a cross-certificate from Microsoft.
Alternatively (solely for debugging purposes) you can load the system in test mode, in which the signature is not checked. To do this you need to press F8 during system boot and choose the corresponding option in the menu.
This is likely due to the fact that the private CA you used to generate the certificate is not trusted by your system. These look relevant:
http://technet.microsoft.com/en-us/library/dd441378(office.13).aspx
http://technet.microsoft.com/en-us/library/cc754841.aspx
You need to install your self-signed certificate as a trusted root certification authority and as a trusted publisher into the local machine store (normally, certmgr.msc shows and manages your user account's store instead):
certmgr.exe -add <your.cer> -s -r localMachine ROOT
certmgr.exe -add <your.cer> -s -r localMachine TRUSTEDPUBLISHER
As you can see, it's very impractical here to generate a new certificate each time. You'd rather generate it once and then reuse.
(Courtesy of http://winitpro.ru/index.php/2014/05/08/kak-samostoyatelno-podpisat-drajver-dlya-windows-7/; instructions to the same effect are at https://technet.microsoft.com/en-us/library/dd919238(v=ws.10).aspx)
If this question is off-topic, please recommend another StackExchange site to post this on :-)
Our company recently purchased G2 code signing certificate from Thawte. I've run through all steps neccessary to sign a 64-bit driver, so it can be installed under Windows 7 64-bit.
Namely, I have:
downloaded a G2 Thawte cross-certificate
obtained our own Thawte certificate (actually a .p12 file which I had to import and re-export as .pfx file for it to work)
successfully signed the driver via the following command: signtool.exe sign /ac cross.cer /f private_key.pfx /p ***** /t "http://timestamp.verisign.com/scripts/timstamp.dll" /v my_driver.sys
imported our company certificate (and even all those Thawte certificates when the first didn't work) into machine's trusted root authorities and trusted publishers
importted thawte cross-certificate into Intermediate Certification Authorities
I've tried to verify the signature using signtool.exe verify /pa /v my_driver.sys, which has passed. If I do not use /pa in the command line, this would say "SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider." (is that something I should be worried about?)
Now when I try to install the driver using a simple INF file (not a cab file), the result is red warning about Windows not being able to verify the issuer of the driver. When I choose not to install the driver, I get a following extra message: A file could not be verified because it does not have an associated catalog signed via Authenticode(tm).
I've read that Thawte could not really be used to sign drivers like this in the past because somehow MS stopped to support it, yet it's still listing a cross-certificate on their website. Not sure if this is still valid, cannot find any proof of it.
Any advice would be greatly appreciated.
You need to add a CatalogFile reference to your inf file, run Inf2Cat.exe (in the DDK) to generate the cat file, then use signtool.exe to sign that too.
I have created a Midelt which accesses phone contact details [read and write contacts] and access network, this application is working fine S60 emulator.
When I try to install in Nokia E71, it is giving certification error.
I have created certificate using below link. When I try to install it in the phone still I am getting the certification error.
http://www.j2start.com/
Can anybody suggest, is there any way to test a midlet in actual Nokia e71 device without certificate from CA?
If certificate is mandatory,
which is the most suitable CA [Verisign or Thawte ] for Nokia E71?
It was stated in that page (where you signed your app) that the validity of the certificate is between Sept 1, 2010 to Sept 17, 2011. You need to set your device's date to any date between the validity period.
If the same error persists, try to check the certificates in the jad and check if the same certificate is in the phone.
Find JadTool.jar in your machine. You may find it in the Java SDK installation directory or WTK installation directory. If you can't find it then simply download it from the internet. For simplicity, put it in (root directory) C: (I'm assuming you're using Windows, if not then tell me later ;)).
Copy your signed jad file in C. (I want you to have both files, JadTool.jar and your app's jad file, in one directory, preferably C, as a prerequisite of the next steps :D)
Open terminal/command prompt. Go to C; type cd \ (Again, I'm assuming you're on Windows.)
Still on the terminal, type java -jar JadTool.jar -showcert -all -inputjad YourAppName.jad. Mind the case of the letters.
On the previous step, you can see which certificates are available in your jad file. You can see the details of each certificate. Let's focus on the fingerprints. If, for example, you see a Thawte certificate, take note of its SHA fingerprint.
Check the certificates in your device. The certificates are usually found in Security under Settings. If you have a Thawte certificate in the jad then you must check the Thawte certificates in the device. Compare the Thawte SHA fingerprint found in the jad against the Thawte fingerprint of the device. If they match then the app with this certificate is install-able on the device. If they don't match then it is more likely that you cannot use this certificate with your jad file.
Do steps 6 and 7 for the rest of the certificates. If you can't find any pair
then, with the signing, it is more likely that you cannot install your app on your device.
By the way, you can still install your app on the device even if it is unsigned. One problem, if your app is unsigned, is that the user will be be bugged with security prompts. However, this can also be minimized. See my answer on how to minimize these prompts.
This could be the problem becase your either your certificate is old or just check the date on your phone. Your Phone might be running old date.