I need to sign my Adobe AIR application which is a native installer. Right now I just have a Windows version, but soon I'll be porting it to other OSes including mobile OS.
My query is whether I need to get a separate code signing certificate for each one or is one enough? Also does 32-bit and 64-bit matter?
Verisign have categorized certificates for Windows (.exe) and Adobe AIR (.air and .airi) separately. So which one should I obtain?
CAs selling code signing certificates always pretend that you need different certificates to sign different kinds of applications. This is basically a scam. Most of the time the certificates are exactly the same, only the file format might differ. Even if the file format isn't supported by your code signing tool, there are ways to convert between different formats. So basically it doesn't matter which certificate you buy.
If you package your AIR app with a captive runtime, you can simply use a self-signed certificate with the adt tool. It's only important to sign the executable created with adt and your installer afterwards. If you create a native installer directly with adt, provide your certificate using the code signing options.
Under Windows, you should use Microsoft's signtool utility to sign the .exe file of your app and your installer if you want to package with a captive runtime. So I'd choose a code signing certificate for Windows. But as I said, it doesn't really matter (and there are cheaper options than Verisign).
Under Mac OS X ("Gatekeeper"), things are a little different. You can only use certificates issued by Apple. You have to enroll in the "Mac Developer Program" ($99 per year) to receive a code signing certificate for OS X. If you use a captive runtime, sign the application bundle created with adt using the codesign utility. If you create a .pkg installer, use the --sign option of the productbuild tool. There's a similar "iOS Developer Program" for iOS apps.
Under Linux, you don't sign packages with certificates issued by a CA. You simply sign them with a GPG key that you can create yourself for free. You have to publish your public GPG key so your customers can make sure that your packages are valid, though.
For Android apps, you can simply use a self-signed certificate, AFAIK.
32-bit and 64-bit apps can be signed in exactly the same way. You don't need separate certificates. But adt will only create 32-bit apps anyway.
Related
I am new for developing CryptoAPI with signing certificate in VB. My old system uses emvtool.exe to sign the certificate with Luna CA3 and HSM. For example, get keys, format data and sign the certificate. I read all the files about CryptoAPI and CSR workflow. I need to redesign the format data and signing parts. I am totally lost on how to use CryptoAPI instead of emvtool.exe.
thanks for any help.
I'm not familiar with the CryptoAPI in Windows, however, I believe if you have the Luna driver installed on the machine, you most likely have a "Crypto Provider" listed in Windows for the HSM. This is useful in interfacing with the HSM when performing some Windows crypto operations. So I'd dig into the CryptoAPI and whenever there's mention of a parameter for the crypto provider, use the Luna's provider.
My company makes a measurement device that connects to the PC via USB and used to use the Windows in-box USB HID driver. I'm using a different driver now to control the device and I am in the process of signing these drivers for many Windows versions. The reason being we want our customers to be able to install our measurement software (which would pre-install these new drivers), plug in our measurement device, and have Windows trust and use our new driver in favor of the in-box USB HID driver. It would also have the added benefit of using this new driver each time the device is connected no matter what USB port is used or if the user connects a unit that has a different serial number in the descriptor.
I've read through and performed the steps outlined in the KMCS_Walkthrough written by Microsoft to perform Test Signing of this driver by creating a catalog file for Windows 7 x64 from the inf file and signing the catalog file with a self-signed certificate. Things seemed to work smoothly on a Windows 7 x64 machine when rebooted into Test Mode. What surprised me was that I was able to create an XP_x86 catalog file, sign it with my test certificate, import my test certificate into the Trusted Root store and get the driver behavior I wanted on a Windows XP machine. The default driver signing policy was set to the default (Warn - Prompt me each time to choose an action).
I'm surprised because all of the MSDN documentation I have been reading about signing drivers for public release for XP seems to have a strict stance on the drivers being WHQL certified in order for the drivers to be fully trusted as opposed to obtaining a code-signing certificate from a third party and using that to sign the driver. Is this not true? How could my self-signed drivers out-rank the in-box USB HID driver in Windows XP?
I think your experience is normal.
At my company, we have distributed USB drivers to Windows XP users and we never had to sign them to get them installed. We later starting signing them ourselves, but that did not really affect the Windows XP user experience.
Our drivers were usually INF-only or they used WinUSB, so that might be different from you if you are compiling binary drivers.
Without a WHQL signature, Windows XP users can still install your driver package as long at they click through this warning:
After the driver package is installed, in my experience there is nothing that prevents the kernel modules it contains from being loaded into the kernel. However, our users always had to go through the "Found New Hardware Wizard" whenever plugging a new device into their computer for the first time.
Perhaps your driver outranks the HID driver because you picked a more specific identifier string (i.e. one with a vendor ID and product ID in it).
For more information I recommend reading my article: Practical Windows Code and Driver Signing.
After A LOT more trial, error, and research, I've finally come to a conclusion.
The key in my initial question was that I was using a self-signed certificate. I generated the self-signed certificate in Windows using makcert and following the example in the KMCS_Walkthrough:
makecert -r -pe -ss PrivateStore -n CN=CompanyName MyCertificate.cer
The parameter which specifies what Enhanced Key Usages (EKUs) the certificate should be valid for (-eku) is not included. What I didn't know was that with this parameter missing, this creates a self-signed certificate with ALL EKUs. Most notably the EKU called "Windows System Component Verification (1.3.6.1.4.1.311.10.3.6)". This EKU is included in certificates for WHQL signing.
So, in fact, Windows XP was behaving appropriately. My driver was indeed WHQL signed, it was just a self-signed WHQL certificate that was used.
Short question:
Does the Windows Store allow applications that obtain DLLs or other low-level resources not packaged at compile time? Is there a requirement either by Windows Phone or Microsoft that requires DLLs to be signed? If so, can I use a DLL in my application that is signed by another developer?
Why I'm asking/explanation:
I'm working an an application for Android that allows users to download extensions (like themes), and I'd like to port this to Windows Phone.
I have determined that it's not possible for my app to utilize libraries or other resources of other applications downloaded from the Windows Store. (Please correct me if this is not always the case)
The workaround I'm considering is an in-app download center for other resources specific to this application. I'm wondering if a downloads for this app, specifically DLLs, can be used in my application. These DLLs would be developed by 3rd party developers, so I see that signing might be an issue.
The store specifically prohibits any additions / modifications after the app has been purchased. So although it may technically be possible, they won't certify it.
This makes sense if you think about certification . If they would allow this, it would make certification a moot point, since you would just publish a basic app, and afterwards side-load the uncertified part.
I read that BlackBerry signing keys can be only installed on one PC.
I'm compiling my Rhomobile Rhodes app on one PC. But the BlackBerry signing keys are installed on another PC. What I need to do in order to sign the app on another PC.
PS: I've set bbsignpwd in rhobuild.yml.
As per Blackberry guideline you have to create build from the PC on which Blackberry signing keys is installed.
Well, its possible to copy signing files from other PC to your PC and use them for signing (of course as long as the users trust each other).
I would like to do Symbian programming with features that require an application to be signed with more then the standard self signed cert. I don't want to pay mony for a cert since I don't know if I will get to a point of selling an application. Is there a way to grant capabilities such as read and write device data to my application for use on just my phone?
If you don't have a Publisher ID the only option for you by now is Open Signed Online.
Open Signed Online allows you to sign an application for installation onto a single device. Unfortunately you will get the signed application, not a certificate itself.
Aside from Open Signed Online, which is pretty hopeless when you want to debug on the device, the only options at the moment are to find someone with a publisher ID to create a developer certificate for you device via Open Signed Offline, or wait for Symbian to come up with another way to get you a developer certificate. They are already planning to make publisher IDs cheaper and easier for individuals to get (currently you need to be a registered company) and wider availability for developer certificates is also on the cards.