Client authentication on openfire with ceritficates

Openfire Openfire Support
1

Hi,

I have gone thru the functionality thoroughly and I found that setting the system property

xmpp.socket.ssl.truststore does not make any difference to the authentication process.

First, I have not come across a jabber client which provides for client authentication with

certificates(I used jeti, gabber, psi, exodus) so if you know one please let me know. But

what I was expecting was that once I set the truststore property none of the clients without

a valid certificate would be authenticated.

Any help is welcome!

Regards,

Linus

2

Ive been working on getting this going, and the latest Beta should have more functionality for doing client based SSL auth. To date, Ive not found a client that does SSL auth with SASL EXTERNAL, but I did motify tkabber to do so (it was pretty trivial to do so). Ive been slowly working on Smack to support it, which means Spark is next on the list.

In summary- not yet, sorry. But coming soon!

3

Hi,

thanks for your prompt reply. Well, if I understand it correctly then all I need is already available. Tkabber which allows for client authentication & Openfire 3.4.0 beta1 which lets me set

xmpp.client.cert.policy system property. I tried my hand at it and the server doesn’t let the authentication handshake to complete if the property value is set to “needed”. Which is great! The problem I face now is that I see many fields in Tkabber such as sslcertfile, sslcacertstore, sslkeyfile and I tried to put (cacert.pem, privkey.pem: OpenSSL) these files in those fields but the authentication process doesn’t complete and Tkabber simply jams.

Do I understand it correctly when I say that the functionality I need is available in the form of Tkabber & Openfire 3.4.0 beta1. If yes, then I would really appreciate if you could help me configure the above mentioned Tkabber fields correctly.

Regards,

Linus

4

Not quite. tkabber requires modification. I dont have any patch sets

available, but basically I had to add a new SASL mechanism for EXTERNAL.

It was easy, since EXTERNAL dosnt do anything. Then in tkabber you

just specify the ssl certificate and key which must be a single file in

pem format. If you dont do the modifications to tkabber, it will do the

ssl auth, but still require some other form of authentication.

Then on the server you need to configure openfire to advertise EXTERNAL,

and require a SSL cert for clients. This isnt really ready for

prime-time yet, so you are kinda on your own for now.

5

slushpupie:

I am working on client certificates issues. I just want to get a prototype client to work, so I use the the same certificates for both Openfire and XMPP client. I copy the Openfire’s keystore file to my XMPP client’s root directory, run my client with arguments: -Djavax.net.ssl.keyStore=keystore -Djavax.net.ssl.keyStorePassword=mypassword, it always fails when Handshake. The server information is: SocketAcceptorIoProcessor-0.0, fatal error: 42: null cert chain, could you please point me if the way I am working is right? Thanks.

6

You are on the right path. The “null cert chain” means the client did

not respond with a certificate. Spark and Smack in the versions

available today do not properly send client certificates, at least not

without some modifications. So you either need to start hacking at the

code, or just have some patience until I get there.

7

We are too very interested in TLS/SASL client authenication based on certificates. User login can still be username/password based, but we are longing for the day when we have both client and user authentication based on cerificates. Is it scheduled for a near time release in Smack and Openfire? Let us know how we can help in the requirements process and testing.

BTW what is the current thinking around audit logs and accountability?

/Kenneth

8

Hey Kenneth,

BTW what is the current thinking around audit logs and accountability?

What information would you need to store? Do you need to store IP, user, password of each attempt where the certs were not trusted? How would you need to retrieve/report that info. Is there any standard around this?

Thanks,

– Gato

9

The two parts of my posting was not 100% correlated. The audit log would more be used after the fact. You were autenticated (and authorized) but did something that is to be scrutinized. Accountability.

Useful information: Time, authenticated user, authenticated client (IP etc), destination, message type, optional: subject, content

Syslog, Log4J, ARM would be a good start.

http://open-arm.sourceforge.net/