Centralizing Certificate Management of LetsEncrypt with a Raspberry PI

Lets Encrypt is a new Certificate Authority (CA), run for the public’s benefit by the Internet Security Research Group (ISRG). At the time of writing it’s currently in Beta and is due to go public in December 2015.

Update: Lets Encrypt went into public -beta on December 3 2015. I have updated this article with the minor change needed to work with the live servers.

Now in the default mode, the standard Lets Encrypt client (it’s not the only one) can manage this automatically – however it’s not ideal if you have more than one server.

What I describe here is how to centralize managing certificate registration (& later renewal) on a central machine. When a certificate is then registered or renewed we can then copy the certs to the remote servers.

Continue reading “Centralizing Certificate Management of LetsEncrypt with a Raspberry PI”

Fixing HTTPS mixed content issues in Chrome

I’ve been beta testing the new Lets Encrypt Certificate Authority so have been adding HTTPS to various services however I hit on a problem where Chrome wasn’t showing the green padlock for a specific application. Instead it was showing the broken padlock because it was saying there was mixed content.

In https, mixed content is usually where you have a resource (css, image etc) thats being served in http instead.

So first I went in to developer tools to find that resource. Now it can be difficult to find, however one first tip is to go to the network tab and right click on any of the columns (e.g. Name) and ensure that scheme is ticked. This now adds a new column which should show https for everything. The one that shows http is the culprit.

Except in this case it didn’t. Everything was https. So what’s happening?

Well in Chrome it caches the https state with each resource, and in this instance I had https originally working with a test certificate. Now I have a real one, so chrome was being confused.

The solution was to restart chrome by opening a new tab and entering the url: chrome://restart

Once chrome restarts (it will restart every tab/window you have open) the problem was fixed.

Writing Servlets the J2EE 6 / Servlet 3.0 way

In the past whenever you wrote a Servlet you had a lot of work to do. First you wrote your servlet, then you had to add configuration for that servlet into web.xml so that your application would use it.

For simple applications this was fine but the more servlets you wrote the harder it became as web.xml started to become large and unwieldy.

Now with J2EE 6 you got the ability to add annotations to your servlets. No more do you need to add anything to web.xml as the container scans the classpath for any servlet that’s annotated with @WebServlet getting the required configuration from there.

This also has the benefit that you can write libraries of servlets. Those servlets get deployed automatically and you don’t have to worry about duplicating the config.

Both Tomcat 7 and TomEE 1.5.1 support the J2EE 6 Web Profile as standard. I’m not certain of other containers as I’ve only tested this on those two.

Continue reading “Writing Servlets the J2EE 6 / Servlet 3.0 way”

The problem of mixing library versions

Usually you wouldn’t mix versions. Build environments like Maven should handle this for you – although even maven can get things wrong.

Yesterday I was playing with Apache TomEE looking at migrating some webapp’s away from Apache Tomcat 7. The impetus for this was to get Rest services working and one of the TomEE profiles supports JAX-RS rest services. Tomcat only supports JAX-WS as thats in Java EE6 Web profile.

Anyhow, with the theory that the webapp’s should just run with minor config changes to the container (declaring datasources, that sort of thing) I installed TomEE and got Netbeans to deploy to it.

Bang!

None of the apps would deploy. They all complained about slf4j missing a method:

java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V
    at org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:133)
    at org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager$1.getConnection(ThreadSafeClientConnManager.java:221)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:401)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)

Now if you ever see this, it’s down to having mixed versions of slf4j in your classpath – and unlike Tomcat, TomEE uses the most recent version of slf4j.

The solution

Many hours later I find this article where someone had a similar problem last year: SLF4J Dependencies and LocationAwareLogger.log Method Not Found Exception.

Now my webapps also use the latest standalone tiles library for layout so after getting maven to show me the dependency tree (mvn dependency:tree) on the webapp it showed that I was pulling in an old slf4j version into the webapp.

So, with a minor change to the pom telling maven to exclude slf4j it finally worked.

Here’s the changes I ended up making to the pom:

<dependency>
  <groupId>org.apache.tiles</groupId>
  <artifactId>tiles-extras</artifactId>
  <!-- needed to exclude slf4j which causes incompatibilities -->
  <exclusions>
    <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-nop</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>jcl-over-slf4j</artifactId>
    </exclusion>
  </exclusions>
</dependency>

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <scope>provided</scope>
</dependency>

The first dependency is for tiles. The <version/> element is missing as I declare that in the project’s root pom and ensures all webapps use the same version.

The important bit is the <exclusions/> element, here we tell maven to exclude those artifacts from the war. There’s one or more <exclusion/> elements which contain just the <groupId/> and <artifactId/> elements – no <version/> here.

The second dependency is for slf4j. It’s here to allow any code provided by the war to have access to it. Again <version/> is missing as its in the root pom but we provide a <scope/> of provided. This tells maven it can use it for compiling but does not include it in the war.

Finally in the project’s other modules I just make sure that any pom with a reference to slf4j is also declared as provided so they don’t cause maven to include it either.

That’s about it. It only took me about 4 hours of hunting around to find the underlying cause. In the Windows world this is known as DLL Hell – well it can happen to any OS/Environment & it is hell when it strikes.

Notes:

  • If you use another logging library within your webapp then that shouldn’t be affected. log4j should just work, this problem appears just to be for slf4j.
  • If you use apache commons logging then you can declare that as provided if you wanted. This is because TomEE provides it at the container level as well as slf4j.

Setting up a Weather WebCam on Linux

Weather webcams are always popular and it is easy and free to set one up yourself.  This article will show how to setup a simple USB webcam to produce still images and serve them on a local apache webserver.

Continue reading “Setting up a Weather WebCam on Linux”

retep.net short url’s

The bitly.Pro service enables custom domains to be used instead of their own ones like bit.ly or j.mp. For example The Onion uses this to link to their articles with url’s like http://onion.com/9J5ziH

So now you will see short links to the blog using the retep.net domain, i.e. http://retep.net/c1VGQO which points to the blog entry about getting ssh-askpass working on OSX.

Like any bit.ly url, if you are ever unsure about a url, copy it, paste it in a new browser window and add a + to the end, like http://retep.net/c1VGQO+.

Earlier in the month, bit.ly finally got round to my application to try out the beta of their bitly.Pro and I’ve been using it for the last few weeks and it’s working pretty well.

The bitly.Pro service enables custom domains to be used instead of their own ones like bit.ly or j.mp. For example The Onion uses this to link to their articles with url’s like http://onion.com/9J5ziH

So now you will see short links to the blog using the retep.net domain, i.e. http://retep.net/c1VGQO which points to the blog entry about getting ssh-askpass working on OSX.

Like any bit.ly url, if you are ever unsure about a url, copy it, paste it in a new browser window and add a + to the end, like http://retep.net/c1VGQO+. You should then see something like this: