Apr 7, 2009 6:36 AM
Openfire+Spark - Client X.509/PKI Certificate Support
-
Like (0)
30069 Views
52 Replies
Latest reply:
May 27, 2009 9:59 AM by
vargok 
-
-
-
Some other things I forgot to mention:
o config.setCallbackHandler() doesn't work; you have to provide it on the connect() for it to work.
So the real patch for XMPPConnection is:
smack> svn diff source/org/jivesoftware/smack/XMPPConnection.java
Index: source/org/jivesoftware/smack/XMPPConnection.java
===================================================================
--- source/org/jivesoftware/smack/XMPPConnection.java (revision 11005)
+++ source/org/jivesoftware/smack/XMPPConnection.java (working copy)
@@ -226,7 +226,7 @@
config.setSASLAuthenticationEnabled(true);
config.setDebuggerEnabled(DEBUG_ENABLED);
this.configuration = config;
- this.callbackHandler = null;
+ this.callbackHandler = config.getCallbackHandler();
}/**
@@ -240,7 +240,7 @@
*/
public XMPPConnection(ConnectionConfiguration config) {
this.configuration = config;
- this.callbackHandler = null;
+ this.callbackHandler = config.getCallbackHandler();
}/**
@@ -1219,9 +1219,9 @@
else {
ks = KeyStore.getInstance(configuration.getKeystoreType());
try {
- ks.load(new FileInputStream(configuration.getKeystorePath()), pcb.getPassword());
pcb = new PasswordCallback("Keystore Password: ",false);
callbackHandler.handle(new Callback[]{pcb});
+ ks.load(new FileInputStream(configuration.getKeystorePath()), pcb.getPassword());
}
catch(Exception e) {
ks = null;And it looks like the CallbackHandler isn't set right in any event:
[XMPPConnection(Config,CBH)] Callback handler: org.jivesoftware.LoginDialog$LoginPanel[,0,188,244x200,layout=java.awt.GridBagL ayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777217,maximumSize=,minimumS ize=,preferredSize=]
OOOOOOOOOOH. I bet... Yup. That's pointing to the PasswordCallback/CallbackHandler in the login pane... meaning they're assuming that the *keystore* and the *account* have the same password!Mmmhmm. That *works*. Completely invalid assumption, but it works when I make them the same. Of course the other hidden caveat is that they're looking for key under the alias of the username. I haven't checked fall-back -- i.e., does it try "<username>" then "mykey", but one might presume. So that's a reasonable thing to do but setting the passwords the same is probably not. There should be a pop-up dialog.... or try the original, then pop-up, would be best.
However, now:Exception in thread "Thread-1" java.lang.NoSuchMethodError: org.jivesoftware.smack.XMPPConnection.login(Ljava/lang/String;Ljava/lang/String ;Ljava/lang/String;Z)V
at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:860)
at org.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:200)
at org.jivesoftware.LoginDialog$LoginPanel$1.construct(LoginDialog.java:606)
at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:131)
at java.lang.Thread.run(Thread.java:595)
But I presume that's an SVN vs. RC/Beta-2 versioning thing:------------------------------------------------------------------------
r10846 | gato | 2008-10-24 01:17:50 -0400 (Fri, 24 Oct 2008) | 1 lineSimplified list of #login methods in XMPPConnection.
Once i point #login(String,String,String,boolean) -> #login(String,String,String); it logs in perfectly!That's with the latest 2.6.0-beta, not using the provided JRE. With another copy of the stock Spark (I think?), the certificate gets sent without the extra login(S,S,S,b) in there, but it gets "stuck" right here:
01E0: 72 65 73 73 69 6F 6E 3E 3C 61 75 74 68 20 78 6D ression><auth xm
01F0: 6C 6E 73 3D 22 68 74 74 70 3A 2F 2F 6A 61 62 62 lns="http://jabb
0200: 65 72 2E 6F 72 67 2F 66 65 61 74 75 72 65 73 2F er.org/features/
0210: 69 71 2D 61 75 74 68 22 2F 3E 3C 72 65 67 69 73 iq-auth"/><regis
0220: 74 65 72 20 78 6D 6C 6E 73 3D 22 68 74 74 70 3A ter xmlns="http:
0230: 2F 2F 6A 61 62 62 65 72 2E 6F 72 67 2F 66 65 61 //jabber.org/fea
0240: 74 75 72 65 73 2F 69 71 2D 72 65 67 69 73 74 65 tures/iq-registe
0250: 72 22 2F 3E 3C 2F 73 74 72 65 61 6D 3A 66 65 61 r"/></stream:fea
0260: 74 75 72 65 73 3E 98 E4 3B 39 92 A1 70 90 38 2D tures>..;9..p.8-
0270: FB 9D 16 18 4B 74 ....Ktand eventually disconnects.
---------------The other change was:
smack> svn diff source/org/jivesoftware/smack/PacketReader.java
Index: source/org/jivesoftware/smack/PacketReader.java
===================================================================
--- source/org/jivesoftware/smack/PacketReader.java (revision 11005)
+++ source/org/jivesoftware/smack/PacketReader.java (working copy)
@@ -467,6 +467,7 @@
else if (eventType == XmlPullParser.END_TAG) {
if (parser.getName().equals("starttls")) {
// Confirm the server that we want to use TLS
+ startTLSRequired = true;
connection.startTLSReceived(startTLSRequired);
}
else if (parser.getName().equals("required") && startTLSReceived) {
which isn't very robust, but at least it does the right thing.So the end of the day:
1) Spark 2.6.0-beta2 -- stock -- might still be broken, but for some other random reason where the connection hangs (provided JRE?)
2) After applying the above patches to smack (also attached), and redeploying an updated lib/smack.jar, Spark 2.6.0b2 (1.5 JRE) should work for you provided:
3) Your keystore's password has:
a) a key+certificate with an alias the same as the user logging in
b) the password for the keystore *and* the key are the same,
c) the password you enter to login in the dialog is the same as (3.b).
I think that's all the non-obvious required conditions -- in addition to all of the regular openfire setup, and not to use the RPM, which apparently is broken. I've not even thought about looking at the diff between .tar.gz and rpm-based installations.
Can these patches be applied to SVN, please? And maybe a document defining everything put together separate from the forums?
If i get some time -- and I don't think I will -- I'll look into what's breaking beta2
Thanks!
-
-
-
Thanks slushpuppie. The patches are quite limited, so applying them should be very obvious, I don't think it's going to require any PKI-specific knowledge to see, e.g., that you must register the callback handler, before calling it back.
However, I do have more to report: apparently I was mistaken regarding the RPM -- you were right, there was no difference.
Apparently the crl and client truststore properties (xmpp.client.certificate.crl and xmpp.socket.ssl.client.truststore) only admit of *relative URLs*. I.e., "/opt/openfire/resources/security/client.truststore" won't work.... "resources/security/client.truststore" will work. That's a tidy bit of info. Of course, I could not ever verify until I'd patched my Spark client per the above, but that's probably a critical piece of information for folks to be aware of. I'll try to add a note to the other thread where you laid out the basic properties.
Anyway, I'd be happy to file a ticket in JIRA, but it's not open to the public. Could you at least create a ticket, if you have access? And attach the patches, etc? Oddly, I do see that the RPM-based 3.6.3 server is showing <starttls><required="true"></starttls>, so I'm not sure what the deal is there, or if I'm looking in the wrong place.
-
-
-
-
client.truststore, etc. properties are relative path-based and owned by the openfire daemon user?
if you're using the default client.truststore, just try removing the properties for that and crl, that seemed to help on mine. Make sure the truststore shows that you're trusting the right CA.
And that the client's truststore/keystore has the server's CA certificate (trusted) in it (and aliased different from 'mykey' probably).
And you're sure you're using the patched .jar file for smack.jar?
I can't think of anything else to check, sorry
-
-
-
-
-
-
-
Okay, Im still stuck. Ive created those openssl certificates once again using only letters. Imported them into the keystore and truststore of the client with all the same password. The same on the server side. Smack api is fixed with the diff patches which where posted above and repacked with ant.
Ive tried to connect on port 5222 with config.setSocketFactory(SSLSocketFactory.getDefault()); and without it. In both configurations I get "Closing session due to excpetion"and java.lang.Exception: Disallowed character. Openssl client test says that there still arent any certificates offered.
openssl s_client -prexit -connect localhost:5222
Loading 'screen' into random state - done
CONNECTED(00000778)
3440:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib.c:188:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 124 bytes
---
New, (NONE), Cipher is (NONE)
Compression: NONE
Expansion: NONE
---Is this an indication for this problem?
Port 5223 offers certificates, but im not able to connect.
With config.setSocketFactory(SSLSocketFactory.getDefault()); i get sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target and without it get javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
Im grateful for any help
EDIT: I found out that, when using config.setSocketFactory(SSLSocketFactory.getDefault()); on port 5223 Smack uses the cacerts keystore in the jre folder. If I add my root certificate into that keystore i get javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Netscape cert type does not permit use for SSL server.
EDIT2: Ive removed all Netscape comments an attributes from those openssl certificates to fix the "Netscape cert type does not permit use for SSL server" problem, but Im ending up in a "null certificate chain". So, back to the beginning. Im getting mad
-
-
Client.truststore has default settings, I didnt change them. Im using Windows, so the server is running with my user which is administrator. I think if there would be no access to the client.trusstore, an error would be listed in the debug log.Obviously on Port 5223 my certificates are offered, so I think openfire is able to access the client.truststore.
The CallbackHandler, which you are using in your client code, which package is it from? If I import the class which eclipse proposes to me(javax.security.auth.callback.CallbackHandler). It cant be instantiated because it is an Interface. Did you write a callbackhandler by yourself?
EDIT: Obviousely connection via port 5223 is working. Setting those systems propertys made my day
But I want to find out, why there are no certificates offerd on port 5222
-
-
-
-
-
-
Hello!
First of all, let me introduce myself. I'm a student at the University of Girona (Catalonia, Spain) and doing my master thesis about an application that uses XMPP. So, recently my tutor told me that it would be great to implement an authentification using X.509, and that's why I have ended in this post.
Well, I follow this topic trying to make it work, but I'm having the similar problems that are describing some posts earlier.
Problems (i'm using 5222 TLS port):
- At client side the error is: "handshake message sequence violation,2" if i'm not using setSocketFactory.
- Using socketfactory: SocketException: coonection is closed ... Remote host closed connection during handshake.
- At server side: Warn: java.lang.Exception: Disallowed character
Debug: SSL Handshake failed .... SSLHandshakeException: null cert chain
If I use 5223 on Debug: SSLException: Unrecognized SSL message, plaintext connection?
There are a few things that I'm not sure if I had done ok, so let me explain what I'm using:
- I followed the instructions of the first posts (create the system preferences in OpenFire).
- I'm using the SMACK API 3.1.0 and patched with the last patch of vargok.
- The callback is called but before doing any SSL connection. Normal?
- I'm not sure if the client is accessing to the client certificate...
- On server side, I added my CA to client.trustore (it appears as trustedCertEntry), in trustore also. The private key of the server was added in keystore (and it appears as a PrivateKeyEntry).
- Openfire complains about pending validation of my private key, althought it was validated by my CA. Does it affect it?
- On client side, I created a keystore and truststore and added the client cert and the CA. But when I checked in keytool about keystore file, it shows the client cert but it says: trustedCertEntry. Is that normal?
- When I do a openssl s_client on 5223, it prints the next output:
xavi@songohan:~/openfire/resources/security$ openssl s_client -prexit -connect localhost:5223CONNECTED(00000003)
depth=0 /C=ES/ST=Catalunya/L=Girona/O=Universitat de Girona/OU=Broadband Communications and Distributed Systems/CN=songohan.udg.edu/emailAddress=contacte@triem.org
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=ES/ST=Catalunya/L=Girona/O=Universitat de Girona/OU=Broadband Communications and Distributed Systems/CN=songohan.udg.edu/emailAddress=contacte@triem.org
verify error:num=7:certificate signature failure
verify return:1
depth=0 /C=ES/ST=Catalunya/L=Girona/O=Universitat de Girona/OU=Broadband Communications and Distributed Systems/CN=songohan.udg.edu/emailAddress=contacte@triem.org
verify return:1Why it gives me three outputs?
I think that it would be very helpful if anyone could attach a fake CA, Server Key and Client Key that works with X.509 auth on OpenFire (or also, a good tutorial to generate it).
Finally, I put some of my code that I'm using to connect in case anything is wrong.
ConnectionConfiguration cc = new ConnectionConfiguration(server,port,server);
String KEYSTORE_PATH=... //absolute path to the keystore file
String KEYSTORE_PASSWORD="changeit"
String TRUSTSTORE_PATH=...
String TRUSTSTORE_PASSWORD="changeit"
cc.setKeystorePath(KEYSTORE_PATH);
cc.setKeystoreType("jks");
cc.setTruststorePath(TRUSTSTORE_PATH);
cc.setTruststoreType("jks");
cc.setTruststorePassword(TRUSTSTORE_PASSWORD);
cc.setCallbackHandler(new myCallbackHandler()); //I'm using vargok callback
//cc.setSocketFactory(SSLSocketFactory.getDefault());
XMPPConnection connection = new XMPPConnection(cc);
//System.setProperty("javax.net.debug","ALL");
SASLAuthentication.supportSASLMechanism("PLAIN",0);
connection.connect();
connection.login(username,password,resource); //hope to remove if it works!
I'm willing to help as much as possible in this aspect. If needed, I'll join the next chat and be avaiable to do as many tests I can. Please, help me
Thanks for advance!
----------------------------------------------------------
Update: Yay! Finally I made it work! As I suspected, the problem is that my client didn't get the client key, so there was no avaiable keys and that's why the server closed the connections.
The openssl output is ok, and the pending validation is not a problem. My real problem is in the client keystore.
There is a little problem adding certs to the keystore using keytool. At the following webpage it explains this problem and how to solve it:
http://www.agentbob.info/agentbob/79-AB.html
To check that the client cert was insered correctly, when you do a :
>>keytool -list -keystore keystore
And it should appear as a KeyEntry instead of CertEntry
After do that, all started to work magicly. The callback detected the client cert and so on
If I try to use the default SocketFactory, it seems that it doesn't work.
One last question: I'm using EXTERNAL auth and works, but is it necessary that the client executes the login method? (e.g. login("","")).
So, here is the needed code to make it work for me:
ConnectionConfiguration cc = new ConnectionConfiguration(server, port, server);
cc.setKeystorePath("....");
cc.setKeystoreType("jks"); //not needed, by default jks
cc.setCallbackHandler(new myCallbackHandler());
connection = new XMPPConnection(cc);//System.setProperty("javax.net.debug","ALL");
SASLAuthentication.supportSASLMechanism("PLAIN", 2);
SASLAuthentication.supportSASLMechanism("DIGEST-MD5", 1);
SASLAuthentication.supportSASLMechanism("EXTERNAL", 0);connection.connect();
connection.login("", "");
