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”
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.
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”