I'm Rob Blake

Using a PEM private key and SSL certificate with Tomcat

Thu, 08 Mar 2012 12:40:52 +0000

This is the first in a series of posts of useful titbits that I have completed in my work over the last few months getting The Law Wizard live. These are a reminder for me as to how I did things, but also they may be useful for others as documentation elsewhere is pretty lacking

In this post I will walk you through importing a PEM private key and CA issued SSL certificate into a Java key store so that it can be used with Tomcat. These instructions are for UNIX users, but I’m sure something similar will work on Windows. To get started, you will need the following:

Your PEM private key that you used to generate your CSR
Your PEM SSL certificate issued by your CA
Any intermediate CA certificates if required
Tomcat
Java 6 with keytool on your path
openssl installed

For the record, my CA was GoDaddy and I required 2 intermediate certificates. However I’m reasonably confident these instructions will work with certificates issued by other CAs.

1: Exporting your private key and certificate to PKCS12

Your first task is to export your PEM private key and PEM CA issued certificate to a format that can be handled by the Java keystore. In this case I am going to convert them to PKCS12 format. This is recommended by the Tomcat 7 docs. To do this you will need the following:

openssl pkcs12 -export -in <your_CA_signed_PEM_cert> -inkey <your_PEM_private.key> -out <your_certificate_name>.p12 -name tomcat -chain -CAFile <your_root_CA_certificate>

You will be asked for a password at this point. Use something that you can remember as you’re going to need it in a minute.

In the above there are few important points:

The “chain” option ensures that the full certificate chain for your certificate is included. This is a must if there are intermediary certificates to your root CA
The “name” option must be tomcat. This is the alias that tomcat will use to search in the keystore to identify the certificate is should present to clients
The “CAFile” option allows the chain option to work correctly. If you have intermediary certificates before your root CA, then this should be a bundle of all those certificates. Your CA should provide this. GoDaddy certainly did. If there are not intermediary certificates, then this is the root certificate for your CA.

2: Importing your new PKCS12 certificate and key bundle into a Java keystore

Java keystores are just a flat file in a particular format. This makes it super easy to create new ones. What we need to do now is take the PKCS12 key and certificate bundle we just exported and create a brand new keystore from it. This is where we need the Java keytool command.

keytool -importkeystore -deststorepass <a_password_for_your_java_keystore> -destkeypass <a_password_for_the_key_in_the_keystore>-destkeystore tomcat.keystore -srckeystore <exported_private_key_and_cert.p12> -srcstoretype PKCS12 -srcstorepass <the_password_I_told_you_to_remember> -alias tomcat

Once this completes, you should see a file called “tomcat.keystore” in the same directory from where you issued the command. This is your brand new Java keystore with the PKCS12 version of your PEM private key and certificate in it.

3: Importing intermediate keys into the keystore if required

If like me your CA has intermediate certificates, now is the time to import them into the new keystore we just created. It is highly likely that your CA will provide instructions on how to do this and how the certificates should be named. In my case I need to import a few from GoDaddy. Just to give you an example, I needed the following:

keytool -import -alias cross -keystore tomcat.keystore -trustcacerts -file gd_cross_intermediate.crt

and

keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file gd_intermediate.crt

You *may* also need to import the root CA certificate into the keystore. You shouldn’t have to as most systems these days come with a pre-configured store of well known root CA certificates. You can give it a try and if the system already knows about it, keytool will ask you if you really want to import it.

4: Move the keystore to a known location

Next you just need to move the keystore to a known location and ensure that the process under which Tomcat will be running has access to it. I created a directory called /usr/local/keystore and stored my keystore in there.

5: Configure Tomcat to use your new keystore

Next we need to configure Tomcat to use your new keystore. Go to the ~conf directory of your Tomcat installation. Open server.xml for editing. Find the SSL connector and ensure that it is enabled. In addition make sure the configuration looks something like the following:

<Connector port="8443" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" keystoreFile="path_to_your_keystore_file" keystorePass="the_password_you_created_for_your_keystore" clientAuth="false" sslProtocol="TLS"/>

This will enable SSL on port 8443. If you need 443 instead, change the port number accordingly.

6. Test

Boot Tomcat and then go to <your_hostname>:8443. If you have done everything correctly the padlock symbol should now show in the browser. You can inspect your SSL certificate using any of the browser built-in tools.

JPA: Ensuring versioning of entities when using Query.executeUpdate

Thu, 28 Jul 2011 21:16:15 +0100

The persistence layer for our code at The Law Wizard makes use of optimistic locking to determine if an entity has changed during the period where a user has been working on it. This helps to ensure that the view the user sees is always consistent with what is in the database.

One problem I came across is how to update multiple versioned entities in a single query whilst ensuring the benefits of optimistic locking are maintained. It turns out the answer is extremely simple, yet it took me while to find it. I thought I would share in case others have the same problem.

First off I’m assuming you’re using Hibernate as your persistence provider.

Imagine you have an entity such as this:


public class MyEntity 
{
       @ManyToOne(fetch=FetchType.Lazy, optional=true)
       private OtherEntity otherEntity;

       @SuppressWarnings("unused")
       @Version
       private long version;

       public OtherEntity getOtherEntity()
       {
               return otherEntity;
       }

       public void setOtherEntity(OtherEntity otherEntity)
       {
               this.otherEntity = otherEntity;
       }
}

The relationship between MyEntity and OtherEntity is uni-directional, i.e. OtherEntity doesn’t know about the MyEntitys that have a reference to it.

Elsewhere in your application it is possible to delete OtherEntity. If this happens, you would like all MyEntitys with a reference to the OtherEntity being deleted, to have their reference set to null. However you will note that MyEntity is versioned for optimistic locking purposes. If the reference to OtherEntity is set to null, you want the version of MyEntity to be incremented.

A horrible way to do this is to load all MyEntity into the PersistenceContext where the OtherEntity is the one that is being deleted, set the reference to null and then persist them back into the database. For example:



for(MyEntity m : em.createQuery("select m from MyEntity m where m.otherEntity=:otherEntity").setParameter("otherEntity",otherEntity).getResultList())
{
     m.setOtherEntity(null);
}

This ensures that versioning works, but depending on the number of MyEntity referencing OtherEntity, you’ve potentially got a lot of database traffic.

Another way to do this would be to use a query to update all OtherEntitys such as the following:

em.createQuery("update MyEntity m set m.otherEntity=null where m.otherEntity=:otherEntity).setParameter("otherEntity", otherEntity).executeUpdate();

That works, but with one major problem. The version of all MyEntity affected by the query is not updated. I was considering writing my own query to update the versions of all MyEntity when I found this little nugget buried deep in the Hibernate documentation:

In keeping with the EJB3 specification, HQL UPDATE statements, by default, do not effect the version or the timestamp property values for the affected entities. However, you can force Hibernate to reset the version or timestamp property values through the use of a versioned update.

So what does that mean? Well simply re-write the above query to the following:

em.createQuery("update versioned MyEntity m set m.otherEntity=null where m.otherEntity=:otherEntity).setParameter("otherEntity", otherEntity).executeUpdate();

The versions of any affected entities are incremented ensuring that your optimistic locking strategy will work without a hitch.

An elegy for the technical book

Sat, 12 Feb 2011 11:29:15 +0000

I’ve been doing a lot of technical investigation over the last few months as part of our plans for The Law Wizard. Part of that means that I’ve been doing a fair bit of technical reading whilst playing around with lots of new technology.

Brain..not..working

For some reason I really struggle to start with a technology when reading a computer screen. My brain seems to shut down and refuse to do anything, so I often resort to printing stuff off and then reading it.

Printing stuff off works OK, but it often means you have to chase around, finding the articles or pages that interest you. Sometimes you just want everything in once place. Sometimes there is nothing better than getting your hands on a printed manual that really starts to explain the technology to you. My tiny brain can then relax and the information that I need starts to seep in. I’m sure I’m not alone here.

However I’m finding an increasing problem with technical books these days is that as soon as they are printed and in your hand, they’re out of date. The technology has moved on, and that nifty new feature you wanted to use doesn’t even appear in the book. I’m not the only one who has noticed that problem either

Goodbye my old friend?

With Messrs iPad and Kindle on the scene, it is more and more likely that technical books will be delivered in ‘e-book’ format. This will also mean that as and when new features are added, the book will be updated and pushed to our ‘e-reader’ devices automatically. It will be great, knowing that your manual will never be out-of-date.

But on the other hand I can feel my brain already starting to revolt. “You can’t learn when reading from a screen”, it taunts. It has me rushing to Amazon to check the availability date on the second edition of the technical book instead.

Technology brings change to all areas, and technical books are not immune. I’m looking forward to more up-to-date documentation, and I’ll convince my brain that reading from a screen isn’t that hard and it’s just being lazy.

But deep down I also yearn for a updated print copy of the technical book in my hands. There is something rewarding about thumbing through the pages and learning the intricacies of the technology. I hope I’m not alone in feeling that way.