I have Vaadin application and my applet which integrated in it. When I start my web application every time i see this warning.
In turns when applet begins to start. After I push run and click button on web application to start applet turns new warning.
My boss told that it is ridiculous to show web app with that warnings. But i don't know how i have to sign my applet to turn off this warnings.
Now i sign my applet with this instruction. It will be nice, if you will help me.
In order to get rid of this warning you're going to have to sign your applet.
By default an Applet is running inside a sandbox. This sandbox isolates the applet preventing malicious code from running without the user's granted permissions. Applets are considered untrusted if they are not signed with a security certificate. Unsigned applets are limited to execute only a set of "safe" operations. Unsafe applets cannot execute the following:
Accessing the local file system, executable files, system clipboard,
and printers on client’s computer.
Connecting to any server other than the server where they are hosted.
Loading native libraries.
Altering the SecurityManager.
Creating a ClassLoader.
Reading some of system properties.
In order to sign your applet you'll need to purchase an RSA certificate from a trusted source. You can purchase for RSA certificates from a Certificate Authority (CA), such as VeriSign and Thawte. To obtain a certificate from a CA, you need to provide the certificate signing request (CSR). The steps are as follow:
Use keytool to generate an RSA keypair.
Use keytool to generate the certification signing request, then submit the CSR to the CA.
The CA will send you a certificate reply (chain) by email.
Import the chain into your keystore.
Use jarsigner to sign applet’s JAR file.
Once you have everything all you need to do is sign the JAR with your certificate and you should be good to go. To sign the JAR just do the following:
jarsigner -keystore <keystore_name> -storepass <store_pass> -keypass <key_pass> -signedjar <signed_jar_file_path> <original_jar_file_path> <alias_name>
Related
I bought a COMODO code signing certificate and used it to sign my java webstart application.
Main question: Is that COMODO code signing certificate even supported by java 8?
More info:
On all machines except my own, java blocks the application, saying it uses a self signed certificate.
I don't even understand why it works on my machine. I looked at the list of trusted certification roots in the java control panel (1.8.0_45-b15), but I cannot find the "COMODO RSA Certification Authority" there.
I do see that certificate in the Windows MMC certificate snap-in under "Trusted Root Certification Authorities". But on at least 3 other machines it does not exist.
I finally solved it - here is the story:
When I bought the certificate, I had to collect it by navigating to a website address that I received by email. There, the certificate was automatically installed into the truststore of my browser (Firefox).
I then exported it from Firefox (Options - Advanced - View Certificates - Your Certificates - Backup button).
What I didn't realize at the time was that Firefox, unlike Java and Windows, has the "COMODO RSA Certification Authority" as an inbuilt token:
What I also didn't know at the time was that the Firefox certificate export seems to only include the certificate chain up to the first trusted authority, in this case the "COMODO RSA Certification Authority".
From this COMODO support site I learned that the chain should actually go one higher, all the way up to "AddTrust External CA Root":
That sounded much more promising, because the AddTrust certificate is actually included in Oracle's java 8 cacerts truststore, which is responsible for verifying the jar during java webstart.
The next thing I did was import the *.p12 file I got from Firefox into the windows certificate manager (Start - certmgr.msc), because for some reason I thought this was the way to convert *.p12 to *.pfx (although now I know that both extension are used for the same pkcs12 keystore format). Anyway, during the import this question popped up:
Here I made the critical mistake: I clicked yes. This caused the "COMODO RSA Certification Authority" to be installed in the Windows truststore as a "Trusted Root Certificate" (btw only visible after I restarted certmgr.msc):
My code signing certificate was installed in "Personal/Certificates". I exported it from there (Action - All tasks - Export...), and marked "Include all certificates in the certification path if possible".
Now the exact same thing happened as when I exported from Firefox. Since Windows now had "COMODO RSA Certification Authority" installed as a trusted root certificate, it only included the chain up to this one. This is what I got after the export:
And now for the genius move, which I stumbled upon by pure chance: I deleted the "COMODO RSA Certification Authority" from the Windows certification manager. Now, when I double clicked my code signing certificate, the displayed chain suddenly looked different:
I admit I got a small adrenaline rush when I saw this. I exported again (exact same settings as before).
And indeed, after I signed my application with this exported certificate, java webstart accepts it:
UPDATE: This was a JRE release bug. Comodo's new CA certs were added to the default keystore in Java 8u51.
An answer to another question which while somewhat out of place there seems very on topic here:
You can tell if a CA's certs will work for Java code-signing by
examining the Java cacerts file, which lists all the CAs known to
Java. If their cert is in this file, then Java will not complain about
the signed code. If it isn't, then it will warn the users. For
example:
root#girflet:~# keytool -list -keystore
/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/security/cacerts | grep
comodo
Enter keystore password: changeit
comodoaaaca, 02-May-2006, trustedCertEntry,
Note that I had to enter the default keystore password, changeit.
This command should work on Windows as well, although you'll have to
change the path to the cacerts file and you won't have grep. Use more
instead and page through until you find or don't find what you're
looking for.
As of today, Comodo is in the cacerts file, and startssl aren't. So a
startssl cert wouldn't be much good for Java code.
Source: https://stackoverflow.com/a/1906679/154527
I can give you a conditional answer.
On one of the computers that doesn't like your certificate, go to http://jonathancrosmer.com/software/invadeearth/
and click Invade Earth.
This program uses a Comodo certificate. I built it against Java 7, but if your computer has only a Java 8 runtime it should still work.
1. If you get the same warning, you know it is a Java 8 issue.
2. Otherwise, you know something is wrong with your certificate.
Either way, you'll probably want to get a refund from your certificate issuer, since they advertise that their certificate is trusted by Java.
I currently have a website hosted with Hostgator that has a java upload applet; however, on page visit, the browser blocks the java applet from executing. Reason given is security settings have blocked a SELF-SIGNED application from running.
My question is, how can I get past this, WITHOUT modifying java security levels. I want users to be able to access the applet without getting this error AND without having to modify any of their current browser settings.
(I signed the applet myself using keytool).
Thank you.
There are two ways:
You need to buy a SSL certificate from a trusted party like Verisign or Thawte, or any other (cheaper) trusted provider. Then you need to sign your applet with this certificate instead. Since such certificate will be provided by a globally-trusted party, your users' JVM will automatically trust it.
If you decide to go with the cheaper ssl provider, make sure it's root certificate is in the default list of trusted certificates of the JVM. You can check that, by listing certificates, that come with the installation of Java - like this:
keytool -list -keystore cacerts -storepass changeit
where changeit is the default cacerts keystore password, and the cacerts file can be found in lib\security folder of jour JRE installation - on Windows this will be something like:
c:\Program Files (x86)\Java\jre[version]\lib\security\
Send the public key to your users, and make them add it to trusted certificates of their JVM (usually that means, importing the certificate you provide to the aforementioned cacerts file. This step however requires using keytool and command line and will most likely be troublesome for most of your users.
Some quick background on what I'm trying to do: a client is using a third party web service that requires mutual authentication. The service requires the client certificate be signed by a public certificate authority (ie: not self-signed). The client has some software written in Java that connects to the service, hence they used Java keytool to generate the original signing request and the key/certificate are stored in a jks keystore.
Our software that the client is going to be using is written in C#/.NET and will need to connect to the third party web service. As such we will we need to be able to access the client certificate.
I can't seem to find any way to export the certificate (along with private key) to either the Windows Certificate Manager or some other format that can be opened by .NET security libraries.
Exporting to a PKCS12 file does not work because keytool does not support it for trusted certificates (not sure if that is a keytool limitation or a limitation of the format).
I also found some Java code for getting the private keys, but I can't seem to figure out how I can get that into Windows Certificate Manager and associate it with the certificate. (How do I list / export private keys from a keystore?)
As a side note, the client doesn't want to generate a new certificate as there is a whole process involved in sending it to and getting it approved by the third party service they are connecting to.
Ultimately I'm hoping there are some commands I can run with keytool/openssl/etc that will allow the certificate & key to be exported/transferred into the Windows Certificate Manager (or some format that it can import).
(Sorry if my terminology is off or if some of this doesn't make sense. I kind of got stuck supporting this despite not being all that familiar with managing certificates.)
This seems to work for exporting the certificate but not the entire chain, the trick is to specify the srcalias:
keytool -v -importkeystore -srckeystore .keystore -srcalias mykey -destkeystore myp12file.p12 -deststoretype PKCS12
Thanks to Warren for pointing me to this: How to export private key from a keystore of self-signed certificate
I have never done https so far, but trying to get grips with it. I understand how to do self-signed certificates which is from what I understood is completely pointless as browsers will fire up straight away the warning. "As one cannot say trust me because I am honest."
From SO posts I understood that Tomcat or any other server environment is responsible for configuration. All clear and good.
The confusion is how these certificate signed when not self-signed. In other words, how do I point my keystore to CA provider.
I am following guide:
http://consultingblogs.emc.com/richardtiffin/archive/2010/10/15/applying-ssl-to-a-spring-web-application-on-tomcat.aspx
The problem is that I don't know what happens after I buy certificate from CA. Do I get a file which I need to point my keystore to or I import keystore itself remotely?
For self-signed we do:
"
Generating a keystore file (Self Certification)
The keystore file is the one which would store the details of the certificates necessary to make the protocol secured, to-do this we'll use the keytool provided as part of JDK 1.6, the following should create the keystore :-
From your Java installation directory %JAVA_HOME%/bin
keytool -genkey -alias emc -keypass password -keystore emc_tomcat.bin -storepass password"
This implies that for not self-signed the details must come from CA provider? So need to add something to the line(URL path?)? Or is it the client responsibility to verify whether my certificate is valid...then how do I link my certificate to the one I purchased. I am completely confused.
Rephrasing other way: how to install CA from official CA providers?
Or I am telling complete rubbish and missing something fundamental. :-)
My apologies if there is duplicate, I've spent quite good bit of time of researching SO and reading wikipedia articles, but the internal mechanics are very difficult for novice users. I've marked bold the actual questions for people short on time. Thanks.
All the information you are asking for is readily provided by any reputable ("trusted") CA. See for example http://www.digicert.com/ssl-certificate-installation.htm
Quoting:
After you create your CSR, purchase your certificate, and the SSL
Certificate validation and processing are complete, you are ready to
install your SSL Certificate(s).
Your certificate will be provided via email or will be available to
download in your DigiCert Management Console. The SSL Certificate is a
text file with encrypted data that your server will use once the
certificate is installed
And following down the Tomcat link:
Tomcat SSL installations can be a bit tricky, but don't worry. Our
knowledgeable support staff is familiar with both the keytool utility
as well as common Tomcat installation methods. We will be happy to
help you generate your Certificate Signing Request (or CSR), install
the certificate to your Java keystore, and configure your server to
use it via either the Tomcat Admintool utility, or by editing the
server.xml configuration file directly.
It seems that this answers all your questions... "buy it and you will see how easy it is".
I'm trying to use Amazon S3 and Amazon Cloudfront CDN to deliver the jar files of my applet application.
I'm seeing several cache misses of my jars by the java plugin. This is a show-stopper for me, as the size of my application is around 3Mb, and I can't make my customers re-download the application every time.
The problem is that, due to a "security vulnerability issue" the java plugin cache is resolving the IP address of the jar remote host, but Amazon S3 uses a dynamic IP. I guess the same problem would happen with Akamai or any other decent CDN service.
Is there anything I can do?
Well the address has to be resolved at some point, that’s not exactly the problem.
The problem is that the applet wants to make sure the .jars come from the same source as the page holding the applet to make sure nobody is returning malicious jars instead of the originals. But when the sockets are opened using the URL it is resolving to a different address, yes, because you are using a cloud not a single server.
Im sure you can solve it by signing the .jars. That way the applet knows they are originals, no matter the source.
What I do is that I create a certificate manually. Like thie:
keytool -genkey -keyalg rsa -keysize 1024 -alias {put a name for the cert here} -validity 3650 -keystore {.. and a file name here.}
Note this will prompt for you to set a user and password for the certificate.
Then sign ALL your jars like this ->
$1/jarsigner -keystore { the above file name} -storepass password -keypass password whatEver.jar {cert name, from above.}
The only issue I have seen with this method is that since the cert is not signed by a recognized authority in the browser, it will promopt the first time to add it to the trusted certs. Normally not an issue.
Other wise you can:
1) Get a certificate from a recognized authority in the browser (Thwate, Verisign ) ( There are some that will do it for free)
2) Set up an authority and ask your users to add it into the browser's recognized authorities.
Hope this helps!
-Alex