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.
Related
coming from Windows, I am used to sign my code (.exe, .dll). Especially with the recent Windows versions, executing unsigned code or code signed with a self-signed certificate becomes more and more difficult, if not impossible. I do therefore own a (payed) Authenticode EV certificate and have integrated signing into my build chain.
How important/mandatory is code signing under Linux?
Thnx, Armin.
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)
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.
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.
I've already asked similar question on this issue on stack overflow already, but I believe this part of the issue can be separated into a new question.
I've not done mobile development before so the use of signing and certificates is a new concept to me, and for all the reading of topics I have done, its not really improved my knowledge as each website I read talks only about a small part of signing, not the complete process, and piecing it all together has been difficult.
The issue I have is my driver is not been loaded at startup on WM6.1. Its a driver for GPS so needs to be loaded so its available to any GPS software accessible on a COM port. I believe this is due to a signing issue, given that the DllMain method is never called.
I have been given a privileged certificate (.pfx) to use, and for the record have also got the new (Jan 2010) SDKSamplePrivDeveloper certificate as well. I assume a privileged certificate is needed for drivers.
So what have I actually done. I've tried atleast several variations on this over the last 4-5 days all with no success.
In visual studio;
1)The DLL project has authenticode signing set to our .pfx certificate. Build the project.
2)The CABWizard project has authenticode set to the same certificate. Build the project.
3)Following the MSDN instructions... Converted the .pfx into a 509 Base64 Certificate, and created an XML provisioning file from it.. It has been created into its own CAB Or CPF file. And also tried provisioning the _setup.xml file into the previously created CAB file so its installed with the application.
4)I have installed these onto the device, and whilst the driver does work in our test app it does not load at boot even though its registry settings in "BuiltIn" are correct. When checking the certificate stores in the registry I can see the certificate added to the SPC, Root, Privileged and Unprivileged stores. And when using System|Certificates I can see the certificate in Root tab. So they have definitely been added.
Given the above did not work. I have also tried the siggner.exe tool from http://www.modaco.com/content/i8000-verizon-sch-i920-omnia-ii-http-i8000-modaco-com/306870/sdkcerts-2010-and-signing-tool/ with the SDKSamplePrivDeveloper certificate.
1)The Dll project has authenticode signing set to No. Build the project.
2)Load up siggner.exe and sign the Dll file with SDKSamplePrivDeveloper.cer.
3)The CABWizard project has authenticode set to No. Build the project.
4)Load up siggner.exe and sign the cab file with SDKSamplePrivDeveloper.cer.
5) Use NewSDKCerts.Cab to install the SDKSamplePrivDeveloper certificate into the stores.
6) Install the CAB file i created with the driver.
7) Again, on a warm reboot the driver is not loaded at boot into device.exe.
Given the above, can anyone give me some clear instructions on a sure fire way to load the driver at startup. I'm obviously doing something wrong with the signing given this does boot up without an issue in Windows CE5. I know the device driver code is OK as I can activate it manually in code with ActiviateDevice() method in WM6.1.
Edit--
It maybe worth adding, I also created a DLL and CAB with no signing at all. And on a clean boot of the OS it installed without complaining. Whilst still not loading at boot I did expect warnings about the CAB and DLL been unsigned.
The reason for driver failure, was not a certificate issue.
The driver was originally self contained and also contained some GUI code, and has since expanded. A library used to make the application full-screen was not available at start up so it silently failed with a dependency issue.
This has currently been resolved with a start-up application loading later to wake up the driver, once the library is available. A proper solution to be added is late loading of the required library to prevent a dependency failure.
Driver signing was also an issue in a related matter with this driver. We now have a certificate from the manufacturer to sign drivers so that issue was resolved as well.