I'm actually building several installers for my Java apps and also .Net apps using Advanced Installer. Everything works smoothly right until the popup appeared once the installer -run, "Unknown-publisher".
So I google around, and I found out that I need to use the signtool given. And luckily Advanced Installer has that features, but... why is the output-installer.exe still producing 'unknown publisher' as it was earlier? Am I missing something?
Are you using a self-signed certificate (generated by you) or a certificate purchased from a certified vendor? (Thawtee, Comodo, Verisign, etc...)
To have your digital signature recognized on any Windows device you need to buy a certificate from one of the certified vendors. Self-signed (self-generated) certificates will not help you in this case. (Self signed certificates are useful in other scenarios, but to keep this simple I will not go into details now)
If you have the budget, I recommend an EV certificate, it will save you some trouble with Microsoft's SmartScreen system.
Here is a list of code signing certificate vendors Microsoft seems to recommend.
Related
I provide a java based editor to in internal network of xml editors. Initially it was a plugin, changed to an Applet using jnlp to launch 6 years ago. With the eminent demise of web start I am changing the framework to a desktop Application. The Applet is signed and timestamped as required by all browsers. Once I transition to an installed java application I question whether I need to sign the application jars? The certificate is not cheap and the signing of 30+ jars takes a lot of time. The editor is used on Macs, Windoze and Linux systems. Do I still have to sign it to get it to run? If not what is the downside of not signing, vs the upside to signing?
Desktop java applications don't validate jar signatures. So there is absolutely no benefit to continue signing your jars. Applets are dead (and so is the "sandbox" security model).
I just want to ask that the AndroidKeystore API used for storing keypair is device specific or app specific. I want to ask if two app using the AndroidKeyStore to store their keypair, then the information for both app will go into same keystore or they will have different keystore containers.
Thanks.
The keystore is app specific. You are allowed to choose the same keystore if you publish two apps, or choose a different keystore. Each has different pros and cons. Some of this is explained in the [signing considerations section here].(https://developer.android.com/studio/publish/app-signing.html#considerations)
If you choose the same keystore for your app it makes various things possible, like code or data sharing through permissions. This is only possible for apps signed with the same key.
On the other hand, suppose in the future you want to sell your app to another company. This can happen to small app developers, where another large game or app development company wants to acquire their app (and they can make a lot of money). If you have signed all your apps with the same key it is very difficult, as the large company needs to be able to sign the app they acquired, so you have to give them your signing key. But this makes it possible for them to produce versions of all your apps, which is not good security practice.
If it was me I would:
choose a different signing key for each app
have my app signing done by Google Play signing, then there are no worries if you lose or compromise your key (or keystore password), or if an annoyed employee takes advantage of your trust to abuse your key.
Keystore API for storage is App specific.
Read this...
Use the KeyChain API when you want system-wide credentials. When an app requests the use of any credential through the KeyChain API, users get to choose, through a system-provided UI, which of the installed credentials an app can access. This allows several apps to use the same set of credentials with user consent.
Use the Android Keystore provider to let an individual app store its own credentials that only the app itself can access. This provides a way for apps to manage credentials that are usable only by itself while providing the same security benefits that the KeyChain API provides for system-wide credentials. This method requires no user interaction to select the credentials.
You can read this on the official site https://developer.android.com/training/articles/keystore#WhichShouldIUse
It is Application Specific not a device specific.
In terms of what you do with it for Android and probably what you're looking for since you mention signing apk's, it is your certificate. You are branding your application with your credentials. You can brand multiple applications with the same key, in fact, it is recommended that you use one certificate to brand multiple applications that you write. It easier to keep track of what applications belong to you.
It is app specific. But you can use same keystore for multiple apps.
Important!!!!!! Keep more copies of key file. If your app is pulished on play store and you missed the keyfile, you never able to provide updates for your app.
You need to build apk with same keystore if your app is already live on playstore otherwise google will not accept your build. You need start again from fresh upload with different package name. App with same package name is also not accepted. You will loose all your app’s rating and download figures as well.
myriad java screen captureI have a Java ME application that I need to sign, but I don't know the Certificate Authority (CA) that are supported by the device. I searched and it seems like there is no way to get a list of supported CA from code. I downloaded many signed applications but I wasn't able to install them because the phone does not support the CA they use. I had no luck in contacting the phone manufacturer nor the company that provides the JVM and all the CA want me to pay full price and promise they will give me the money back if their certificate is not supported. The phone I am targeting is a chinese feature phone very popular in India and many other countries. It is running a JVM own by "Myriad". According to my research Esmertec made the JVM then Myriad bought Esmertec. If one of you ever signed a Java ME app that works properly on Esmertec or Myriad Java please provide guidance.
I have an application that is written in Java and is going to be distributed on Mac OS X, Windows, and Linux. Currently, I am packaging the app for each platform as follows (but I'm willing to change it if an alternative is needed):
Mac OS X: Using Eclipse, go to "File" -> "Export…" and choose Mac OS X Application bundle
Windows: Bundle the jar file into an exe file using Launch4j
Linux: Bundle the jar file into an sh file using Jnix
The trouble is, I'm starting to run into problems with my programs not being trusted. Google Chrome reports that beta versions of my app are not from a trusted source and Windows 8 Smartscreen filter does the same. It's my understanding that the only way to get these security measures to trust my app (which will definitely be necessary if I want to distribute it for real) is to have the app signed. However, I'm finding precious little documentation about how to do this and most of it is for one platform (e.g. this tells me about signing for Windows 8).
My question is: is there a way to sign my Java code once and automatically have the executables I create be signed? Or do I have to sign each executable file separately? If it's the latter, is there one code signing authority that I can use or do I have to get it signed separately with different groups?
With the suggestion from ParrotMac, I wound up doing Digicert's livechat and asked some of these questions to "David". Here is what he had to say (edited for clarity):
Do I authenticate the Java code or the end product executable or both?
You'll want to sign the end product.
Do I purchase one certificate and use it for other platforms or do I purchase them separately?
You can purchase a code signing certificate, download it for a platform of your choice (e.g. Java jar files), then re-key it for another (e.g. authenticode for Windows .exes), if you would like. Re-keying is free and you can re-key your certificate for different platforms as many times as you would like as long as the certificate is valid. When you rekey, it does not invalidate your prior certificate, just enables you to download another one for a different platform. The platform you choose for digicert is just the platform it is initially keyed for.
One of my platform targets is Linux. Is there such thing as Linux code signing? Or is it just for OS X and Windows?
You can use the certificate in Linux, you would just use a different tool to sign it than you would for Windows or OS X.
So there you have it. At least from digicert (and I would presume other code authentication companies) you can buy one certificate and use it for multiple platforms at no charge. You then authenticate your end product; authenticating your raw jar file is unnecessary unless you're distributing it that way.
However, I did find out that if you wanted to get past Windows 8, you have to get more secure code signing.
Would code signing work to get past Windows 8's Smartscreen filter?
You would need the EV Code Signing certificate to get past the Windows 8 Smartscreen filter. The EV does cost more, but mainly due to the extra validation that comes with it. You can do the same thing with the EV as you would with the non-EV certificate.
And for good measure, I asked if a certificate was needed if it was being sent to the Mac OS X App Store or other store.
If I wanted to distribute this cross-platform app in the Mac OS X App Store or other store, do I need a certificate? If so, is it the same certificate?
For stores like Google's Apps store or Mac App Store, you'll need to have your software signed by a trusted certificate. But you would want to view that particular stores requirements to determine exactly what you need.
If I lost the original certificate.keystore file created with keytool, but have the exact terminal output and all the stuff I entered to make it, is that enough to be able to create a new certificate that the android market publish site will accept without saying that the new apk must be signed with the same certificate?
This is a MAJOR flaw in the google android market. unlike apple where you can request your certificate with your apple developer account, google has no such service yet. If you loose your certificate, thats it. You will be unable to publish an updated version of your app for people to download.
Best thing to do is let your userbase know there is a new version of the app out with changes that made it impossible to update normally, and they need to uninstall the old version and download the new version, unpublish the old version from the app store and publish the new one. (its a bit of a white lie, but people wont cry too much, and its a lot better than saying you lost the certificate, most users wont even know what you are on about)
Then keep your certificate duplicated for backups and keep it SAFE!!! Email it to yourself, put it on a unnamed flashdrive (incase it gets stolen people wont know what the certificates for). Gmail is good because its easy to retrieve mail from months ago with keywords. Burn it on a CD and put it in your medicine cabinet if you have to.
Hope this helps, good luck
I dont think the generated certificate and the private key will be the same.