I am writing a tool suite that, among other things, must support PlayReady Model Certificate generation from various Device Company CA certificates (which we will receive from customers).
In order to properly test the software end-to-end I need to obtain some test Company certificates. I could not find the relevant information in PlayReady documentation that was provided by Microsoft. Is there a way to obtain such certificates easily?
(Thinking about it, there probably should exist a root certificate for testing purposes only - I could not find any info on that as well)
Thanks in advance.
What you are looking for can be found in a subdirectory below the 'test' directory of the source code that is provided when you install the Microsoft PlayReady Device Porting Kit (PK). If you do not have this Device PK MSI installer (perhaps you only have the Microsoft PlayReady Certificate Generation Kit MSI), then I recommend that you contact Microsoft to legally obtain a copy of the latest PlayReady Device PK MSI.
If you have PlayReady Device PK 2.0.0:
If you need it, a test root certificate is located here:
c:\PlayReady\Device_PK_2.0.0\test\ToolTests\files\rootcert.dat
There are some example test group/model certificates (bgroupcert*), and their associated test private keys (zgpriv*), are located here: C:\PlayReady\Device_PK_2.0.0\test\devicedevcert\
There are also some example files that you may find informative in the C:\PlayReady\Device_PK_2.0.0\Samples\ sub-directory, such as:
SampleDACResponsePR.dat
SampleDACResponseWMDRMPD.xml
SamplePrivKeys.xml
It looks like there are also some potentially useful files in the C:\PlayReady\Device_PK_2.0.0\test\certs\files sub-directory, such as:
companyprivkey.xml
companypubkeymodulusb64.txt
rootprivkey.xml
rootpubkeymodulusb64.txt
testrootprivkey.dat
testrootpubkey.dat
unsignedtemplate.xml
That said, you should be able to use the following tools, and some of the files above, to simulate/test the full certificate request and generation process:
C:\PlayReady\Device_PK_2.0.0\Tools\generatecompanycertrequest.exe
C:\PlayReady\Device_PK_2.0.0\Tools\generatekeypair.exe
C:\PlayReady\Device_PK_2.0.0\Tools\generatemodelcert.exe
Note: Since PlayReady certificate chains are in "binary" format (i.e. not XML), you will need to use bcertdump to view them, similar to: c:\PlayReady\Device_PK_2.0.0\Tools\bcertdump.exe -b:.\rootcert.dat -v
Also, if/when you have PlayReady Device PK 2.5.0, things may be organized (and work) slightly differently.
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
I use IDE version 6.7(dp4).
I create simple application for iPhone and I have certificate on apple.When I bundle app my screen has freeze.
Here pricture:
Sounds like it might be an issue with your certificates, licenses and/or provisioning profiles.
Have you made sure they are set up identically on both machines?
You may need to delete all the certificates and profiles from the second machine and start from scratch....
Also, check out the mailing list archives for others that have had similar problems. There is a wealth of information there:
http://lists.runrev.com/mailman/listinfo/use-livecode
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.