Home.... | log in.... | Pub my question! | Sign-up....

Java-index >> Security >> Java Secure Socket Extension (JSSE)

need some help..Newbee

what is the difference by seting the keystore, trust store with the System.setProperty() or by creating them as....

KeyStore ks = KeyStore.getInstance("JKS");

ks.load(new FileInputStream(keystore), keystorepass);

KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");

kmf.init(ks, keystorepass);

is it that u create ur own keystore/ truststore if u require to store new certificates through coding.................

can u tell me that which implementation should be used and when?

[533 byte] By [Deo_Zonea] at [2007-11-26 20:52:16]

«« Problem with ClassPath
»» SocketOutputStream.socketWrite0(Native Method)

# 1

Use the system properties unless you have a good reason not to.

ejpa at 2007-7-10 2:17:36 >

top of Java-index,Security,Java Secure Socket Extension (JSSE)...

# 2

u mean use the default sslcontext.

but if there is a condition where a new client connects wo the server, and its certificate entry is not in the trust store...... then how will it be added ....is it that i need to create a trust manager then so that i can configure it to add new entry or either i can do that with out creating one

Deo_Zonea at 2007-7-10 2:17:36 >

# 3

(a) The client certificate is only required if you have set needClientAuth=true at the server.

That would be a reason for not using the system properties.

(b) If the client certificate isn't in the trust store why would you want to add it? Are you interested in security or not? If not, why use SSL at all? if you're just going to trust any client?

ejpa at 2007-7-10 2:17:36 >

# 4

sorry 4 my silly questions....

i have setNeedClientAuth=true on my server side

i had a confusion on which implementation to use .... at the moment as i have used self signed certificates i have created a trustmanager 2 accept it. i guess thts the reason why i have used the 2nd implementation by creating the truststore.....

otherwise is it ok if i use the SSLSocketFactory.getDefault to create the sslcontext and set the system properties for the keystore and trust store.........

both are working at the moment.

Deo_Zonea at 2007-7-10 2:17:36 >

# 5

You're embedded in a contradiction here. You want the clients to authenticate themselves by providing their certificates, and you also want to accept any certificate the client sends you.Why bother?

ejpa at 2007-7-10 2:17:36 >

# 6

no i just want 2 have the client authentication the reason i had constructed the trust store was that i was recieving an error as im using self signe certificates so for the time being i had just created that to handle the situation....

sorry i guess i did'nt specify the problem clearly b4. All i want 2 ask is that if i want client authentication then is it right to use the default sslcontext using the system property because in the JSSE refrence guide it says that "The default factory is typically configured to support server authentication only "

Deo_Zonea at 2007-7-10 2:17:36 >

# 7

That statement in the JSSE Reference Guide doesn't make much sense, as there is nothing the SSLSocketFactory or an SSLSocket can do about client authentication: it's configured at the server.

However the answer to your question is 'yes', you can use the default SSL context along with needClientAuth=true at the SSLServerSocket.

ejpa at 2007-7-10 2:17:36 >

# 8

i want to know if there is client authentication is taking place or not.... i have debugged both the client and server programs but now i dont know how to verify it. is there some sort of message printed in the debug that tells when client is sending its certificate?

Deo_Zonea at 2007-7-10 2:17:36 >

# 9

Certainly. The server will send a Certificate Request and the next message from the client will be a Certificate message.

But if you have needClientAuth=true the handshake won't succeed unless the client is authenticating itself successfully, so if you can send and receive data it's all happening: no news is good news.

ejpa at 2007-7-10 2:17:36 >

# 10

well its some thing like this.....

after sending the certificate request is the next data from client or is the server sending some info....

]

***

*** CertificateRequest

Cert Types: RSA, DSS,

Cert Authorities:

<CN=xxxx OU=home, O=home, L=xxxx, ST=xxxxx C=xxx>

*** ServerHelloDone

Thread-0, WRITE: TLSv1 Handshake, length = 769

Thread-0, READ: TLSv1 Handshake, length = 714

*** Certificate chain

chain [0] = [

[

Version: V1

Subject: CN=casper, OU=home, O=home, L=xxxx, ST=xxxx, C=xxxx

Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

Key: Sun RSA public key, 1024 bits

modulus: 114853966683034469378815389355517833489580875214163953468754623516418342361734698294719709847790412703863840235375913044

1554724665030679409774338011969263884881411578710691774580063423

public exponent: 65537

Validity: [From: Wed Jan 10 13:21:30 GMT 2007,

To: Mon Mar 26 14:21:30 BST 2007]

Issuer: CN=casper, OU=home, O=xxxx, L=rxxx, ST=xxxx, C=xxx

SerialNumber: [45a4e85a]

]

Algorithm: [MD5withRSA]

Signature:

0000: 96 9A C8 32 77 85 97 BAA6 AA 92 D5 06 C6 C8 0F ...2w...........

0010: D3 B1 AF D9 5E 04 60 708D EB 98 44 91 36 34 25 ....^.`p...D.64%

0020: 05 53 2F F1 F2 73 70 6018 4F EB 86 B6 D1 A9 05 .S/..sp`.O......

0030: C7 15 A0 47 51 F3 92 0104 58 92 69 92 4D FB 46 ...GQ....X.i.M.F

0040: C0 13 03 7A FB 06 73 5A38 AA 7B 86 74 34 7A C1 ...z..sZ8...t4z.

0050: EB D8 05 D8 F6 29 1D 6BD5 EC 68 54 DB 46 11 36 .....).k..hT.F.6

0060: ED EB AC A3 FA 00 D3 952B BE 23 40 98 36 30 60 ........+.#@.60`

0070: D4 E9 E0 C0 35 E3 4E CC5B 74 33 B4 36 DB 9E B3 ....5.N.[t3.6...

]

***

Found trusted certificate:

[

Version: V1

Subject: CN=cxxx, OU=home, O=home, L=xxxx, ST=xxxx, C=xxxxx

Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

Key: Sun RSA public key, 1024 bits

modulus: 114853966683034469378815389355517833489580875214163953468754623516418342361734698294719709847790412703863840235375913044

1554724665030679409774338011969263884881411578710691774580063423

public exponent: 65537

Validity: [From: Wed Jan 10 13:21:30 GMT 2007,

To: Mon Mar 26 14:21:30 BST 2007]

Issuer: CN=cxxxr, OU=home, O=home, L=xxxx, ST=xxxx, C=GB