We Keep Coding

Windows Certificate Store vs Java KeyStore: which is preferred for java server application?

We have server application developed in Java to which agent connects. We need to secure network connection with Certificates signed by Trusted CAs.
Customers can use their own Certificate Authority to sign the certificates. So we need to add root certificates in truststore. We need to decide whether to use Java Keystore (cacerts) or Windows store.
What is the standard practice?
There are few points to consider
Java do not have standard library to read windows store. We need to use JNI
If we use java truststore then customer will have to explicitly add their certificates
We need to store public certificates and private keys.

lotus notes ssl certificate self signed client no trusted certificate java

I'm currently building a .NET webapi service that is supposed to be used by IBM Notes. The connection in the final product is supposed to be a call from a domino server to the webapi using a java agent over https.
Up until now I've been using http communication between the two, easy enough.
But now I wanted move to https instead, so I created a self-signed certificate and inserted it into IIS using a guide from Jayway.com from Elizabeth Andrews.
After some tweaking I got it working and my self signed certificate is trusted by the os.
The cert is:
SHA512 RSA2048bit
I found this "guide" on how to insert the certificate into the cacerts store in notes:
http://www-01.ibm.com/support/docview.wss?uid=swg21588966
although working on the client and this guide is for server a assumed the jvm would work the same on both.
After this i tried a simple https call inside a java agent in the fashion shown here:
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Connecting_to_a_Domino_server_over_SSL_in_Java_using_a_self_signed_certificate._
Now my problem is that the code works when run as a java project, but when running the code as a notes agent I get this exception:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: No trusted certificate found
If there is anyone who would like to nudge me in the right direction i would be very grateful.

Your Domino server has a directory called names.nsf in which it stores (inter alias) the credentials it trusts. This natively includes the root certificates of the major certificate vendors such as Verisign & co.
Two options here :
- go pro and buy a certificate from a well-known vendor
- or import your own self-signed certificate in the Domino repository.

Can a signed certificate be used without importing explicitly?

I've read a lot of articles regarding the import of a cert, but I am still unclear on a couple things.
When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?
I can install a client cert manually, but there is an expiration date. So I'll need to manage the expiration dates of all client installed certs on our application server, and take an outage to update each one.
It feels like there should be a better way.
Shouldn't the application automatically accept a valid signed cert? [In this case, it is signed by VeriSign]
We are getting an exception currently when trying to access an https url from the application without explicitly installing the cert.
The API proxy library is swallowing the internal exception, so I dont know the details.
If the cert should be accepted automatically, then there may be a different issue here...

Can a signed certificate be used without importing explicitly?
Yes, it does not need to be installed prior to use. In fact, if you know in advance of what to expect, then you can include that information into the application. That has an added benefit of improving the application's security posture.
To avoid importing the certificate, use a custom X509TrustManager and override checkServerTrusted. In checkServerTrusted, ensure the server's public key is expected (i.e., pin the server's certificate or public key); or verify the server's certificate is valid (i.e., is within validity and forms a chain to your trusted root).
When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?
In the case of client certificates, the server advertises the issuer whom it relies upon to issue client certificates. So the server will need to know the trust point for issuing client certifcates for authenticating clients.
In this case, it is signed by VeriSign
This could be really bad. In this case, you will trust all of your clients signed under the Verisign PKI, and all of Verisign's other clients signed under the Verisign PKI.
In this case, it would probably be better to avoid public CAs and run your own PKI (i.e., be your own CA). In this case, pick up a copy of Network Security with OpenSSL. The book will show you how to accomplish the customary tasks using both the openssl command and programmatically.

JBoss/Java and SSL

Hi I'm a bit lost and hope you'll get me out of here. I'll try to be as clear as possible since I don't really understand/know how I should use certificates.
I've got an application that is supposed to communicate with another one using webservices and SSL. We both asked our main "Certificate Authority" to get certificates.
They sent us 4 files and a password for the .P12 file:
.csr, .cer, .key, .P12
Here is what I did :
* Configure JBoss to use SSL on 8443 and used the P12 file as the keystore
To test this I did a small Java class that call a webservices on this server, using :
props.setProperty("javax.net.ssl.trustStore", "/.../.../certif.p12");
props.setProperty("javax.net.ssl.trustStorePassword", "XXXXXXXXX");
props.setProperty("javax.net.ssl.trustStoreType", "PKCS12");
The connection works, but I think I'm missing something as I did not use the other files.
If I send my .P12 file and the password to the application that is supposed to call my Webservices will it be ok/enough ?
Edit :
I forgot to mention that I should call a Webservice on the other application too, so it should be the other way around, do I only need a .P12 and pass ?
I've read a lot of thing about public key, private key, keytool but it's a bit messy in my head right now.
Thanks for any information !

They sent us 4 files and a password for the .P12 file: .csr, .cer,
.key, .P12
Ideally, you should have generated the private key (in .key) and CSR (in .csr) yourself and the CA should have come back with the certificate (typically in .cer) based on the CSR, which you would have assembled together to build your PKCS#12 file (.p12).
At this stage, you can discard the CSR. The PKCS#12 file should now contain the private key, its associated certificate and possibly the certificate chain attached. You could extract the .key and .cer files from that .p12 file later again. I guess you were given all these files because of the way they have been generated (using intermediate files), or for convenience, not to have to convert them yourself.
The Java terminology isn't ideal, but keystore and truststore are two entities of type keystore, but with a different purpose. The difference between the KeyManager and TrustManager (and thus between javax.net.ssl.keyStore and javax.net.ssl.trustStore) is as follows (quoted from the JSSE ref guide):
TrustManager: Determines whether the remote authentication credentials (and thus the connection) should be trusted.
KeyManager: Determines which authentication credentials to send to the remote host.
The javax.net.ssl.trustStore* properties are one way of configuring the TrustManager. The javax.net.ssl.keyStore* properties are one way of configuring the KeyManager.
Typically, there is no need for private key material in a trust store (unless you also use the same as a keystore). It's often better to use a separate truststore, which you'd be able to copy freely across machine, without worrying about leaking private key material.
What would make sense would be to build a new keystore (JKS) that you would use as a truststore, using the CA certificates (not sure if you've been provided with them).
You're not doing mutual authentication by setting the truststore only (there are no default values for the keystore, so they need to specify these parameters explicitly). If you want to use your client-certificate to connect to a remote party, you need to set it in the keystore (for example, using the javax.net.ssl.keyStore* properties in the same way you've done it for the trust store).
You could point both the keystore and truststore to the same .p12 file. The side effect is that other connections made by your service to other places (e.g https://www.google.com) would not be trusted, since it wouldn't contain the CA for those. That's why it might be better to create a separate "truststore keystore" (JKS might be easier) for the CA certificates. You could make a copy of the default cacerts (in the JRE directory), import your CA's certificate into it and use that.

I've got an application that is supposed to communicate with another
one using webservices and SSL.
Ok, stop here. Communicate how? I mean is it only server authentication i.e. your client application will authenticate the web service or mutual authentication and the web service will also request your applications certificate?
This is important as the files you present by the names seem to suggest the latter i.e. that mutual authentication is expected while your code you show is only setting SSL library for server authentication.
Since you are not providing context here I would say that:
.key has your private key
.p12 has your private key along with your signed certificate or perhaps the CA's root certificate (?)
cer could have your signed certificate or perhaps the root's CA
signing certificate that is considered as trusted in the domain and
has probably also signed the web service you want to communicate with
certificate (well that is a possibility/guess here since you don't
say much)
csr is your certificate signing request
I did a small Java class that call a webservices on this server, using
What you do in the code is setting the p12 as the truststore.
If you say this works then there is no mutual authentication only server side authentication and you are authenticating the web service using whatever is in the p12.
In this case the rest are not needed for communication.It is for you to keep especially the key file since this could be your private key and if you lose/someone steals this then your private certificate is useless/compromised.
I am not sure what your requirements on security are here, but it seems to me that you should probably look into it more.
Even for this question I just tried to do an educated guess based on the file names.....
I hope this puts you in some track to read.

Enabling https for Java Webstart

I have a swing application deployed in HTTP Server. Users use the browser to point an URL and install the client using java webstart. Now I need to enable https access to my application deployed on HTTP server. I am using JDK 1.5 as default jdk supported in the jnlp file. For time being I use a self signed certificate to the sign the jars (by default created using Sun's jarsigner, keytool, etc, utils).
Solution/steps would be much appreciated.
Thanks in advance
Ramesh

As far as I understand your question you don't need to change anything to your code of the client. If you only want to give access to the JNLP via HTTPS you would only need to reconfigure the application server distributing the JNLP or if you have a webserver in front of the application server (as we do here: user - https -> apache -> AJP -> tomcat) you need to reconfigure the webserver to allow the access to the JNLP via HTTPS.

You need to enable HTTPS on the web server. To get the certificate you need to provide credentials and the host name of the server to a certificate authority (CA) like VeriSign or Thawte. They can provide you with a server certificate signed by their root certificate or some intermediate certificate. This certificate must then be imported into the web server to enable HTTPS over SSL. The web clients, like a browser or webstart will then verify the certificate chain when accessing the server.
If you use a self signed jar, all your users will be presented with a warning message about potentially unsafe code. To avoid this you should get a code signing certificate from a CA, which would be somewhat similar to the web server certificate. This CA-provided certificate can be imported into the keystore and used in the same way you use the self signed certificate. The code signing certificate will be signed by the CA so that the certificate chain can be verified by webstart.

What is the feature of https that you are hoping to leverage?
The signing/server authentication is done by code signing, though you are undermining this using a self-signed certificate.
Does your application code contain secrets that must be hidden from eavesdroppers?
As you say you "need to enable" there must be an underlying reason.
I believe that before you "need https" you need a proper code signing certificate. You might want to rephrase your question so that your underlying problem can be solved instead of the very specific question.