Why do we have to play with keystores to start an https server?

If you develop in Java and want to start an httpS server, more often than not, you end up trying to understand how to put your certificates into a keystore. That’s a lot of frustration.

If you know nginx, the configuration for an SSL proxy is so simple:

server {
    listen 443;
    ssl on;
    ssl_certificate /etc/nginx/keys/domain.crt;
    ssl_certificate_key /etc/nginx/keys/domain.key;

    location / {
        proxy_pass http://localhost:8080;
    }
}

Why the hell can’t we do the same simple thing in Java?

That’d be so nice to just give those two files, the certificate and the key, and let the web server work things out.

That’s exactly what I’ve implemented in fluent-http. Here’s the code to start an http server:

import net.codestory.http.*;

public class HelloWorld {
  public static void main(String[] args) {
    new WebServer().start();
  }
}

Here’s the code to start an https server:

import net.codestory.http.*;

public class HelloWorld {
  public static void main(String[] args) {
    new Webserver().startSSL(9443, Paths.get("server.crt"), Paths.get("server.der"));
  }
}

Can you spot the differences?

6 thoughts on “Why do we have to play with keystores to start an https server?”

  1. Now I just have to be able to use Java 8 in my projects 😉 The fluent-http lib looks great by the way, can’t wait to be able to use for all my testing…

  2. For a production server I need to specify the keystore path, the certificate alias and the keypass at runtime.

    It makes sense if I want to:
    – Keep the default keystore in the VCS along with source files, and ship it so we know exactly what we deploy.
    – Prevent developers from accessing the certificate. Some audits require to separate coding and operations.
    – Switch between certificates and keystore for testing purposes, without reshipping.

    It turns out that “stupid keystores” (as Fluent-Http documentation says) may serve a useful purpose.

    Fortunately supporting the keystore wouldn’t bloat the API so much:
    startSsl( Paths.get( “keystore.jks” ), alias, keypass )

    1. Hi Laurent, all your requirements can be met with files also and yes the Api could support keystores without much complexity in the codebase. The complexity is elsewhere. All this work on keystores just to provide a layer of indirection…

  3. Keystores are well-designed regarding all they can do, but as we don’t use them more than 3 times a year we need to re-learn keytool options each time, so they look painful in the end.

    “All this work on keystores just to provide a layer of indirection”: yes it’s true. I wanted the certificate in the source code without giving free access to it. Instead of copying 2 files (private key + certificate) in the production environment I just need to set a password. The keystore is the price to pay for this.

  4. Euh… C’est quand même super pratique une Keystore quand tu dois changer *tout* tes certificats suite à un bug OpenSSL 😉

Comments are closed.