23 Aug 2016, 23:30

Export Certificate and Private key from JKS

I had to migrate web application written in Java to NodesJS,

Java web containers store certificates inside JKS Keystore where NodeJS requires certificate and private key in PEM format.

Exporting certificate directly from JKS is easy by using keytool, but exporting private key is not allowed, To export the private key using Java, we need to interact with the keystore by writing some custom code using the Keystore java API,

the other alternative is simply convert the JKS into a PKCS12 and export the certificate & key using openssl

Convert JKS to PKCS12 format:

keytool -importkeystore -srckeystore mykeystore.jks -destkeystore mykeystore.p12 -deststoretype PKCS12

Note: The -importkeystore parameter is only supported with the keytool that ships with Java ver 1.6+

you can view the content of the pkcs12 keystore by:

openssl pkcs12 -in mykeystore.p12

(Specifically look for the friendlyName that corresponds to the alias property of in JKS)

Export the certificate:

openssl pkcs12 -in mykeystore.p12 -nokeys -out cert.pem

Export the private key (unencrypted)

openssl pkcs12 -in mykeystore.p12  -nodes -nocerts -out key.pem

the -nodes means “No DES”, that is “do not encrypt the private key that will be exported to key.pem”

Make sure you keep the private key safe (recommended: chmod 600 key.pem)

09 Feb 2015, 00:00

Hello world using Ratpack.

About Ratpack

Ratpack is a set of Java libraries that facilitate fast, efficient, evolvable and well tested HTTP applications built on Netty event driven networking engine,

After crawling into its source code, I find it simple and easy to use and it feels right, why? because:

  1. It’s super simple, its core has very limited number of dependencies
  2. Has out of the box extensions such as Guice, Jackson, etc, but nothing dictates you using them thanks to Guice modular architecture.
  3. Compatible with Java8 lambda syntax
  4. Testing is very easy.

Code can be written in Groovy or Java, and since java8 lambda syntax is so pretty, I find it suitable for the Ratpack handlers architecture quit well.

So here’s a simple hello world using Ratpack and Java8,

The build file (Gradle)

While used to Maven, It feels like Ratpack folks like Gradle, so I said why not use it?

Here’s a simple build.gradle file:

buildscript {
  repositories {
  dependencies {
    classpath "io.ratpack:ratpack-gradle:0.9.13"

apply plugin: "io.ratpack.ratpack-java"
apply plugin: "idea"

dependencies {
  //Ratpack uses slf4j for logging
  runtime "org.slf4j:slf4j-simple:1.7.5"

//we need this since 0.9.13 is based on snapshot version of Netty
repositories {
    maven {
      url "http://clinker.netty.io/nexus/content/repositories/snapshots"

Create basic directories

mkdir -p src/main/java
mkdir -p src/ratpack

Run in the command like gradle idea to create Intellij project:

gradle idea

One of the things I mostly like about Ratpack is that it has no real notion of a “container”, you can simply start it a plain main method just like that:

import ratpack.server.RatpackServer;
import ratpack.server.ServerConfig;

public class Server {
    public static void main(String[] args) throws Exception {
        RatpackServer server = RatpackServer.of(b -> b
                        .serverConfig(ServerConfig.embedded()) //default config
                        .registryOf(r -> r.add(String.class, "world"))  // registry of supporting objects - optional
                        .handlers(chain -> chain                    // request handlers - required
                                        .get("hello", ctx -> ctx.render(ctx.get(String.class) + " !"))


Server will start with on some available port and will print: Ratpack started for http://localhost:65478

now hit in the browser http://localhost:65478/hello ! :)

01 Feb 2015, 00:00

Choosing Java Backend framework in 2015.

So it’s year 2015 and I’m taking a role in a new cloud service, helping to choose the right backend technology,

This is the summary of our requirements:

  1. Can quickly come up with some POC.
  2. HTTP driven.
  3. Native support for Async.
  4. Modular.
  5. Avoid frameworks that dictates specific code structure.

Here are few options we tried but decided to pivot and seek for alternatives,


Akka seems very promising, it feels lightweight, highly concurrent and distributed, Akka is based on actors pattern, an old pattern invented by Carl Hewitt and friends, promoted lately by Erlang,

We tried to create a POC with Akka, in conjuction with their new Akka Streams (which seems to replace Spray), both felt like a complete solution, but we decided to pivot out of it, I think I can summarize it in one sentence.

Although Akka seems to have support for Java, it’s just not a java project, Akka is written in Scala, and exposes Java APIs via bindings layers, I felt like its community is Scala oriented debugging code of Scala is something tough for people that plans to stick in the Java domain.


Vert.x is similar to NodeJs, written in Java, It is Netty based and works in a non blocking mode,

Vertx 3 seems to be very promising we found some advantages of it,

  1. We quickly could create a web app using Apex.
  2. Almost no configuration and deployment code is required to see real results.
  3. Completely written in Java (which was a big releaf after Akka)
  4. Scale out by levaraging an internal even bus.

But we decided to pivot again, but why?! because Vert.x makes certain irreversible decisions about how applications should be written, and working with the event bus was a nightmare, we tried to use Vertx Service Factory which eliminates most of the boilerplate code required to perform actions over the event bus, but it restrictions of passing only JsonObject and JsonArray frustrated us, We found ourself spending too much time on convertions between Vertx’s JsonObjects and application / core services models.

What now?

So what now? we’r still seeking for a better solution that hopefully will satisfy our needs.