-1

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 !

Michael Laffargue
  • 10,116
  • 6
  • 42
  • 76
  • You might want to read more about the difference between keystore and truststore, for example [here](http://stackoverflow.com/a/6341566/372643). – Bruno Feb 10 '12 at 17:52

2 Answers2

2

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.

Cratylus
  • 52,998
  • 69
  • 209
  • 339
  • Thanks for the comment, after more reading it becomes clear that I should use mutual authentication. I found this interesting link https://community.jboss.org/wiki/SSLSetup (Chapter 2), but they start creating public/private key pair. Having already a .key file with my private key I don't really know how to create the associated public key, if that's the way of doing thing. – Michael Laffargue Feb 13 '12 at 15:06
  • Your public key is in your certificate – Cratylus Feb 13 '12 at 15:41
2

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.

Bruno
  • 119,590
  • 31
  • 270
  • 376
  • Thanks a lot for this comment, it helps a lot. If I go with the "keystore and truststore being the .P12 file", I'll have to give it to the client with the .P12 password ? Isn't it a bit dangerous as the .P12 file contains the private key ? – Michael Laffargue Feb 13 '12 at 15:02
  • Indeed, you would have to give them the password (and thus the private key): something you should avoid, of course. I would suggest building a separate JKS store, with only the CA certs (not your cert or its private key). I doubt those certs are in your `.cer` file (it's probably only your cert, without the chain), but the full chain might be in the `.p12` file. You should also be able to get the CA certs from the CA itself quite easily. Then, import it into a new keystore using `keytool -import`. – Bruno Feb 13 '12 at 15:17
  • Thanks a lot, I did a lot thing after reading your response, but it gave me the good way. – Michael Laffargue Feb 14 '12 at 15:52