getting TLS/SSL client-side certificate into 3.0.0?

[Lucas Fisher]

Finally got time to get my code up on mtn.pidgin.im. See the branch:
	im.pidgin.cpw.ljfisher.ssl_client_auth

I've been able to successfully use certificate authentication with the Openfire 
XMPP server. 

To test it out:
1. Configure with --enable-cyrus-sasl. I have to look into whether this 
requirement can go away. 
2. Create your own client certificate and key. Can be self-signed. Put the key 
and certificate in a PKCS12 file.
3. Configure Openfire to do SSL client authentication and add to the client's 
cert to the Openfire client truststore. Ask for more assistance.
4. In pidgin create an account for your XMPP server.
5. Do Tool -> Certificates -> Your Certificates -> Add. Select your PKCS12 file 
and put in the passwords as requested.
6. Edit $HOME/.purple/accounts.xml and add a node under your account giving 
the id of the certificate you added in step 5 as so:
	<account>
		...
		<certificateid>mycertificate</certificateid>
		...
	</account>
This will be accessible via the GUI at some point.
7. Enable (login to) your account. You should be prompted for a password to 
access your key, but not for the server.

Still needs some UI implemented. I want allow each XMPP account to select 
which certificate/key to use but haven't figure out how to add that. 
PurpleAccountOption is the obvious solution but it looks like it is set at 
startup and cannot be changed later??

More polish and testing as always.

If you want to get a working setup, let me know and I can help.

Lucas

On Tuesday, March 22, 2011 09:49:29 pm John Bailey wrote:
> On 03/22/2011 09:20 PM, Lucas Fisher wrote:
> > I have a bunch of code I've been working on to add client-side SSL/TLS
> > certificate authentication to XMPP and am wondering what steps I need to
> > take to get it into 3.0.
> 
> I'd *love* to see client-side certificates usable.  Just continue working
> on it and let us know when it's ready for review.  If you'd like, you can
> open a ticket about it and reply to me off-list about it, including the
> ticket number, so I don't accidentally overlook it (it's easy to lose
> tickets in the massive sea we have!).
> 
> > I've been working from im.pidgin.pidgin, so I haven't yet looked at
> > getting it working with im.pidgin.pidgin.next.major so that is on the
> > todo list. Should I be pushing my branch up to mtn.pidgin.im? I made
> > several API additions. It still needs more work on UI tie-ins, but it is
> > getting close to a fully workable solution.
> 
> mtn.pidgin.im isn't a public-writable server.  We can arrange for you to
> have write access if no one objects to it, so long as your work goes on a
> branch other than im.pidgin.pidgin or im.pidgin.pidgin.next.major.  We'd
> obviously like the chance to review your code before we merge it :)
> 
> John