ansaurus

Question

Keytool create a trusted self signed certificate

Answer 1

A:

I don't get it. Are you using the server key store with the client? What is your use case exactly? Are you trying to setup mutual authentication?

If yes, you're on the wrong path here. You'll need a client key store (for the client's self-signed certificate and private key) and a client trust store (for the server's "stand-alone" self-signed certificate i.e. without its private key). Both are different from the server key store.

Pascal Thivent 2010-02-04 14:44:16

I thought that I could use the server's keystore with the client for testing. This would ensure that the client has the servers certificate. Although maybe the client does need its own self signed certificate...

sixtyfootersdude 2010-02-04 15:00:57

AS I said, it depends on what you want to do (which is not clear to me). If you want to implement mutual authentication, the client needs its certificate too. And in that case, I don't think that you can use the server key store as client trust store.

Pascal Thivent 2010-02-04 15:42:07

Answer 2

+1 A:

You would need to "establish trust" between your server and client (I'm assuming you only need to do server-side authentication). This is because you use self-signed certs. That involves importing your server's cert into the client trust store:

On the server side:

keytool -keystore <keystore file> -alias <alias> -export <certfilename>.cert

Copy the .cert file over to the client side and then:

keytool -keystore <truststore file> -alias <alias> -import <certfilename>.cert

Armadillo 2010-02-04 15:28:28

+1: Thanks for the clear answer. I am pretty sure that this what I am doing **Except** I am setting both the client and the server to use the same keystore file. Ie: server.keystore. I beleave that the keystore can act as both a keystore and truststore. I am using mine to be both the server's and the client's keystore and truststore. Is this legal?

sixtyfootersdude 2010-02-04 16:50:26

I haven't tried that configuration myself but it *may* work. You would have to use different aliases for the key material and the cert as they serve different purposes (and both have to be there). It seems that you are aware that this setup is only good for testing purposes and not production...

Armadillo 2010-02-04 17:05:56

Meaning that I would have to have one trustedCertEntry and one privateKeyEntry in my one .keystore file? If I continue to have problems I will try to create a separate .keystore file for the client. Thanks for your assistance.

sixtyfootersdude 2010-02-04 17:35:31

Armadillo, Thanks for the feedback, I added an update in the question. I think it is better to move to a simpler configuration (one keystore for server, one truststore for client) as you suggested. However I am still getting the same exception. Maybe now that I have a clearer example (above) it will be easier to identify my problem.

sixtyfootersdude 2010-02-04 18:41:19

Not sure this is the actual problem, but you have clientAuth="true" in your 8443 port connector. That would require trust to also be established in the other direction (client -> server). Your 443 port does not have that. Which is your requirement?

Armadillo 2010-02-04 19:03:38

Hi Armadillo, I changed that to false but I still have the same exception. Thanks for the pointer

sixtyfootersdude 2010-02-04 19:26:00

OK. So can you post your client code so that I can take a look?Also, can you point your browser at the same port? What do you get? (you should be able to query for the WSDL of your web service)

Armadillo 2010-02-04 19:43:01

You question lead me to an interesting observation. My client was attempting to access: https://sco-up:443/common/ws/A2. But I was curious if that was the problem. I changed that address to https://sco-up:443/asdfasdhahdhadsfkjlasd (ie garbage). And I got the same exception. This seems very odd to me. Going to look into this.

sixtyfootersdude 2010-02-05 14:19:48

In response to you question if I navigate to https://sco-up:443/common/ws/A2 in a browser I get plain text: "HTTP GET not supported". (Which I think seems logical). If I navigate to https://sco-up:443/asdfasdfkd/asdfads: I get some kind of html table with title: "HTTP Status 404 - /asdfasdfkd/asdfadsf".

sixtyfootersdude 2010-02-05 14:22:55

How should I be able to query the WSDL for web service? Should I be able to do this even if it is in httpS ? Thanks and happy friday.

sixtyfootersdude 2010-02-05 14:24:11

Actually, I was making a dumb mistake. I was not restarting my server properly so it was not rereading the keystores. Thanks for all the help have a great weekend.

sixtyfootersdude 2010-02-05 21:44:39

Answer 3

+1 A:

You mustn't do that. A keystore is strictly private. If you leak it to anybody you have fatally compromised security. There is no point in doing this kind of thing just to get it working, because it isn't working - it is just a security breach. You have to do it right: export from the server's keystore into the client's truststore, and from the client's keystore if any to the server's keystore.

EJP 2010-02-15 02:19:04

ansaurus

tags:

views:

answers:

Keytool create a trusted self signed certificate

Update

Update

related questions