I created an application which is currently on Android market. The key used to sign the application was made using jarsigner. How do I sign using the .key file originally generated?
You will need the original private key that you used to sign the first version.
Full information is available here, but here is the excerpt it sounds like you need:
Application upgrade – As you release
updates to your application, you will
want to continue to sign the updates
with the same certificate or set of
certificates, if you want users to
upgrade seamlessly to the new version.
When the system is installing an
update to an application, it compares
the certificate(s) in the new version
with those in the existing version. If
the certificates match exactly,
including both the certificate data
and order, then the system allows the
update. If you sign the new version
without using matching certificates,
you will also need to assign a
different package name to the
application — in this case, the user
installs the new version as a
completely new application.
AFAIK, .key is not a standard (conventional) file ending. Most of the time you are working with a .keystore file. The keystore contains the key. The keystore and the key both have passwords and separate security measures for safety.
If you generated your ".key" file using jarsigner and one of the commands listed here, then you likely created a keystore file and happened to give it the ending ".key" If this is the case, then just compile your application into release mode, sign the application using the jarsigner tool, and use zipalign (not sure what this is for, compression perhaps?).
If you don't have the original keystore and key file, then you're boned. Sorry :/ Tons of other info can be found on the Signing Your Application page
HTH,
Hamy
Related
On my java application, that runs on Tomcat in a RedHat linux machine, I need to send a request to an API that uses ssl trust certificate. Our partners have already sent us two files that should be used to trust them: wse-tst_partner_com.crt and DigiCertCA.crt.
Our partners have sent these instructions: https://www.digicert.com/csr-ssl-installation/apache-openssl.htm#ssl_certificate_install
However, I'm stuck on step 2, since I didn't find an httpd.conf file, neither apache2.conf file. I wonder if these are not applicable to Tomcat (they didn't actually know what we have before creating the API and their security stuff).
I've also tried to look for installing trust certificates for Tomcat, but the instructions I've found were only to create a new certificate with keytool - I don't want to create a new certificate, I need to "trust" the ones our partners already created.
I've also found this question on serverfault. However, I don't have any .pem files, and I don't want to create new files - I just want to use the ones I mentioned on the beginning of this post.
I'm a noob in this subject - I don't think this should be a complicated task... Should I add something to my server.xml file? Or, maybe I'm looking for the conf files in the wrong place?
httpd.conf and apache2.conf are apache files not tomcat.
They assumed you were using apache instead of tomcat.
Either put an apache in front of tomcat and use that guide or create a keystore with keytool (A keystore is "like a box" containing the certificates) and add the certificates you were provided inside, you will need to add the intermediate and the root as well. And then configure tomcat (listeners, connectors) to use that keystore.
Follow the steps from this guide instead https://www.digicert.com/csr-ssl-installation/tomcat-keytool.htm but ignore the creation of certificate as the certificates are already provided. Make sure you have the key as well, otherwise you'll have to create the CSR in the server and provide that to whoever signs the certificates (your partner I guess) and they will get back to you with new certificates. Incorporate the certs to the keystore as suggested.
I recently joined a project that has an application running in Tomcat that uses a single file as both the KeyStore and the TrustStore. In other words, it includes both entries of types trustedCertEntry and PrivateKeyEntry.
While upgrading from Tomcat 8.5.6 to 8.5.20, I realized catalina.out was giving me
java.lang.IllegalArgumentException: java.security.KeyStoreException: Cannot store non-PrivateKeys
The solution was to make to remove the trustedCertEntry entries from the keystore.
To me, this seems fairly obvious that you would want to keep these separate. My question is, are there any possible security consequences to using the same file as a keystore and truststore? If so, why does Java (or SSL) allow these to be kept in the same file?
SSL and TLS are interoperable protocols; by IETF policy and tradition they say nothing about storage of anything and everything at either or any endpoint. "That's a local matter."
Java historically used one file format (JKS) for both TrustedCert's and PrivateKey's, not only for SSL/TLS but for all public-key crypto (and optionally with JCEKS some symmetric crypto also), and Java9 is switching to PKCS12 for both. Using the same format doesn't mean you must use the same file, and I would say it's preferable to use separate files, but I don't see an actual security problem in using a single file as long as you keep any file containing a privatekey restricted to one system, or as few systems as absolutely necessary, plus appropriate backup; however that's not really a programming Q and you might try for better answers on security.SX.
Tomcat 8.5 sorta-kinda combines the previously separate and (often confusingly) different config for Java-JSSE and APR=OpenSSL stacks, and I believe this restriction that the keystore can only contain PrivateKey's is a result of that change.
I have a working applet and I am trying to add it to my website for my portfolio. My problem is I can't get the applet to run without adding the directory (I'm running it locally for now) to the site exception list. my applet code is as follows:
<applet code = "myTetris.TetrisApplet"
archive = "myTetris\jar.jar"
height = "400" width = "200">
I have created a jar file using IntelliJ IDEA. The manifest is as follows:
Manifest-Version: 1.0
Permissions: sandbox
Application-Name: Tetris
I have signed the jar file.
Since Java 7 update 51 Java Web Start applications and applets need to be signed and must have a permission set in the manifest. You have done both correctly. However, the certificate you used for code signing, was probably a so-called self signed certificate. As the identity of the signer cannot be verified, such certificates are not trusted by browsers, operating systems, and the Java Runtime. To fix this, you would either need to import your certificate into your system and trust it, or you would need to obtain (buy) a certificate that was issued by a trusted authority. Some organizations offer trusted certificates for open sources projects.
We have been using a java applet from a 3rd party vendor for years. The vendor no longer exists. The certificate is expired and java is showing a warning message every time users access the applet.
Is there some way to mark the certificate or the JAR as being trusted so it doesn't keep warning users?
Get yourself a new code signing certificate and sign the JAR file(s) yourself.
In Eclipse EE 3.7, I've installed the JavaFX SDK and created a JavaFX Project. When I open the build.fxbuild file and select the Build Properties tab, there's a section titled Signing Properties. And it asks for the following information,
Keystore
Store-Password
Alias
Key-Password
For the Keystore field, it provides options for browsing the filesystem and workspace, but I don't know where to locate the keystore. Can anybody help me figure out how to do information signing via an Fx Build Configuration file?
For many applications (for example a standalone application), code signing is simply not required - it can introduce complications and can degrade performance and user experience. Code signing is only required for WebStart and Browser Embedded applications which require resources outside of the Java sandbox. If you are certain you actually need to sign your application, then continue reading.
Here are the steps to create your own keystore for signing using the java keytool. For test purposes you can generate your own self signed certificates. For a real application deployed to the general public which minimizes security warnings, it is best to purchase a code signing certificate.
An example commmand line for creating a keystore to be used for code signing is:
keytool -genkey -alias signFiles -keystore examplestore
You will be prompted to enter passwords for the key and keystore.
The JavaFX deployment packaging documentation has information on how to sign applications via the standard JavaFX SDK. You could just follow that description and sign your jars using, for instance, the JavaFX ant tasks.
However, it would seem that Eclipse has some inbuilt functionality for doing the signing. If you want to take advantage of that, follow the instructions above to create your keystore. After you have an appropriate keystore, enter the values used in creating the keystore into the appropriate fields for the Eclipse IDE to perform the signing.
Matching the fields up with the example command line for keystore generation I provided earlier.
Keystore - file location of the keystore containing your signing key: examplestore
Store-Password - password you assigned to access the keystore
Alias - friendly name to refer to the key: signFiles
Key-Password - password you assigned to access the key in the keystore
Although there is a default keystore provided in the Java JDK installation directory, this is not usually the same keystore which would be associated with your own signing keys and certificate. The keystore provided with the JDK is primarily used to store certificates for certificate authorities used in validating SSL connections. As the java keystores produced by a given jdk vendor follow one generic format, you could also use it for storing signing keys and certificates. However, I would not advise this and would instead advise creating and using your own keystore. Generally you want to keep the keystore containing your code signing keys separate from other information, backed up and very secure.