We Keep Coding

Configuring Certificates in Server

I am very new to webservice and configuring certificates. I have roughly gone through PKI concepts. Below are come basic questions I have
1) I have certain certificates which i use in my code to Sign the XML elements,
What is the need to add these certificates to in the cacerts file under lib/Security of JRE
2) what is the use of this cacerts file.
I use weblogic server with jockrit jre
Do let me know , if there are some sites to learn the above concepts

2) what is the use of this cacerts file.
cacerts is the default trust store of your JRE. It contains the root certificate of Certification Service Providers that JRE manufacturer considers to be trusted. Cacerts is checked by default TrustManager to verify if a certificate has been issued by some of this CSP's, for example when you invokes a third party service using SSL/TLS, the server certificate is validated
1) I have certain certificates which i use in my code to Sign the XML elements
You do not need to add anything to cacerts. But if you use a self-signed certificate you should provide the public part of your certificate to the receivers in order they can verify the signature.

Java webstart says my app uses a self signed certificate, but I used a COMODO code signing certificate

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.

Sign java applet for work without java warnings

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>

How to connect with CA to sign ssl 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".

java plugin cache and dynamic IP host

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