HTTPS in jBoss 6

In setting up a jBoss 6 server for SSL, I found quite a bit of information was not readily available and there were several unexpected issues.  Here's the long and short...

First, the server will need a keystore with a self-signed certificate.  Use keytool, and an alias of "tomcat".  I'll gloss over some of these general certificate steps because they are well covered in other places.

keytool -genkey -alias tomcat -keyalg RSA -keystore somekeyfile -validity 9999

In the first question, for first and last name, use the name that this server will be refereed to as, in client calls; "localhost", a hostname or an IP address.  Use "changeit" for the passwords.

Next, extract the certificate just created from this file and set it aside.

keytool -export -keystore mykey -storepass changeit -alias tomcat -file tomcat.crt

I'm going to ultimately use this same store as both the key store and the trust store, so I re-import this certificate with the alias that the machine will be referred to.  For example:

keytool -import -alias 192.168.0.8 -file tomcat.crt -keystore somekeyfile -storepass changeit

Now the file has the self-signed certificate, which the server will hand to clients making requests, and the same certificate, with the different alias, that clients will compare the server's certificate to, when making calls to this host.

Edit the follow file to enable the use of this keystore.

[server directory]/server/default/deploy/jbossweb.sar/server.xml

You can set the SSL port here too, like this.

<!-- SSL/TLS Connector configuration using the admin devl guide keystore --   
           port="8643" address="${jboss.bind.address}"
           scheme="https" secure="true" clientAuth="false" 
           keystoreFile="${jboss.server.home.dir}/conf/somekeyfile"
           keystorePass="changeit" 
           truststoreFile="${jboss.server.home.dir}/conf/somekeyfile"
           truststorePass="changeit" 
           sslProtocol = "TLS" />

As an aside, I am using a port set that is supposed to add 200 to all my puts.  This did not work for the SSL port, so I set it to the normal port + 200 as above, is server.xml.

Note that "truststore" properties are specified above, and some documentation indicates that this works.  It does not.  The keystore specification works however.  The server will use the "tomacat" aliased certificate in the given file as it's own.  I don't believe setting "truststoreFile" in server.xml has any impact.

For the truststore, clients will actually use the JRE's system trust store file.  If nothing else is done but the above, to continue this example, then when this server attempts to access https://192.168.0.8:8643/something/ an exception will be thrown.

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This happens because the server certificate, the "tomcat" certificate provided by the server on the initial handshake, can't be found in the JRE truststore file.  I added it to the somekeyfile above, but this file it not being checked.  Options...

1. Add the certificate to the Jave truststore file, with the proper alias.

keytool -import -alias iws03qa5 -file tomcat.crt -keystore /opt/jdk1.6.0_30/jre/lib/security/cacerts -storepass changeit

2.  Use properties set at the Java command line to specify a truststore location.

-Djavax.net.ssl.trustStore=[path and filename]
-Djavax.net.ssl.trustStorePassword=changeit

3. Set the truststore in jBoss's SSL support properties.  To do this, edit:

[server directory]server/default/conf/bootstrap/security.xml

Add this, at the bottom, inside the "deployment" block:


[path]/server/default/conf/somekeyfile
 changeit
 [path]/server/default/conf/somekeyfile
 changeit

Change [path] to your server path of course.

Interestingly, keystore properties must be given here also, even though they also appear in the other file.  Otherwise, the security system will not initialize and it's a big mess.

With this setup, and the server bounced of course, the certificate is found and HTTPS works.

Trouble

I've been having a good deal of trouble with Ubuntu 1, on 11.something.  Ubuntu One solidly occupies that perfect space where it is just barely stable enough to be useful, but not enough to be reliable.  It is a space of peak frustration.


First, performance was terrible on my PC.  I found the Ubuntu One daemon using 100% of the CPU.  With a bit of Googling I found that this is a common problem - it just goes crazy for no reason.  Ok...  In attempting various suggested solutions, I found right off that the normal shutdown command for the sync daemon would not work. But this did:


sudo killall -9 ubuntuone-syncdaemon


I also did this:


u1sdtool -q rm -rf ~/.local/share/ubuntuone u1sdtool -c

and rebooted.  Didn't help...  An I/O nice on the process would seem to be in order:

ionice -c 3 -p $( ps h -o pid -C ubuntuone-syncdaemon )

And this seemed to help, for a few minutes I thought it was ok.  But then the whole process died.

To take a step back, I think what started the trouble was that I accidentally unpacked a very large tar/zip into the sync'ed directory.  The system hit my account limit.  I'm here to tell you, don't let this happen.  It does NOT handle it well.  The software will begin to fail to connect to the service.

So while in the midst of trying to get the daemon to connect and run, I was also discovering, and deleting, the extra files.  I went and deleted them from another sync'ed computer too, which I think helped.

Also, at some point in there I did what, I guess, re-sets the local Ubuntu One "marks on the wall".


rm -rf ~/.local/share/ubuntuone

But somewhere in the middle of all this I was distracted by nautilius no longer functioning.  It was extremely sluggish, and eventually terminating.  Again, Googling this called for deleting various files and directories - none of which worked for me.

At some point though, after deleting a lot of things, and several changes and reboots,  nautilius, out of the blue started working.  I unfortunately can't pin this on any specific action on my part.  It just started working, while I was sitting there contemplating just going on with life, without it.

Then two things happened at about the same time.  One was that Ubuntu One appeared to start working, even though CPU was still swamped. 

Also, I looked at my Droid 2.  Verizon's service had set the date/time on my phone to about 2 days and an hour into the future.  I know it had been correct earlier in the day.  One problem at a time though...  Or two...  Or three...

Several hours later after a lot of goofing around, nautilius and Ubuntu One are working.  The date/time magically fixed itself in Verizon's network too.

However...

One of my most important files in the Ubuntu One sync directory is gone.  Fortunately I have other copies, having had prior experience with Ubuntu One over-writing newer files with older files (yes, it absolutely does that, although it hasn't happen in awhile), so I can in theory, put the file back.

But when I do this, Ubuntu One instantly deletes the file and creates a new conflict file with the desired content.  There appears to be nothing I can do about this.  I have to call the file something else.

I really shouldn't try using software that hasn't been out for 5 years.  Or should that be 10...  Performance on my PC is back to normal though.


In other interesting trivia, I also had Ubuntu One running on a Windows XP machine.  This was not easy to install, but that's another story.  The funny thing currently is that for the past 2 or 3 weeks, if I start the Ubuntu One GUI program on that machine, a dialog appears.  It tells me that an update is available and asks if I want to upgrade.  


At first I clicked "yes".  But nothing further happens and it has never done anything, apparently, because the dialog continues to appear.  So now I don't bother.