DDevelopment & Design

JCE keystore and untrusted sites

Recently at work I was in need of connecting to a web service exposed via HTTPS. I’ve been doing this from inside Servicemix 3.3.1, which may seem a bit inhibiting, but that was a requirement. Nevertheless I’ve been trying my luck with the included ser…Recently at work I was in need of connecting to a web service exposed via HTTPS. I’ve been doing this from inside Servicemix 3.3.1, which may seem a bit inhibiting, but that was a requirement. Nevertheless I’ve been trying my luck with the included ser…

Recently at work I was in need of connecting to a web service exposed via HTTPS. I’ve been doing this from inside Servicemix 3.3.1, which may seem a bit inhibiting, but that was a requirement. Nevertheless I’ve been trying my luck with the included servicemix-http-2008.01 component. I’ve created a simple Service Unit using that component and made connection attempt. Unfortunately I’ve encountered issues with the SSL conversation negotiation. I had to dig deeper into the servicemix-http code to find out these had something to do with my JCE keystore. Read more to find out what happened!

Ok, so I had my xbean.xml for http component looking like this:

 

As you can see this is a proxy adapter to some outside service exposed via secured HTTP protocol. Since it’s HTTPS I’ve specified some SSL parameters. It was sufficient in my case to just pass the keystore file and it’s password.

I’ve created my keystore.jks file in smx_home/conf with password servicemix in the following manner:

 

You can see what’s in this file with this command:

 

At this point I thought, that having a configured keystore and my component would suffice. Wrong! As soon as I’ve tried to connect to the external service I got an exception:

 

Hmmm.. this looks pretty nasty, but it’s not that bad. As one can read here, it’s associated with the other site’s having an untrusted (unsigned) certificate. Assuming you actually trust the other end of the communication and this situation is ok for you, you should add the servers certificate to your keystore. The previously mentioned link contained a little java class that would do just that. You can find it here (original code) InstallCert.java or you can look into my slightly changed version here at github.

You should call it as follows, assuming that file keystore.jks is in the current directory:

 

What you’ll probably see, when you execute this app is this:

 

Please note that there is a prompt (Enter certificate to add to trusted keystore…) in which you can enter the certificate number you wish to add to your keystore.

After all those steps my request got through and I could happily query HTTPS service as long as I wanted to! Great!

Possible problems

In my search for this problem’s solution I’ve encountered this kind of exception:

 

A little googling led me to this StackOverflow question.

It seems that you cannot have multiple keys with different passwords in the same keystore and use KeyManagerFactory class. Oh well…

.

Ending

To sum up, the solution given works, but in my opinion using the InstallCert.java app is rather dirty. I’ve been wondering, do you know other ways of doing that thing?

— Previous article

<!--:en-->Using Eclipse snippets for faster JUnit test creation (with Mockito!)<!--:-->

Next article —

<!--:en-->Few thoughts on Crockford's "JavaScript: The Good Parts"<!--:-->

You May Also Like
DDevelopment & Design

Simple HBase ORM

When dealing with data stored in HBase, you are quick to come to a conclusion, that it is extremaly inconvenient to reach to it via HBase native API. It is very verbose and you always need to convert between bytes and simple types - a pain. While I wa...When dealing with data stored in HBase, you are quick to come to a conclusion, that it is extremaly inconvenient to reach to it via HBase native API. It is very verbose and you always need to convert between bytes and simple types - a pain. While I wa...
DDevelopment & Design

Turing completeness II

Well, as I wrote in the previous post, sed is a Turing complete language. We can use it to implement some simple algorithms, or even a dc interpreter. But what does it really mean? How complex tasks may we achieve using plain sed?What about writin...Well, as I wrote in the previous post, sed is a Turing complete language. We can use it to implement some simple algorithms, or even a dc interpreter. But what does it really mean? How complex tasks may we achieve using plain sed?What about writin...
DDevelopment & Design

Private fields and methods are not private in groovy

I used to code in Java before I met groovy. Like most of you, groovy attracted me with many enhancements. This was to my surprise to discover that method visibility in groovy is handled different than Java!

Consider this example:

class Person {
private String name
public  String surname

private Person() {}

private String signature() { "${name?.substring(0, 1)}. $surname" }

public String toString() { "I am $name $surname" }
}

How is this class interpreted with Java?

  1. Person has private constructor that cannot be accessed
  2. Field "name" is private and cannot be accessed
  3. Method signature() is private and cannot be accessed

Let's see how groovy interpretes Person:

public static void main(String[] args) {
def person = new Person()   // constructor is private - compilation error in Java
println(person.toString())

    person.@name = 'Mike'       // access name field directly - compilation error in Java
println(person.toString())

    person.name = 'John'        // there is a setter generated by groovy
println(person.toString())

    person.@surname = 'Foo'     // access surname field directly
println(person.toString())

    person.surname = 'Bar'      // access auto-generated setter
println(person.toString())

println(person.signature()) // call private method - compilation error in Java
}

I was really astonished by its output:

I am null null
I am Mike null
I am John null
I am John Foo
I am John Bar
J. Bar

As you can see, groovy does not follow visibility directives at all! It treats them as non-existing. Code compiles and executes fine. It's contrary to Java. In Java this code has several errors, pointed out in comments.

I've searched a bit on this topic and it seems that this behaviour is known since version 1.1 and there is a bug report on that: http://jira.codehaus.org/browse/GROOVY-1875. It is not resolved even with groovy 2 release. As Tim Yates mentioned in this Stackoverflow question: "It's not clear if it is a bug or by design". Groovy treats visibility keywords as a hint for a programmer.

I need to keep that lesson in mind next time I want to make some field or method private!